内部每天烧近万亿 token 的推理系统对外开放了：Prime Inference 首个端点给了 GLM-5.3

TL;DR

10 月 2 日，Prime Intellect 正式发布推理平台 Prime Inference：serverless 端点 + 预留容量、跨数据中心自动容灾、OpenAI 兼容 API（api.pinference.ai），首个公开端点是在 OpenRouter 上已经跑了两周的 GLM-5.3——官方称其工具调用错误率近零、上线以来 100% 在线率。这套系统不是 demo：Prime 内部拿它跑 RL rollout、合成数据和长跑编码智能体，日均处理近 1 万亿 token。对用开源模型跑生产负载的团队，这篇发布里最值钱的不是"又一个推理 API"，而是智能体负载怎么优化的完整技术账。

导语：训练-服务的最后一环接上了

先看一家公司的动作顺序，再看懂这次发布。

Prime Intellect 这两年的路径是：prime-rl（RL 训练框架）→ verifiers（验证器）→ 沙箱与 RL 环境——后训练的基础设施一路铺齐。但 10 月 2 日的公告里，官方把话挑明了：持续学习的闭环缺一环——训好的模型要能服务真实用户、生成新经验、再把生产轨迹回流到训练里。推理服务就是缺的那一环，所以 Prime Inference 上线了。

这套系统对 Prime 自己一点不新鲜：内部跑 RL rollout、合成数据生成、模型评测、长时间运行的编码智能体，每天处理的 token 量接近 1 万亿；对外服务客户的生产部署从今年 1 月就开始了。换句话说，这次不是"我们做了个推理平台"，而是"我们把自家吃饭的家伙开放出来了"——这个出身决定了它整个技术栈的口味：不追榜单峰值，追持续负载下的稳。

想直接用？

智能体流量长什么样？为什么普通推理栈扛不住

Prime 贴了一张典型的智能体负载画像：一轮对话在 140K token 的提示上只新增约 6K token——也就是说，绝大部分计算是在反复"回忆"会话历史。这类流量和新来的长提示请求混跑，把普通推理栈的两个短板全暴露了：长提示的 prefill 会打断正在生成的会话，缓存装不下这么多的历史前缀。

Prime 的答案是四个字：分而治之。prefill（处理提示）和 decode（生成 token）跑在独立的 GPU 组上，NVIDIA Dynamo 负责路由编排，prefill 算完的 KV 缓存通过 NIXL 传给 decode 侧。测试结果：p90 帧间延迟（衡量"打字卡不卡"的核心指标）降了近 40%。

Prime Inference 生产服务架构：公共 API 与模型机群分离

图：API 层与机群层解耦——容量可以迁移、故障、扩缩，客户端端点不变（来源：官方博客）

缓存问题则分三层打。拓扑上选 DEP8（8 路数据并行注意力），同样的显存比备选方案多出约 5 倍可用前缀缓存；调度上把单步 prefill 的 token 预算从 8K 砍到 4K，让排队请求更早进场——中位排队等待从 550ms 降到 110ms，首 token 时间约降 20%；传输上 vLLM 社区的 BLHNC 块主布局把 KV 传输描述符从 19,559 个压到约 1,940 个，传输时间 146ms → 78ms，砍掉 47%。

KV 感知路由 + Mooncake 主存缓存：按缓存命中与排队负载权衡调度

图：Dynamo 的 KV 感知路由器按"前缀缓存命中量 vs 排队工作量"选 prefill 节点，Mooncake 在 GPU 显存外提供第二级缓存（来源：官方博客）

两个硬核数字：NVFP4 压缩与 66 路并发

技术细节里有两个数字最值得单独说。

第一个是显存的魔法。 Prime 把 GLM-5.3 的 MLA 缓存潜向量压成 NVFP4（每值 4 bit + 每 16 值一个 FP8 缩放因子），缓存行从 576 字节缩到 352 字节——同样显存，每个 decoder 的缓存容量从 109 万 token 提到 163 万，提升 50%。压这么狠精度不崩吗？官方跑了以长上下文为主的评测套件验证无回退，而且为此写了个原生 sparse-MLA 内核（跳过中间缓冲区、片上解压，15 token/launch 时 12.0μs），内核会贡献给 FlashInfer。缓存容量为什么是命门？回到上面的负载画像：智能体的每一轮都在靠缓存历史活命，缓存多 50%，能留住的"记忆"就多一半。

第二个是并发密度的账。 以"每用户 100 token/秒"的交互门槛为目标，GB200 NVL72 上调出的 1:4 P/D 配比能做到单个 prefill 组服务 66 个并发会话（实测 101 tok/s/用户，同时每 GPU 100 输出 token/秒）。这是"持续性能"路线的成绩单——不冲单请求极限，冲单位硬件能养活多少个稳定会话。

GLM-5.3 on GB200 NVL72：不同 P/D 配比下的性能前沿

图：100 tok/s/用户门槛下，1:4 配比的可服务并发数最多（来源：官方博客）

Agent 团队该划的重点：工具调用可靠性

如果你在跑生产 Agent，这次发布里和你最相关的段落可能是工具调用。

Prime 在大规模服务 GLM-5.3 时发现了几类反复出现的故障：模型调用了未声明的工具，系统静默丢弃后正常返回——Agent 拿不到动作也拿不到报错，只能干瞪眼；还有参数缺失、类型错误，即便客户端明确要求遵守 schema，生成路径也没强制。这些名字你可能耳熟——它们和 ThinkingBox 这类基准测出来的"八成失败是工具处理问题"完全对得上。评测侧在查账，供给侧在还债。

Prime 的解法是约束解码：给 NVIDIA Dynamo 贡献了一个 structural-tag builder，把工具定义翻译成生成约束，vLLM 侧用 xgrammar 在解码时直接屏蔽违规 token——模型想生成不合法的函数名或参数都生成不出来。顺带修了 < 被错误反转义、schema 引用解析错等一串 bug，并配了覆盖流式/非流式、auto/required/none 等场景的自有测试套件。最终成绩：长跑智能体会话中工具调用错误率近零。

再把账本摊开看整体：GLM-5.3 端点 9 月 22 日先上 OpenRouter 试水，官方称已是该平台上最快的 GLM-5.3 端点之一、上线以来 100% 在线率。路线图上还有批量/异步推理和自有容量上的一键部署（包括把 Prime 训练产出的微调模型直接部署上线）——训练、服务、部署的闭环已经画到了纸面上。

把话说明白：性能数字全部来自官方自测（跑分框架 AgentX 是 SemiAnalysis 的，数字是 Prime 自己跑的），"最快之一"的"之一"请保留；内部万亿 token 的口径也有第三方写成 600B/日，引用时以官方表述为准。但方向是清楚的：推理供给的竞争正在从"榜单速度"转向"智能体负载的持续可靠性"——缓存、调度、约束解码这些原本散在论文里的词，正在变成生产标配。你下一个 Agent 项目的推理选型，值得把这张清单拿出来对照打分。

参考来源

posted @ 2026-10-05 08:42  Lusca2026  阅读(11)  评论(0)    收藏  举报