LLM Serving

NVIDIA Dynamo 不是另一个 vLLM 或 TensorRT-LLM。它不负责重新实现 Attention、Continuous Batching 或模型执行，而是把多个推理引擎实例组织成一个可路由、可拆分、可扩缩的服务。 这一区分决定了阅读源码的入口：不要从 CUDA kernel 开始，而应先找到请求如何跨过 Frontend、Router、Prefill Worker 和 Decode Worker，以及服务发现、事件传播、KV 传输分别位于哪一层。 本文基于 Dynamo 提交 27f09d5，仓库版本为 1.5.0。 一、Dynamo 解决的不是单卡执行问题 单个推理引擎已经能完成一次生成：接收 token、执行 Prefill、循环 Decode、管理本机 KV Cache。规模扩大后，系统出现新的问题： 同一前缀可能被多个副本重复 Prefill。 Prefill 与 Decode 的算力和延迟特征不同，固定配比容易浪费 GPU。 Worker 上下线后，路由器必须快速获得最新拓扑。 KV Cache 不仅存在于显存，还可能分布在主存、SSD 或其他节点。 不同后端有不同请求格式与 KV 传输协议，但上层服务不应被绑定。 Dynamo 把这些问题放在推理引擎之上： 控制面 Discovery / Planner / Metrics | v Client -> Frontend -> Router -> Inference Worker | | | | +---- KV Events+ | +------ 流式响应 ----------> KV 数据面（按需） Prefill Worker ======> Decode Worker NIXL / backend connector 请求平面回答“请求发给谁”；KV 数据面回答“缓存如何移动”；控制面回答“哪些实例存在、负载怎样、是否扩缩容”。三者分开，是 Dynamo 架构最重要的设计。 ...

大模型推理框架并不只是执行一次 model.forward()。在线服务面对的是持续到达、长度不同、生成进度不同的请求，它必须同时解决文本编解码、动态批处理、KV Cache、GPU 执行和流式返回。 Mini-SGLang 把这些问题压缩在一套相对紧凑的代码中。本文先不进入具体优化，而是建立阅读后续源码所需的整体模型：一次请求如何从 HTTP 文本进入系统，经过 Prefill 和多轮 Decode，最后以流式文本返回。 本文基于 Mini-SGLang 提交 9a91cfa。 一、推理为何分成 Prefill 和 Decode 输入 prompt 包含多个 token。模型第一次执行时，需要同时处理全部输入 token，并为每一层生成 Key、Value。这一阶段称为 Prefill。 输入： [t0, t1, t2, t3] 计算： 同时处理多个位置 产物： 最后位置的 logits + 四个位置的 KV Cache 接下来每轮只生成一个 token。已有 token 的 K、V 不应重复计算，只需读取缓存并计算新 token： 已有： [t0, t1, t2, t3] 第 1 轮 Decode：输入 t3，生成 t4 第 2 轮 Decode：输入 t4，生成 t5 第 3 轮 Decode：输入 t5，生成 t6 因此两阶段的计算形态不同：Prefill 计算量大、输入长度不等；Decode 单次计算小，但会循环很多轮。现代推理引擎通常分别为两者设计调度与 Attention kernel。 ...