延迟从哪来：prefill 决定首字，decode 决定逐字
要优化先懂 LLM 推理分两段：prefill（把你的输入一次性算完，计算受限，决定首 token 延迟 TTFT）和 decode（一个一个吐字，显存带宽受限，决定逐 token 速度）。一个关键不对称：输出 token 比输入更贵也更慢——所以减少生成长度、限 max_tokens、用流式改善体感，是性价比最高的第一招。
显存里最大的占用是 KV cache（存已算过的注意力）：朴素管理会浪费 60–80% 显存；PagedAttention（vLLM）借操作系统的分页思想管理，把浪费降到不到 4%、吞吐翻几倍。配套的连续批处理（continuous batching）把调度从「请求级」降到「迭代级」，一个序列完成就立刻替补新请求，大幅提吞吐。
五个降本提速的实招
① Prompt caching：缓存命中的输入只按基础价的 10% 计费，还压低首 token 时间——对有大段固定前缀（系统提示 / 文档）的场景特别香。② Batches API：牺牲实时性，输入输出 token 都打五折、24 小时内返回——适合离线批量。③ 模型级联 / 路由（FrugalGPT）：先用便宜模型、不够格再升级到贵的，能在保持 GPT-4 质量下省最高 98%。
④ 提示压缩（LLMLingua）：用小模型按信息量删冗余 token，最高 20x 压缩、性能几乎不掉。⑤ 投机解码（speculative decoding）：小草稿模型先猜一串、大模型并行验证，无损加速约 2–3 倍（输出分布不变，代价是要多跑一个小草稿模型）。最该破的误区：以为「换更大模型」就能解决一切——多 agent 架构本身就把 token 成本放大约 15 倍，先优化架构和上面这些手段，再谈换模型。
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
LLM 推理里，决定「首 token 延迟（TTFT）」的主要是哪一段？
答案：prefill（一次性算完输入，计算受限）
prefill 把输入算完，决定首字延迟；decode 一个一个吐字，决定逐字速度。
下面哪个是「在保持质量的前提下降本」的手段？
答案：模型级联 / 路由：先用便宜模型，不够格再升级到贵的（FrugalGPT 省最高 98%）
FrugalGPT 按置信度从便宜到贵级联，保 GPT-4 质量省最高 98%；prompt caching / batches / 压缩 / 投机解码也是降本提速实招。
判断对错：「Agent 又慢又贵，最直接有效的办法就是换一个更大更强的模型。」
答案：错误
换更大模型往往更贵更慢；应先优化架构 + prompt caching（读缓存仅 10% 价）/ 批处理（五折）/ 路由 / 压缩 / 投机解码。多 agent 本身已放大约 15 倍成本，架构优先。