TL博士
一系列经过生产环境测试、影响深远的优化措施已经开发完成。 Novita AI 用于部署基于 SGLANG 的 GLM4-MOE 模型。我们引入了一种 端到端性能优化策略 它解决了整个推理流水线中的瓶颈问题——从内核执行效率到跨节点数据传输调度。通过集成 共享专家融合 和 后缀解码我们观察到关键生产指标显著提升，包括：
- 首次令牌获取时间 (TTFT) 最多可缩短 65%
- 每次输出令牌所需时间 (TPOT) 提高了 22%
在代理编码工作负载下。
所有结果均已验证 TP8 和 FP8 配置下的 H200 集群为在要求苛刻的生产环境中实现最佳吞吐量和低延迟提供了经过实战检验的蓝图。
我们如何为GLM-MoE实施核心生产优化
1. 共享专家融合
这项优化完全归功于Deepseek模型的原始工作。如上图所示，诸如GLM4.7之类的MoE模型会将所有输入词元路由到一个共享专家，同时每个词元还会被单独路由到由模型路由器选择的其自身的前k个路由专家集合。然后，所有专家的输出会被加权并聚合。例如，GLM4.7使用了160个路由专家和一个共享专家，每个词元选择前8个路由专家。在早期的实现中，这两个部分是分开处理的。鉴于它们具有相同的张量形状和计算过程，很自然地可以将它们统一起来，将共享专家合并到路由MoE结构中——从总共161个专家中选择前9个，共享专家始终被分配到第9位。
如新闻稿所述，此优化在 TTFT 和 ITL 方面分别实现了高达 23.7% 和 20.8% 的性能提升。这些提升符合预期，因为在 TP8 和 FP8 配置下（其中中间尺寸仅为 192，对于 H200 硬件而言相对较小），融合操作显著提高了流式多处理器 (SM) 的利用率，并大幅降低了内存 I/O 开销。
2. Qknorm融合
这项迁移基于 Qwen-MOE 的优化。其基本思路很简单。由于这两个算子都执行逐头计算，因此将它们融合到一个内核中是自然而然的。我们的贡献在于调整这个融合内核，使其能够适应 GLM4-MOE 变体的特殊情况，即每个头部只有一半的维度需要旋转。
3. 异步传输
https://github.com/sgl-project/sglang/pull/14782
在采用重叠调度方案的PD解耦场景下，虽然吞吐量可以提升约10%，但TTFT却显著下降。我们观察到，在当前的预填充实现中，数据传输过程会被延迟到下一个批次内核启动之后。对于像GLM4.7这样包含92层的模型，在没有CUDA图的情况下启动内核可能非常耗时（通常需要数百毫秒，甚至超过1秒）。
为了解决这个问题，我们在修改方案中稍微提前了传输步骤，将其安排在相应步骤之后。 GPU 操作已完成。此外，数据传输被放置在单独的线程中。通过谨慎处理潜在的数据竞争问题，它可以在不阻塞主线程的情况下进行。
对于内核启动次数较多的模型，性能提升非常显著。在高负载情况下，这种优化最多可以节省 1 秒的 TTFT，如下所示。
生产基准结果
实施上述方法后，我们观察到 GLM-MOE 模型的性能得到了显著提升，如下面的基准测试结果所示。
基准配置
- 输入长度： 4096
- 输出长度： 1000
- 请求速率： 14 个请求/秒
- 型号： GLM-4.7 FP8 (TP8)
功能验证
这些优化并非实验性质——它们已经在 Novita.ai 的生产推理服务中部署和验证。如果您正在寻找可靠、低延迟的 GLM-MoE 后端以应对实际工作负载，欢迎直接试用。 novita.ai.
后缀解码
代理编码场景（如 Cursor 和 Claude Code）展现出大量的可重用代码模式，从而可以进行有针对性的性能优化，例如后缀解码。
背景：智能体编码中的推理瓶颈
LLM 智能体在代码生成任务中表现出色，但延迟仍然是一个重大挑战。传统的推测解码通过预先预测多个词元来加速推理，但常用方法需要训练额外的草稿模型，从而增加了工程复杂性。
后缀解码的工作原理
后缀解码采用了一种截然不同的方法——它是 完全无模型:
- 不依赖于额外的模型权重
- 利用先前生成的输出序列中的模式来预测即将出现的词元
- 当当前请求的后缀与历史模式匹配时，它会沿着该历史序列继续进行推测。
数据验证：输出模式重复分析
通过分析 22 个 Claude Code 会话（共 17,487 个对话回合），我们发现：
- 39.3% 输出模式重复类似工具调用和响应模式的高频率
- 高度结构化的自主行为诸如“让我……”、“现在让我……”之类的固定短语频繁出现。
为了支持进一步的研究，我们已将 Hugging Face 的评估数据集开源： https://huggingface.co/datasets/novita/agentic_code_dataset_22
性能比较
内置的 MTP 加速功能进一步降低了后缀解码的开销。 TPOT 提高 22% （从 25.13 毫秒降至 19.63 毫秒）：
| 米制 | MTP | 后缀解码 | 更改 |
| 平均TPOT | 25.13毫秒 | 19.63毫秒 | -21.90％ |
| 中位TPOT | 25.95毫秒 | 20.05毫秒 | -22.70％ |
结语
这些优化措施的结合为 SGLANG 部署提供了全面的性能提升：
- 共享专家融合 解决 MoE 模型中的计算效率问题
- QK-Norm-RoPE融合 降低内核启动开销
- 异步传输 优化分散部署中的数据传输
- 后缀解码 利用模式重复进行推测性解码，实现智能编码。
大多数组件已在上游合并或正在进行集成；请随意。 去看一下 ，具体采用了 新加坡语言 回购。
如何重现
这里只显示与性能相关的关键参数。
完整的启动脚本（基线版与优化版）、基准测试框架和性能分析跟踪文件均已发布在我们的 GitHub 上：https://github.com/novitalabs/sglang/tree/glm_suffix.
- 核心优化标志（SGLang 运行时）
--tp-size 8 --kv-cache-dtype fp8_e4m3 --attention-backend fa3 --chunked-prefill-size 16384 --enable-flashinfer-allreduce-fusion --enable-fused-qk-norm-rope --enable-shared-experts-fusion --disaggregation-async-transfer
- 推测性解码配置（代理编码工作负载）
--speculative-algorithm NEXTN --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4
- 后缀解码配置（可选）
--speculative-algorithm SUFFIX --speculative-suffix-cache-max-depth 64 --speculative-suffix-max-spec-factor 1.0 --speculative-suffix-min-token-prob 0.1
案例
Novita AI 是领先的人工智能云平台，为开发者提供易于使用的 API 和价格实惠、可靠的 GPU 用于构建和扩展 AI 应用程序的基础设施。
探索 Novita 的更多内容
订阅即可将最新帖子发送到您的电子邮箱。
