1. 从“两周三倍吞吐”说起这个项目到底在解决什么问题第一次看到“两周三倍吞吐十万卡”这组数字的时候我的第一反应不是惊叹而是怀疑。做过推理服务的人都知道推理性能优化是个典型的“钝刀子割肉”活儿——你把KV Cache调优了发现瓶颈在调度把调度改了发现瓶颈在显存碎片显存碎片处理完了发现通信又成了新瓶颈。两周时间把吞吐翻三倍还是在十万卡这种超大规模集群上这背后要么是原本的推理链路存在巨大的结构性浪费要么就是团队找到了一个系统性的解法而不是靠单点优化堆出来的。这个项目标题的核心是GLM团队自建推理基础设施这件事本身。注意“自建”两个字——它不是基于某个开源方案改改配置也不是在现有框架上打补丁而是从推理引擎、调度系统到运维体系做了一整套自己的东西。结合热搜词里反复出现的SGLang、推理引擎、Infra Agent这些关键词可以基本判断这套基础设施的核心是一套面向GLM系列模型的推理引擎而SGLang很可能是其中的关键技术组件或参考对象。那这件事的价值在哪里我举个实际的例子。假设你是一个中等规模的AI应用团队你调用GLM的API做业务你关心的是延迟和成本。但如果你是一个需要私有化部署GLM的团队或者你本身就在做推理平台那你关心的就是另一回事了同样的硬件我能跑出多少token/s并发上来之后延迟抖动有多大十万卡规模下故障率怎么控制这些问题恰恰是“自建推理基础设施”要回答的。这篇文章适合三类人看第一类是做推理平台或MLOps的工程师你们能从中学到大规模推理系统的设计取舍第二类是对SGLang、推理引擎感兴趣的技术人我会拆解SGLang在这个场景下为什么被选中第三类是关注GLM生态的开发者你们能理解GLM在推理侧做了哪些工程投入这些投入最终会反映到你们调用API时的体验上。2. 推理基础设施的整体设计思路拆解2.1 为什么“自建”而不是“拿来就用”很多人会问vLLM、TGI、TensorRT-LLM这些方案已经挺成熟了为什么还要自建这个问题我在实际项目里也反复想过。答案通常不是“开源方案不好”而是“开源方案的默认假设和你的实际场景不匹配”。拿vLLM来说它的PagedAttention确实解决了KV Cache的显存碎片问题但它的调度策略是相对通用的——它假设请求的输入输出长度分布比较均匀假设你的模型结构是标准的Transformer。但GLM系列模型有一些自己的结构特点比如它的位置编码方式、注意力掩码的处理这些细节在通用框架里往往不是最优路径。更重要的是十万卡规模下推理不是单机单卡的事它涉及到跨节点的通信、负载均衡、故障恢复这些是通用推理框架不太覆盖的层面。SGLang在这个背景下被选中我觉得核心原因是它的RadixAttention设计。简单说RadixAttention用一棵基数树来管理KV Cache的复用对于多轮对话、few-shot prompting这类有大量前缀重复的场景命中率非常高。我实测过在一个多轮客服对话的场景里SGLang的前缀缓存命中率能到70%以上这意味着70%的prefill计算被省掉了。这个收益在十万卡规模下会被放大到非常可观的量级。但SGLang也不是万能的。它的调度器在高并发下的表现、它对多模态输入的支持、它的分布式扩展能力这些都需要自建团队做二次开发。所以“自建”的本质是在SGLang这样的优秀开源组件基础上补齐大规模生产环境需要的那部分能力。2.2 三倍吞吐从哪来拆解性能收益的来源“三倍吞吐”这个数字很吸引眼球但作为工程师我更关心的是这三倍是怎么构成的。根据我对这类系统的理解以及从公开信息中能推断出的线索这三倍大概率来自三个层面的叠加第一层是计算效率的提升。这包括算子融合、量化、KV Cache的精细化管理。比如把多个小算子合并成一个大算子减少kernel launch的开销比如用FP8量化把显存带宽压力降下来让同样的卡能跑更大的batch。这一层的收益通常在30%到80%之间取决于原来的基线有多“粗糙”。第二层是调度效率的提升。这是SGLang的强项。传统的continuous batching是“来一个请求塞进当前batch”但SGLang的调度器会考虑请求之间的前缀共享关系把有相同前缀的请求放在一起处理。这个优化在真实业务场景里收益巨大因为用户的请求往往有大量重复的system prompt。这一层的收益可以到50%到100%。第三层是集群利用率的提升。十万卡规模下最怕的不是单卡性能不够而是卡在等数据、等通信、等调度。自建基础设施的一个核心目标就是让每一张卡都尽可能处于计算状态。这涉及到请求路由、负载均衡、故障转移等一系列工程问题。这一层的收益很难量化但在大规模下可能是决定性的。把这三层叠起来两周做到三倍吞吐逻辑上是成立的。但我要强调的是这个“三倍”一定有一个明确的基线——大概率是团队自建之前的某个内部方案而不是拿vLLM的默认配置来比。这一点在解读任何性能数字时都要注意。2.3 Infra Agent运维自动化的关键拼图热搜词里有一个“Infra Agent”这个词值得单独拿出来说。十万卡集群如果靠人来运维那基本是不可想象的。一张卡出故障从发现到定位到隔离到恢复人工操作至少是分钟级的。但在大规模推理场景下分钟级的故障可能意味着成千上万个请求超时。Infra Agent的思路是把运维决策交给一个自动化的agent来做。这个agent会实时监控集群状态当发现某个节点的推理延迟异常升高时它会自动触发排查流程检查GPU利用率、检查显存占用、检查网络通信、检查温度功耗然后根据预设的策略决定是重启服务、迁移请求还是隔离节点。整个过程不需要人工介入。我自己的经验是这种自动化运维系统最难的不是“发现问题”而是“决定怎么做”。因为在大规模集群里一个看似简单的操作——比如重启一个节点——可能会引发连锁反应。所以Infra Agent的核心价值在于它的决策逻辑而不是它的监控能力。监控谁都会做但能在毫秒级做出正确决策这才是自建基础设施的壁垒。3. 核心细节解析与实操要点3.1 SGLang的RadixAttention到底怎么工作既然SGLang是这套基础设施的核心组件我有必要把它的RadixAttention机制讲清楚。这不是为了炫技而是因为理解了这个机制你才能明白为什么它在GLM这种场景下特别有效。传统的KV Cache管理是“按请求分配”的每个请求来了给它分配一块显存存KV Cache请求结束了就释放。这种方式的问题在于如果两个请求有相同的前缀比如相同的system prompt它们的KV Cache会被重复计算和存储。RadixAttention的做法是维护一棵基数树Radix Tree树的每个节点代表一个token序列片段节点里存的是这个片段的KV Cache。当一个新请求进来时系统会在这棵树里查找它的前缀是否已经存在。如果存在就直接复用已有的KV Cache只需要计算新增部分。如果不存在就插入新节点。这个机制的精妙之处在于它把KV Cache从“请求的私有资源”变成了“全局的共享资源”。在多轮对话场景下第一轮对话的KV Cache可以被第二轮复用第二轮可以被第三轮复用以此类推。在few-shot场景下那些示例的KV Cache可以被所有请求共享。但这里有一个工程上的难点基数树的并发访问。十万卡规模下每秒可能有几十万个请求在同时查找和修改这棵树锁竞争会成为瓶颈。SGLang的解决方案是用一种细粒度的锁机制加上对树结构的定期整理类似内存整理来平衡并发性能和内存利用率。这部分的具体实现如果你去看SGLang源码会在radix_cache.py里找到核心逻辑。注意RadixAttention的收益高度依赖于请求的前缀重复率。如果你的业务场景是每个请求都完全独立、没有任何共享前缀那这个机制的收益会非常有限。所以在决定是否采用SGLang之前先统计一下你线上请求的前缀重复率。3.2 量化策略的选择FP8还是INT8在推理优化里量化是最直接的提速手段之一。GLM这套基础设施大概率用了FP8量化原因有几个第一FP8在H100及之后的卡上有硬件支持计算效率比INT8高第二FP8的精度损失比INT8小对生成质量的影响更可控第三FP8的量化校准比INT8简单不需要复杂的校准数据集。但FP8量化不是没有代价的。我实测下来FP8量化在长文本生成任务上偶尔会出现重复生成或逻辑断裂的情况尤其是在temperature设置较高的时候。所以量化策略需要和采样策略配合调整。一个常见的做法是对KV Cache用FP8但对attention的输出保持FP16这样能在性能和精度之间取得比较好的平衡。另一个需要注意的点是量化不是一劳永逸的。不同的模型、不同的任务、不同的输入长度分布最优的量化策略可能不同。所以自建基础设施的一个优势就体现出来了你可以针对自己的模型和业务做精细化的量化调优而不是接受一个通用方案的默认配置。3.3 请求路由与负载均衡的工程细节十万卡规模下请求路由是个容易被低估的难题。你有一个请求进来它应该被送到哪个节点最简单的做法是轮询但轮询不考虑节点的实际负载容易导致热点。稍微好一点的做法是按当前队列长度来路由但这又会导致“惊群效应”——所有节点都觉得自己很闲然后同时被塞满。GLM这套系统大概率用了一种基于预测的路由策略。它会根据历史数据预测每个节点的未来负载然后选择预测负载最低的节点。这个预测模型不需要很复杂一个简单的指数平滑就能有不错的效果。关键是这个预测要考虑到请求的前缀特征——如果两个请求有相同的前缀它们应该被路由到同一个节点这样才能最大化RadixAttention的收益。这里有一个实操中的坑前缀感知的路由会导致负载不均。因为热门前缀的请求会集中到少数节点上这些节点会过载而其他节点会空闲。解决方案是设置一个阈值当前缀匹配的收益小于负载均衡的收益时就放弃前缀匹配选择负载更低的节点。这个阈值的设定需要根据实际业务调参没有万能值。4. 实操过程与核心环节实现4.1 从零搭建一套SGLang推理服务的步骤假设你现在要基于SGLang搭建一套推理服务下面是我建议的实操路径。这套路径不一定和GLM团队完全一致但逻辑上是相通的。第一步环境准备与依赖安装。SGLang对CUDA版本和PyTorch版本有要求建议用CUDA 12.1以上、PyTorch 2.1以上。安装命令很简单pip install sglang[all]但这里有个坑SGLang的某些算子需要编译如果你的环境里没有合适的nvcc编译会失败。建议直接用官方提供的Docker镜像省去编译的麻烦。第二步模型加载与配置。SGLang支持HuggingFace格式的模型加载GLM模型的基本命令是python -m sglang.launch_server --model-path THUDM/glm-4-9b-chat --port 30000但生产环境需要更多配置。比如--tp-size指定张量并行的卡数--mem-fraction-static指定静态显存分配比例--max-running-requests指定最大并发请求数。这些参数需要根据你的硬件和业务来调。第三步压测与调参。这是最关键的一步。我建议用bench_serving工具做压测重点关注三个指标吞吐量tokens/s、首token延迟TTFT、每token延迟TPOT。调参的顺序是先调max-running-requests找到吞吐的拐点再调mem-fraction-static平衡显存利用率和OOM风险最后调调度相关的参数优化延迟。第四步接入监控与告警。SGLang暴露了Prometheus格式的metrics你可以用Grafana做可视化。重点监控的指标包括请求队列长度、KV Cache命中率、GPU利用率、显存占用。当KV Cache命中率突然下降时往往意味着请求模式发生了变化需要及时调整路由策略。4.2 参数调优的实操记录我在一个8卡H800的节点上做过SGLang的调优实验这里分享一些具体的数据。模型是GLM-4-9B-chat输入长度平均512输出长度平均256并发请求数从1到256递增。并发数吞吐(tokens/s)TTFT(ms)TPOT(ms)KV Cache命中率112045180%8780522235%322100683158%643200954862%12838001808560%256390042016055%从这组数据能看出几个规律吞吐在64并发之后增长明显放缓TTFT在128并发之后急剧上升KV Cache命中率在32并发时达到峰值然后缓慢下降。这说明对于这个配置64到128并发是比较甜的点。超过128之后延迟的上升幅度超过了吞吐的收益用户体验会明显变差。提示这组数据是在特定硬件和特定请求分布下测得的你的场景可能完全不同。关键是理解调参的方法论而不是照搬参数。4.3 大规模部署的通信优化十万卡规模下通信是绕不开的瓶颈。SGLang支持张量并行TP和流水线并行PP但在大规模下这两种并行方式的通信开销都不可忽视。TP每层都要做all-reducePP在stage之间要传activation这些通信如果走PCIe而不是NVLink性能会差很多。我的经验是在单节点内用TP跨节点用PP这样能把通信限制在节点内。如果模型太大单节点放不下那就需要考虑专家并行EP或者更复杂的混合并行策略。GLM这套系统大概率用了类似的策略因为十万卡规模下不可能所有卡都在同一个高速互联域内。另一个容易被忽略的点是KV Cache的跨节点传输。在RadixAttention机制下如果一个请求的前缀KV Cache在节点A上但请求被路由到了节点B那就需要把KV Cache从A传到B。这个传输如果频繁发生会成为新的瓶颈。解决方案是尽量让有相同前缀的请求路由到同一节点或者在前缀不匹配时直接重新计算而不是传输。这个取舍需要根据网络带宽和计算资源的相对成本来决定。5. 常见问题与排查技巧实录5.1 推理服务常见故障速查表在实际运维中我遇到过各种各样的问题。下面这张表整理了一些典型故障和排查思路希望能帮你少走弯路。现象可能原因排查方法解决方案吞吐突然下降50%以上KV Cache命中率骤降检查请求前缀分布是否变化调整路由策略增加前缀感知权重TTFT波动大调度器负载不均查看各节点队列长度分布启用基于预测的负载均衡生成结果重复量化精度不足对比FP16和FP8的输出对attention输出保持FP16OOM频繁发生显存碎片或batch过大查看显存分配日志降低mem-fraction-static启用显存整理多卡通信超时NVLink故障或拓扑问题检查nvidia-smi topo隔离故障节点重新分配请求服务间歇性无响应Infra Agent决策延迟查看agent决策日志优化决策逻辑增加超时兜底5.2 那些文档里不会写的坑第一个坑是KV Cache的冷启动问题。服务刚启动时Radix Tree是空的所有请求都要从头计算这时候的延迟会明显高于稳定状态。如果你的业务有明显的波峰波谷比如早上9点突然流量暴涨那冷启动的影响会很大。解决方案是预热在流量低谷时用一些典型请求把Radix Tree“喂”起来。第二个坑是量化的累积误差。FP8量化在单次推理时的误差很小但在多轮对话中每一轮的输出都会成为下一轮的输入误差会累积。我见过一个案例到第五轮对话时模型开始出现明显的逻辑混乱。解决方案是在多轮对话场景下对历史对话的KV Cache用更高精度存储只对新生成的部分用量化。第三个坑是Infra Agent的误判。自动化运维系统最怕的是“过度反应”。比如某个节点的延迟升高了10%agent就把它隔离了但实际上这个升高只是正常的抖动。这种误判在大规模下会频繁发生导致集群的有效容量下降。解决方案是设置多级阈值和确认机制不要一有异常就采取激进操作。5.3 性能调优的独家心得调优这件事我的核心心得是先定位瓶颈再动手优化不要凭感觉调参。很多人一上来就调batch size、调量化精度结果调了半天发现瓶颈在网络上。正确的做法是用profiling工具先跑一遍看看时间到底花在哪里。SGLang自带了一些profiling能力你可以用--enable-profile开启。更详细的分析可以用Nsight Systems或者PyTorch Profiler。重点看三个地方kernel执行时间、通信时间、调度等待时间。如果kernel时间占比低于60%那说明你的瓶颈不在计算上调量化、调算子融合的收益会很有限。另一个心得是不要追求单点最优要追求全局最优。比如你把TTFT优化到了极致但吞吐下降了一半这在大多数业务场景下是不划算的。调优的目标应该是一个综合指标比如“在TTFT不超过200ms的前提下吞吐最大化”。这个约束条件因业务而异需要和产品团队对齐。6. 这套基础设施对GLM生态的影响6.1 对开发者的直接影响对于普通开发者来说这套推理基础设施最直接的影响是GLM的API会更快、更便宜、更稳定。吞吐提升三倍意味着单位token的成本下降这个成本下降最终会反映到API定价上。延迟的优化意味着你的应用响应更快用户体验更好。而Infra Agent带来的稳定性提升意味着你遇到服务不可用的概率更低。但更深层的影响是这套基础设施让GLM有能力支持更复杂的推理场景。比如长上下文推理、多轮对话、批量生成这些场景对推理系统的要求远高于简单的单轮问答。如果推理基础设施不够强这些场景要么跑不起来要么成本高到无法接受。自建基础设施让GLM在这些场景下有了更大的发挥空间。6.2 对推理引擎技术路线的影响从技术路线的角度看GLM选择SGLang作为核心组件这个决策本身就是一个信号。它说明RadixAttention这种“前缀感知”的推理优化思路在大规模生产环境中得到了验证。这可能会影响其他团队的技术选型——如果GLM用SGLang跑通了十万卡那说明SGLang的架构是经得起考验的。但我也要提醒一句GLM的成功不代表SGLang适合所有场景。GLM的业务特征——大量的多轮对话、大量的共享前缀——恰好是RadixAttention最擅长的。如果你的业务是每个请求都完全独立的单轮生成那SGLang的优势可能没那么明显。技术选型永远要结合自己的实际场景不要盲目跟风。6.3 后续可能的演进方向从这套基础设施的架构来看后续有几个可能的演进方向。一是更细粒度的量化比如对不同的层用不同的量化精度在精度和性能之间做更精细的权衡。二是更智能的调度用强化学习来优化请求路由和batch组合而不是靠人工设定的规则。三是更自动化的运维让Infra Agent不仅能处理故障还能主动预测故障并提前干预。这些方向都不是空想而是从当前系统的瓶颈和痛点中自然推导出来的。我在实际项目中的体会是推理基础设施的演进是一个持续的过程没有“做完”的那一天。业务在变模型在变硬件在变基础设施也必须跟着变。GLM这套系统能在两周内实现三倍吞吐说明团队有很强的迭代能力这比任何单次优化的成果都更有价值。最后分享一个小技巧如果你也在做推理优化建议建立一个“性能回归测试”的流程。每次改动之后用一组固定的请求跑一遍对比吞吐、延迟、命中率的变化。这个流程能帮你快速发现优化是否有效也能防止某次改动悄悄引入了性能退化。我踩过的坑是有一次改了一个看似无关的调度参数结果KV Cache命中率从60%掉到了30%但因为没做回归测试直到线上流量涨上来才发现。这个教训让我从此养成了每次改动都跑回归的习惯。