模型推理

它是什么

模型推理是把已经训练完成的模型应用到新输入上，产生分类、数值预测或生成内容的过程。对大语言模型而言，它通常指模型接收提示并生成响应。正常推理不会像训练那样根据这次请求反向传播并更新模型参数。[S1]

为什么需要它

训练决定模型获得什么参数，推理才是用户真正调用这些参数的阶段。产品的响应速度、并发量、显存成本、生成长度和解码设置都在这里变成现实约束。即使两个产品使用同一模型，只要推理配置和服务系统不同，用户体验与成本就可能明显不同。

它如何工作

系统先把输入转换为模型可处理的 Token，执行模型计算并得到输出。生成式语言模型会根据已有上下文计算下一 Token 的分布，再按解码配置选择一个 Token，将它追加到上下文并重复，直到满足停止条件。[S1][S2] 服务层还会处理请求排队、批处理和键值缓存；vLLM 的研究说明缓存管理会直接限制批量大小、吞吐和延迟。[S3]

真实例子

客服助手收到问题后，先拼接系统规则和检索资料，再调用模型逐 Token 生成草稿。较长上下文会增加计算与缓存占用，较长回答也会延长完成时间。服务可以合并并行请求提高硬件利用率，但仍要分别记录首个可见输出时间、完整响应时间、成本和回答质量。

什么时候适合与不适合

在线推理适合需要按请求立即返回结果的交互，批量推理适合可以延迟处理的大量任务。批处理和缓存优化可能提高吞吐，却会受请求长度、模型大小、硬件与调度策略影响。[S3] 推理系统更快不代表答案更真实，解码参数变化也不会补充模型缺失的知识或权限。

亲自试一下

目标是把一次模型调用拆成可测量步骤。画出“接收请求、准备上下文、分词、模型计算、逐 Token 解码、返回结果”的时间线，并为每一步标出一个指标和失败状态。若只记录总响应时间，应再区分排队、首个输出和完整生成，才能定位优化位置。

接下来学什么

先学习模型服务理解请求如何运行，再阅读解码策略、温度参数和核采样理解 Token 选择；结合延迟与吞吐量评估系统取舍。

来源与修订

传统模型与大语言模型的推理定义参考 Google Machine Learning Glossary [S1]；生成配置和 Token 选择参数参考 Hugging Face Transformers 文档 [S2]；批处理、键值缓存和服务吞吐约束参考 vLLM 论文 [S3]。本文不把论文中的特定吞吐提升外推到所有模型、硬件和负载。