快手万擎大模型推理成本和性能优化实践

大模型能力快速提升之后，真正决定其能否规模化落地的，不再只是模型参数和榜单分数，而是推理系统能否在高并发、长上下文和复杂 Agent 场景下，持续提供低延时、低成本、稳定可靠的 Token 服务。对线上业务而言，推理优化不是单纯“把模型跑快”，而是在模型能力基本不损失的前提下，同时压低单位 Token 成本、提升吞吐、保障 TTFT/TPOT 等服务体验指标。本文将以 GLM-5.2、DeepSeek-V4 等模型的推理优化实践为例，介绍快手万擎在并行策略、PD 分离、KV cache、投机解码和调度系统上的全链路优化方法。

一、推理优化：大模型规模化落地的关键

随着大模型从能力验证走向规模化应用，系统关注点已从“能否完成任务”转向“能否稳定、低成本地服务真实业务”。训练决定能力上限，推理则直接影响吞吐、时延和单位调用成本，是模型能力转化为产品价值的关键。

不同于可复制、分发和缓存的传统互联网内容，大模型每次请求都需持续计算并占用 GPU。Agent 多轮规划与工具调用、百万级长上下文及长推理输出，进一步放大了 Token 消耗，使成本、吞吐和时延成为规模化落地的主要约束。

为此，推理优化需在保持模型能力的同时，降低单位 Token 成本、提升有限算力下的吞吐，并稳定满足 TTFT、TPOT 等指标。快手系统软件围绕 GLM-5.2、DeepSeek-V4 等新一代模型，从并行执行、算子与通信、KV Cache、量化、调度及弹性服务等方面开展全链路优化，构建高性价比推理方案。

二、不以模型能力损失为代价做优化

推理服务的价值不能只看 Token 单价。过度量化、精度裁剪或推理参数调整，虽然能够降低成本，却可能损害复杂推理、工具调用和长上下文能力。因此，我们关注的不是绝对低价，而是在模型能力基本保持的前提下，降低单位 Token 成本。

作为快手技术商业化品牌，StreamLake 是“快手万擎”大模型平台对外提供推理服务的官方 Provider。本文介绍的推理引擎kLLM，包含并行执行、PD 弹性、分级 KV cache、算子与编译等能力，是支撑其高性能、低成本推理服务的底层系统能力。

OpenRouter AutoExacto Benchmark 的 Provider 级能力对比，为截图时点的32日滚动均值，新版本TAU-Bench 预计提升较大，数据Update之后会更好。数据来源：OpenRouter

计入 Prompt Cache 后的实际 Token 价格为截图时点的30日滚动均值。数据来源：OpenRouter

如图所示，在 OpenRouter 的同模型 Provider 对比中，StreamLake 的 GPQA Diamond 和 TAU-Bench Airline 表现与模型官方及其他头部 Provider 处于相近水平；与此同时，在计入 Prompt Cache 后，StreamLake 仍保持具有竞争力的实际 Token 价格。公开结果表明，我们并非通过牺牲模型能力换取低价，而是通过系统级推理优化实现能力与成本的兼顾。

三、模型结构演进与推理挑战

以 GLM-5.2 和 DeepSeek-V4 为代表的新一代大模型，并非单纯扩大参数规模，而是在巨量参数与稀疏激活、稀疏/压缩注意力、百万级上下文三个方向同步演进。模型结构在降低理论计算与存储成本的同时，也改变了推理系统的执行形态。

新一代模型结构演进与推理系统挑战

从系统视角看，这些结构演进并不是简单地减少推理开销，而是在降低模型侧理论成本的同时，重新分配了计算、通信、显存和调度压力。具体而言：

首先，巨量参数与稀疏激活使模型能够通过更大的总参数量提升容量，同时将单 Token 激活参数控制在较小比例。但动态专家路由也引入了专家负载不均、小矩阵计算和跨卡 All-to-All 通信。

其次，稀疏注意力与百万上下文降低了长序列 Attention 的理论计算成本，但超长上下文仍会显著放大长 Prefill、KV cache 容量、不规则访存和数据搬运压力。

由此带来的推理挑战是：模型侧降本并不等于系统侧同比提效。推理瓶颈已经从单一算力问题，转化为计算、通信、显存与调度相互耦合的系统问题。系统既要提升吞吐和资源利用率，又要满足 TTFT、TPOT 和尾延迟等服务目标，最终将模型结构的理论收益转化为真实的吞吐、时延与单 Token 成本收益。

四、核心技术全景图

过去两年，快手系统软件团队集中建设推理引擎kLLM，将多年沉淀的系统级性能优化方法与技术延伸至大模型推理领域。在大模型时代持续追求极致性能优化，致力于为快手万擎打造高性能、低成本、高质量的大模型推理引擎，为行业稳定产出高可用、低延时、高精度的 Token。

系统软件推理引擎kLLM是一个覆盖业务接入、调度、推理引擎、硬件资源全链路的高性能推理平台。其核心引擎层通过 PD/AF 解耦分离、TP/PP/EP/CP 多维并行策略、DeepEP/Mooncake 高效异构通信、FlashAttention-4/FlashInfer 高性能算子、L1 GPU/L2 CPU/L3 Remote 三级 KV cache 体系、FP8/INT8/NVFP4 多精度量化压缩、MTP/EAGLE-3/DSpark 投机解码等关键技术，实现了超长上下文与 MoE 大模型的高吞吐、低延迟、高并发推理；同时通过 SLO 感知调度、Prefix 亲和路由、弹性伸缩、全链路 Metrics/Trace 监控与灰度降级机制保障生产稳定性，并兼容国产 GPU 与网络生态，支撑内外部多业务场景的高效服务。

快手系统软件大模型推理框架kLLM全景架构

五、关键技术攻坚

2025 年 DeepSeek R1 发布时，我们通过自研时分 PD 分离、DeepEP Auto 通信模式（Prefill 采用 Normal、Decode 采用 Low Latency）、无精度损失的 FP8 KV cache 及调度优化等技术，在测试集、机型、Cache 命中率和 TTFT、TPOT 约束严格对齐的条件下，获得了行业极致的Token推理成本。

今年，我们进一步将相关能力扩展到 GLM、DeepSeek、KIMI 等新一代模型，形成覆盖模型适配、推理引擎、分布式执行、缓存与调度的全栈优化能力，并完成多个主流模型的大规模线上部署。下面列举其中几项典型的优化技术。

5.1 MLA + DP Attention：Attention DP 与 MoE EP 的混合并行

5.1.1 从降低单 Token 开销到扩展节点有效 KV 容量

在百万级长上下文场景中，Attention 计算量与 KV Cache 占用会随上下文长度快速增长。GLM-5.2 通过 DSA 从历史上下文中筛选 Top-k Token 参与 Attention，降低计算量；同时利用 MLA 的压缩表示 cKV，减少单 Token 的缓存开销。

然而，DSA 和 MLA 主要优化计算量与单 Token KV 大小，并未解决多卡部署中的状态分布问题。随着上下文和并发持续增长，瓶颈将进一步转向：节点内多张 GPU 的显存能否共同扩展有效 KV 容量。

5.1.2 纯 TP：切分了 Attention 计算，却复制了 cKV

GQA 包含多个独立 KV Head，可沿 Head 维度进行 TP 切分；MLA 的 cKV 则是跨 Head 共享的压缩状态，无法采用相同方式切分。

因此，当 Attention 直接沿用 TP Group 时，各 Rank 虽共同完成计算，却需要处理相同请求并保存相同的 cKV。以 TP=8 为例，同一批请求的 KV Cache 会在节点内复制 8 份。增加 GPU 只能扩展计算能力，无法等比例提升有效 KV 容量。

在长上下文、高并发场景下，即使系统仍有剩余算力，也可能因 KV Cache 空间不足而无法扩大 Batch 或接收新请求。此时，真正的瓶颈已从 Attention 算力转为 TP Group 内重复存储的请求状态。

5.1.3 并行策略重构：Attention 按请求并行，MoE 按专家并行

针对 MLA 与 MoE 不同的结构特征，我们没有将整个模型简单切换为 DP，而是重新划分 Attention 与 MoE 之间的并行边界：

• Attention 采用 Request DP：不同 Rank 处理不同请求，仅保存所属请求的 cKV、Token 历史和索引状态；Attention 阶段不再进行跨 DP Rank 的结果同步。

• MoE 采用 EP：Router 为每个 Token 选择 Top-k Experts，通过 All-to-All Dispatch 将 Token 发送至专家所在 Rank，专家计算完成后再通过 All-to-All Combine 将结果返回原 Request Rank。

• Dense/Shared FFN 按需保留 TP：如果非路由计算仍按模型维度切分，则只在对应子路径执行 Gather/Reduce-Scatter，不与 EP 的 Dispatch/Combine 混为一套通信。

其核心不是选择一种并行方式覆盖整个模型，而是让不同状态遵循各自最合适的分布方式：

MLA 场景下 Attention DP 与 MoE EP 的并行边界重构

Attention 从 TP8 调整为 Request DP8，每张 GPU 只保存所属请求的 cKV；MoE 继续采用 EP8，通过 All-to-All Dispatch/Combine 完成 Token 与专家之间的路由。

5.1.4 收益与边界

在图示 8 卡配置中，DP Attention 使各 GPU 分别保存不同请求的 cKV，节点有效 KV 容量由纯 TP 的2.9M Tokens 提升至 21.2M Tokens，增长约 7.3 倍，平均 TTFT 下降 25%。

优化后，系统瓶颈由 TP Group 内的 KV 复制，转向 Request DP 的负载均衡以及 EP 阶段的专家负载与 All-to-All 通信。因此，DP Attention 更适合长上下文、大 Batch 和 KV 容量受限的高吞吐场景；在小 Batch、低并发下，数据布局转换和 EP 通信的额外开销可能抵消收益，需结合实际负载与集群通信能力选择。

5.2 Ring Attention：将同步聚合改造成分块流水

5.2.1 百万上下文下的 CP 扩展

当上下文长度从 200K 扩展到 1M，KV cache 容量随序列长度线性增长，Prefill 阶段的 Attention 计算和显存压力也快速上升。为支持百万级长上下文，我们首先引入 Context Parallelism（CP），沿序列维度将 Context Token 切分到多个 CP Rank，使每张 GPU 只处理部分 Query，并持有对应的 KV 分片，从而将单卡无法承载的请求扩展到多卡执行。

但序列切分只解决了 KV cache 的基础分布问题。如何让各 Rank 的本地 Query 完成对全部可见 K/V 的 Attention，决定了 CP 的实际显存开销与执行效率。

5.2.2 分块式 Ring Attention 实现

我们在推理引擎的 CP 执行路径中实现了分块式 Ring Attention。对于 CP Rank$i$，本地 Query $Q_i$在整个计算过程中保持不动，本地 KV 分片$K_i,V_i$则与其他 Rank 的 KV Block 一同沿 Ring 拓扑逐跳传递。每一轮中，GPU 使用当前 KV Block 计算一部分 Block Attention，同时异步接收下一轮 KV Block；当前计算结束后，直接切换到已经到达的下一 Block。

经过 N轮后，每个$Q_i$都完成了对全部有效 KV Block 的 Attention，KV 分片也恰好沿 Ring 轮转一周。

Ring Attention 的序列切分与环形计算机制

为了在分块计算下保持与完整 Attention 相同的数值结果，我们使用 Online Softmax 跨轮维护最大值、归一化分母和输出累积状态$(m,\ell,O)$。每处理一个 KV Block，便更新一次局部状态；全部有效 Block 处理完成后，即可得到本地 Query 的最终输出$O_i$，不需要物化完整 Attention Matrix。

5.2.3 与 All-Gather CP 的执行路径对比

原有 All-Gather CP 在每层 Attention 计算前，先将各 Rank 的 KV 分片汇总到每张 GPU。虽然每张 GPU 最终只计算本地 Query 对应的输出，但在该层执行期间仍需要临时物化完整 K/V，并等待 All-Gather 完成后才能启动 Attention。

Ring Attention 改变的不是 Attention 的数学结果，而是 K/V 的组织方式和通信时序：每张 GPU 只保留本地 KV 分片及单块通信缓冲，将一次性的全量同步聚合拆解为连续的分块传输，并与 Block Attention 形成流水。

Ring Attention 在显存节省、通信计算重叠方面相对更有优势，对比如下：

All-Gather CP 与 Ring Attention 执行路径对比

5.2.4 实际收益

我们验证，在相同模型、Batch、CP Degree、KV 精度和硬件配置下，ISL 512K，Ring Attention CP 相比 All-Gather CP吞吐提升16.9%。

5.3 DSpark：从前沿架构到在线收益

5.3.1 主流投机解码架构的性能权衡

投机解码正在从单一的草稿模型竞争，走向草稿生成、目标验证与硬件调度的系统协同。围绕 DeepSeek V4 Flash 的生成时延优化，我们持续跟进 Eagle3、DFlash 和 DSpark 等技术路线，也没有把离线接受率作为唯一选型指标，而是同时考察草稿延迟、接受长度，以及动态负载下的验证成本。

Eagle3 和 DFlash 分别代表自回归与并行草稿的两端：前者依赖建模充分，但草稿成本随推测长度增加；后者一次产生整块候选，延迟更低，但后缀质量容易衰减。DSpark 通过半自回归结构在两者之间建立了新的平衡，并进一步以置信调度控制目标模型的验证开销，更符合长输入在线服务的成本结构。

主流投机解码架构在草稿时延、接受长度和验证开销上的性能特征。位置为定性示意。

5.3.2 从草稿模型到完整解码链路

DSpark 首先通过并行网络一次产生多个位置的 logits，再由轻量序列模块逐位置采样。每个位置在采样前，会根据前一个已采样 token 计算 Bias，并修正当前位置的 logits。串行部分只执行 Bias 修正与采样，不重复完整模型前向，因此能够在保留并行草稿低延迟的同时，缓解后缀质量衰减。

DSpark 半自回归草稿生成示例。并行模块一次生成各位置 logits，轻量序列模块根据上一位置的采样 token 修正当前位置并完成采样。图中分数为示意值。

5.3.3 端到端性能收益

在 DeepSeek V4 Flash 的线上典型场景中，ISL 约为 3K–6K、OSL 约为 0.5K。相较基线，接入 DSpark 后平均 TPOT 降低 15%。

5.4 分级 KV Cache：从容量扩展到高效复用

5.4.1 L1 容量限制与缓存失效

长上下文场景下，KV Cache 随序列长度线性增长，而 GPU 显存还需承载模型权重和运行时状态。仅依赖 L1 时，缓存会因容量不足频繁淘汰，使系统提示词、工具定义和历史对话等重复前缀无法稳定复用，同类请求仍需重新执行 Prefix Prefill。

为延长 Prefix KV 的生命周期并扩大复用范围，我们构建了由 GPU HBM、CPU DRAM 和 SSD/分布式存储组成的三级 KV Cache。

5.4.2 分级缓存、前缀复用与 Cache-Aware 路由

三级缓存承担不同的数据角色：

• L1 · GPU HBM：保存实例内最热的 KV，命中后可直接参与计算；

• L2 · CPU DRAM：承接从 L1 下沉的数据，在实例内提供低延迟回填；

• L3 · SSD/分布式存储：跨实例共享 Prefix KV，并根据容量和系统压力持久化全部数据或高复用前缀。

首次 Prefill 生成的 Prefix KV 由 L1 下沉至 L2/L3，并通过 Cache Event 同步缓存位置。后续同前缀请求由网关结合匹配长度、缓存位置和负载进行 Cache-Aware 路由；命中后将 KV 回填至 L1，仅计算未命中后缀。对于 Chunked Prefill，我们复用上一轮前缀树状态，仅处理新增 Token，避免重复扫描完整前缀。

L1/L2/L3 分级 KV Cache 与跨实例复用机制

5.4.3 分级KV Cache优化效果

从线上生产窗口可以看到，L1 仍然承担主要命中流量；当 L1 因容量压力出现命中率下降时，L2/L3 能够承接被淘汰的 Prefix KV，使总命中率保持相对稳定。图示窗口内，总命中率平均约为 87.6%，其中 L1、L2、L3 的平均命中贡献分别约为 77.5、9.6 和 0.6 个百分点。当然在不同工矿下，提升的比例也会有差别，在我们的典型场景下，L3最高能将命中率提升15PP。有了L3之后，命中率基本能到理论上限。

在相同模型、流量和 SLO 条件下，与仅使用 L1 的基线相比，完整的分级缓存与 Cache-Aware 路由使缓存命中率提升 20 个百分点，SLO 约束下吞吐提升 30% 。

5.4.4 前缀树关键路径优化

在长输入场景下，开启分级 Cache 过程中，我们注意到前缀的相关操作存在严重的性能问题，产生了明显的 GPU Bubble。通过火焰图分析热点，并深入分析前缀树源码，我们发现性能问题的根源在于总是使用全量 token 序列进行前缀匹配以及插入，这种计算方式对于分块请求而言存在相当大的冗余。

例如，对一个全新的请求"这个前缀有点长"需要进行 Prefill，假定 ChunkSize 为 4，则需分成 2 个 Chunk 进行计算：

• 第一轮：匹配前缀，执行 Prefill 并插入前缀树

• 第二轮：再次全量前缀进行匹配，以及全量前缀插入

因此，我们提出了一种基于中间状态缓存的增量前缀匹配/插入优化算法，消除了这部分冗余计算：

5.4.5 前缀复用优化效果

完成优化后，使用相同压测数据集压测，优化前后GPU Bubble从平均 400ms 锐减至 30ms，长请求端到端Prefill性能提升约 40%。

优化前：平均bubble 400 ms

优化后：平均bubble 30 ms

5.5 PD 分离：从固定配比到 SLO 驱动

PD 分离使 Prefill 和 Decode 可以独立配置资源，但在生产环境中，更关键的问题是如何持续维持合理的 P/D 配比。同样的 QPS 下，ISL 变长主要增加 Prefill 压力，OSL 和并发增长则更多消耗 Decode 容量，因此静态 P/D 比例难以适应不断变化的请求形态。

早期的固定 xPyD 服务组虽然简单稳定，但只能整组扩缩，容易出现一侧排队、另一侧空闲；分钟级实例启动又使资源调整难以及时生效。

为此，我们将 PD 系统设计为一个以 TTFT、TPOT SLO 为目标的在线资源控制系统：通过 SLO Load 感知两侧压力，结合 10 秒级实例启动和 P/D 全局资源池，形成动态调整 P/D 容量配比的闭环。

Cache Aware 与负载感知的智能路由

5.5.1 SLO Load：分别度量 P、D 压力

GPU 利用率只能反映设备是否繁忙，无法判断负载是否已经影响用户体验。由于 Prefill 和 Decode 分别主要决定 TTFT 和 TPOT，我们以其相对 SLO 的背离程度统一度量两侧压力。

真实指标能够反映已经发生的性能退化，但存在观测滞后；根据队列积压和实际服务率计算的预测指标能够提前发现拥塞，但可能存在估计误差。为兼顾及时性与可靠性，我们取预测值和真实值的上界：

$Load_P = \frac{\max(TTFT_{pred}, TTFT_{actual})} {TTFT_{target}}$

$Load_D = \frac{\max(TPOT_{pred}, TPOT_{actual})} {TPOT_{target}}$

经过 SLO 归一化后，P、D两侧获得了统一的负载尺度：Load=1表示达到目标边界，Load>1表示对应阶段存在容量压力。

5.5.2 10秒级启动：让扩缩容真正跟得上负载

传统推理实例启动需要依次完成权重加载、JIT 编译、显存初始化和运行时预热，完整冷启动通常达到分钟级。如此长的启动时间无法及时响应流量波动，也限制了 PD 配比调整和故障恢复速度。

我们针对启动关键路径进行了三项优化：

• 通过 RDMA 直接从运行中实例加载模型权重，避免重复从远端存储读取；

• 共享 JIT Cache，复用已经完成的算子编译结果；

• 基于 CUDA VMM 复用显存布局，通过 unmap/remap 减少显存重新分配和初始化。

最终将推理实例启动时间由约 10 分钟降低到 10 秒以内，使 P、D 扩容能够及时作用于当前负载变化。类似的“从运行实例通过 RDMA 分发权重”也已成为社区快速弹性的重要方向，例如 Dynamo ModelExpress 支持从现有 Worker 的 GPU 显存向新 Worker 传输权重 Dynamo Model Caching。

5.5.3 大PD：解除固定组绑定

早期我们采用固定 xPyD 部署：将 x 个 P 实例和 y个 D 实例组成一个服务组，扩缩容也以完整服务组为单位。这种方式拓扑明确、实现简单，但其资源调整粒度与实际负载变化并不匹配——ISL、OSL 和并发变化往往只会首先推高 P 或 D 一侧的压力，而固定 xPyD 无法单独调整其中一侧。例如长输入流量增加时，P 侧已经排队，D 侧仍有空闲，但扩容 P 仍需要同步增加完整的 xPyD 组。

大 PD 架构：从固定 xPyD 服务组到 P/D 全局资源池

为解决这一问题，我们将固定 PD 组升级为大PD架构。P、D 实例分别组成全局 Prefill Pool 和 Decode Pool，并可以独立加入或退出资源池。每个请求不再绑定预先配置的 PD 组，而是由 Global Router 即时选择 P_i 和 D_j，完成请求级动态组对：

• 请求到达后，根据 KV cache-aware 和负载均衡策略选择 P 实例；

• Prefill 完成后，结合 D 侧负载、KV cache 位置和传输成本选择 D 实例；

• P、D 实例的生命周期相互独立，可以根据两侧压力分别扩缩。

大PD使容量调整能够直接作用于瓶颈侧：P 侧压力高时只扩 Prefill Pool，D 侧压力高时只扩 Decode Pool，从而避免非瓶颈侧被同步扩容，并以实例为粒度持续调整 P/D 配比。

5.5.4 最终效果

SLO Load、10 秒级启动和 P/D 全局资源池共同构成 PD 弹性闭环：系统能够识别 P、D 两侧的容量压力，以单实例粒度独立扩缩，并将新增容量在 10 秒内投入服务，相比传统约 10 分钟的实例启动，容量生效速度提升约 60 倍。

OpenRouter 公开监测显示，StreamLake 的 GLM‑5.2 服务近 30 天 Provider Uptime 达到 99% +。

5.6 长请求稳定性优化

前文介绍的 CP 与 Ring Attention，解决了超长上下文“算得动”的问题，使推理引擎具备百万级 Token 上下文处理能力。本节进一步解决“稳定承载”的问题：长输入和长输出请求在实际业务中的占比通常不足 5%，但单个请求消耗的计算时间、KV Cache 和资源驻留时间远高于普通请求，容易将局部阻塞放大为全局排队，显著抬高主流请求的 TTFT。

针对这一问题，我们从引擎和全局调度两个层面建立了长请求调度闭环：实例内避免单个请求长期霸占资源，实例间避免流量继续向过载节点堆积。

KV Events 提供缓存状态，Engine Load 反映实时压力，引擎侧负责公平执行和 KV 高水位保护

5.6.1 长输入引擎调度改造：Chunk Prefill 公平调度

长输入主要通过两条路径影响 TTFT：

• Chunk Prefill 阻塞：长请求被拆成多个 Chunk。若连续执行，后到的短请求需要等待多轮，TTFT 被显著拉高。

• KV 准入阻塞：Decode 实例需要为请求预留 KV 空间。当余量不足时，长请求停在准入阶段，并可能阻塞后续短请求。

我们以 Chunk 为调度粒度，并结合 KV 预算分配执行配额：可在单个 Chunk 内完成的短请求优先执行；长请求在配额耗尽后于 Chunk 边界让出资源，同时保留已经计算完成的前缀 KV。再次获得执行机会时，长请求直接从断点恢复，无需重复计算。

为避免长请求长期得不到执行机会，其恢复配额会随让出次数逐步增加，在保护短请求 TTFT 的同时保证长请求最终完成。

Chunk Prefill 公平调度机制。无公平调度时，长请求 B 连续占用计算资源，短请求 C、D 到第 11 轮才获得执行机会；公平调度基于 KV 预算发放执行配额，并在 Chunk 边界保存前缀 KV、让出资源和断点恢复，使 C、D 在第 2 轮完成，同时通过恢复配额递增避免 B 长期饥饿

优化效果

在现有混合流量测试中，公平调度使平均 TTFT 下降 17.8%，P50 下降 26.0%，P95 下降 12.1%。整体 P99 上升 2.7%，体现了“短请求提前、长请求小幅延后”的公平调度权衡。

公平调度前后的整体 TTFT 分布。平均值、P50、P90 和 P95 分别下降 17.82%、25.96%、14.02% 和 12.10%；P99 上升 2.65%

5.6.2 长输出治理：Decode KV 高水位保护

长输出请求会长期驻留在 Decode 实例，并随着生成过程持续增加 KV 占用。高并发下，少量长输出可能将 KV Cache 推至高水位，使新请求无法准入并引发持续排队。对此，我们采用两层保护：

• 调度侧分流：持续感知 Decode 实例负载，停止向高负载实例继续加压，等待存量请求完成并释放 KV。

• 引擎侧保护：KV 达到高水位时暂停新请求准入；必要时释放循环输出等异常长请求占用的 KV，并将请求重新调度到资源更充足的实例。

通过公平执行、状态感知、负载分流和高水位保护，少量长请求对主流请求 TTFT 与系统稳定性的影响被限制在可控范围内。

六、未来演进

极致的推理优化没有终点。基于现有全链路优化成果，团队将围绕算力效能、国产化适配、智能运维持续攻坚，进一步下压成本、抬升服务上限，构建下一代推理Infra。主要介绍如下四个代表性方向：

6.1 异构 PD 架构升级

现有同构 PD 集群无法精准匹配Prefill密集计算、Decode 高访存迭代的差异化特征，存在算力浪费。后续将落地异构 PD 协同架构：以高性能算力承载 Prefill批 量预处理任务（如国产卡），以大显存高带宽算力承载 Decode 生成任务（如N卡），搭建异构算力统一调度中台，实现流量智能分流与负载均衡。同时优化跨设备通信与动态任务分片能力，适配长短请求与业务峰谷波动。

6.2 Program-Aware 全生命周期调度

把调度单元从"单请求"提升到 Program（一次 agent 会话/工作流），做暂停/恢复调度 + 工具调用空窗资源回收，两者本是同一生命周期的两面，合并落地。核心机制：容量紧张时"最短程序优先"驱逐、全局 BFD 装箱恢复、请求边界准入；同时利用 agent 等待 tool-call 返回的 GPU 空闲窗口卸载/预取 KV，把显存让给活跃 Program。

6.3 SLO 感知调度（请求分优先级）

多租户/多业务混跑时，长请求阻塞短请求会严重伤害尾延迟。引入紧急度优先级调度：预测 prefill 完成时间，动态选择请求最大化 SLO 达成；对延迟敏感请求做 QoS 保护与限流。对万擎多业务共享推理集群，这是保障高质量 Token（低延时 SLA）的关键。

6.4 全栈智能化自适应调优和Kernel 优化

针对人工固定规则适配性弱的问题，引入AI全栈智能调优体系。通过强化学习模型实时感知业务流量、序列特征与硬件负载，自适应优化PD配比、弹性阈值、长短流量调度、CP分片粒度；同时结合时序预测预热热点缓存、优化淘汰策略，实现全链路动态最优，替代传统静态配置，达成无人化极致运维。另外，通过 Agentic RL 训练的大模型写 Kernel算子，也是需要重点研究的方向。

七、总结

本文面向 GLM‑5.2、DeepSeek‑V4 等新一代大模型，构建了覆盖并行执行、运行时调度、KV Cache、算子编译、量化与投机解码的全栈推理优化体系。围绕 Ring Attention、DP Attention + EP、大 PD、分级 KV Cache 和 DSpark 等技术，结合 SLO 感知调度、弹性扩缩及长短请求治理，系统缓解长上下文、动态负载和大规模部署下的计算、通信与显存瓶颈。通过模型结构与系统工程的协同优化，将模型侧的理论降本转化为实际的吞吐、时延、资源利用率和单位 Token 成本收益，为大模型服务的规模化部署提供可复用的工程实践。

关于我们

系统软件中心是公司核心的技术引擎，是公司传统软件和大模型软件承上启下的关键一层，拥有最先进的算力与最新的软件体系。团队不仅深耕JVM/JDK、编译器、构建系统等传统系统软件核心能力，还全面打造AI Infra——大模型训练、推理引擎，为公司各业务线提供高速、稳定、可扩展、低成本的大模型训练与推理服务。

• AI Infra方向

AI Infra训推引擎团队支撑公司基模与MaaS平台的核心引擎，致力于打造业界领先的大模型训练与推理基础设施。团队自主研发优化SFT/RL训练框架，快速适配新模型与训练范式，以极致的算力效率和迭代速度，支撑算法团队探索模型效果极限；深度优化推理引擎、调度与运营体系，确保平台上各类模型以更低成本、更快响应、更高性能服务海量用户，让大模型用得起、用得好。

加入AI Infra训推引擎团队，你将深入引擎内核，攻关PD分离、KVCache迁移、多模态性能等前沿架构；驾驭新一代算力，通过算子优化、量化、通信重叠释放硬件潜力；构建智能调度与成本优化系统，在保障SLO的同时最大化资源效益；打造下一代训练框架，支持万亿参数模型高效训练与RLHF等复杂流程，一起构筑大模型时代的核心引擎。

• 系统软件方向

团队专注于JVM、C++高性能计算、编译器等领域的产品特性的研发与优化。作为支撑快手业务的技术底座，团队致力于打造性能极致优化的系统软件，解决快手核心业务场景的关键技术瓶颈，用系统技术突破为业务创造价值。

加入系统软件团队，你将会深度优化系统软件底座，支撑快手亿级DAU的高并发访问；你将开发Java透明协程、高性能GC等一系列业界创新的JVM产品特性，优化改进Protobuf库、内存分配器等硬核基础软件，推进LLVM/GCC前沿编译优化技术的落地；一起通过创新的系统软件产品特性，让快手的每一行代码都跑得更快，运行得更稳，为业务发展提供坚实的保障。

热招岗位

1、大模型训练工程师（LLM Training Engineer）

• 职位描述

• 负责大模型训练框架与训练平台的研发与演进，支撑万亿级参数模型训练落地

• 负责分布式训练方案设计与优化（DP/TP/PP/ZeRO/FSDP/MoE 等），提升吞吐与资源利用率

• 负责训练性能调优，包括算子优化、混合精度（BF16/FP16/FP8）、显存优化、通信优化与 pipeline overlap

• 负责训练稳定性建设，包括容错恢复、监控告警、性能回归、训练诊断与自动化运维能力

• 参与强化学习训练框架与对齐训练流程建设，支持 RLHF/PPO/DPO/GRPO 等训练任务的工程优化与平台化落地

• 跟进前沿训练系统技术，推动在业务场景规模化落地

• 职位要求

• 本科及以上学历，计算机/软件/电子相关专业

• 熟练掌握 Python/C++，具备扎实的工程能力与系统调试能力

• 熟悉 PyTorch 训练机制，理解反向传播、梯度同步、显存管理等原理

• 熟悉分布式训练框架（Megatron-LM/DeepSpeed/FSDP 等）并具备实战经验

• 熟悉 GPU/NPU 性能优化方法，能独立完成 profiling 与瓶颈定位（Nsight/perf 等

• 熟悉训练侧算力优化技术，包括算子融合、图优化、Triton/CUDA Kernel 开发、编译器优化等

• 了解强化学习训练基本流程与常见框架，熟悉 rollout、reward model、policy update 等机制者优先

• 具备良好的问题分析能力与跨团队协作能力

• 加分项

• 有 MoE/长序列/多机多卡大规模训练经验

• 熟悉 NCCL/HCCL/RDMA/IB 通信优化

• 有量化训练、低比特训练或 QAT（Quantization-Aware Training）相关实践经验

• 有国产卡适配与性能优化经验

• 有开源贡献或高性能系统相关论文/专利

2、大模型推理工程师（LLM Inference）

• 职位描述

• 负责大模型推理引擎的研发与优化，提升吞吐、降低时延与推理成本

• 负责推理核心模块建设，包括 KV Cache 管理、Batching/Scheduling、Prefill/Decode Pipeline、PD 分离等

• 负责推理性能优化，面向 TTFT/TPOT/TPS/RPM 等指标进行系统级优化（算子、显存、通信、调度）

• 负责推理侧算子研发与优化，包括算子融合、Kernel 优化、图优化、推理编译优化，以及 INT8/FP8/FP4 等量化推理加速方案落地

• 负责推理稳定性与高可用建设，包括故障恢复、限流降级、容量评估、自动化诊断与 SLA 保障

• 推动推理平台化能力建设，包括模型发布流程、灰度、监控、日志、Tracing 与自动化运维工具链

• 职位要求

• 本科及以上学历，计算机/软件相关专业

• 熟练掌握 C++/Python，具备高性能系统研发能力

• 熟悉 Transformer 推理原理，理解 Attention、KV Cache、采样策略等机制

• 熟悉主流推理框架或推理引擎（TensorRT/Sglang/vLLM 等）

• 熟悉 GPU/NPU 性能调优与 profiling，能定位性能瓶颈并推动优化落地

• 熟悉推理侧算力优化技术，包括算子融合、图优化、Triton/CUDA Kernel、推理量化与推理编译加速等

• 熟悉 Linux、网络与容器化（Docker/K8s），具备线上系统运维与稳定性经验优先

• 加分项

• 有大规模在线推理落地经验，熟悉高并发、长上下文、多租户调度等场景

• 熟悉 KV Cache 压缩/复用、请求迁移恢复、跨实例调度等关键能力

• 有通信优化经验（NCCL/HCCL/RDMA）

• 有推理量化落地经验（如GPTQ/AWQ 等）或推理加速相关经验

• 有国产卡适配经验

3、系统软件开发（JDK/C++）工程师/专家

• 职位描述

• 负责维护内部JDK产品，参与即时编译器（JIT）、垃圾回收器（GC）等JVM虚拟机核心模块的设计、开发与优化

• 对内部C++服务进行深度性能分析，识别性能瓶颈，设计和实施针对性的优化方案，提升服务整体性能

• 职位要求

• 熟练掌握Java/C++，熟悉Python

• 熟悉Java/C++程序的性能分析与优化，了解相关性能分析工具的使用方法和工作原理

• 熟练掌握Java/C++程序的调试工具，具备调试复杂软件的实战经验

• 熟悉X86/ARM等硬件体系结构，熟悉Linux开发环境

• 具备高级语言虚拟机（JVM、JavaScript V8、Python虚拟机等），高性能网络编程，编译器等相关领域（任选其一）开发经验者优先

• 具备良好的沟通能力和团队合作精神，有持续学习的热情，能够快速掌握解决问题所需的技术

4、编译器开发工程师

• 职位描述

• 负责公司C/C++自研编译构建系统 的维护与持续演进，提升构建效率与稳定性

• 负责C/C++编译工具链（LLVM/GCC 相关） 的维护、升级与问题定位

• 优化构建链路性能，推进分布式构建、编译缓存（ccache）、分布式编译（distcc）等能力落地

• 建设编译与构建可观测、诊断能力，快速定位编译/链接/ABI 等复杂问题

• 支撑AI Infra工程，优化CUDA/异构算子相关编译流程，提升训练与推理交付效率

• 职位要求

• 精通C/C++/Python，具备扎实的系统工程能力

• 熟悉Bazel、Blade等构建工具，了解ccache、distcc等加速方案

• 熟悉LLVM/GCC 编译体系，能快速定位编译与工具链问题

• 学习沟通能力强，对自研系统有责任心，能快速响应业务需求

• 熟悉AI Infra技术栈，有CUDA开发经验；熟悉Triton/Cutlass优先

• 投递方式

扫描下方二维码投递，或投递简历至邮箱：tangqian09@kuaishou.com

**【