Gimlet Labs：a16z 押注“多硅推理云”，让每段推理各用其芯片 (2026)

原文定位

2026 年 9 月 5 日，a16z.news 刊发了《Investing in Gimlet》，由 Raghu Raghuram、Sarah Wang、Shangda Xu 和 Steph Zhang 联名，主题是 a16z 投资 Gimlet Labs。1

Gimlet Labs 做的是一层推理基础设施：让 GPU、CPU 和面向特定任务的加速器共同处理 AI 工作负载。a16z 的核心判断是，AI 推理的需求增长会把瓶颈推向电力、数据中心和芯片供给，基础设施需要从“尽量使用同一种芯片”转向“让每段工作使用更合适的芯片”。这个判断属于 a16z 的投资论点；Gimlet 的产品能力和性能数字，则来自 Gimlet 及其合作方的公开材料。

先看这笔投资在押什么

Gimlet 官方在 2026 年 9 月 4 日宣布完成 3 亿美元 B 轮融资，由 Andreessen Horowitz 领投，Menlo Ventures、Sapphire Ventures、Arm、M12、Samsung Ventures 等机构参与。官方公告还称，Gimlet 自 3 月完成上一轮融资以来，新增了数十亿美元的合同收入、数吉瓦的数据中心项目储备，并把受管理容量扩展到数百兆瓦。融资额属于已公开的融资事实；收入、项目储备和容量属于公司自述，读者应把它们当作待验证的商业化信号。2

这笔钱所押的对象很具体：Gimlet Cloud 面向 AI agent 提供 serverless inference，让开发者导入已有的 agent pipeline，串联多个模型、搜索和自定义数据源，再由平台处理调度、编排与优化。Gimlet 官网同时列出了 kforge 项目，用多智能体方法从 PyTorch 生成优化后的底层 kernel，支持 CUDA、ROCm 和 Metal。3

因此，Gimlet 的位置介于芯片和 AI 应用之间。它没有把主要价值放在制造一款新芯片，而是试图让已经存在、性能特点各不相同的芯片组成一个可调用的系统。

为什么同一套硬件很难兼顾推理需求

AI 推理包含多种资源需求。一次 agent 任务可能连续调用模型、检索资料、运行工具，还会在不同路径之间分支。Menlo Ventures 对 Gimlet 的投资说明把三类阶段概括得很清楚：prefill 主要受计算能力影响，decode 主要受内存带宽影响，工具调用则更多受网络影响。4

推理阶段	主要瓶颈	更适合承担的任务	需要核对的系统指标
Prefill	计算密集	处理输入上下文，适合高吞吐 GPU	首 token 延迟、批处理吞吐
Decode	内存带宽和逐 token 响应	生成后续 token，适合内存型或低延迟加速器	token 延迟、内存带宽利用率
工具调用	网络往返和控制逻辑	调用搜索、代码执行和外部服务，通常需要 CPU 与网络编排	端到端延迟、失败重试、并发度

这个表格描述的是 Gimlet 与 Menlo 对工作负载的技术解释。它提供了理解产品的框架，不能单独证明某一种硬件在所有模型和流量下都更快。

Gimlet Labs 官方展示的三种推理拆分方式 — Gimlet 官方 Series B 公告展示了三种拆分方式：把 prefill 与 decode 分开，把 speculative decode 交给专用加速器，以及把 decode 内部的 attention 与 FFN 分开。图中方案和性能方向属于 Gimlet 的技术说明。2

Gimlet 怎样把模型和硬件接起来

Gimlet 把这种做法称为 heterogeneous disaggregation，也就是把一个推理工作负载拆成不同部分，再按可用硬件和服务目标重新安排。

第一层是模型和工作负载拆分。Gimlet 官方公告提到，系统会追踪模型、把模型分解成不同部分，并根据工作负载的服务等级目标和可用硬件，把各部分调度到不同加速器上。最容易理解的例子是 prefill/decode disaggregation：计算密集的 prefill 放到一组设备上，内存带宽密集的 decode 放到另一组设备上。2

第二层是运行时编排。Gimlet 在 a16z 原文中的描述是：系统可以把不同模型和工具路由到不同处理器，把 prefill 与 decode 分开，甚至在模型层或操作层切分工作；编译器针对目标硬件优化每一部分，runtime 再协调整个系统。开发者看到的是一套 inference API，底层则处理多种硬件、网络、功耗和散热条件。1

第三层是数据中心运营。Gimlet 官网把 SLA-aware dynamic datacenter scheduling 列为研究方向，目标是让多阶段 agent 在计算、内存和网络瓶颈不同的情况下，仍然满足性能与成本目标。官网还列出面向异构硬件的 MLIR universal AI compiler，以及混合端侧与云端的工作负载编排。它们目前更适合被理解为公司的产品与研究方向，成熟度需要通过部署结果继续观察。3

“10 倍”应该怎样读

a16z 原文称，Gimlet 已经在相同功耗范围内，让前沿模型获得最高 10 倍的吞吐和交互性提升；这句话是投资方对被投公司能力的概括。1

Gimlet 官方 B 轮公告给出的口径是：对于前沿工作负载，异构拆分可以带来 5—10 倍速度提升，或者在相同延迟下带来相近幅度的吞吐提升。官方公告把这一比较放在同等功耗范围内，并配了一张吞吐量与交互性图。2

Gimlet Labs 官方展示的吞吐量与交互性比较 — 图表比较了 homogeneous 与四种 heterogeneous disaggregation 方案在标准化 token 吞吐量和交互性上的曲线。图表来自 Gimlet 官方 B 轮公告；它展示的是公司选定的比较条件，读者需要进一步核对模型、批大小、硬件组合和基线。2

d-Matrix 与 Gimlet 在 2026 年 3 月的合作公告，则把“10 倍”限定为相对 GPU-only 部署，在延迟和每瓦吞吐量上比较双方组合方案。公告还说，双方计划在 2026 年下半年通过 Gimlet Cloud 向部分客户提供组合方案。这个数字来自硬件厂商与 Gimlet 的联合材料，适合说明产品的目标场景，暂时不适合推导成所有推理任务的普遍收益。5

三组说法可以放在一起理解：a16z 用“最高 10 倍”概括投资判断，Gimlet 用“5—10 倍”描述自己的前沿工作负载结果，d-Matrix 用“相对 GPU-only”说明一次具体合作口径。它们的基线、硬件、模型和工作负载并不完全相同，比较时需要保留这些条件。

这对创业者意味着什么

Gimlet 的机会来自一个变化：AI 应用的性能问题开始同时跨越模型、编译器、调度器、网络和数据中心。过去，应用团队可以围绕单一 GPU 供应商优化一套部署；当 agent 任务把多轮推理、检索和工具调用串在一起后，单一硬件的平均效率就未必代表整条链路的效率。

创业者评估这类基础设施时，可以先核对四件事：

性能收益是否跨真实工作负载成立。 需要看到不同模型、上下文长度、并发量和 agent 路径下的端到端数据，而不是只看某个阶段的峰值。
系统承担了多少运营复杂度。 多种芯片意味着不同的编译器、驱动、网络、功耗和散热条件。产品若只把 API 做得简单，却把排障和容量管理留给客户，部署成本仍然会落在客户团队身上。
客户购买的到底是什么。 Gimlet 同时描述了自有 Gimlet Cloud 和部署到客户数据中心的软件形态。创业者需要问清楚，价格按 token、容量、延迟目标还是托管服务计算，以及硬件采购由谁负责。2
结果责任由谁承担。 当一次 agent 任务跨过多个模型、芯片和外部工具，团队需要知道哪一段导致延迟、错误或成本超标。可观测性、重试策略和故障归因会决定这层基础设施能否进入生产环境。

这四个问题也划出了产品边界。若团队只能展示“同一模型在一块芯片上跑得更快”，产品更接近单点优化；若团队能持续管理跨硬件、跨阶段的端到端结果，产品才更接近 AI 时代的基础设施层。

结论与观察边界

可以独立核验的事实是：Gimlet 官方在 9 月 4 日公布了由 a16z 领投的 3 亿美元 B 轮融资，并公开介绍了 Gimlet Cloud、异构推理、编译器和数据中心调度方向。2 3

属于 a16z 及 Gimlet 的判断是：随着推理需求增长，异构硬件会比单一芯片堆叠更有效；Gimlet 的软件和数据中心系统可以把这种异构性转化为更高的吞吐、更低的延迟和更多的有效算力。性能数字已经有公司和合作方的公开口径，统一、可复现、跨工作负载的第三方基准仍值得关注。

接下来最有信息量的观察点有三个：Gimlet 在 2026 年下半年向部分客户提供的 d-Matrix 组合方案能否公开端到端结果；公司宣称的数百兆瓦受管理容量能否转化为持续收入和可验证的服务质量；以及客户数据中心部署后，异构系统的故障定位和成本管理是否足够简单。对创业者来说，真正值得跟踪的数字不是单次演示里的峰值，而是单位功耗下持续交付的 token、延迟和客户结果。

阅读 a16z.news 原文《Investing in Gimlet》