Thunder Compute 获 1300 万美元融资：企业 GPU 虚拟化采购指南

Thunder Compute 于 2026 年 8 月 19 日完成 1300 万美元 A 轮融资，计划把已服务超过 10,000 名用户的自有云 GPU 虚拟化技术部署到企业与云服务商的集群中。本轮由 Matrix Partners 领投，Y Combinator 和 CEAS Investments 参投。这些事实来自 Thunder Compute 融资公告。对基础设施采购者而言，更难的问题是：网络化 GPU 资源池回收的有效容量，能否超过延迟、集成工作和运维风险带来的成本？

简短答案：当负载具有突发性、GPU 被固定在某台服务器或某个团队名下，而且调度器无法回收空闲时段时，GPU 虚拟化可以减少被困住的容量。它不会创造额外算力，只会改变谁能在何时访问哪块物理 GPU，以及资源能被切分到多细。正确方案取决于负载形态、隔离、显存、网络和延迟要求。

本文只负责 GPU 虚拟化和 GPU 资源池的采购意图。我们的本地模型与 API 盈亏平衡计算器先回答企业是否应该拥有推理算力。如果你已经拥有或预留了一批 GPU，本文帮助判断虚拟化能否让这批资产更高效。

Thunder Compute 的 A 轮融资为何值得关注

融资是市场信号，不是“所有 GPU 都应虚拟化”的证明。资金将支持产品从供应商完全控制的云走向现有企业环境，这也提高了证据门槛。云产品可以控制硬件、网络和负载边界，企业产品则必须适配 Kubernetes、Slurm、虚拟机、裸金属、安全分区、变更窗口和供应商从未见过的负载。

利用率问题确实存在，但百分比必须放进语境。CAST AI 在其数据集中测得平均 GPU 利用率为 5%，样本来自 AWS、Azure 和 Google Cloud 上数万个尚未优化的 Kubernetes 集群。其定义是 24 小时内产生有效输出的已配置 GPU 计算周期占比。同一份 2026 Kubernetes Optimization Report 也记录了一个包含 136 块 H200、平均利用率 49% 的集群。这一差距说明运维方法重要，但不能证明每个企业集群都只有 5%，更不能证明虚拟化能单独解决问题。

什么是 GPU 虚拟化？

GPU 虚拟化把工作负载看到的加速器与真正执行任务的物理 GPU 分开。抽象层可以把整块 GPU 分配给虚拟机，把一块 GPU 切成隔离实例，在租户之间分配执行时间，或通过网络暴露远端 GPU。不同方法分别改善资源分配、可迁移性或隔离性，同时也会把瓶颈移到不同位置。

这些方案可以组合。NVIDIA 将时间切片 vGPU 定义为时间维度的资源分配，而 MIG 创建拥有独立计算与显存资源的空间隔离实例。MIG-backed vGPU 还能结合两者。NVIDIA vGPU 功能文档清楚列出了隔离、调度和平台支持的差异。

Thunder Compute 的网络 GPU 资源池如何工作

Thunder Compute 表示，其虚拟化层位于 CUDA 边界。工作负载发出普通 CUDA 调用，软件把调用转换成网络消息，发送给数据中心网络中的远端 GPU。负载活跃使用时独占整块卡，进程退出或闲置后，GPU 可以解除绑定并分配给另一个负载。

Thunder 报告称，在其自有云中，首次连接大约需要 10 到 20 毫秒，同一批 GPU 可服务约 1.8 倍用户。该公司同时承认，少数边缘负载可能比原生执行慢约 2 倍。这是供应商数据，并非独立基准。它指向正确的采购标准：衡量整个集群完成的有效业务工作，不要只看单个 kernel 的速度。其 GPU-over-TCP 技术说明解释了架构与限制。

GPU 虚拟化 ROI：计算回收容量，不做利用率表演

利用率曲线更高，不一定代表商业结果更好。GPU duty cycle 可能上升，但有效吞吐、延迟或可靠性反而下降。Google 建议用 scheduling goodput、runtime goodput 和 program goodput 评估 AI 基础设施，分别衡量资源是否可用、有效步骤是否完成，以及程序提取了多少硬件性能。这个 Google Cloud goodput 框架比单一平均利用率更适合作为试点基础。

每月虚拟化价值 = 避免新增的 GPU 容量 + 新增有效集群小时 + 缩短排队带来的价值，再减去软件、网络、集成和运维成本。

设置基线组和实验组。两组都要记录成功 job 或 request、已配置加速器小时、有效工作小时、排队时间、p50 和 p95 延迟、失败、重试、能源以及工程师工时。按负载类型归一化。把训练、交互推理和开发 notebook 混成一个平均数会掩盖结果。

企业试点评分表

最适合网络 GPU 虚拟化的场景

• 开发和研究集群：notebook 与实验在计算和人工思考之间切换。
• 突发性单 GPU 推理：不同服务在不同时间到达峰值。
• 组织资源分散：一个团队的队列空闲，另一个团队仍在等待。
• 已承诺的云容量：企业已经为固定 GPU footprint 付费。
• 智能体 GPU sandbox：短时、I/O 密集会话留下大量可回收空隙。

可能不适合的场景

• 紧耦合多 GPU 训练：collective communication 和拓扑可能主导性能。
• 持续满载任务：没有多少空闲容量可回收。
• 严格长尾延迟：网络与控制平面波动可能破坏 SLO。
• 硬件特定 profiling：抽象层可能隐藏调优需要的细节。
• 隔离要求不清：必须验证显存清理、身份、网络分段、日志和故障边界。

如何执行企业 GPU 虚拟化试点

1. 先测量两周基线。按负载、GPU 型号、队列、团队和时间分段。
2. 选择三类负载。包括最可能受益、延迟敏感以及已知困难的案例，并保留对照组。
3. 测试正常和故障路径。测量冷连接、稳定运行、p95、GPU reset、主机丢失、网络降级、取消和数据清理。
4. 计算完整运维模型。加入许可证、网络升级、集成、可观测性、值班、安全审查和供应商依赖。
5. 测试前确定门槛。写明最低 goodput 增益、最大延迟退化、兼容性和回收期。

向 Thunder Compute 或其他供应商提出的问题

• 支持哪些 CUDA 版本、GPU、驱动、框架、自定义 kernel 和 profiler？
• 容量提升来自哪些负载 trace，未虚拟化基线是什么？
• 不同负载的 p50、p95 和 p99 如何变化？
• GPU、主机、交换机或控制平面失败时，运行中的 job 会怎样？
• 显存如何清理，租户隔离有哪些证据？
• 产品补充还是替代 Kubernetes、Slurm、MIG 和现有 quota？
• 客户能否导出指标、策略和负载映射，退出路径是什么？
• 定价按 GPU、主机、回收容量还是用量计算？

结论：虚拟化能扩大有效供给，但只有真实负载能证明

Thunder Compute 正在解决一个有价值的层：被负载、服务器和组织边界困住的容量。A 轮融资给了它在自有云之外证明模式的资源，但不会把利用率差距自动变成客户 ROI。

对于预留具有突发性、队列很长的集群，网络 GPU 资源池值得做受控试点。对于已满载的多 GPU 训练、严格长尾延迟，或可以通过 batching、autoscaling、MIG 和时间切片解决的问题，应先用更简单的手段。真正的采购问题是：哪种抽象能在不削弱性能、安全和可运维性的前提下，让每一欧元产出更多成功工作。