上一篇，我们把一次请求拆成了 Prompt、Context、输出约束和结果校验。但请求组装完成，只代表“模型收到了什么”，还没有回答另一个关键问题：这些 Token 进入推理服务后，怎样变成屏幕上逐字出现的答案？
这中间并不是一个瞬间完成的黑盒。请求要经过网关、排队和分词，模型先处理全部输入，再一个 Token 一个 Token 地生成输出；服务还要维护缓存、调度并发、返回流式事件，并记录每个阶段的延迟和资源消耗。
今天继续使用企业差旅助手。制度问答、票据抽取、行程建议和创建申请虽然可能使用同一个模型，但它们对稳定性、创造性、首字延迟、总耗时和可验证性的要求完全不同。我们将沿着一次真实请求的时间顺序，把生成质量与服务性能分开讲清楚。
资料核对日期：2026 年 9 月 4 日。本文以自回归语言模型的常见推理方式为主。具体 API 是否开放 Temperature、Top-p、Seed、Reasoning Effort 或其他参数，取决于模型和供应商；服务实现也可能使用不同缓存、调度和加速机制。
01 训练与推理，是模型生命周期中的两个阶段
边界速记：训练阶段通过数据和优化算法更新参数；推理阶段通常固定参数，根据当前输入执行计算并生成结果。
训练（Training）回答的是“模型参数怎样形成”。预训练、SFT、偏好优化和微调都会让损失或目标函数反向影响参数。第 17 篇讨论的主要是这一侧：数据怎样进入训练，梯度怎样推动参数更新，以及 LoRA、量化分别改变什么。
推理（Inference）回答的是“已经得到的模型怎样被使用”。系统把当前请求转换为 Token，通过一次或多次前向计算得到输出。在普通在线推理中，模型权重不会因为某个用户问了一句话就自动修改。对话历史、RAG 证据和任务状态即使影响本轮回答，也只是进入了上下文，不等于重新训练模型。
企业助手例子：公司没有为每张票据重新训练模型，而是使用已经训练好的模型，把票据字段、报销制度和用户身份放入本轮请求进行推理。
常见误区：模型在对话中“记住了我刚才说的话”，说明它已经在线学习。多数情况下只是历史消息再次进入上下文，模型参数并未更新。
02 一次请求要经过网关、排队、计算和返回
用户点击发送到看到完整答案，中间包含应用侧、服务侧和模型侧的多个阶段。
应用首先完成身份验证、权限检查、内容组装和参数设置，再把请求发送到模型网关或推理服务。服务端需要选择模型实例、进入调度队列，并将文本转换为 Token ID。输入越长、并发越高，排队和输入处理通常越明显。
模型接着经历 Prefill 和 Decode。Prefill 处理整段输入并建立后续生成需要的中间状态；Decode 根据已有输入与已经生成的 Token，计算下一个 Token 的候选分布。解码策略选出一个 Token 后，它会成为下一轮计算的一部分，如此循环，直到遇到结束条件。
企业助手例子：“分析这张票据”在模型调用前还要完成文件读取、OCR 或视觉编码、用户权限检查和 Schema 组装。模型生成后，应用仍要校验金额、日期和字段完整性。
常见误区：API 显示模型耗时两秒，就代表用户两秒得到结果。网络、排队、上下文构建、工具调用和前端渲染都可能增加端到端耗时。
03 Prefill 与 Decode 的计算特点不同
边界速记：Prefill 一次处理大量输入 Token；Decode 通常按步生成新 Token。两者面对的瓶颈、指标和优化方法并不相同。
Prefill 可以理解为“先读完整个题目”。模型并行处理请求中的系统指令、用户输入、检索证据和工具定义，为每一层 Attention 计算后续会复用的 Key、Value 等状态。输入上下文越长，这一阶段通常需要处理的数据越多。
Decode 可以理解为“开始逐步作答”。自回归模型每一轮生成一个新 Token，再把它追加到已有序列中继续生成。由于前面 Token 的状态通常已经放入 KV Cache，系统不必每轮从头计算全部历史，但每个新 Token 仍要经过模型层并访问缓存。
企业助手例子：阅读一份 60 页差旅制度后只回答“可以报销”，属于长 Prefill、短 Decode；根据简单要求生成一份详细行程方案，则可能是短 Prefill、长 Decode。
常见误区：上下文已经进入 KV Cache，后续生成就几乎没有成本。缓存避免重复计算历史状态，但新 Token 仍需计算，而且缓存本身占用显存和带宽。
04 模型先产生 Logits，再形成候选概率
模型不会一次“想好整句话”，而是在每一步对词表中的候选 Token 给出分数。
在某一轮 Decode 结束时，模型输出一组 Logits，可以理解为对词表中每个候选 Token 的未归一化分数。经过 Softmax 等处理后，这些分数可转成一个概率分布。解码策略再根据这个分布选择下一个 Token。
这里的“概率”描述的是模型在当前上下文和参数下更倾向生成哪个 Token，不是答案为真的概率。语言上常见、流畅的说法可能获得高分，但其中的日期、金额或政策仍然可能错误。
企业助手例子：模型认为“可”比“不可”更像下一个 Token，不代表它已经验证了最新制度。是否允许报销必须回到制度证据和业务规则检查。
常见误区：某个 Token 的生成概率很高，所以对应事实一定可信。生成倾向、模型校准和外部事实正确性是三个不同问题。
05 Greedy、Sampling 与 Beam Search 是不同解码策略
解码策略决定怎样从候选分布中选择序列，它不改变模型已经学到的知识。
Greedy Decoding 每一步都选择当前分数最高的 Token。它实现简单、行为通常较稳定，适合短分类、受限抽取或确定性要求较高的任务。但“每一步局部最高”不保证整段序列整体最好，长文本还可能出现重复或僵化。
Sampling 按调整后的概率分布抽样，因此同一输入可能得到不同结果。它适合头脑风暴、表达改写和候选方案生成，但多样性越高，输出结构和事实稳定性通常越需要额外控制。
Beam Search 同时保留多条候选序列并比较累计分数，常用于机器翻译、语音识别等序列任务。对开放式对话，它可能增加计算并产生表达趋同，不应因为“搜索更多路径”就被视作默认更优。Hugging Face 的生成文档也把这些方法作为不同策略，而不是固定升级顺序。Generation Strategies
企业助手例子：票据字段抽取倾向低随机性的单一结果；行程创意可以采样多个候选，再由预算、时间和政策规则筛选。
常见误区：Beam 数量越大，答案一定越聪明。它搜索的是当前模型分布下的候选序列，不会补充缺失知识，也可能增加延迟。
06 Temperature 改变分布形状，不代表置信度
边界速记：Temperature 是采样分布的调节方式，不是“模型认真程度”或“事实可信度”的旋钮。
Temperature 通常作用于 Logits。较低值会让高分候选更突出，分布更尖；较高值会拉近候选差异，增加抽到低概率 Token 的机会。它主要影响生成多样性，而不是让模型学会新事实。
对票据抽取、分类和结构化输出，团队通常更重视稳定性，会从低随机性配置开始评估。对标题、文案和路线创意，可以适度提高多样性并生成多个候选。但“低温度”不自动等于正确，“高温度”也不自动等于优质创意，最终仍要用任务数据评估。
企业助手例子：制度结论不能靠降低 Temperature 保证正确；它需要可靠证据、引用和规则校验。Temperature 只影响模型怎样表达或选择候选 Token。
常见误区：把 Temperature 调到零，模型就会像数据库一样只返回事实。生成目标和事实检索之间的差距仍然存在。
07 Top-k 与 Top-p 缩小候选集合
Top-k 按候选数量裁剪，Top-p 按累计概率质量动态裁剪。
Top-k 只保留当前分数最高的 k 个候选，再在其中采样。无论分布很集中还是很分散，候选数量都固定。k 太小可能限制表达，k 太大则接近未裁剪分布。
Top-p，也称 Nucleus Sampling，选择累计概率达到阈值 p 的最小候选集合。分布集中时保留的 Token 较少，分布不确定时保留的候选更多，因此集合大小会随每一步变化。原始工作关注开放式生成中固定候选截断的不足。The Curious Case of Neural Text Degeneration
企业助手例子：生成三种差旅行程时，可以通过采样增加候选差异；最终选择仍由航班时间、预算和员工偏好决定，而不是由 Top-p 直接决定。
常见误区：Top-p 为 0.9 表示答案有 90% 的概率正确。它表示候选 Token 集合的累计概率阈值，与事实正确率无关。
08 长度、停止与重复控制共同决定怎样结束
生成系统必须定义停止路径，不能只等待模型“自然说完”。
模型通常在生成结束 Token、达到最大输出 Token 数、匹配停止序列、触发内容策略、超时或被应用取消时停止。不同结束原因具有不同业务含义：正常结束可以进入验证；达到长度上限可能意味着结构被截断；安全拒答和服务错误则需要不同处理。
Max Output Tokens 是资源和风险边界，不是期望字数。设置过小会截断 JSON、引用或工具参数；设置过大则增加尾延迟和成本。Stop Sequence 可以帮助终止特定格式，但如果字符串也可能出现在正常内容中，就会产生提前停止。
企业助手例子：票据抽取达到长度上限时，系统不能把半段 JSON 当作“没有问题”，而应识别 incomplete 状态并重新请求或降级处理。
常见误区：输出被截断后，直接把最大 Token 翻倍就能解决。还要检查上下文预算、循环内容、停止条件和任务是否应该拆分。
09 Seed 与低随机性仍不等于绝对可复现
边界速记：可复现是一条端到端系统属性，不是单个 Seed 参数能够独立承诺的结果。
Seed 可以固定伪随机数序列，让支持该能力的服务在相同条件下更容易复现实验结果。但要接近可复现，还必须固定模型版本、请求内容、参数、工具结果、检索索引、服务实现和硬件执行条件。
即使不采样，底层并行计算、浮点运算顺序、推理引擎更新、动态批处理和路由策略也可能带来差异。PyTorch 的可复现说明明确指出，不同版本、平台和设备之间并不保证完全一致。PyTorch Reproducibility
企业助手例子：同一张票据两次生成的解释措辞可以不同，但金额、币种、日期和制度结论必须通过同一套确定性校验。
常见误区：Temperature 为零并设置 Seed 后，模型输出就能作为审计证据。审计需要保存输入、模型与配置版本、证据来源和最终业务判断。
10 Reasoning 预算控制推理投入，不保证答案正确
Reasoning Model 通常在给出最终答案前投入更多推理计算，但参数名称和具体机制不是统一行业标准。
一些模型服务提供 Reasoning Effort、Thinking Level 或 Thinking Budget，用于在延迟、成本和复杂任务表现之间做选择。简单抽取、路由和格式转换未必需要高推理投入；复杂比较、代码分析和多约束规划可能从更多计算中获益。
这类控制与 Temperature 不属于同一维度。Temperature 调整候选采样分布；Reasoning 配置影响模型在产生最终答案前投入的推理计算或 Token。不同模型对这些参数的支持、取值和计费方式都可能不同，例如 Google 的 Thinking 配置就会随模型系列变化。Gemini Thinking
企业助手例子：从票据中提取日期可以使用低推理配置；比较三套跨城方案并解释预算、会议时间和退改风险，可以提高推理投入后再评估收益。
常见误区：Reasoning Effort 调高后，事实和权限自动更可靠。它不能替代 RAG、权限系统、工具结果和业务校验。
11 Streaming 改善等待体验，但不等于总计算更快
流式响应把已经生成的内容尽早交给用户，核心改善通常是可感知等待，而不是减少全部计算。
Time to First Token（TTFT）表示请求发出后到收到首个输出 Token 的时间，通常包含网络、排队、分词和 Prefill。Time per Output Token（TPOT）描述开始生成后每个 Token 的平均间隔。端到端延迟则从用户发起请求一直计算到完整结果可用。
Streaming 允许服务通过 SSE、WebSocket 或其他事件通道逐步发送增量结果。用户可以更早看到回答，界面也能显示阶段状态或支持取消。但如果业务必须等待完整 JSON、引用或工具参数验证后才能继续，首个 Token 到达并不代表任务已经完成。
企业助手例子：行程建议可以边生成边展示；创建差旅申请的参数必须在完整返回并通过 Schema、权限和金额检查后才能进入审批。
常见误区：开启 Streaming 后模型生成速度会自动提高。它可能降低用户等待首字的感受，但总 Token 数和模型计算未必减少。
12 KV Cache 与 Prefix Cache 减少重复计算
边界速记：KV Cache 保存 Attention 计算需要的中间状态；Prefix Cache 尝试让共享前缀跨请求复用。它们都不是业务记忆。
自回归生成时，如果每轮都重新计算全部历史 Token，成本会快速增加。KV Cache 保存各层已处理 Token 的 Key 和 Value，使下一轮主要计算新 Token，并读取已有状态。序列越长、并发越高，缓存占用通常越大，因此它既是加速机制，也是显存管理问题。
Prefix Cache 在多个请求拥有完全相同前缀时，进一步复用对应缓存。例如固定系统指令、相同长文档或多轮会话前缀可能受益。vLLM 将 Automatic Prefix Caching 描述为复用共享前缀的 KV Cache，从而跳过重复 Prefill 计算。Automatic Prefix Caching
缓存命中不会改变模型知识，也不保证回答更准确。多租户系统还必须把模型版本、适配器、权限和缓存键纳入隔离设计，避免不属于当前用户的敏感前缀被错误复用或通过侧信道暴露。
企业助手例子：多位员工都使用同一版公开差旅制度时可以评估共享前缀缓存；包含个人票据、审批意见或私密行程的上下文不能无条件共享。
常见误区：开启 Prefix Cache 后，模型就拥有了长期记忆。缓存只服务于计算复用，业务记忆仍需独立存储、权限和生命周期管理。
13 Continuous Batching 在吞吐与延迟间调度
批处理不是简单“等够一批再算”，现代推理服务会在生成过程中持续加入和移出请求。
传统静态批处理通常等一组请求凑齐后共同执行，整批完成才能释放位置。生成任务长度差异很大，短请求容易被长请求拖住。Continuous Batching 会在迭代边界持续重新组织批次：完成的请求离开，新请求可以进入，以提高设备利用率和总体吞吐。
但吞吐与单请求延迟不是同一个指标。更大的批次可能提高每秒处理 Token 数，也可能增加排队或每轮调度开销。长上下文 Prefill 还可能阻塞正在 Decode 的交互请求，因此一些引擎提供 Chunked Prefill 或 Prefill/Decode 分离等策略。vLLM 当前将 Continuous Batching、Chunked Prefill、Prefix Caching 等列为推理服务能力。vLLM Documentation
企业助手例子：员工正在等待的制度问答关注 TTFT；夜间批量生成差旅报告更关注总吞吐。两类请求混在同一队列可能互相影响。
常见误区：GPU 利用率越高，用户体验一定越好。设备满载可能伴随更长排队和更差尾延迟，需要同时观察吞吐与延迟分位数。
14 Speculative Decoding 用草拟与验证加速
推测解码让较快的草拟过程一次提出多个候选，再由目标模型并行验证，而不是直接用小模型替代大模型。
标准 Decode 通常每轮只确认一个新 Token。Speculative Decoding 使用草拟模型、N-gram、模型原生多 Token Prediction 或其他方法先提出多个 Token，目标模型一次验证这些候选。被接受的 Token 可以连续加入结果，被拒绝的位置则回到目标模型分布继续生成。
在满足相应接受与采样规则时，这类方法可以保持目标模型的输出分布，而重点减少逐 Token 等待。但加速幅度取决于草拟成本、接受率、硬件、批量大小和流量。vLLM 官方文档也明确建议按工作负载基准测试，并指出不同方法存在适用范围与兼容限制。Speculative Decoding
企业助手例子：面向用户的长文本行程建议可能关注逐 Token 延迟，可以测试推测解码；短分类或高吞吐批任务未必获得同样收益。
常见误区：推测解码就是先让小模型写答案，再让大模型润色。核心是 Token 级候选与验证，不是两个模型串行完成两篇文本。
15 企业助手的完整推理链路与选型清单
可靠推理需要同时设计生成语义、服务性能和模型外验证，不能只调整一个采样参数。
企业助手收到请求后，应用先完成身份、任务识别和 Context Builder 组装，再通过模型网关选择模型、版本和推理策略。推理服务负责排队、Prefill、Decode、缓存和流式返回；应用侧解析完成状态，执行 Schema、事实、权限和业务规则验证，最后决定展示、重试、降级或进入审批。
四类任务可以使用不同配置。制度问答强调证据引用与低随机性；票据抽取强调结构完整和失败检测；行程建议允许生成多个候选，但必须经过预算和时间约束；创建申请属于写入动作，模型只能提出参数，执行前还要授权、审批和幂等检查。
选型时至少回答六个问题：任务需要稳定还是多样；输入和输出分别多长；是否值得增加 Reasoning 预算；用户关注 TTFT 还是完整结果；是否存在可复用前缀；结果怎样被验证。随后再决定采样、长度、流式、缓存和调度配置，并在真实任务集和真实流量上测量。
企业助手例子：“解释制度”可以流式展示并附引用；“提取票据”应等待完整结构；“设计路线”可以生成多个候选；“创建申请”必须在模型输出之外完成权限与审批。
常见误区：找到一组 Temperature、Top-p 和 Reasoning 参数，就能作为所有功能的统一最佳配置。任务目标、流量和风险不同，配置也必须分开评估。
我现在把一次请求记成四个阶段：PREFILL 处理输入，DECODE 逐步生成，SAMPLE 选择候选，STREAM 交付结果。这四个动作解释生成过程，但生产质量还来自 Context、Schema、外部验证、权限和完整 Trace。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
