---
title: "GPU 虚拟化：Thunder Compute 企业采购指南"
canonical: https://wavect.io/zh/blog/thunder-compute-gpu-virtualization-series-a/
language: zh
description: "评估 Thunder Compute GPU 虚拟化：比较 GPU 资源池、MIG、vGPU 和直通，计算 ROI，并设计企业试点。"
image: "https://wavect.io/img/blog/headers/header_thunder-compute-gpu-virtualization-series-a.png"
---

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

9 分钟 阅读 · 2026年8月21日 最近审核 2026年8月21日

[**下一篇**](/zh/blog/local-models-vs-apis-break-even-eu-2026/)

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

要点速览

Thunder Compute 完成 1300 万美元 A 轮融资，计划把网络化 GPU 虚拟化部署到企业和云服务商的集群中。其软件把 CUDA 调用转换成网络消息，在 GPU 空闲时解除绑定并重新分配，不要求应用代码随之改变。对于昂贵 GPU 已被预留但负载呈突发性、容量分散在不同团队，或被固定服务器边界困住的组织，这一方案具有商业吸引力。它并不能全面替代 MIG、时间切片 vGPU、GPU 直通、batching 或 autoscaling。采购方应以现有栈为基线，比较每集群小时完成的有效工作、p95 延迟、排队时间、故障恢复、兼容性和隔离性。先用代表性负载做边界明确的试点，只有回收的容量超过运行开销、集成成本和运维风险时才值得采购。

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

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

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

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

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

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

## 什么是 GPU 虚拟化？

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

| 方案 | 共享对象 | 适合场景 | 主要代价 |
| --- | --- | --- | --- |
| PCIe 直通 | 整块 GPU 分配给一台虚拟机 | 追求兼容性和稳定性能 | 空闲时段仍被锁定 |
| NVIDIA MIG | 固定计算与显存分区 | 需要硬件隔离的并行负载 | 固定尺寸可能造成碎片 |
| 时间切片 vGPU | 虚拟机之间共享 GPU 执行时间 | 可容忍调度竞争的交互或混合负载 | 高负载下吞吐和延迟波动 |
| 网络 GPU 资源池 | 跨服务器共享 GPU | 负载突发且容量被服务器边界困住的集群 | 必须测量网络和兼容性开销 |

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

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

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

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

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

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

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

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

### 企业试点评分表

| 指标 | 为什么重要 | 采购信号 |
| --- | --- | --- |
| 每集群小时完成的有效工作 | 直接测量回收容量 | 扣除失败和重试后仍明显提升 |
| 端到端 p95 延迟 | 暴露网络与调度长尾 | 保持在生产 SLO 内 |
| 排队与启动时间 | 判断用户是否更快拿到资源 | 受限负载的等待时间下降 |
| 兼容性通过率 | 发现不支持的 kernel 和工具 | 代表性负载无需隐藏 fallback |
| 恢复时间与故障范围 | 测试基础设施失败 | 影响受控且满足 runbook |
| 每个成功任务的成本 | 合并容量、软件与运维 | 优于现有集群和云替代方案 |

## 最适合网络 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 和时间切片解决的问题，应先用更简单的手段。真正的采购问题是：哪种抽象能在不削弱性能、安全和可运维性的前提下，让每一欧元产出更多成功工作。

## GPU 虚拟化常见问题

### GPU 虚拟化与 GPU 资源池有什么区别？

GPU 虚拟化是工作负载与物理加速器之间的抽象。GPU 资源池是其中一种实现，把多台服务器上的 GPU 作为共享资源提供。

### GPU 虚拟化会提升单卡原始性能吗？

不会。它通过减少空闲和碎片提高集群有效容量。由于网络和调度开销，单个负载可能同样快，也可能更慢。

### Thunder Compute 会替代 NVIDIA MIG 吗？

不一定。MIG 在单块 GPU 上创建隔离分区，Thunder Compute 跨网络汇集 GPU。架构可以同时使用两者。

### 试点最重要的指标是什么？

以每集群小时完成的成功工作为主指标，再用 p95、排队、失败、兼容性、恢复和每成功任务成本设护栏。

### 什么时候不应虚拟化 GPU？

当任务已持续满载、多 GPU 通信主导、长尾延迟极严，或无法在代表性试点中证明隔离和兼容性时，不应增加这一层。

## 你可能也喜欢..

[**本地模型还是 API：计算盈亏平衡点** 优化 GPU 集群前，先判断自有算力是否比托管 API 划算。](/zh/blog/local-models-vs-apis-break-even-eu-2026/) [**Netflix 的 vLLM 与 Triton 推理栈** 了解 batching、routing 与 serving 架构如何改善工作负载层的 GPU 经济性。](/zh/blog/netflix-vllm-triton-inference-stack/)

模型与基础设施

## 继续浏览此集群

模型选择、推理经济性、本地部署、压缩与服务架构。

[从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/)

- [Pika Audio API 价格：SFX 真的便宜 20 倍吗？](/zh/blog/pika-audio-models-api-pricing-2026/)
- [AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价](/zh/blog/airllm-layer-wise-inference-low-vram/)
- [Qwen3.8-27B：自托管电脑操作智能体，截图不出内网](/zh/blog/qwen3-8-27b-self-hosted-computer-use-agents/)
- [Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验](/zh/blog/netflix-vllm-triton-inference-stack/)
- [Transformers.js 浏览器本地 AI：什么时候适合放进产品](/zh/blog/transformers-js-browser-ai-guide/)

只收重要内容

## 关注与你相关的内容

每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

9 分钟 阅读 · 2026年8月21日 最近审核 2026年8月21日

[**下一篇**](/zh/blog/local-models-vs-apis-break-even-eu-2026/)

邮件订阅新文章 ×

×

通过邮件获取新文章

我们发布时给你一封简短邮件。免费，不做跟踪。

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/#organization",
      "@type": [
        "Organization",
        "ProfessionalService",
        "LocalBusiness"
      ],
      "employee": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "founder": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "legalRepresentative": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "name": "Wavect GmbH",
      "subjectOf": {
        "@id": "https://wavect.io/verified-claims.json#dataset",
        "@type": "Dataset",
        "creator": {
          "@id": "https://wavect.io/#organization",
          "@type": [
            "Organization",
            "ProfessionalService",
            "LocalBusiness"
          ]
        },
        "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.",
        "inLanguage": "en",
        "isAccessibleForFree": true,
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "name": "Wavect verified publication claims",
        "url": "https://wavect.io/verified-claims.json"
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/team/kevin-riedl/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Kevin Riedl",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796365",
        "https://www.linkedin.com/in/wsdt",
        "https://github.com/wsdt"
      ],
      "url": "https://wavect.io/team/kevin-riedl/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/team/christof-jori/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Christof Jori",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796367",
        "https://www.linkedin.com/in/jocr77/",
        "https://github.com/jo-chris"
      ],
      "url": "https://wavect.io/team/christof-jori/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/#website",
      "@type": "WebSite",
      "inLanguage": [
        "en",
        "de",
        "es",
        "zh"
      ],
      "name": "Wavect",
      "potentialAction": {
        "@type": "SearchAction",
        "query-input": "required name=search_term_string",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://wavect.io/search/?q={search_term_string}"
        }
      },
      "publisher": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/zh/blog/thunder-compute-gpu-virtualization-series-a/#webpage",
      "@type": "WebPage",
      "dateModified": "2026-08-21",
      "inLanguage": "zh",
      "isPartOf": {
        "@id": "https://wavect.io/#website",
        "@type": "WebSite"
      },
      "lastReviewed": "2026-08-21",
      "url": "https://wavect.io/zh/blog/thunder-compute-gpu-virtualization-series-a/"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "abstract": "Thunder Compute 完成 1300 万美元 A 轮融资，计划把网络化 GPU 虚拟化部署到企业和云服务商的集群中。其软件把 CUDA 调用转换成网络消息，在 GPU 空闲时解除绑定并重新分配，不要求应用代码随之改变。对于昂贵 GPU 已被预留但负载呈突发性、容量分散在不同团队，或被固定服务器边界困住的组织，这一方案具有商业吸引力。它并不能全面替代 MIG、时间切片 vGPU、GPU 直通、batching 或 autoscaling。采购方应以现有栈为基线，比较每集群小时完成的有效工作、p95 延迟、排队时间、故障恢复、兼容性和隔离性。先用代表性负载做边界明确的试点，只有回收的容量超过运行开销、集成成本和运维风险时才值得采购。",
  "articleBody": " 博客概览/AI 与智能体/模型与基础设施 Thunder Compute 获 1300 万美元融资：企业 GPU 虚拟化采购指南 要点速览 Thunder Compute 完成 1300 万美元 A 轮融资，计划把网络化 GPU 虚拟化部署到企业和云服务商的集群中。其软件把 CUDA 调用转换成网络消息，在 GPU 空闲时解除绑定并重新分配，不要求应用代码随之改变。对于昂贵 GPU 已被预留但负载呈突发性、容量分散在不同团队，或被固定服务器边界困住的组织，这一方案具有商业吸引力。它并不能全面替代 MIG、时间切片 vGPU、GPU 直通、batching 或 autoscaling。采购方应以现有栈为基线，比较每集群小时完成的有效工作、p95 延迟、排队时间、故障恢复、兼容性和隔离性。先用代表性负载做边界明确的试点，只有回收的容量超过运行开销、集成成本和运维风险时才值得采购。 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。不同方法分别改善资源分配、可迁移性或隔离性，同时也会把瓶颈移到不同位置。 方案共享对象适合场景主要代价 PCIe 直通整块 GPU 分配给一台虚拟机追求兼容性和稳定性能空闲时段仍被锁定 NVIDIA MIG固定计算与显存分区需要硬件隔离的并行负载固定尺寸可能造成碎片 时间切片 vGPU虚拟机之间共享 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 混成一个平均数会掩盖结果。 企业试点评分表 指标为什么重要采购信号 每集群小时完成的有效工作直接测量回收容量扣除失败和重试后仍明显提升 端到端 p95 延迟暴露网络与调度长尾保持在生产 SLO 内 排队与启动时间判断用户是否更快拿到资源受限负载的等待时间下降 兼容性通过率发现不支持的 kernel 和工具代表性负载无需隐藏 fallback 恢复时间与故障范围测试基础设施失败影响受控且满足 runbook 每个成功任务的成本合并容量、软件与运维优于现有集群和云替代方案 最适合网络 GPU 虚拟化的场景 开发和研究集群：notebook 与实验在计算和人工思考之间切换。突发性单 GPU 推理：不同服务在不同时间到达峰值。组织资源分散：一个团队的队列空闲，另一个团队仍在等待。已承诺的云容量：企业已经为固定 GPU footprint 付费。智能体 GPU sandbox：短时、I/O 密集会话留下大量可回收空隙。 可能不适合的场景 紧耦合多 GPU 训练：collective communication 和拓扑可能主导性能。持续满载任务：没有多少空闲容量可回收。严格长尾延迟：网络与控制平面波动可能破坏 SLO。硬件特定 profiling：抽象层可能隐藏调优需要的细节。隔离要求不清：必须验证显存清理、身份、网络分段、日志和故障边界。 如何执行企业 GPU 虚拟化试点 先测量两周基线。按负载、GPU 型号、队列、团队和时间分段。选择三类负载。包括最可能受益、延迟敏感以及已知困难的案例，并保留对照组。测试正常和故障路径。测量冷连接、稳定运行、p95、GPU reset、主机丢失、网络降级、取消和数据清理。计算完整运维模型。加入许可证、网络升级、集成、可观测性、值班、安全审查和供应商依赖。测试前确定门槛。写明最低 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 和时间切片解决的问题，应先用更简单的手段。真正的采购问题是：哪种抽象能在不削弱性能、安全和可运维性的前提下，让每一欧元产出更多成功工作。 GPU 虚拟化常见问题 GPU 虚拟化与 GPU 资源池有什么区别？ GPU 虚拟化是工作负载与物理加速器之间的抽象。GPU 资源池是其中一种实现，把多台服务器上的 GPU 作为共享资源提供。 GPU 虚拟化会提升单卡原始性能吗？ 不会。它通过减少空闲和碎片提高集群有效容量。由于网络和调度开销，单个负载可能同样快，也可能更慢。 Thunder Compute 会替代 NVIDIA MIG 吗？ 不一定。MIG 在单块 GPU 上创建隔离分区，Thunder Compute 跨网络汇集 GPU。架构可以同时使用两者。 试点最重要的指标是什么？ 以每集群小时完成的成功工作为主指标，再用 p95、排队、失败、兼容性、恢复和每成功任务成本设护栏。 什么时候不应虚拟化 GPU？ 当任务已持续满载、多 GPU 通信主导、长尾延迟极严，或无法在代表性试点中证明隔离和兼容性时，不应增加这一层。 查看相关服务： RAG 与 AI 架构 看看生产环境中的应用: Twinsoft AI 先做决定: 如何为 MVP 选择技术栈 你可能也喜欢.. 本地模型还是 API：计算盈亏平衡点 优化 GPU 集群前，先判断自有算力是否比托管 API 划算。 Netflix 的 vLLM 与 Triton 推理栈 了解 batching、routing 与 serving 架构如何改善工作负载层的 GPU 经济性。 模型与基础设施 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 从核心文章开始在欧盟自托管 LLM：开放权重模型何时才真正划算 Pika Audio API 价格：SFX 真的便宜 20 倍吗？ AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价 Qwen3.8-27B：自托管电脑操作智能体，截图不出内网 Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验 Transformers.js 浏览器本地 AI：什么时候适合放进产品 集群中的上一篇Pika Audio API 价格：SFX 真的便宜 20 倍吗？集群中的下一篇AirLLM 只用 4GB 显存跑超大模型？逐层推理原理与代价 查看相关服务： AI 咨询 看看生产环境中的应用: Twinsoft AI 先做决定: 如何为 MVP 选择技术栈 只收重要内容 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 Company 电子邮箱 你希望接收哪些内容？ 完整的 Wavect 博客接收六个主题下的每一篇新文章。 仅接收所选主题请在下方选择一个或多个分类。 选择主题 AI 与智能体 产品与 MVP 交付与",
  "articleSection": "工程",
  "author": {
    "@id": "https://wavect.io/team/kevin-riedl/#person",
    "@type": "Person",
    "name": "Kevin Riedl",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q139796365",
      "https://www.linkedin.com/in/wsdt",
      "https://github.com/wsdt"
    ],
    "url": "https://wavect.io/team/kevin-riedl/"
  },
  "citation": [
    {
      "@type": "WebPage",
      "name": "Thunder Compute 融资公告",
      "url": "https://www.thundercompute.com/blog/thunder-compute-series-a"
    },
    {
      "@type": "WebPage",
      "name": "2026 Kubernetes Optimization Report",
      "url": "https://cast.ai/reports/kubernetes-optimization-report/"
    },
    {
      "@type": "WebPage",
      "name": "NVIDIA vGPU 功能文档",
      "url": "https://docs.nvidia.com/knowledge-base/latest/vgpu-features.html"
    },
    {
      "@type": "WebPage",
      "name": "GPU-over-TCP 技术说明",
      "url": "https://www.thundercompute.com/blog/how-thunder-compute-works-gpu-over-tcp"
    },
    {
      "@type": "WebPage",
      "name": "Google Cloud goodput 框架",
      "url": "https://docs.cloud.google.com/architecture/framework/perspectives/ai-ml/performance-optimization"
    }
  ],
  "dateModified": "2026-08-21",
  "datePublished": "2026-08-21",
  "description": "Thunder Compute 完成 1300 万美元 A 轮融资，计划把网络化 GPU 虚拟化部署到企业和云服务商的集群中。其软件把 CUDA 调用转换成网络消息，在 GPU 空闲时解除绑定并重新分配，不要求应用代码随之改变。对于昂贵 GPU 已被预留但负载呈突发性、容量分散在不同团队，或被固定服务器边界困住的组织，这一方案具有商业吸引力。它并不能全面替代 MIG、时间切片 vGPU、GPU 直通、batching 或 autoscaling。采购方应以现有栈为基线，比较每集群小时完成的有效工作、p95 延迟、排队时间、故障恢复、兼容性和隔离性。先用代表性负载做边界明确的试点，只有回收的容量超过运行开销、集成成本和运维风险时才值得采购。",
  "headline": "Thunder Compute 获 1300 万美元融资：企业 GPU 虚拟化采购指南",
  "image": "https://wavect.io/img/blog/headers/header_thunder-compute-gpu-virtualization-series-a.svg",
  "inLanguage": "zh",
  "keywords": "GPU 虚拟化, AI 基础设施",
  "mainEntityOfPage": {
    "@id": "https://wavect.io/zh/blog/thunder-compute-gpu-virtualization-series-a/",
    "@type": "WebPage"
  },
  "publisher": {
    "@id": "https://wavect.io/#organization",
    "@type": [
      "Organization",
      "ProfessionalService",
      "LocalBusiness"
    ]
  },
  "url": "https://wavect.io/zh/blog/thunder-compute-gpu-virtualization-series-a/",
  "wordCount": 439
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/",
      "name": "首页",
      "position": 1
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/overview/",
      "name": "博客概览",
      "position": 2
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/topics/ai-agents/",
      "name": "AI 与智能体",
      "position": 3
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/",
      "name": "模型与基础设施",
      "position": 4
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/thunder-compute-gpu-virtualization-series-a/",
      "name": "GPU 虚拟化：Thunder Compute 企业采购指南 | ",
      "position": 5
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "GPU 虚拟化是工作负载与物理加速器之间的抽象。GPU 资源池是其中一种实现，把多台服务器上的 GPU 作为共享资源提供。"
      },
      "name": "GPU 虚拟化与 GPU 资源池有什么区别？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不会。它通过减少空闲和碎片提高集群有效容量。由于网络和调度开销，单个负载可能同样快，也可能更慢。"
      },
      "name": "GPU 虚拟化会提升单卡原始性能吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不一定。MIG 在单块 GPU 上创建隔离分区，Thunder Compute 跨网络汇集 GPU。架构可以同时使用两者。"
      },
      "name": "Thunder Compute 会替代 NVIDIA MIG 吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "以每集群小时完成的成功工作为主指标，再用 p95、排队、失败、兼容性、恢复和每成功任务成本设护栏。"
      },
      "name": "试点最重要的指标是什么？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "当任务已持续满载、多 GPU 通信主导、长尾延迟极严，或无法在代表性试点中证明隔离和兼容性时，不应增加这一层。"
      },
      "name": "什么时候不应虚拟化 GPU？"
    }
  ]
}
```
