上一篇我们把一次请求拆成了 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 一次处理大量输入 TokenDecode 通常按步生成新 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 TokenTTFT表示请求发出后到收到首个输出 Token 的时间通常包含网络、排队、分词和 Prefill。Time per Output TokenTPOT描述开始生成后每个 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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】