01. 推理系统的分工

本篇导读

从一个最普通的提问开始：“年假怎么申请？” 本篇先拆开屏幕背后的三件事：应用准备问题、引擎安排执行、模型在设备上计算。读完后，应能指出 vLLM、SGLang 放在哪里，以及换引擎会改变什么。暂时不用记住框架清单和底层公式。

先看一个资料问答助手

小林在公司的资料助手里输入问题。应用找到他有权阅读的《请假制度》，把相关片段和问题交给模型服务，收到回答后显示出来。图中的制度与答复均为教学示例，不代表某家公司的实际规则。

此时有两个不同任务：找对资料，以及根据资料组织答案。模型服务收到的是本次输入，不会因为读到新制度就自动更新自己的长期参数。

可以把业务应用理解为柜台，把推理引擎理解为派单与进度管理。实际答复还要依靠模型规定的计算和设备执行。点选下列环节，沿同一个问题查看各自职责。

小林：年假怎么申请？

业务柜台
把“年假怎么申请？”和有权访问的制度片段交给模型服务；结果回来后决定如何展示、是否调用业务接口。

这也解释了一个常见现象：换成更高效的引擎后，回答可以更早出现、同时接待更多人；但如果制度根本没送进来，或模型理解能力不足，单换引擎不会补上这部分事实与能力。

训练像学习方法，推理像完成这一次答复

训练时，模型根据大量样本调整参数。部署后的常规推理使用已确定的参数处理当前问题，产生本次结果。好比培训阶段形成工作能力，接待阶段使用这些能力和眼前资料完成任务。

类比有边界：模型并不是一个能保证理解和查证事实的人；权重也不是保存完整原文的数据库。制度会更新时，常需要应用重新检索资料；要核对原文，则应回到文档或业务系统。

一个人能回答，为什么还需要引擎

只有小林时，加载模型后调用一次生成，已经能完成实验。到了上班时间，几十位同事同时提问：有人读一页制度，有人上传整份手册，有人中途关闭窗口。

如果每次都重新加载模型，启动和权重占用会浪费；如果所有请求简单串行，后面的人会等很久。推理引擎于是持续管理三件事：哪些请求在等、哪些状态要保存、下一轮一起算谁。后面第 3—5 篇会逐项拆开它们。

到这里，只需要能在图上找到 vLLM、SGLang：它们主要负责中间的引擎层。模型、底层算子和业务应用仍有各自的职责。

深入：常见项目分别处在哪一层？

层次	例子	主要职责
模型与配置	具体 checkpoint、tokenizer、chat template	规定计算、参数与输入约定
计算框架	PyTorch、MLX	张量、设备执行、编译等
算子库	FlashAttention、FlashInfer	高效完成 attention 等计算
推理引擎	vLLM、SGLang、TensorRT-LLM	状态、调度、采样、执行与服务
本地路线	llama.cpp、MLX-LM	本地执行、量化与设备适配
外围系统	Dynamo、Mooncake、LMCache	路由、KV 传输、缓存或存储
应用	资料助手、语音助手	检索、权限、会话、工具和业务校验

边界并非互斥：引擎也可以实现 kernel、提供 HTTP 接口。本系列先按主要职责理解，再到第 8—12 篇看实际组合。

深入：所有模型都像聊天模型这样回答吗？

Embedding 通常一次前向得到向量，reranker 得到相关分数；CTC ASR 按声学帧输出再解码；扩散或 flow 音频生成按去噪或积分步骤执行。它们都需要计算资源和调度，却不一定存在文本 LLM 式的逐 token 生成。本系列先以常规因果语言模型建立直觉，第 11 篇再展开语音差异。

另外，NVIDIA Triton Inference Server 与 Triton 编程语言是不同项目；GGUF 是容器格式；Ollama 偏重本地模型管理与使用入口。遇到名字时，先问它在链路上负责哪一段。

本篇回顾

• 模型规定计算和已学参数，设备实际执行；本次制度从应用输入进入。
• 推理引擎管理请求和状态，让同一模型能持续服务多人。
• 回答“可以提交申请”只是生成文字；实际提交仍由业务应用检查权限和状态。

现在已经知道谁在工作。下一篇继续追问：模型为什么先停一会儿，再一个片段一个片段地回答？ 进入从输入到逐步生成。