开源大模型推理卷上新高度，GLM-5.3 在英伟达 GB200 上飙出 100 tok/s

大家好，我是 Ai 学习的老章

平时大家聊开源大模型，注意力往往全放在模型参数有多大、榜单刷了多少分上，真到了实际把模型拉出来跑 Agent 的生产环境，很多人立刻傻眼：多轮长会话一挂，并发稍微一拉高，首字延迟（TTFT）直接飙到几秒开外，词间生成卡成 PPT，中间还动不动因为格式解析翻车把 Tool Call 给吃掉

专注分布式 AI 训练的团队 Prime Intellect，刚刚正式上线了他们的重磅生产级推理服务平台 —— Prime Inference，并将底层核心架构与算子全栈开源回馈社区

很多人对 Prime 的印象大概还停留在分布式训练工具箱（prime-rl、verifiers、沙箱环境），没想到他们一直在暗中憋大招，不声不响把开源前沿大模型的生产级推理底座彻底重构了一遍

简介

先搞清楚 Prime 为什么非要自己亲自下场死磕推理底座

按他们的战略构想，想要打造持续自我进化的 Agent 智能栈，只有训练环节是远远不够的，必须形成一个严丝合缝的持续学习飞轮：前沿模型训练出来 → 投入生产环境提供可靠推理 → 在真实世界交互中产生全新体验（Experience Trace）→ 数据清洗回流再喂给下一轮训练

持续学习大回路：训练、推理与经验生成

在正式对外公开发布前，这套系统早已在他们内部高压运转了相当长时间

他们的自研系统每天要硬扛大规模强化学习 Rollout、合成数据生成、系统 Benchmark 评测以及长时间运行的 Coding Agent，仅仅在他们团队内部，单日处理的 Token 吞吐量就已经接近 1 万亿（Trillion）大关，从今年 1 月份起更是在高并发生产环境为大客户稳定提供支撑

这逼得他们必须放弃单纯跑分模式，把所有工程刀刃全部砍向极其苛刻的持续吞吐、模型响应质量以及真实生产 SLA

他们的首个公开端点就是跑在英伟达最新 GB200 NVL72 上的 GLM-5.3

战绩极其亮眼：在 OpenRouter 上排在同类 GLM-5.3 端点最快梯队，长会话工具调用（Tool-call）错误率接近于零，上线以来保持 100% 运行时间无故障

Prime Inference 生产环境解耦架构：网关与模型集群彻底分离

整套基础设施深度融合了 NVIDIA Dynamo、vLLM、Mooncake 以及 FlashInfer，并且把他们在生产中踩坑换来的硬核优化，全部回馈给了上游开源社区

老章把他们这次公布的整套生产级推理底座与关键优化链路梳理了一张全景图，咱们先看明白整体全貌：

Prime Inference 生产级全景架构白板图

下面老章带大家拆解他们为了降延迟、省显存、保稳定，硬生生啃下的六大工程硬骨头

生产级长上下文 Agent 推理面临的真正噩梦

搞过多轮长上下文 Agent 的朋友一定深有感触：这玩意的流量特征和平时打字聊闲天有着本质差别

在典型的 Agent 会话中，单轮往往需要在已经堆叠了 140K Token 的超长上下文历史之上，再追加 6K Token 的新交互内容

在高并发生产环境下，集群面临的是冰火两重天的极端混合流量：一边是大量疯狂复用先前对话历史前缀的老会话，另一边是带着超长、毫无缓存的 Cold Prompt 冷启动新请求

如果老老实实把所有请求扔在同一组 GPU 上跑传统的块状预填充（Chunked Prefill），当长 Prompt 进场计算时，立刻会疯狂抢占 GPU 算力，把同卡上正在吐字的现有会话挤得直接丢帧卡顿

为了在维持每用户每秒 100 输出 Token 的极速交互体验下大幅拉高并发，Prime 团队必须重构整条链路

预填充优化：拓扑选择与调度气泡消除

首先遭重的是 Prefill（预填充）阶段

首字时间（TTFT）不仅包含计算 Prompt 的耗时，还深陷在缓存提取、排队准入、新 Token 计算以及跨卡转移 KV 的重重泥潭之中

1. 彻底实现 Prefill/Decode 物理分离（PD 分离）

他们把 Prefill 计算和 Decode 生成彻底拆分到不同的专属 GPU 组上独立运行

由 NVIDIA Dynamo 负责上层全局路由与分布式编排，底层各节点运行 vLLM，当 Prefill 阶段一算完，立刻通过 NIXL 总线把计算好的 KV Cache 跨卡推送到 Decode 节点上

Chunked Prefill 与 PD 物理分离模式对比

在 Dynamo 的精准协同下，仅仅做完这层物理池解耦，p90 词间延迟在测试中就直接降了将近 40%

2. 拓扑选型深思：为什么锁定 DEP8 架构？

在集群拓扑选型上，他们最终选择了 DEP8：8 个数据并行（Data Parallel）注意力 Rank，搭配组内跨卡共享的专家并行（Expert Parallelism）

在 GLM-5.3 采用的 MLA（Multi-head Latent Attention）缓存布局下，传统的 TEP8 拓扑会把每一个请求的 KV 强行冗余复制到所有 8 个 Rank 上，显存浪费极其惊人；而 DEP8 允许各个 Rank 独立缓存不同请求的历史前缀

即便扣除模型权重额外占用的少许显存，在相同硬件规格下，DEP8 实际可用的前缀缓存容量达到了 TEP8 的整整 5 倍左右

当然天下没有免费的午餐，DEP8 的代价在于 DP Rank 之间的同步：每个 Rank 处理不同的请求，但在每个 MoE 层都必须参与全互联通信（all-to-all），跑得快的 Rank 偶尔得跑空转等待同伴

下图展示了 DEP8 单个 Rank 在 Prefill 时的耗时切片，自身 Forward 耗时 408ms，随之伴随大约 245ms 的协同等待：

DEP8 Rank 在预填充阶段的执行耗时与等待拆解 3. 减半 Token 预算，消除调度气泡

在深入 Profiling 时他们抓到了一个幽灵现象：有些请求的 KV 缓存明明早就加载完毕，却迟迟进不了正在运转的 Batch 中

排查发现，Worker 只有在前后两次 Forward Pass 的间隙才检查缓存加载状态，赶巧的请求很容易错过当前周期的调度决策，被迫在批处理队列里原地罚站

遇到高负载时，正在执行的会话把下一个 Prefill Batch 占得满满当当，造成严重的调度气泡（Scheduler Bubble）

他们的破解手段异常干脆：直接把每张 GPU 在每个 Prefill Step 允许处理的 Prompt Token 上限腰斩，从 8K 骤降到 4K

步伐迈小之后，等待中的新会话能够以快得多的频率切入计算批次，排队中位等待时间直接从 550ms 暴跌到 110ms，让中位首字时间（TTFT）大幅缩减了约 20%

预填充 Token 预算减半前后，排队等待延迟从 550ms 暴跌至 110ms 缓存与路由协同：Dynamo 感知路由与 Mooncake 二级缓存

把 Prefill 和 Decode 从物理上拆开之后，调度器怎么分发请求成了决定系统吞吐的核心关键

面对多轮长文本 Agent 请求，如果每次把会话随机乱扔给 Worker，刚算好的前缀缓存根本复用不上

Prime 团队在这里构建了三重极其关键的缓存与路由协同机制：

1. Dynamo 的 KV 前缀感知路由（KV-aware Router）

NVIDIA Dynamo 的路由器在分发新请求到 Prefill Worker 时，会综合权衡两件事：

• 前缀重合度 ：目标节点显存里已经命中了当前 Prompt 的多少历史前缀

• 排队负载 ：该节点当前的待处理工作队列有多长

各个 Worker 实时向路由器上报并发布自身的缓存状态更新，让路由器时刻掌握全集群的前缀分布地图，在缓存命中收益与排队等待成本之间找到最佳平衡点

2. 会话粘性绑定（Session Pinning）

为了让生成阶段也能充分享受 KV 复用红利，他们让同一个 Agent 会话在不同轮次交互中，尽量锁定在同一个 Decoder 上，避免生成端频繁重新搬运 KV

3. Mooncake 主机内存二级缓存（Host DRAM Cache）

当并发持续冲高、GPU 显存告急时，传统方案只能把超出的前缀无情踢出，下次再来时只能打落牙齿重新计算

他们引入了 Mooncake 作为第二级缓存层，把被挤出 GPU 显存的前缀数据转存（Offload）到服务器主机内存（Host DRAM）中

后续轮次一旦命中，直接从主机内存拉取回显存，开销远比从头重新算一遍 Prompt 划算得多，极大地延长了 Agent 会话历史的留存窗口

Dynamo KV 感知路由权衡与 Mooncake 主机内存二级缓存架构 解码优化：NVFP4 显存压缩与手写原生算子

到了 Decode 吐字阶段，挑战完全转移到了显存容量与访存带宽上

在目标吞吐下，TP4（Tensor Parallelism 4）在所有测试拓扑中拿到了最低的词间延迟，但 TP 的硬伤是每个 GPU 必须持有一份完整的 KV 副本，显存空间极其紧张

1. NVFP4 显存无损压缩

为了把更多并发塞进显卡，他们对 512 维的 MLA latent 施加了 NVFP4 深度压缩：每个数值仅用 4 个 bit，每组 16 个数值共享一个 FP8 缩放尺度，位置分量保持 FP8

算上 Scale 之后，单行 MLA 缓存体积从原来的 576 字节直接压缩到了 352 字节

在保持索引器和状态不变的情况下，单解码节点的总缓存容量直接暴增约 50%，从 109 万 Token 跃升至 163 万 Token

在 GB200 NVL72 上采用 1:4 的 Prefill/Decode 比例时，系统在每用户每秒 100 Token 极速门槛下达到的黄金并发前沿：

GLM-5.3 在 GB200 NVL72 上不同 P/D 配比下的性能 Pareto 前沿 2. 手写原生 Sparse-MLA 解码算子

压缩把容量提上去了，但初期实现却遇到了性能坑：旧方案是在 GPU 显存里先分配一块临时 FP8 Buffer，把压缩数据解包后再调用常规 Attention Kernel

这导致每一层计算都要多进行一轮显存写入和二次读出，访存开销极其难看

于是他们联合英伟达团队直接编写了一个原生的 Sparse-MLA 解码 Kernel，彻底砍掉了中间缓冲区

NVFP4 纯粹作为存储格式，片上 Thread Block 加载到 SM 后当场解包，计算全程维持在 FP16 乘法与 FP32 累加

看这张数据流对比图就能直观感受到两者的差距：

NVFP4 解码算子数据流对比：带临时中间缓冲 vs 原生片上直通算子

在 GB200 的架构细节上，他们更进一步：

• 采用协同线程块集群（Cluster）跨 3 到 8 个 SM 协同分担选中的行，不同 Block 通过分布式共享内存聚合局部结果，连二次 Kernel Launch 都省了

• 三级流水槽（Three-slot Buffer）巧妙将行解包、注意力打分与 Softmax 累加完全重叠，隐藏等待延迟

• 针对短上下文填补 -1 的空槽直接跳过数据加载，避免重复读取无用显存行

在 15 个 Query Token 的典型并发下，优化后的原生算子在 GB200 上耗时仅需 12.0 微秒，远低于原先分步解包的 17.7 微秒与传统 FP8 的 13.7 微秒

单 Query Token 的候选行在 4 个 SM 协同集群下的无缝流水线掩盖设计 连续版本迭代下 NVFP4 解码算子耗时阶梯式下降至 12 微秒

更令人放心的是，他们在长上下文严格评测集上的评测结果证明，NVFP4 压缩没有给模型精度带来可察觉的下降，这项硬核原生算子目前已作为实验性特性正式合并回馈给了 FlashInfer 项目

长文本评测集下 NVFP4 与 FP8 KV 缓存精度毫无衰减 传输优化：BLHNC 内存布局治好 NVLink 碎片病

当把 Prefill 和 Decode 拆开后，另一只拦路虎浮出水面：跨节点转移 KV 缓存的开销

团队在早期测试中惊愕地发现：在跨节点走多节点 NVLink 传输时，首字延迟居然比走 InfiniBand 还要慢上 292ms，天下最快的硬件互联竟然被拖慢了

罪魁祸首是数据传输的极度碎片化

原来经典的 Layer-major 布局（LBHNC）是按层分别存储 Cache 的，当一个 200K 上下文的大请求到达 TP4 解码节点时，跨层提取传输竟然触发了整整 32000 次细碎的小块显卡间拷贝

海量的微型传输描述符瞬间把硬件提交队列撑爆，NVLink 恐怖的带宽还没来得及发力就被调度卡死在起跑线上

他们迅速换装了由 vLLM 社区贡献的 Block-major 内存布局 —— BLHNC

它把同一个 Logical Block 在不同层的数据紧凑排布在连续物理内存中，使得传输引擎能以少量大块内存拷贝替代蚂蚁搬家

按层排布 LBHNC 与按块排布 BLHNC 内存布局在物理排布上的本质差异

实测效果堪称奇迹：在 TP8 测试下，即使把 Block 粒度从 1024 Token 细腻缩小到 64 Token（细粒度更省显存），BLHNC 产生的传输描述符依然从 19559 个暴降至 1940 个（缩减整整 10 倍），平均传输耗时从 146ms 砍到 78ms，直接砍掉约 47% 的通信等待

生产环境绝不能忍的翻车点：Tool Calls 零容忍

跑 Benchmark 只要吐字速度快就容易拿高分，但在真实 Coding Agent 或企业级工作流中，如果模型调工具翻车，一次就会导致整个长任务彻底崩盘

很多开发者都有过切肤之痛：模型莫名其妙调用了一个根本没声明的幻觉工具、漏填必填参数、参数类型把整数写成字符串，甚至在转义代码时把 < 机械翻译成 <，直接破坏代码文件语法

Prime 团队在这次部署中联手英伟达从底层对症下药：

• 向 NVIDIA Dynamo 贡献了专门针对 GLM 格式的 Structural-tag Builder，把工具 Schema 定义在源头转译为严格语法约束规则

• 在 vLLM 解码层集成 xgrammar，在模型生成每个 Token 时进行精准的语法遮罩（Grammar Masking），只要遇到不符合 JSON Schema 或参数约定的非法 Token，直接从概率分布中暴力剔除，从根源堵死格式幻觉

• 修复了此前在解析链路中导致特殊符号被错误转义的深坑

经过这套软硬协同的约束防线加持，GLM-5.3 在持续高并发 Agent 长任务下的工具调用错误率被直接压制到了接近绝对零度

快速上手

Prime Inference 提供了极其简单灵活的接入方式，不仅有开箱即用的命令行工具，还全面拥抱标准 OpenAI API 规范

想在终端快速测试一把的小伙伴，两行命令搞定：

# 安装并登录 Prime 统一工具链
uv tool install prime && prime login


 # 极速发起对话请求
prime inference chat 'z-ai/glm-5.3' "Write a haiku about KV caches."

如果你是在既有项目或代码库中使用，无须修改任何现存 SDK 逻辑，直接给官方 OpenAI Python SDK 换一个 Base URL 即可无缝平替：

import os
from openai import OpenAI

 # 填入申请好的 Prime API Key
client = OpenAI(
    api_key=os.environ.get("PRIME_API_KEY"),
    base_url="xxx"
)

 response = client.chat.completions.create(
    model="z-ai/glm-5.3",
    messages=[
        {"role": "user", "content": "你好，请用简练生动的语言总结什么是 Prefill 和 Decode 解耦"}
    ]
)

 print(response.choices[0].message.content)

国内外的开源推理引擎生态正在从过去单纯拼内核速度的单兵作战阶段，迈入如今系统级、全栈式协同优化的深水区

从硬件拓扑（DEP8 vs TP4）、通信碎片消除（BLHNC）、二级主机内存缓存（Mooncake），再到片上流水线融合算子（FlashInfer NVFP4 Sparse-MLA）和语法受约束解码（xgrammar），每一个点都在老老实实解决真实高并发下的致命工程暗礁

这套方案尤其适合需要跑复杂 Agent、长文本代码编写、高吞吐合成数据以及大并发线上服务的技术团队

大家如果对前沿大模型推理架构、KV 缓存优化或算子编写感兴趣，强烈推荐去深入研读他们的官方技术博文与开源贡献