Prime Intellect 发布推理平台 Prime Inference，已上线 GLM-5.3 端点

Prime Inference：为前沿开放模型提供快速、可靠的服务

Prime 的使命是构建前沿开放模型和开放超级智能栈，以持续改进智能体。我们已提供端到端的后训练基础设施，从 prime-rl 和 verifiers 到沙箱和 RL 环境。但持续学习循环只有在训练好的模型能够服务真实用户、生成新经验，并将这些生产轨迹反馈到训练中时才算完整。

我们很高兴今天发布 Prime Inference。它涵盖无服务器端点和预留容量，并在我们横跨多个数据中心的 GPU 基础设施上提供前沿开源模型的弹性服务。

Prime Inference 最初是我们自己需要的服务平台。早在公开发布之前，它就支撑着大规模 RL 推演、合成数据生成、评估和长时间运行的编码智能体，仅内部每天就处理近一万亿个 token。这种规模推动我们针对持续性能、质量和可靠性进行优化，而不仅仅是基准测试速度。

我们的首个公开部署 GLM-5.3 于 9 月 22 日在 OpenRouter 上线。它目前位列 OpenRouter 上最快的 GLM-5.3 端点之一，工具调用错误率接近零，自上线以来正常运行时间达 100%。

Prime Inference 概览

• 低延迟、实时服务： 我们在 OpenRouter 上的 GLM-5.3 端点持续接受质量评估，从一开始就内置生产级 SLA、安全性和隐私保护。
• 跨数据中心的高端基础设施： Prime 托管的模型目前运行在 NVIDIA Blackwell 上，Vera Rubin 即将推出。
• 正常运行时间： 跨数据中心的自动故障转移可将流量持续导向健康的部署。
• 兼容 OpenAI： 使用 Prime 端点和 API 密钥连接您现有的工具和 SDK。
• 扩展性： 无服务器端点应对可变需求，预留容量支持持续工作负载。
• 成本： 跨模型的统一计费和团队级用量跟踪，让推理支出更易于管理。
• 强大的开源基础设施： 我们的技术栈结合了 NVIDIA Dynamo、vLLM、Mooncake 和 FlashInfer，与 Inferact 和 NVIDIA 密切合作开发，并将改进贡献回上游。

开始使用

或者将任何 OpenAI SDK 指向 https://api.pinference.ai/api/v1。完整 API 参考请参阅文档。

为生产级 SLA 而构建

Prime Inference 将公共 API 与模型集群分离，因此容量可以迁移、故障或扩展，而无需更改客户端端点。

我们的共享断路器让每个网关副本对故障做出一致反应，而基于租约的准入控制可防止过载，并在进程消失时自动恢复容量。

在软件层之下，每个集群都受到持续监控，健康检查一直深入到 NVLink 和 InfiniBand。警报会发送给 24/7 待命的团队，因此 GPU 故障能被快速发现和修复，而不是让服务缓慢降级。而且由于 Prime 保有大量溢出容量，我们可以在需要更多容量时重新路由流量并启动新部署。

这些保障措施共同维持了服务的可用性。接下来的章节将通过我们在 GB200 NVL72 上服务 GLM-5.3 的工作，深入探讨一个生产部署的内部情况。

我们如何服务生产级智能体流量

工作负载

一个典型的 agent 轮次会向 140K token 的提示中增加约 6K token，并复用大部分对话历史。在负载下，这些返回的会话会与带有长且未缓存提示的新请求一起运行。

我们用 SemiAnalysis 的 AgentX 对这一混合负载进行基准测试，它会重放多轮 agent 会话。我们的基准测试框架还会注入带有长提示的冷启动请求。我们测量每用户端到端每秒 token 数（用于交互性）和每 GPU 每秒输出 token 数（用于效率）。

预填充/解码分离

在共享 GPU 上，处理长提示可能会中断现有会话的 token 生成。分块预填充限制了这些中断，但两种工作负载仍会争抢 GPU 时间。

我们在独立的 GPU 组上分别运行预填充和解码。NVIDIA Dynamo 负责路由和编排，而 vLLM 在每个组上运行模型。预填充完成后，解码器通过 NIXL 拉取已计算的 KV，并将请求加入其批次。

借助 Dynamo 协调独立的预填充和解码池，我们在测试中将 p90 令牌间延迟降低了近 40%。

缓存与路由

Dynamo 的 KV 感知路由器会根据预填充工作进程已缓存多少提示以及其队列中有多少工作，来选择预填充工作进程。工作进程会发布缓存更新，以便路由器跟踪前缀在何处可用。我们还会在轮次之间将会话保持在同一个解码器上，以支持 KV 复用。

Mooncake 在主机 DRAM 中提供第二层缓存。从 GPU 内存中卸载的前缀可以被检索，而无需重新计算，从而使我们能够保留更多对话历史。

有了这一架构，我们在 GB200 NVL72 上针对三个目标同时调优 GLM-5.3：交互速度、模型质量和并发性。

性能：GB200 NVL72 上的 GLM-5.3

长上下文 agent 服务既是一个计算问题，也是一个缓存管理问题。因此，性能取决于保留该历史、及时调度新工作，以及在不中断正在进行的生成的情况下移动缓存状态。

我们的交互性目标是每用户每秒 100 个端到端 token。我们针对在该速度下可支持的并发会话数量进行调优。

我们分别优化了这些路径：预填充拓扑和调度以减少首 token 时间；压缩 KV 和融合注意力内核以支持低延迟解码；以及便于传输的缓存布局以减少在工作进程之间移动 KV 的开销。

在 100 tok/s/用户的标准下，1:4 的 P/D 比例服务能力最强：每个预填充组 66 个会话，达到 101 tok/s/用户和每 GPU 100 输出 tok/s。

技术深入探讨

对于想要了解工程细节的读者，本文余下部分将深入介绍每一项优化，随后是我们关于可靠工具调用的工作。

以下各节涵盖我们在拓扑、调度、压缩注意力和 KV 传输方面的工作：

1. 为预填充和解码选择正确的拓扑
2. 减少预填充上的调度器气泡
3. 在 FlashInfer 上进行 NVFP4 KV 压缩
4. 使用 BLHNC 布局在 NVLink 上实现更快的 NIXL 传输

预填充：首 token 时间

首 token 时间不仅取决于对提示词的处理。一个请求可能需要检索缓存历史、等待准入、计算新 token，并将 KV 传输到解码器。我们调查了这条路径上的延迟，从缓存容量和调度开始。

选择正确的拓扑

我们选择了 DEP8：八个数据并行注意力 rank，并在整个组内进行专家并行。DEP8 将请求分配到八个注意力 worker 上，同时在组内共享模型的专家。在我们使用的 MLA 缓存布局下，TEP8 会将每个请求的 KV 复制到全部八个 rank 上，而 DEP8 则让各 rank 缓存不同的请求。即使考虑到这需要额外的权重内存，在相同硬件上，我们的可用前缀缓存容量大约是同拓扑 TEP8 的五倍，TEP8 也经过了基准测试。

DEP8 的缺点是 DP rank 同步：每个 DP rank 处理不同的请求，但在每个 MoE 层都要加入相同的 all-to-all 通信，因此即使某个 rank 空闲，也可能需要运行前向传播以跟上其他 rank。

随着 EP 规模扩大，分发开销会进一步增加。我们发现 1 个 DEP16 比两个 DEP8 组耗时多 17.9%，其中 combine 和 finalization 增长最多。

调度器气泡与 token 预算

缓存容量并不能消除调度延迟。我们发现，一个请求的缓存 KV 可能已经可用，但该请求仍在等待进入运行批次。

Worker 在前向传播之间检查已完成的加载。结果随后经过批处理队列和调度器，此时一个就绪的请求可能错过当前决策，再等待一步。在负载下，已在进行的请求可能填满下一个预填充批次，即使缓存历史已就绪，也会延迟准入。这会产生调度器气泡。

为了减少这个气泡，我们将每个预填充步骤处理的提示词 token 数量减半，从每 GPU 8K 降至 4K。更短的步骤让等待的请求可以更早开始。在我们的配置上，中位队列等待时间从 550ms 降至 110ms，使中位首 token 时间减少了约 20%。

更小的步骤会给长且未缓存的提示词增加开销，但这种权衡适合我们的工作负载，因为大多数轮次都复用了已有的前缀。

解码：NVFP4 KV 压缩

在我们的目标负载下，TP4 在我们测试的配置中给出了最低的 token 间延迟。在相同的 GPU 预算下，我们可以运行更多解码引擎，每个引擎上运行的会话更少。

然而，TP 拓扑在 KV 容量上存在权衡。TP 将模型权重分布到各 GPU 上，但在我们使用的 MLA 缓存布局下，每个 rank 仍然持有请求潜在 KV 的完整副本，因此 TP 会存储 KV 副本，这也增加了 NIXL 从预填充传输到解码的数据量。TP4 存储的 KV 副本比 TP8 少，但每个 GPU 也持有更大份额的模型权重。我们希望保持 TP4 的延迟优势，同时在每个 GPU 可用内存中容纳更多 KV。

DEP 通过将请求分配到不同的注意力等级来避免这种复制，从而提供更多可用的 KV 容量，但在测试时，我们发现 MoE 分发前 DP 等级之间的同步增加了解码延迟。

我们还测试了解码上下文并行（DCP），它将缓存的序列分布到各个等级上，同时为模型保留张量并行。这减少了 KV 重复，但引入了通信来收集查询、合并候选结果并组合部分注意力输出。在稀疏注意力下，每个查询最多读取 2,048 个缓存 token，因此一开始就没有太多注意力工作可以拆分到各个等级上。在我们的测试中，将这项工作分布到各个等级所节省的计算量太少，无法抵消增加的通信开销。因此我们保留了 TP4，并寻找一种方法来容纳更多 KV。

为低延迟解码腾出空间

我们使用 NVFP4 压缩了 512 值的 MLA 潜在表示：每个值四位，每 16 个值一组使用一个 FP8 缩放因子。64 值的位置分量保持 FP8。包括缩放因子在内，每行 MLA 缓存从 576 字节缩小到 352 字节。

在索引器和其他状态不变的情况下，总缓存容量增加了约 50%，在相同内存预算下，每个解码器从 109 万增加到 163 万个缓存 token。

原生 NVFP4 稀疏 MLA 解码内核

我们的第一个实现将选定的行解包到 GPU 内存中的临时 FP8 缓冲区，然后再调用现有的注意力内核。这带来了容量优势，但每一层都要付出转换以及通过 GPU 内存额外写入和读取的代价。

我们构建了一个原生稀疏 MLA 内核来消除该中间缓冲区。它使用稀疏索引器选定的位置，加载压缩后的行，并在注意力需要时在片上解包。NVFP4 是存储格式；注意力计算使用 FP16 操作数和 FP32 累加。

对于每个查询 token，一组协作的线程块划分选定的行。在 GB200 配置中，每个集群跨越三到八个 SM。这些块通过分布式共享内存合并它们的部分结果，无需第二次内核启动。

在每个 SM 内部，不同的 warp 组分别解包行、计算注意力分数和 softmax，并累加输出。

有三项改动特别有用：

• 重叠阶段。 一个三槽缓冲区让一组解包行，而其他组对更早的阶段进行评分和累加，从而减少每组等待数据的时间。
• 根据批次调整集群。 较小的批次可以为每个 token 提供更多 SM，而较大的批次需要较小的集群以适配一次执行波次。在每次启动 20 个查询 token 时，这将内核时间从约 32 μs 减少到 14.8 μs。
• 跳过空槽的加载。 短上下文会在 2,048 位置列表中留下未使用的条目，用 -1 表示。我们最初的处理将这些条目映射到第零行，反复读取不需要的数据。将它们零填充后，在引擎跟踪中，一次 35 token 的注意力启动从约 41 μs 减少到 20.6 μs。

在每次启动 15 个查询 token 的情况下，优化后的 kernel 在 GB200 上耗时约 12.0 μs，而分阶段的 NVFP4 路径为 17.7 μs，FP8 attention 为 13.7 μs。这些是该工作负载下的结果，并非在所有 batch size 下都优于 FP8。

在 32 个并发会话下，attention 约占解码步骤的 8%，因此更大的实际收益来自保留更多 KV。NVFP4 让我们的 KV-cache 容量增加了约 50%，同时在启用 decode prefix caching 的情况下保持了相当的单用户速度。

NVFP4 KV 精度

我们运行了一套严格的评估套件，特别侧重于长上下文任务，以确保 NVFP4 KV 压缩不会降低精度。

我们正将原生 kernel 作为实验性操作贡献给 FlashInfer。

压缩提升了解码容量，但分离式架构引入了另一个瓶颈：如何高效地将 KV 从 prefill 传输到 decode。

KV 传输：降低 NVLink 上的拷贝开销

我们使用 vLLM 的 NIXL connector，让每个 decoder 通过多节点 NVLink 从 prefill worker 拉取 KV。在早期对比中，相对于 InfiniBand，NVLink 配置使首 token 时间增加了约 292 ms。更快的互连并没有转化为更快的服务。

瓶颈在于传输碎片化。在我们分析的路径中，每个传输描述符都变成了一次小的设备到设备拷贝。一个 200K token 的请求到达单个 TP4 rank 时触发了 32K 次拷贝。提交和处理如此多的小操作限制了传输，使我们无法有效利用 NVLink 的带宽。

改变布局以减少碎片化

最初的 layer-major KV 布局 LBHNC 将每一层的 cache 分开存储。因此，跨模型传输一个逻辑块时，需要为其在不同层中的数据分别提供描述符。

增大块大小有所帮助：使用 1,024 token 的块减少了传输描述符的数量。然而，更大的块仍然使数据跨层碎片化，并且可能因在部分填充的块中浪费更多空间而降低 KV-cache 利用率。

随后我们测试了 BLHNC，这是 vLLM 社区最近引入的一种 block-major 布局。它将一个块中来自多个层的数据放在内存中相邻的位置，使 NIXL 能够以更少、更大的拷贝操作传输这些连续区域。我们感谢 vLLM 社区开发并分享这一布局。

在另一项 TP8 对比中，layer-major 布局（LBHNC）使用 1,024 token 的块，而 block-major 布局（BLHNC）使用 64 token 的块。尽管块小了 16 倍，BLHNC 仍将描述符数量从 19,559 减少到约 1,940——约少 10 倍——并将平均传输时间从 146 ms 降低到 78 ms，降幅约 47%。BLHNC 布局让我们能够使用更细粒度的 KV 块，同时降低传输开销。

可靠的工具调用

性能只是生产级 agent 服务的一部分。Agent 还需要可靠的工具调用来读取文件、运行命令和进行编辑。如果模型调用了错误的工具或生成了不可用的参数，agent 就必须重试或停止。

在我们的配置中，Dynamo 将模型生成的工具调用转换为智能体收到的 API 响应。在大规模服务 GLM-5.3 时，我们发现了几个反复出现的故障模式。最初，我们发现系统可能会静默丢弃对未声明工具的调用，并返回正常的停止，使智能体既没有可执行的操作，也没有可恢复的错误。

其他调用存在参数缺失或类型错误，即使客户端明确要求模型遵循工具的输入格式。模型收到了这些定义，但我们的 GLM 服务路径在生成过程中并未强制执行它们。

Dynamo 已经有针对此问题的机制，但缺少对 GLM 格式的结构化标签支持。我们向 Dynamo 贡献了一个结构化标签构建器，将工具定义转换为限制模型可生成的名称和参数的规则。

vLLM 使用 xgrammar 在解码过程中强制执行这些规则，屏蔽会违反工具调用语法的 token。我们还修复了解析过程中引入的错误：诸如 < 这样的字面字符串被转换为 <，改变了代码或文件内容，而一些 schema 引用和可空参数类型被错误解释。

我们测试了最终 API 响应的以下方面：

• 参数类型、必填字段和枚举
• Schema 引用、递归和嵌套 schema
• 流式和非流式响应中的 schema 一致性
• 工具选择行为，包括 auto、required 和 none
• 拒绝格式错误的工具请求

我们维护自己的工具调用测试套件，覆盖这些情况，验证最终 API 响应，并在更新服务栈时检查回归。

通过与 NVIDIA 团队的深度合作和开源上游贡献，Dynamo 在生产环境中的长时间智能体会话中处理工具调用，错误率接近零。

构建于开源之上，与优秀的伙伴同行

我们感谢支撑我们技术栈的开源社区和合作伙伴。

• vLLM 和 Inferact。 我们的技术栈运行在 vLLM 推理引擎上。我们感谢 Inferact 在性能和生产服务方面的深度合作，以及全球 vLLM 贡献者不断推进该引擎的发展。
• NVIDIA Dynamo。 我们 LLM 推理平台之下的操作系统，协调分离式 worker、路由请求和 KV 状态，并将分布式 GPU 集群变成一个具有韧性的服务系统。

路线图

• 批量和异步推理，以更低价格处理大型离线任务。
• 专用和 1 键部署，在您自己的预留容量上，包括来自 Prime 训练运行的微调模型。

我们正在招聘

在排行榜上服务前沿模型，同时支撑我们能构建的最大规模 RL 运行，是当前 AI 中最有趣的系统问题之一。如果你想从事 kernel、分离式服务、KV 缓存系统或全局路由方面的工作，来和我们一起工作吧。