【大模型基础设施工程·特别篇】29：推理框架详解——为啥需要、做什么、底层举例与部署 Demo
内容提要
推理框架是模型从“能跑”走向“可服务”的关键层，负责调度、KV管理、并行、采样与API。裸generate缺少请求级调度、分页KV和连续批处理，并发一高延迟与显存即崩。框架核心包括Scheduler、KV Manager、并行运行时、采样与Model Runner。2026年常用框架：vLLM通用、SGLang擅前缀缓存、TensorRT-LLM低延迟、LMDeploy、MindIE、llama.cpp边缘。上手建议先跑vLLM OpenAI server，再对照SGLang或LMDeploy。
延伸解读
从“能跑”到“可服务”的差距在哪
文章指出，裸 generate 缺少请求级调度、分页 KV、连续批处理与 OpenAI 兼容接口，并发一高 TTFT/TPOT 和显存会同时恶化。框架的价值不是发明新算法，而是把调度、KV 管理、并行、采样和内核路径组装成可运维流水线。读者可据此判断：若只是单请求验证，裸 generate 够用；一旦要按 SLO 服务多用户，就必须引入推理框架。
选型口诀背后的约束条件
文章给出 2026 年常用地图：vLLM 通用、SGLang 擅前缀缓存、TensorRT-LLM 低延迟、LMDeploy 吞吐特化、MindIE 对应昇腾、llama.cpp/Ollama 面向边缘。但作者强调这是工程直觉而非分数榜，同一引擎在不同模型和卡型上相对位置会变。选型时应先看硬件与模型约束，再对照差异，而不是把某个框架当万能默认。
Demo 能验证什么、不能验证什么
文章提供的 vLLM、SGLang、LMDeploy 和 llama.cpp/Ollama 命令均按公开文档整理，作者明确未在 GPU 上实跑。Demo 适合验证接口连通、模型名对齐和基本可用性，不能直接外推集群吞吐或生产延迟。尤其 Ollama 的体感延迟不应等同于 vLLM 集群能力；上生产还需叠加服务化、网关与可观测层。
框架层仍在争论的开放问题
文章列出 PD 分离与 chunked prefill 的取舍、block-hash 与 radix 前缀共享的隔离语义、编译栈与动态图的维护税、框架 API 与外置网关的边界。这些问题没有万能阈值，取决于 prompt/decode 比例、网络与 KV 传递成本、多租户公平性等。读者在架构评审时可把这些作为待验证假设，而非直接套用结论。
Q&A
为什么不能直接用 transformers 的 generate() 做高并发服务？
generate() 设计目标是正确性与研究灵活性，不是高并发 serving。它通常一次处理一个或静态拼好的 batch，默认 KV 用 DynamicCache 随生成动态增长，缺跨请求的 block 管理、前缀共享与动态插入，也没有稳定的 OpenAI 兼容 HTTP、grammar-constrained decoding、prefix cache 命中统计。并发一高，TTFT/TPOT 和显存会同时崩。
推理框架内部有哪些核心组件？各自负责什么？
核心组件包括：Scheduler（请求调度、continuous batching、chunked prefill、抢占与优先级）、KV Manager（block 分配/回收、prefix/radix cache、swap）、Parallel Runtime（TP/PP/DP/EP 及集合通信）、Sampling + Structured Output（temperature/top-p、JSON/grammar、tool call 约束）、Model Runner + Kernels（加载量化权重、调用 FlashAttention/FlashInfer 等）。
2026 年常用的大模型推理框架有哪些？各自适合什么场景？
vLLM 是通用 CUDA serving 默认候选，生态大、OpenAI 兼容成熟；SGLang 擅 Agent/多轮前缀缓存，RadixAttention 和结构化输出是卖点；TensorRT-LLM 提供 NVIDIA 极致延迟，但换模型工程税高；LMDeploy 常见于国内对照；MindIE 是昇腾主路径；DeepInfer 是 DeepSeek 特化；llama.cpp/Ollama 适合边缘/本地。TGI 已归档，新项目不推荐。
PagedAttention 的 block table 是如何工作的？
PagedAttention 把 KV 切成固定大小 block，用 block table 做逻辑块号到物理页的映射，类似操作系统虚拟内存。append 新 token 时，当前 block 未满则写下一 slot；写满后才从 free pool 分配新 block 并在 block table 末尾追加映射。框架需保证分配、共享、写时复制、回收在调度步之间一致，否则 attention 会读错块。
Continuous Batching 的调度器每一步具体做什么？
Scheduler 维护 waiting/running 队列，每步生成 SchedulerOutput，包含本步要跑的请求（prefill 或 decode）、需分配/释放的 block、换入换出、被抢占请求。调度时先尽量留下一步的 decode 避免饿死已上线会话，再用剩余 token budget 和空闲 block 接纳 waiting 中的 prefill（可 chunk）。客户端断连时需从队列摘除请求并按 refcount 释放 KV。
如何快速上手部署一个推理框架？有可复制的命令吗？
推荐先跑 vLLM OpenAI server：创建虚拟环境后 pip install vllm，然后 vllm serve Qwen/Qwen2.5-0.5B-Instruct --host 0.0.0.0 --port 8000 --served-model-name demo，用 curl /v1/models 检查就绪，再发 /v1/chat/completions 请求。之后可串行对照 SGLang（python -m sglang.launch_server）或 LMDeploy（lmdeploy serve api_server）。本地/CPU 可用 Ollama 或 llama.cpp。注意不要多个引擎同时占同一张卡。
