在大多数数据中心里,GPU 的处境像一种昂贵的装饰品。企业为训练和推理任务采购了成批的加速卡,但这些芯片被分配给特定工作负载后,无论是否有计算任务在跑,都会持续占用资源。CPU、存储和内存早已通过虚拟化技术实现了多租户共享,唯独 GPU 长期停留在“一台机器绑定一张卡”的裸金属时代。Thunder Compute 在其官方博客中转述 Cast AI 的 2026 年 Kubernetes 优化报告称,企业 GPU 平均利用率约为 5%。该数字为公司转述口径,公开材料未提供独立验证路径。这意味着大量已付费的算力在机柜里空转,而市场上另一端的 AI 团队却在为获取 GPU 容量支付溢价。

Thunder Compute 试图把虚拟化这层被 CPU 和存储验证过的逻辑搬到 GPU 上。这家总部位于旧金山的公司成立于 2022 年,由 Carl Peterson 和 Brian Model 联合创办。Peterson 此前在 Bain & Company 担任管理顾问,Model 则在 Citadel Securities 做过量化开发。两人瞄准的正是 GPU 无法像网络资源一样被灵活调度的结构性缺口。2026 年 8 月 19 日,公司宣布完成 1300 万美元 A 轮融资,由 Matrix Partners 领投,Y Combinator 和 CEAS Investments 参与。公司博客称,Matrix Partners 此前也领投了种子轮,但公司未披露种子轮金额、时间及参与方,公开材料中亦无独立验证。需要说明的是,InforCapital 网站显示公司成立于 2024 年,并称其融资总额为 1800 万美元,包括 2026 年 1 月的 450 万美元种子轮;这与官方来源的 2022 年成立时间和仅披露 A 轮的口径存在冲突。RecodeX 建议读者以公司官方来源为准,但应知悉该数据冲突尚未解决。

字段 内容
公司 Thunder Compute
轮次 A 轮
金额 1300 万美元
投资方 Matrix Partners(领投)、Y Combinator、CEAS Investments
总部 旧金山,加利福尼亚州
创始人 Carl Peterson、Brian Model
官网 https://thundercompute.com

把 GPU 从“独占设备”改造成“网络资源”

Thunder Compute 的产品逻辑并不复杂:在系统层面插入一层虚拟化软件,把物理 GPU 从工作负载中解耦出来。公司披露,其专有软件将 GPU 视为网络资源,使数据中心内的任何工作负载都可以按需访问算力,而不是被绑定在特定硬件上。这种设计的关键在于“对开发者透明”——虚拟化层运行在工作负载之下,改变的是机器学习代码与物理 GPU 的交互方式,但开发者无需修改现有工作流。上述产品描述均为公司口径,公开材料未提供独立测试或第三方验证。

这个思路与 CPU 虚拟化的历史路径相似。VMware 当年把 x86 服务器从单机单应用的模式中解放出来,让多个虚拟机共享同一台物理机。Thunder Compute 的创始人 Carl Peterson 在官方博客中直接使用了“GPU 的 VMware”这一类比。从技术叙事上看,这比单纯优化某个 AI 框架或特定推理任务的公司更具平台野心。但 GPU 虚拟化的难点也恰恰在这里:CPU 虚拟化经过数十年发展,硬件厂商提供了从指令集到 I/O 的完整支持;而 GPU 的虚拟化至今仍面临显存隔离、任务调度延迟和驱动兼容性等底层约束。创始人 Carl Peterson 在官方博客中声称:“Since then, we have invented cutting-edge virtualization technology for GPUs”,即“我们已经发明了前沿的 GPU 虚拟化技术”。这是创始人博客中的直接引语,属于公司单方面声称,公开材料中没有独立第三方测试或公开基准数据可以验证。

从已披露的信息看,Thunder Compute 至少完成了一件事:它运营着一个自服务云平台。公司披露已有超过 10,000 名用户在该平台上运行过虚拟化 GPU 工作负载,该数字为公司口径,未经独立验证。如果属实,说明其软件在真实负载下已经跑过一定规模。但“用户运行过工作负载”与“企业付费部署”之间仍有距离。公司同时披露,目前有两家企业正在试点其软件,但未公布客户名称、行业或部署规模。这意味着外部无法判断这些试点是生产环境还是测试环境,也无法评估其商业化的真实进度。

5% 利用率背后的产业链约束

Thunder Compute 反复引用的一个数字是企业 GPU 平均利用率约 5%,来源是 Cast AI 的 2026 年 Kubernetes 优化报告。公司未披露该数字的具体计算方法,该报告是否可独立获取,公开材料未说明;公司转述与独立验证之间没有可核验的路径。公司还进一步提出,全球有超过 2000 亿美元的数据中心容量处于闲置状态。这是公司口径,未经独立验证,公司也未披露计算方法。这两个数字构成了 Thunder Compute 商业故事的基础:既然有这么多算力被浪费,那么任何能提升利用率的软件都应该有巨大的市场空间。

但把这两个数字直接等同于 Thunder Compute 的可服务市场,需要打一个折扣。首先,5% 的平均利用率是一个跨行业、跨负载类型的统计值。它包含了那些因为任务调度不饱和、模型开发迭代间歇、以及预留冗余容量而造成的空闲。其中一部分空闲是结构性浪费,可以通过虚拟化来回收;但另一部分空闲是企业为了应对突发流量或保证性能隔离而主动保留的缓冲。后者即使有了虚拟化,企业也未必愿意释放。其次,2000 亿美元的闲置容量是公司口径,来源材料中没有提供该数字的计算方法或第三方验证。编辑无法从现有信息判断这个数字指的是硬件采购成本、数据中心运营成本,还是某种机会成本口径。

更现实的约束来自 GPU 本身的技术特性。与 CPU 不同,GPU 任务往往对显存带宽和计算单元有强绑定需求。一个正在训练的大模型可能需要独占多张 GPU 并通过 NVLink 高速互联,虚拟化层如果不能在显存和通信层面做到足够低的损耗,就难以适用于训练场景。Thunder Compute 的公开材料没有说明其技术主要面向训练还是推理,也没有披露支持哪些 GPU 型号、哪些云环境或本地部署架构。从公司强调“工作负载共享 GPU 资源”和“在现有数据中心部署”来看,其目标场景更可能是推理和中小规模训练任务,而非大规模分布式训练集群。但这只是基于公开表述的推断,公司未明确界定其适用边界。

商业模式:卖软件,而不是卖算力

Thunder Compute 的商业模式是 B2B 软件销售。公司计划与企业合作,在其现有数据中心中部署虚拟化软件,以提高 GPU 利用率。这与许多 GPU 云服务商的路径不同。后者通常自建或租赁 GPU 集群,然后按小时向开发者出售算力。Thunder Compute 也运营自服务云,但公司将其定位为技术验证和产品打磨的手段,最终目标是让企业把软件部署到自己的机房里。上述商业模式为公司披露口径,公开材料未提供已签约客户或收入数据。

这种模式的优点是轻资产、可规模化。如果软件真的能提升现有 GPU 的利用率,企业无需采购新硬件就能获得更多可用算力,ROI 逻辑相对直接。但挑战同样明显:企业 IT 部门对在 GPU 基础设施层引入第三方虚拟化软件会非常谨慎。GPU 驱动、容器运行时、调度器和监控工具之间的兼容性,任何一环出问题都可能导致 AI 工作负载中断。Thunder Compute 需要证明其软件不仅能在自己的云环境里跑通,还能在企业的异构环境中稳定运行。目前两家企业试点的存在说明公司正在朝这个方向推进,但试点数量本身还不足以构成商业验证。

另一个值得注意的点是,Thunder Compute 的 A 轮领投方 Matrix Partners 也是其种子轮的领投方。公司没有披露本轮估值、稀释比例或是否有其他新机构参与。从公开信息看,参与方只有 Matrix Partners、Y Combinator 和 CEAS Investments 三家。Y Combinator 作为早期孵化器的参与方式通常是延续此前轮次的权益,CEAS Investments 的公开信息也较少。这意味着本轮融资的“新钱”主要来自 Matrix Partners 的追加投资,而非新机构的独立判断。这一判断基于公开投资方名单,但公开材料未提供各家机构的出资比例或历史参与记录。

竞争格局:没有直接对手,但替代方案无处不在

来源材料中没有列出 Thunder Compute 的直接竞争对手。这在一定程度上反映了 GPU 虚拟化作为独立软件品类的早期阶段。但这并不意味着公司没有竞争压力。相反,它的替代方案来自多个方向。以下为编辑分析,相关竞争判断需结合后续披露的第三方测试、客户采购和生态合作指标核验。

第一类是 NVIDIA 自身的软件栈。NVIDIA 在 GPU 虚拟化领域有 vGPU 技术,虽然主要面向虚拟桌面和图形工作负载,但在 AI 场景中也在不断扩展。对于许多企业来说,如果 NVIDIA 的官方工具能解决部分利用率问题,引入第三方虚拟化层的意愿就会降低。第二类是 Kubernetes 生态中的调度和共享方案。包括 NVIDIA 的 MIG(多实例 GPU)、各类 GPU 共享插件和调度器,都在尝试从容器层解决 GPU 利用率问题。这些方案虽然不如系统级虚拟化彻底,但部署门槛更低,且与现有云原生工具链集成更紧密。第三类是专门的 GPU 云服务商,如 CoreWeave、Lambda 等,它们通过大规模采购和高效调度来降低单位算力成本。企业如果只是需要更多算力,直接使用这些云服务可能比改造自有数据中心更简单。

编辑分析认为,要验证 Thunder Compute 的竞争位置,需要至少完成以下同口径对比:在相同工作负载下,对比 Thunder Compute 与 NVIDIA vGPU 的性能损耗;在相同 GPU 型号和驱动版本下,对比 Thunder Compute 与 NVIDIA MIG 的显存隔离粒度;在相同 Kubernetes 集群中,对比 Thunder Compute 与 GPU 共享插件的调度延迟。目前公开材料未披露这些指标,因此无法判断 Thunder Compute 在性能、隔离性和兼容性上是否具有可量化的优势。这些信息缺口构成 Thunder Compute 的验证边界。

Thunder Compute 的差异化在于“通用性”和“透明性”。Matrix Partners 的普通合伙人 Ilya Sukhar 在官方博客中表示,很多创业公司专注于优化特定工作负载,而 Thunder Compute 通过通用且透明的方式优化数据中心。这是投资方口径,公开材料未提供独立验证。这个判断如果成立,意味着 Thunder Compute 的护城河在于系统层面的抽象能力,而不是某个垂直场景的深度优化。但“通用”也意味着它需要在足够多的场景中证明自己,否则容易被更聚焦的替代方案逐个击破。

投资逻辑:押注 GPU 虚拟化的“VMware 时刻”

Matrix Partners 对 Thunder Compute 的投资逻辑,可以从其合伙人的公开表态中读出一些线索。Ilya Sukhar 强调了两点:一是团队在问题定义上的前瞻性,二是“时机现在正好”。前者指向 Peterson 和 Model 四年前就开始布局 GPU 虚拟化,后者则与当前 AI 算力短缺的背景相呼应。上述引语来自公司博客,属于投资方口径。

从资本结构看,Matrix Partners 连续两轮领投,说明其在这个项目上投入了较高的信念。这是编辑分析,依据是 Matrix Partners 在种子轮和 A 轮均担任领投方;但公开材料未提供其他投资方参与度的对比数据,因此无法判断这一信念在机构间是否具有普遍性。A 轮 1300 万美元的规模,对于一家要做“GPU 的 VMware”的公司来说并不算大。作为对比,VMware 在 2000 年代初期的融资规模和资源投入远超这个量级。当然,Thunder Compute 不需要像 VMware 那样自建完整的虚拟化生态,它可以依托现有的 Kubernetes 和云原生基础设施。但 1300 万美元能否支撑公司从“自服务云验证”跨越到“企业级软件销售”,仍然是一个待验证的问题。

从已披露的信息看,Thunder Compute 的资金用途是“扩大运营,与企业合作,规模化虚拟化 GPU”。这个表述比较宽泛,没有具体到研发投入、销售团队扩张或客户成功体系的建设。考虑到公司目前只有两家企业试点,销售和交付能力的建设可能比技术研发更紧迫。企业级软件销售周期长、决策链复杂,1300 万美元在旧金山的工程和销售人才成本下,能支撑的跑道有限。

资金用途与待验证假设

公司称本轮资金将用于扩大运营、与企业合作并规模化虚拟化 GPU。从字面上看,这意味着公司需要从“技术验证”阶段过渡到“商业扩张”阶段。但来源材料没有提供具体的招聘计划、市场进入策略或阶段性目标。编辑无法判断这笔钱会在多长时间内花完,也无法评估其对应的商业化里程碑是什么。

Thunder Compute 面临的核心待验证假设有三个。第一,技术假设:其虚拟化软件能否在企业的真实异构环境中稳定运行,并且性能损耗足够低?公司称其技术“对开发者透明”,但透明不等于零损耗。显存隔离、任务切换延迟和驱动兼容性都是潜在的性能瓶颈。第二,商业假设:企业是否愿意为 GPU 虚拟化软件单独付费?如果企业已经通过 Kubernetes 调度或 NVIDIA 官方工具部分解决了利用率问题,Thunder Compute 需要证明其系统级方案能带来足够大的增量收益,才能说服客户引入新的基础设施层。第三,规模假设:超过 10,000 名自服务云用户能否转化为企业级客户?自服务用户通常是个人开发者或小团队,他们的使用行为和企业 IT 部门的采购决策之间存在巨大差异。两家企业试点是积极信号,但距离可重复的销售模式还有相当距离。

从已披露的自服务云用户规模和企业试点数量来看,这意味着 Thunder Compute 已经完成了一定程度的技术验证,但商业验证才刚刚开始。企业客户的付费意愿和续约率尚未披露,因此结论的边界是:公司有技术故事和早期用户基础,但能否成为“GPU 的 VMware”,取决于未来几个季度企业试点的转化情况,而这一点目前无法从公开信息中判断。

风险:客户匿名、数据冲突与生态依赖

Thunder Compute 的公开信息中存在几个值得注意的风险点。首先是客户匿名。公司没有披露两家试点企业的名称,也没有提供任何关于试点规模、行业或部署环境的信息。在 B2B 软件领域,客户名称的缺失会显著降低外部对公司商业进展的可信度。虽然早期试点阶段保密并不罕见,但这也意味着市场无法独立验证公司声称的“企业合作”是否真实存在。

其次是公开数据的不一致。官方新闻稿和公司博客均显示公司成立于 2022 年,但 InforCapital 的数据显示公司成立于 2024 年,且其融资总额和轮次信息与其他来源存在冲突。InforCapital 称公司总共融资 1800 万美元,包括 2026 年 1 月的 450 万美元种子轮和 2026 年 8 月的 1300 万美元 A 轮,而官方来源仅披露了 A 轮。这一冲突目前无法从现有材料中解决,建议读者以官方信息为准,但需注意数据来源为 InforCapital。这种差异可能源于数据平台的记录错误,也可能反映了公司早期融资信息的不透明。无论如何,外部在评估公司历史时需要保持谨慎。

第三是生态依赖风险。Thunder Compute 的软件运行在 NVIDIA GPU 之上,而 NVIDIA 自身也在不断扩展其软件栈。如果 NVIDIA 未来在 GPU 虚拟化或共享调度方面推出更强大的原生功能,Thunder Compute 的独立价值可能被压缩。公司需要在 NVIDIA 生态中找到自己的位置,而不是与之正面竞争。目前公开材料没有说明 Thunder Compute 与 NVIDIA 是否存在合作关系,也没有披露其软件对特定 GPU 型号或驱动版本的依赖程度。

验证边界与可复核指标

本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述,如无另行说明,均是公司、创始人或投资方在现有公开材料中的披露口径;RecodeX未在本次采集材料中找到独立审计或第三方测试结论,因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析,不代表相关结果已经实现。

  • 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果;
  • 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化;
  • 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。

RecodeX 极客视:GPU 虚拟化的故事并不新鲜,但 Thunder Compute 的切入点值得关注——它不是在卖算力,而是在卖“让已有算力更值钱”的软件层。1300 万美元的 A 轮在 AI 基础设施赛道里不算大钱,真正的考验在于:当两家匿名试点企业变成二十家、两百家时,它的虚拟化层能否在 NVIDIA 的生态夹缝中站稳。如果“5% 利用率”这个痛点真的像公司说的那样普遍,那么 Thunder Compute 最大的对手可能不是其他创业公司,而是企业 IT 部门对“再引入一层基础设施”的本能抗拒。

信息来源

本文在采集与核验阶段引用了以下公开来源,按站点去重列出;来源内容归原发布方所有,其口径不代表 RecodeX 的核实结论。