Skip to content

模型推理系列 ​

小林打开公司的资料助手,问:“年假怎么申请?” 回答开始时有一点等待,之后一块块出现。过几天,他上传整份手册,同事也一起使用,服务开始变慢。再后来,他希望直接开口提问,并听到语音回答。

这条逐渐变复杂的使用过程,就是本系列的主线。先从屏幕上的现象开始,再打开请求、显存、缓存和调度,随后进入 vLLM、SGLang,最后回到多卡、语音、选型和实测。

资料助手从一次文字提问到长文档、多人服务、框架优化和语音的递进过程

由表到里的四个阶段 ​

第一遍按顺序阅读。每篇先用图和例子建立直觉,之后进入机制;公式、支持边界与完整参数放在展开区。每篇末尾回顾已经建立的认识,并给出下一篇自然产生的问题。

前五篇先不急着比较“谁更快”,而是回答:为什么要等、为什么显存不够、为什么缓存能省工作、为什么很多请求能一起算。建立这些直觉后,框架名称才会对应到具体机制。

同一个问题,逐层放大 ​

深入一层资料助手出现的现象接着研究什么
屏幕回答停一会儿才开始,一块块出现应用、引擎、prefill 与 decode
机器文档更长、人数更多时装不下权重、KV 与临时空间
状态同一份制度为什么重复计算KV、前缀复用、分页与 attention
调度短问题为什么被长问题挡住连续 batch、分块与队列
实现相同工作能否更高效量化、编译、推测、vLLM、SGLang
工程多卡与语音该如何部署通信、音频链路、选型与测量

类比用于解释关系,不替代技术定义。计算便笺不等于文本笔记,显存工作台不等于实际文件柜,模型也不保证像熟练员工一样理解和核对事实。每篇会在进入机制时说明边界。

完整目录与每篇要解决的问题
文章本篇的问题
01. 推理系统的分工应用、引擎、模型和设备各做什么?
02. 从输入到逐步生成已知输入与未知输出为何分两段处理?
03. GPU 与显存预算谁占空间,谁随文档与并发增长?
04. 注意力与 KV 缓存算过的状态怎样保留、共享和摆放?
05. 批处理与调度多人怎样一起算,如何减少空等?
06. 量化、算子与编译如何减少一轮计算的存储、搬运和提交成本?
07. 推测解码为什么先写草稿、再验证可能更快?
08. vLLM 的执行机制前面的优化由哪些模块组织起来?
09. SGLang 的执行机制共享前缀怎样形成可管理的树?
10. 多卡、MoE 与分离部署一台设备不够时,怎样拆工作和状态?
11. 语音与多模态推理从开口到听见回答,还要经过哪些阶段?
12. 框架对比与版本怎样把机制与需求变成选型条件?
13. 部署、压测与排错如何证明收益来自哪里,而非输出变少或条件不同?

先观察,再预测,再验证 ​

交互实验在浏览器本地运行,不下载模型。先预测改变人数、长度、缓存或输出方式会发生什么,再操作观察,最后把结果对应回机制。教学模拟、预算估算与真实 GPU 测量会分别标明。

版本快照截至 2026-10-20。原理的学习顺序不依赖某一次 release;实际启动与升级仍应对齐安装版本和模型支持。

简要概览见大模型推理与部署;语音工程细节见流式语音技术实践。现在从第一篇:推理系统的分工开始。

别急,先让缓存热一下。