Inference Serving 全景：从指标、瓶颈到框架与生态

01推理服务本身：要求与指标

Inference serving 的任务是把训练好的模型变成一个服务：接收请求、在加速器上跑前向、把结果（常常是流式地）返回。它要同时满足三类目标，而这三类目标互相拉扯：

四种典型场景

一个请求的生命周期

以 OpenAI 兼容的 /v1/chat/completions 流式请求为例。前端进程做 HTTP、chat template、tokenize；调度器决定这一步让哪些请求上 GPU；model runner 跑前向；sampler 采样；detokenizer 把 token 变回文本，经 SSE 流回客户端。

核心指标定义

吞吐和延迟的权衡：Pareto 曲线

decode 一步的耗时近似是 t(B) ≈ t₀ + c·B：t₀ 是把权重读一遍的固定成本，c·B 是随批大小增长的部分（读各自的 KV、计算）。于是批大小 B 越大，每 GPU 吞吐 B/t(B) 越高，但每用户速度 1/t(B) 越低。SemiAnalysis 的 InferenceMAX 等基准就是把这条曲线画出来比较。

两条要背下来的关系式

负载画像决定优化方向

• ISL / OSL（输入 / 输出长度）。RAG、摘要、agent 是长输入短输出（prefill 重）；推理模型（o1 / R1 类）是短输入长输出（decode 重）。基准测试一定要说明长度分布。
• 前缀共享。系统 prompt、few-shot、多轮对话历史、agent 的工具定义，都让大量请求共享前缀 → 前缀 cache 命中率可以很高（官方 API 对 cached input 打折就是这个原因）。
• 到达模式。泊松到达 vs 突发；闭环（固定并发，发完一个再发下一个）vs 开环（按速率发）。闭环测试会掩盖排队问题。
• 多轮与会话。同一会话的下一轮要能找到上一轮的 KV，这影响路由（会话粘性 / KV 感知路由）。

不同应用场景的推理负载画像

同样叫“推理”，不同场景的模型结构不同、用户需求不同，落到 GPU 上的负载形状就完全不同。下表是全文的索引：每一行在对应章节里都有“模型特征 → 场景 → 负载”的详细拆解。

02物理限制：为什么 LLM 推理难

所有优化技术都是在和下面几条硬约束周旋。面试里能把这几条讲清楚并给出数量级，比背技术名词有用得多。

限制 1：自回归，token 只能一个一个生成

第 t+1 个 token 依赖第 t 个 token 的采样结果，所以 decode 无法在时间维度并行。一个 1000 token 的回答至少要 1000 次串行前向。并行只能来自三处：同时服务多个请求（批）、一次猜多个 token 再验证（投机解码）、或者换模型（多 token 预测、扩散 LM）。

限制 2：prefill 吃算力，decode 吃带宽

一次前向对每个参数大约做 2 次浮点运算（乘 + 加）。设权重 BF16（每参数 2 字节），处理 n 个 token：

• Prefill：一个 2000 token 的 prompt 一次前向就处理 2000 个 token，强度远超脊点，是 compute-bound。
• Decode：每个请求每步只处理 1 个 token。批大小 B 的 decode 对权重的强度约为 B，B 不到几百就是 memory-bound。更糟的是 attention 部分要读每个请求自己的 KV cache，这部分不能被批摊薄，强度始终约为 1。
• 推论：decode 的 batch=1 速度上限 ≈ 带宽 / 权重字节。8B 模型 BF16 约 16 GB，H100 上每步 ≥ 4.8 ms，即单流最多约 200 token/s（还没算 KV）。

限制 3：KV cache 吃显存，而且随并发和上下文线性增长

为了不重复计算历史 token，每层的 Key / Value 要缓存下来。每个 token 的 KV 大小：

一块 80 GB 的 H100 跑 Llama-3-8B（BF16）的显存账大致如下。KV 池决定了最大并发：约 52 GB ÷ 128 KiB ≈ 40 万 token，平均每请求 4k token 时约 100 个并发。并发上不去，批就大不了，decode 就一直在带宽屋顶的低处。

限制 4：互联带宽比显存带宽低一到两个数量级

模型放不进一张卡就要切分，而切分后的通信走的链路越来越慢。设计并行策略的原则是：通信最频繁的切分（TP）放在最快的链路（NVLink）里。

限制 5：负载不可预测

• 输出长度事先未知：调度器不知道一个请求会占多久显存，所以要么保守预留（浪费），要么允许超卖再抢占（复杂）。
• 请求异构：10 个 token 的问候和 100k token 的代码库分析混在一个批里。
• 流量突发：GPU 扩容是分钟级（拉镜像、加载几百 GB 权重），流量变化是秒级。

限制 6：其他常被忽视的瓶颈

• CPU 开销：Python 调度、构造输入张量、kernel launch。decode 一步 GPU 只要几毫秒，CPU 慢 1 ms 就是十几个百分点的损失。这是 CUDA graph、多进程架构、调度与计算重叠的动机。
• 尾延迟：一个长 prompt 进来，整个批的 ITL 都受影响。
• 数值非确定性：同一请求在不同批大小下结果可能不同（浮点加法不满足结合律、kernel 按批大小选不同切分）。RL 训练和评测对此很敏感，见 08。
• 功耗与成本：大规模部署时电力和机柜才是上限，单位是“每瓦 token 数”。

主流加速器参数（厂商公开峰值，稠密，约值）

03需要解决的问题

把上一节的限制落到一个朴素实现上（HuggingFace generate() 套一层 HTTP）会暴露出下面这些具体问题。后面每一项技术都可以对应回这张表；面试时先说“它解决哪个问题”，再说怎么做。

04LLM serving 的核心技术

这一节按“它解决哪个问题”组织。现代引擎（vLLM、SGLang、TensorRT-LLM）几乎都实现了全部这些技术，差异在实现细节、默认值和组合方式上。

通用 LLM：模型特征 → 场景 → 推理负载

4.1 批处理与调度：continuous batching

解决 P2、P3。朴素的静态批（static batching）把 N 个请求凑成一批，直到最长的那个结束才能换下一批。Orca（OSDI ’22）提出 iteration-level scheduling：调度粒度从“一个请求”降到“一次前向迭代”，每一步结束后，完成的请求立刻退出、等待的请求立刻补进来。这就是 continuous batching（也叫 in-flight batching）。

和 continuous batching 配套的几件事

• Selective batching / 扁平化。线性层（QKV 投影、MLP）不关心 token 属于哪个请求，把所有请求的 token 拼成一个 [总 token 数, hidden] 张量一起算，没有 padding；只有 attention 按请求分开（varlen / paged attention kernel）。
• Token budget。每步最多处理 max_num_batched_tokens 个 token、最多 max_num_seqs 个请求，控制单步时长和激活显存。vLLM V1 把 prefill 和 decode 统一看成“给每个请求分配本步要算的 token 数”，于是 chunked prefill、前缀 cache、投机解码都落在同一套逻辑里。
• 抢占（preemption）。KV 不够时把某些请求踢出：recompute（丢掉 KV，之后重新 prefill，vLLM 默认）或 swap（KV 拷到 CPU 内存）。抢占频繁说明并发超过了 KV 容量。
• 调度策略。FCFS 最常见；还有优先级调度、公平调度（如 OSDI ’24 的 VTC，按租户已服务 token 数做公平）、按预测输出长度排序（近似最短作业优先，降低平均延迟）、SLO 感知调度。SGLang 还有 cache-aware 调度：优先调度前缀命中长的请求。

4.2 KV cache 管理：PagedAttention、前缀缓存、分层存储

PagedAttention（vLLM，SOSP ’23）

解决 P1，间接解决 P3。借鉴操作系统的虚拟内存分页：KV 被切成固定大小的 block（默认 16 个 token），每个请求有一张 block table 把逻辑 block 映射到任意位置的物理 block，按需分配。浪费只剩每个请求最后一个没填满的 block。论文报告已有系统浪费 60–80% 的 KV 显存，vLLM 降到 4% 以下，吞吐提升 2–4 倍。分页还让共享变得容易：并行采样、beam search 的公共前缀只存一份，靠引用计数 + copy-on-write。

前缀缓存：vLLM APC 与 SGLang RadixAttention

解决 P5。请求结束后不立刻释放 KV，而是留作 cache；新请求如果前缀相同就直接复用，只 prefill 不同的部分，TTFT 和算力都省下来。两种主流实现：

KV 分层存储与 offload

解决 P5、P10。GPU 显存装不下所有值得缓存的前缀（多轮对话、agent 的长上下文、多副本之间的共享），于是把 KV 下沉到 CPU 内存、本地 SSD、甚至远端分布式存储，命中时再载回。判断是否值得的数量级：

• 开源实现：LMCache（vLLM 生态的 KV 存储层，CPU / 磁盘 / 远端后端）、Mooncake Store（Kimi 的 KVCache-centric 架构，利用集群空闲的 CPU 内存和 SSD，RDMA 传输）、SGLang HiCache（GPU → CPU → 存储三级 radix cache）、NVIDIA Dynamo KVBM（KV block manager）。
• 商业 API 的体现：DeepSeek 的上下文硬盘缓存、Anthropic / OpenAI 的 prompt caching（命中部分价格大幅打折）。
• KV 量化（FP8 / INT8）也是一种“扩容”：容量翻倍、attention 读带宽减半，通常精度损失很小。

4.3 Chunked prefill：把 prefill 切碎塞进 decode 批

解决 P4。长 prompt 的 prefill 一次要跑几百毫秒，期间同一 GPU 上所有 decode 请求都停住，ITL 出现尖峰。Sarathi-Serve（OSDI ’24）把 prefill 切成固定大小的 chunk，每次迭代 = 所有 decode token + 一个 prefill chunk，凑满 token budget。这样 decode 永不被长时间阻塞（stall-free），而 prefill chunk 正好把 decode 批“吃不饱”的算力用掉。

• 权衡：chunk 越小，ITL 越平稳，但 prefill 效率下降（每个 chunk 要重读之前 chunk 的 KV、GEMM 变小），X 自己的 TTFT 变长。常见 token budget 是 2k–8k，根据 TPOT SLO 调。
• 与 PD 分离的关系：chunked prefill 是“同一 GPU 内做时间上的隔离”，PD 分离是“换不同 GPU 做空间上的隔离”。中小规模部署用 chunked prefill 通常就够了；它在 vLLM V1 中默认开启。

4.4 Prefill–Decode 分离（PD disaggregation）

解决 P4，并让两阶段可以独立选并行度、硬件和扩缩容。prefill 是 compute-bound、关心 TTFT；decode 是 memory-bound、关心 TPOT 和大批。放在一起时，无论怎么调度都在两个 SLO 之间妥协。DistServe（OSDI ’24）、Splitwise（ISCA ’24）、Mooncake（FAST ’25）把它们放到不同的 GPU 池，prefill 算完后把 KV cache 通过 RDMA / NVLink 传给 decode 实例。DistServe 报告在同样 SLO 下最多可服务 7.4 倍的请求。

• 实现：vLLM 的 KV Connector 抽象（NixlConnector、LMCacheConnector、P2pNcclConnector、Mooncake 等），SGLang 的 PD 模式（Mooncake / NIXL 传输后端 + bootstrap 握手），NVIDIA Dynamo 和 llm-d 在集群层编排 PD。
• 进一步的拆分：EPD（把多模态 encoder 也拆出去，见 09）、AF 分离（attention 与 FFN/专家分到不同 GPU，例如字节的 MegaScale-Infer、阶跃星辰 Step-3 的 AFD），本质都是“按算力特征把模型的不同部分放到最合适的资源上”。

4.5 投机解码（Speculative decoding）

解决 P6。decode 小批时 GPU 算力大量闲置，验证 k 个 token 的成本和生成 1 个几乎一样（都是读一遍权重）。于是：用便宜的方法先猜 k 个 token（draft），再让目标模型一次前向并行验证，接受最长的正确前缀，外加目标模型在第一个拒绝位置自己采样出的一个 token。用拒绝采样（rejection sampling）做接受判断时，输出分布与目标模型完全一致（Leviathan et al. 2022；Chen et al. 2023）。

4.6 Kernel 与 runtime：把每一步做快

解决 P8、P9。批处理和调度决定“算什么”，kernel 和 runtime 决定“算得多快”。理解 kernel 最好的办法是沿着一层 decoder 的执行顺序，看每一步调用了哪个 kernel、它是 compute-bound 还是 memory-bound、和谁可以融合。

按类别看 kernel：要解决什么、代表实现、源码

面试常问的 kernel 概念

写 kernel 的工具链：CUDA C++ + CUTLASS / CuTe 仍是性能天花板；Triton 是最常用的 Python DSL（vLLM / SGLang 大量 MoE、attention 变体用它）；CuTe DSL（Python 版 CUTLASS，FA4 用它）、TileLang（DeepSeek 的稀疏 attention 等用它写参考实现）、ThunderKittens 让写 Hopper / Blackwell 专用 kernel 更容易。

4.7 量化：少读字节、多放 KV

解决 P3、P6、P7。decode 是 memory-bound，权重字节数减半，单步时间就接近减半；同时省下的显存给 KV，批更大。prefill 是 compute-bound，只有激活也量化（W8A8、FP8、FP4）且用对应的 Tensor Core 指令时才加速。

工具：vLLM 的 llm-compressor、NVIDIA ModelOpt、Intel AutoRound、PyTorch torchao、bitsandbytes、llama.cpp 的 GGUF k-quants。面试常问“量化后怎么验证”：除了 perplexity，一定要在目标任务（数学、代码、长上下文检索）上评测，量化对推理链长的任务更敏感。

4.8 模型结构侧的优化：从源头减小 KV 与计算

解决 P3、P10。很多“推理优化”其实发生在模型设计阶段，serving 系统要跟着支持。

4.9 并行策略：模型放不下、或一张卡太慢

解决 P7、P10。推理里的并行与训练相似，但目标不同：训练追求吞吐，推理还要压单请求延迟，所以 PP 在推理中没那么受欢迎（它不降低单 token 延迟）。

4.10 结构化输出、多 LoRA、API 层功能

解决 P11、P12。这些不提升“裸性能”，但是产品必需品，而且做不好会严重拖慢吞吐。

• 结构化输出（constrained decoding）。把 JSON schema / 正则 / CFG 编译成自动机，每步生成一个 token mask，把非法 token 的 logit 置为 −∞。难点是 mask 计算要在 GPU 前向期间完成、不成为瓶颈。XGrammar 用下推自动机 + 预计算“与上下文无关”的 token 集合，把大部分检查挪到预处理；llguidance、Outlines 是其他实现；SGLang 早期的 compressed FSM 可以一次“跳过”确定的多个 token（jump-forward）。
• 工具调用与推理内容解析。不同模型的 tool call 格式各异，服务端需要 tool-call parser 和 reasoning parser 把输出转成 OpenAI 格式的 tool_calls 和 reasoning_content。
• Multi-LoRA。一个基座 + 成百上千个 LoRA adapter 同时服务。S-LoRA 把 adapter 权重与 KV 统一分页管理并按需从 CPU 载入；Punica 的 SGMV kernel 让一个批里不同请求用不同 adapter 仍然高效。vLLM / SGLang 都支持动态加载与批内混合 adapter。
• 多租户隔离。优先级、配额、按租户的公平调度、按 token 计费与限流（TPM / RPM）。
• OpenAI 兼容 API。/v1/chat/completions、/v1/completions、/v1/embeddings、/v1/audio/*、Responses API；logprobs、n 采样、stop、seed 等参数都要在引擎里正确实现。

4.11 总表：技术 → 问题 → 代价

05扩展到 MoE：显存按总参数、计算按激活参数

Mixture-of-Experts 把 FFN 换成 E 个专家，router 为每个 token 选 top-k 个。当前大多数前沿开源模型都是 MoE：

MoE：模型特征 → 场景 → 推理负载

MoE 让推理更难的地方

• 显存：671B 参数 FP8 也要约 700 GB，至少要 8×H200 或跨机。所有专家都要常驻显存，因为任何 token 都可能路由到任何专家。
• decode 时专家 GEMM 极小：批里 B 个 token，每个选 k 个专家，平均每个专家只分到 B·k/E 个 token。DeepSeek-V3 在 B=64 时：被激活的专家数 ≈ E·(1−(1−k/E)^B) ≈ 222 个（几乎全部），平均每个专家只有约 2.3 个 token。结果是几乎要读全部专家权重，却每个只做极小的矩阵乘 —— 严重 memory-bound。
• 通信：专家分在不同 GPU 上，每个 MoE 层要两次 all-to-all（dispatch 把 token 发给专家，combine 把结果收回），延迟敏感且量大。
• 负载不均：热门专家所在的 GPU 成为瓶颈，整个层等最慢的那张卡。训练时可以用 capacity factor 丢 token，推理时不能丢。

MoE serving 的技术栈

案例：DeepSeek-V3/R1 的线上推理系统

DeepSeek 在 2025 年 2 月的 Open Infra 周最后一天公开了线上系统概况，是面试中讲 MoE serving 最好的例子：

• PD 分离 + 不同并行度：prefill 阶段每个部署单元 4 个节点（32 卡），路由专家 EP32、MLA 与共享专家 DP32；decode 阶段每单元 18 个节点（144 卡），EP144、DP144。
• 重叠：prefill 用双微批重叠，decode 把 attention 切成两段做 5 级流水的重叠。
• 负载均衡：prefill、decode 和 attention 各有自己的均衡器（专家冗余、按 KV 使用量与请求数分配请求）。
• 结果（公开数字，H800）：平均每节点 prefill 约 73.7k token/s（含 cache 命中）、decode 约 14.8k token/s；理论成本利润率 545%。
• SGLang 团队随后在 96 张 H100 上用 PD 分离 + 大规模 EP 开源复现，2k 输入时每节点约 52.3k 输入 token/s、22.3k 输出 token/s。

机柜级硬件（GB200 / GB300 NVL72）把 72 卡放进一个 NVLink 域，宽 EP 的 all-to-all 可以完全走 NVLink，是当前超大 MoE 部署的主流形态。

06扩展到大规模集群

单个引擎实例优化到头之后，问题变成集群层面的：几百上千张 GPU、多个模型、PD 两个池、跨机实例、流量波动、硬件故障。这一层的软件叫 orchestration / control plane，它不替代 vLLM / SGLang，而是管理一群引擎实例。

路由：命中率和负载均衡的权衡

• 轮询 / 最少连接会把同一会话打散到不同实例，前缀 cache 几乎失效。
• 会话粘性 / 一致性哈希提高命中，但热点会把某个实例打爆。
• KV 感知路由：路由器维护每个实例缓存了哪些 block（通过引擎上报的 KV 事件，或近似 radix tree），对每个候选实例算 “命中可省的 prefill 量 − 负载代价”。代表：NVIDIA Dynamo KV Router、llm-d 的 inference scheduler（prefix-cache scorer）、SGLang Model Gateway（原 sgl-router）的 cache-aware 策略、AIBrix router。
• Kubernetes 标准化：Gateway API Inference Extension 定义了 InferencePool 和 endpoint picker，把“模型感知的选实例”做成 K8s 网关的扩展点，llm-d 等基于它实现。

扩缩容与冷启动

• 别用 GPU 利用率当信号：decode 时 nvidia-smi 的 util 几乎总是 100%。应看队列长度、KV 使用率、TTFT / TPOT 的 SLO 违约率。PD 分离时 P 和 D 分开扩（Dynamo Planner 就是做这个）。
• 冷启动链路：调度 GPU 节点 → 拉镜像（几十 GB）→ 加载权重（几百 GB，从对象存储 → 本地 NVMe → 显存）→ torch.compile / CUDA graph 预热。优化手段：权重预放到节点、并行流式加载（Run:ai Model Streamer、fastsafetensors）、节点间 P2P 分发权重、编译缓存、GPU 进程快照（如 Modal 的 GPU memory snapshot、CUDA checkpoint）。
• 多模型共用 GPU：vLLM 的 sleep mode（释放权重 / KV 显存，秒级唤醒）、多 LoRA、按需加载，适合长尾模型。

可靠性

• 一个宽 EP 实例跨 18 个节点时，任意一张卡出错整个实例就挂；需要健康检查、快速剔除、请求重试、专家迁移。
• 请求迁移：Llumnix（OSDI ’24）在实例间实时迁移请求（连同 KV），用于负载均衡、降级和优雅下线。
• 流量削峰：Batch API（离线任务，24 小时内完成，通常半价）填平低谷；优先级让在线请求先走。

集群层的开源项目

07LLM 推理框架

引擎（engine）负责单个实例里的调度、KV 管理和执行；上一节的 orchestration 负责一群实例。面试最常被问的是 vLLM 和 SGLang 的架构和区别。

vLLM

2023 年出自 UC Berkeley Sky Computing Lab（PagedAttention 论文），现为 PyTorch Foundation 托管项目，是模型和硬件覆盖最广的开源引擎。2025 年起 V1 架构成为默认实现。2026 年 1 月核心作者创立 Inferact（a16z、Lightspeed 领投 1.5 亿美元种子轮）做商业化。

• 特点：模型覆盖最全（文本、多模态、embedding / reward / pooling）；硬件最广（CUDA、ROCm、TPU、Gaudi、XPU、CPU，以及 vllm-ascend 等插件）；插件化的 KV connector（PD 分离）、attention backend、量化方法；投机解码（EAGLE、MTP、n-gram）；多 LoRA；结构化输出；RL 集成（sleep mode、权重热更新）。
• 周边：vLLM-Omni（多模态生成）、llm-d、production-stack、AIBrix、llm-compressor、guidellm（压测）、semantic-router（意图路由）。

SGLang

2023 年底出自 LMSYS（Berkeley / Stanford 等），最初是“前端结构化生成语言 + 高效运行时（SRT）”，以 RadixAttention 闻名，后来在 DeepSeek 大规模 EP、结构化输出、RL rollout 方面成为主力引擎之一。2026 年核心团队成立 RadixArk（Accel 领投），继续维护开源 SGLang 并开发 RL 框架 Miles。

• 特点：RadixAttention 与 cache-aware 调度；零开销 overlap scheduler；DP attention + DeepEP / DeepGEMM / EPLB / TBO 的大规模 EP；PD 分离（Mooncake / NIXL）；EAGLE-2/3 投机；HiCache 分层 KV；sgl-kernel 自有 kernel 库；SGLang Model Gateway（Rust 写的路由器）。
• RL 生态：verl、slime、AReaL、Miles 等都把 SGLang 作为 rollout 引擎（见 08）。
• 扩展：SGLang Diffusion（图像 / 视频生成）、SGLang-Omni（多阶段语音与 omni 模型）、TPU 后端（SGLang-JAX）。

vLLM vs SGLang：面试怎么答

其他引擎

08后训练里的推理：RL rollout 是一个推理问题

推理引擎不只用来服务用户，后训练的很多环节本质上都是大批量推理：

• 在线 RL（PPO、GRPO、DAPO 等）：每一步都要用当前策略为每个 prompt 生成多条回答（GRPO 常见 8–64 条），推理模型的回答动辄上万 token。
• 数据合成与蒸馏：用强模型批量生成 SFT 数据；rejection sampling / best-of-N 挑选高分样本。
• 打分：reward model、LLM-as-judge 也是推理负载。
• 训练中的评测：每隔若干步在基准上跑一遍。

后训练：模型特征 → 场景 → 推理负载

和在线服务相比，rollout 有什么不同

四个核心难题

1. 权重同步

• Colocated（共置）：训练和推理分时共用同一批 GPU。训练时推理引擎“睡眠”（vLLM sleep mode / SGLang release_memory_occupation 释放 KV 和权重显存），推理时把训练状态 offload。权重通过 CUDA IPC 句柄零拷贝传给推理引擎，并从 FSDP / Megatron 的切分方式 reshard 成推理的 TP 布局。verl 的 HybridEngine 是代表。
• Disaggregated（分离）：训练和推理各用一组 GPU，权重通过 NCCL / RDMA 广播。资源利用更灵活，适合异步 RL；超大模型要优化传输（例如 Moonshot 开源的 checkpoint-engine 用于万亿参数模型的快速权重更新）。

2. 长尾（straggler）

同步 RL 里，一个 step 必须等最长的回答生成完，其他 GPU 空转。

• Partial rollout（Kimi k1.5）：超长回答先截断，下一轮接着生成。
• 异步 / off-policy：AReaL（全异步 + staleness 控制）、verl / slime 的 one-step off-policy、PipelineRL（生成中途更新权重）。
• 动态采样 / 过采样：DAPO 丢掉奖励全相同（无梯度信号）的组，多发一些 prompt 来凑满批。

3. 训练–推理不一致（training–inference mismatch）

推理引擎算出的 token 概率和训练引擎对同一序列重算的概率不完全一样：kernel 不同、批大小不同导致的归约顺序不同、rollout 用 FP8 而训练用 BF16、MoE 的路由在两边选了不同专家。结果是“名义上的 on-policy 实际上是 off-policy”，会导致训练不稳定甚至崩溃。

• 训练侧重算 logprob，并用重要性采样修正（如截断重要性采样 TIS）。
• MoE 路由回放：记录 rollout 时每个 token 用了哪些专家，训练时强制用相同路由。
• 确定性 / 批不变（batch-invariant）kernel：Thinking Machines 2025 年的文章《Defeating Nondeterminism in LLM Inference》指出非确定性主要来自 kernel 的归约顺序随批大小变化，而不是常说的“GPU 并发”；之后 vLLM 和 SGLang 都加入了确定性推理模式（会损失一些性能）。

4. Agentic RL 的多轮交互

• 一条轨迹包含多次“生成 → 调工具 → 拿结果 → 再生成”，环境步骤（跑单元测试、编译、浏览网页）可能比生成还慢，需要异步调度，否则 GPU 空等。
• 需要大量并发 sandbox（几千个隔离的容器 / microVM），见 14。
• 多轮之间要复用 KV（会话粘性、前缀 cache）；尽量 “token in, token out”，避免每轮把文本重新 tokenize 带来的 token 序列漂移。

RL 框架与它们用的推理引擎

商业形态：Thinking Machines 的 Tinker 把“训练 + 采样”做成 API；各家推理平台也提供微调 + 托管一体的服务。

09Omni / 语音 / 多模态模型的推理服务

多模态分两类：多模态输入（VLM，图像 / 视频 / 音频 → 文本），基本可以沿用 LLM serving，只多一个 encoder；多模态输出（文本 + 语音、图像生成、any-to-any），模型由多个异构组件串起来，serving 的假设被根本改变。

代表模型的结构：Thinker–Talker

以 Qwen3-Omni 为例：音频 encoder（AuT）和视觉 encoder（SigLIP2）把输入编码后交给 Thinker（30B 总参数 / 3B 激活的 MoE LLM）生成文本；Thinker 的隐藏状态再交给 Talker（3B / 0.3B 激活的 MoE，带 MTP 预测多层 codebook）生成音频 codec token；最后 Code2Wav（约 2 亿参数的卷积网络）把 codec token 解码成波形，按块流式输出。类似结构还有 Qwen2.5-Omni、MiniCPM-o、Ming-Omni 等；全双工模型如 Kyutai 的 Moshi 能边听边说。

Omni / 语音：模型特征 → 场景 → 推理负载

相对 LLM serving，哪些假设变了

级联 vs 端到端

指标

TTFT（文本首 token）、TTFP / TTFA（首个音频包）、TPOT、RTF（生成耗时 ÷ 音频时长，< 1 才能实时）、播放 underrun；质量上用 ASR 转写生成语音算 WER（可懂度）、说话人相似度（SIM）、UTMOS（自然度）；ASR 服务看 WER 和 RTFx（每秒处理多少秒音频）。

框架

10扩散模型推理

图像 / 视频 / 音频扩散模型（DiT 为主，如 FLUX、SD3、Qwen-Image、Wan、HunyuanVideo）的推理和 LLM 几乎是镜像关系：

扩散：模型特征 → 场景 → 推理负载

扩散推理的加速技术

扩散的 serving 系统设计

• 异步任务 API：生成要数十秒，通常是“提交 → 轮询 / webhook / 流式进度”，而非长连接等待。
• 请求级 vs 步级批处理：每一步跑的是同一个网络，不同请求处在不同步也能拼批（step-level continuous batching）；要求分辨率 / 帧数相同或做分桶。vLLM-Omni 等已实现扩散的连续批处理。
• LoRA 热切换：图像平台上用户大量使用风格 LoRA，需要快速加载与融合。
• 流水线解耦：文本 encoder、DiT、VAE 可以放不同 GPU / 不同批大小（AR + DiT 混合模型更需要，如 HunyuanImage-3、BAGEL）。
• 与 LLM 技术融合：自回归视频扩散（CausVid、Self-Forcing）按帧块生成并缓存 KV，能实时流式出视频；交互式世界模型（如 Genie 3、Cosmos 类）把扩散推理变成了“流式 + KV cache + 低延迟”的问题。扩散语言模型（LLaDA、Mercury、Gemini Diffusion）则把并行去噪带到了文本生成。

指标：单图 / 单视频端到端延迟、每秒步数（it/s）、吞吐（images/s）、峰值显存；流式视频看首帧时间；质量看 FID、CLIP score、GenEval、VBench 与人类偏好分。

框架

11机器人推理：从“吞吐”回到“实时”

机器人策略模型（VLA，Vision-Language-Action）在结构上是“VLM + 动作头”，看起来像多模态 LLM，但推理的目标函数完全不同：它运行在一个物理闭环里，延迟和抖动直接决定任务成败与安全，而吞吐几乎无所谓。

代表模型

机器人：模型特征 → 场景 → 推理负载

机器人推理 vs LLM serving

关键技术

• Action chunking（ACT，2023）：一次推理预测未来 H 步动作，降低推理频率要求；相邻块重叠部分用 temporal ensembling 平滑。π0 系列用 50 步的块。
• 异步推理：执行当前块的同时就开始推理下一块，机器人不需要停下来等模型（LeRobot 的 PolicyServer + RobotClient 架构，SmolVLA 论文中提出）。
• Real-Time Chunking（RTC，Physical Intelligence 2025）：异步时新块和正在执行的块会“接不上”。RTC 把生成新块看作 inpainting：推理延迟期间必定会执行的动作被冻结，其余部分被引导与之衔接，在不重新训练的前提下得到平滑连续的动作。
• 快慢双系统：把慢的语义理解和快的运动控制解耦，各自按自己的频率运行（Helix、GR00T）。
• 压缩与编译：INT8 / FP8 / INT4 量化、TensorRT 引擎、更少的 flow 积分步、蒸馏小策略；batch = 1 时 kernel launch 开销占比高，CUDA graph / JAX jit 很关键。
• 远程推理：机器人只做传感与控制，策略跑在附近的 GPU 上（openpi 用 websocket 提供策略服务）；要处理网络抖动和断连回退。
• 仿真与世界模型：训练和评测依赖大规模 GPU 仿真（Isaac Sim / Isaac Lab）和视频世界模型（NVIDIA Cosmos 等），它们本身也是推理负载（大批量、扩散生成）。

框架

12Coding Agent 的推理：长会话、高命中、慢工具

代码是目前 LLM 商业化最成功的场景之一，但“写代码”背后其实是三种完全不同的推理负载：编辑器内的行内补全、把建议应用到文件的快速编辑（apply），以及自主完成任务的 agentic coding（Claude Code、Codex、Cursor Agent、OpenHands 等）。它们对 serving 的要求差别之大，几乎可以当成三个产品来设计。

模型特征 → 场景 → 推理负载

三种负载的对比

Serving 侧的具体做法

• 把命中率当一等指标。监控 per-session 的 cached-token 比例；路由用会话 ID 或前缀哈希做粘性，再叠加负载感知（06 的 KV 感知路由）。商业 API 的 prompt caching（例如 Anthropic 默认 5 分钟、可选 1 小时 TTL 的缓存）就是把“工具空档里保留 KV”这件事产品化。
• KV 的生命周期跨越工具调用。GPU 上用 LRU 保留，压力大时下沉到 CPU / SSD（LMCache、HiCache、Mooncake、Dynamo KVBM）；按 4.2 的估算，载回远比重算便宜。
• 长上下文 prefill 的成本控制：chunked prefill 防止一个 200k prompt 卡住别人；必要时用上下文并行；agent 侧做上下文压缩、子 agent 拆分任务，减少单会话上下文长度。
• 可靠的工具调用：每个模型家族的 tool-call 格式不同，引擎里的 tool parser / reasoning parser 必须和模型模板严格匹配；必要时用结构化输出约束参数 JSON。
• Sandbox 是推理链路的一部分：每个会话一个隔离环境（容器 / microVM），要快速创建、可暂停恢复、可快照；训练（agentic RL）和线上用的是同一套。阿里开源的 OpenSandbox 就是面向 coding agent、GUI agent、评测和 RL 的通用 sandbox 平台（Docker / Kubernetes 运行时，多语言 SDK，内置 MCP server），见 14。
• 评测：SWE-bench 系列（真实仓库 issue → 补丁 → 在容器里跑测试）、Terminal-Bench 等；评测本身就是“推理 + 大量 sandbox”的负载。

13AI for Science 的推理：结构、几何与物理

科学模型的输入不是自然语言，而是蛋白质序列与多序列比对、原子坐标、基因组、全球气象网格。这些数据的结构决定了模型结构（成对表示、等变网络、图网络、超长卷积），进而让推理负载和 LLM serving 很不一样：batch 往往为 1、显存随问题规模平方增长、CPU 侧预处理可能比 GPU 推理还慢、对数值精度更敏感、大量是离线批量筛选。

模型特征 → 场景 → 推理负载

与 LLM serving 的差异总结

• 优化手段：主干分块与 activation offload；三角注意力 kernel（NVIDIA cuEquivariance 提供 triangle attention / multiplication，DeepSpeed4Science 有 Evoformer attention）；MSA 搜索 GPU 化与缓存；扩散样本批量化；MLIP 用 CUDA graph 和融合的等变 kernel 降低每步延迟，并与 LAMMPS / ASE 等 MD 引擎原生集成。
• 服务化：NVIDIA BioNeMo（框架与 NIM 微服务，覆盖结构预测、蛋白 / 基因组语言模型）、Google DeepMind 的 AlphaFold Server、ColabFold 的公共 MSA 服务、NVIDIA Earth2Studio（天气模型推理与集合预报流水线）、ECMWF 的 AI 预报业务化运行。

14和 inference serving 相关的技术

Sandbox：让模型生成的代码和动作安全地执行

Agent 会写代码、跑命令、开浏览器；RL 训练需要几千个并发环境跑单元测试。这些代码不可信，必须在隔离环境里执行。sandbox 已经成为 agent 产品和 RL 基础设施的标准组件。

• 关键需求：冷启动（预热池、快照 / 恢复、CRIU）、密度（单机几百上千个）、网络出口控制、文件系统持久化与暂停 / 恢复（长时 agent 会话）、资源限额与超时、可观测性。
• 开源平台：OpenSandbox（阿里开源，仓库现位于 opensandbox-group 组织）提供统一 sandbox API、Python / Java / JS / C# / Go SDK、CLI 与 MCP server，并带有 Claude Code、Gemini CLI、Codex CLI 等 coding agent 的接入示例；E2B 也开源了 SDK 与基础设施代码。
• 服务商：E2B、Modal Sandboxes、Daytona、Runloop、Northflank、Cloudflare Sandbox / Containers、Vercel Sandbox 等；模型厂商自带的代码执行工具（OpenAI Code Interpreter、Anthropic code execution tool）。
• 开源：Firecracker、gVisor、Kata；面向 agent 的运行时如 OpenSandbox、OpenHands runtime、SWE-ReX。

API 网关、模型路由与缓存

• 统一网关：LiteLLM（开源代理，统一上百家供应商的 OpenAI 兼容接口）、OpenRouter（模型市场与路由）、Portkey、Kong AI Gateway、Envoy AI Gateway、Cloudflare AI Gateway。负责鉴权、按 token 限流（TPM / RPM）、配额、计费、重试与 fallback。
• 模型路由：按问题难度选模型以省钱（RouteLLM、vLLM Semantic Router）；按地域、价格、延迟选供应商。
• 缓存：精确缓存、语义缓存（向量相似度命中，需谨慎）、供应商侧的 prompt caching。
• 多租户安全：前缀缓存可能被用作跨租户的时序侧信道（命中更快），可以按租户加 cache salt 隔离（vLLM 支持 cache_salt）。

可观测性、压测与评测

模型加载、分发与冷启动

• 格式：safetensors（可 mmap、零拷贝、无反序列化风险）、GGUF（llama.cpp）。
• 加速加载：Run:ai Model Streamer、fastsafetensors、CoreWeave tensorizer、GPUDirect Storage；权重预置到节点本地 NVMe；节点间 P2P 分发（如 Dragonfly）。
• 镜像：推理镜像动辄几十 GB，用懒加载镜像（eStargz、Nydus）或预拉取。
• 快照：进程级 / GPU 显存级快照恢复，把“加载 + 编译 + 预热”的分钟级冷启动压到秒级。

安全与合规

• 内容安全分类器（Llama Guard、ShieldGemma、NeMo Guardrails）与主模型并行或流式运行，避免串行增加延迟。
• Prompt injection 防护（尤其 agent 读取外部内容时）、PII 脱敏、日志留存策略。
• 机密计算（H100 / Blackwell 的 Confidential Computing 模式）用于敏感数据推理。

硬件与编译器生态（简表）

15公司与开源项目地图

按技术栈从上到下分层。绿色描边是开源项目，其余是公司或商业服务。这个领域变化很快（融资、收购、更名频繁），下面反映的是约 2026 年中的格局，面试前建议再核对一次。

按领域

16源码导读：带着问题读代码

文中所有源码链接都固定在某个 commit（与本文写作时 GitHub 上的 main 一致），行为与链接不会因为上游重构而失效；想看最新版本，在 GitHub 页面按 y 切换或手动换成 main。◈ Code Wiki 链接指向 Google Code Wiki 为该仓库生成的结构化讲解（按模块解释架构和调用关系），适合在读源码前先建立全局图；若某个仓库还没生成，页面会提示。

LLM 引擎

特性专题

17面试速查

估算公式（背下来，现场能算）

高频问题

18参考文献与延伸阅读