AI Knowledge

外观

LLM 推理与服务优化 极简一问一答 ​

定位｜ LLM 推理与服务优化 一分钟速答页。每章固定 10 题，只保留结论、机制、边界与验证关键词；单个回答控制在 10～60 秒。

1. 怎么使用 ​

本页重点｜ L1 概念 → L2 边界 → L3 原理 → L4 实现 → L5 工程 → L6 架构 → L7 复盘 → 误区、验证、证据强化。不会展开时，再进入正式主题或专项题库。

图：LLM 推理与服务优化 十题极简脑图

替代文本： LLM 推理与服务优化从 L1 概念和 L2 边界，依次进入 L3 原理、L4 实现、L5 工程、L6 架构与 L7 项目复盘，再用误区、最小自测和证据边界三题强化。

图表加载中…

读图结论： 掌握 LLM 推理与服务优化 不能停在定义；先顺着七层链路说清机制与工程，再用误区、自测和证据边界确认没有虚假掌握。

2. 极简一问一答 ​

Q001｜LLM 推理为什么要区分 Prefill、Decode 和流式返回？

文本先 Tokenize，Prefill 并行处理完整 Prompt 并建立各层 KV Cache，Decode 再逐 Token 生成并追加缓存，Detokenize/Stream 将新 Token 增量返回。首个可见 Token 前的时间是 TTFT，后续相邻 Token 的延迟常用 ITL/TPOT 描述，端到端时间还受输出长度和停止条件影响。

Q002｜Greedy、Temperature、Top-k 和 Top-p 怎样影响生成？

Greedy 每步选择最大 Logit；Temperature 用 softmax(z/T) 调整分布尖锐度；Top-k 只保留最高的 k 个候选，Top-p 取累计概率达到阈值的最小候选前缀后重归一化。采样只改变已有分布，不能补充缺失事实；工程 API 常把零温实现为 Greedy 特例，不能直接除以 0。

Q003｜Prefill 与 Decode 的计算和 KV 张量有何不同？

Prefill 对完整 Prompt 做并行前向并写入各层 K/V；Decode 第 t 步只输入新 Token，Query 形如 [B,h_q,1,d_h]，缓存 K/V 各为 [B,h_kv,t,d_h]，新 K/V 再追加一个位置。MHA 通常 h_kv=h_q，GQA 让一组 Query 头共享 K/V，MQA 常令 h_kv=1，因此后二者能减少 Cache 和带宽。

Q004｜KV Cache 显存如何估算，它改变了什么复杂度？

忽略元数据、对齐和碎片，KV 理论字节约为 2×L×B×h_kv×t×d_h×s，其中 2 表示 K/V，s 是每元素字节数。KV Cache 保存每层历史 K/V，使后续步骤无需把全部历史 Token 重新跑过各层的 Attention、投影和 FFN；但当前新 Token 仍要执行自身的投影与 FFN，并用新 Query 读取全部历史 K/V。初始 Prompt 长度为 P、生成 T 个 Token 时，单层 Decode Attention 累计约为 O((PT+T²)d)，全部 L 层为 O(L(PT+T²)d)；稠密投影与 FFN 还包含约 O(LT(d²+d·d_ff)) 的新 Token 计算。因此 Cache 用显存换掉历史前缀重算，但每步并非 O(1)。

Q005｜Continuous Batching 与 Paged KV 分别解决什么问题？

Continuous Batching 在迭代边界移除完成请求、加入新请求，以动态批次摊薄权重读取并提高设备利用率；Paged KV 把逻辑连续 Cache 映射到固定大小物理块，减少连续预留与碎片。调度等待、大 Prompt 阻塞 Decode、块管理、抢占和租户公平都会影响 TTFT/ITL 尾延迟，因此吞吐提升不等于单请求更快。

Q006｜如何设计量化、准入和降级一体化的推理服务？

权重、激活或 KV 量化能降低位宽与部分容量/带宽，但实际速度取决于硬件内核、反量化、batch 和瓶颈位置，必须用固定质量集与目标硬件实测。入口按实际 Token、最大输出、模型/Adapter 和 KV 水位准入，过载时有界排队、限流或降级；断连传播取消，流式后重试使用幂等与明确状态。请求内 Paged KV 由 Run/Sequence ID、块表和生命周期管理，不依赖内容语义命中；只有跨请求复用的 Prefix Cache 才需要严格 Cache Key，至少绑定租户或安全域、模型权重、Adapter、Tokenizer、模板、精确 Token ID、位置/RoPE 语义、KV dtype/layout 和 Cache 配置，任一影响 Logit 的字段变化都必须失效。

Q007｜如何设计多租户企业 LLM Gateway？

这是源文档中的示例项目：网关负责鉴权、租户限流、请求幂等键和 Token/KV 预算，调度器区分交互与离线负载并执行 Continuous Batching，Worker 绑定模型、量化、Adapter 和 Tokenizer 制品。每个 Run 记录 queued → prefill → streaming → completed/failed/cancelled → billed 状态与流式事件序号；首个片段发出后不盲目重跑，而是按 Run ID 查询状态、返回已持久化结果，或在协议支持时从事件序号续传。计费账本以租户、业务幂等键和计费类型建立唯一约束，取消和异常退出必须释放并对账 KV 块；Trace 记录队列、TTFT、ITL、Token、显存、事件序号与结束原因。仓库没有运行服务或压测，不能声称吞吐、延迟、成本或加速倍数。

Q008｜这个专题最常见的误区是什么？

常见误区有三类：认为模型一次前向就产生完整文本，或把流式输出等同总耗时下降；只按参数量估算服务显存，或声称 KV Cache 使 Attention 成为 O(1)；声称 INT4 固定快四倍，流断后无条件重试，或 Cache Key 漏掉 Adapter/模板/位置语义。

Q009｜怎样做最小自测？

最小自测分三步：画出 Tokenize → Prefill → Decode → Stream，并标注 TTFT/ITL；给定层数、KV 头、头维、长度、并发和 dtype 计算理论 Cache；用固定 Logits 比较 Greedy、Temperature、Top-k 和 Top-p。

Q010｜回答这个专题时，证据边界是什么？

KV Cache 不会让每步 Attention 变成 O(1)，量化和批处理也没有脱离硬件与负载的固定加速倍数。

3. 总结 ​

一句话记忆： 文本先 Tokenize，Prefill 并行处理完整 Prompt 并建立各层 KV Cache，Decode 再逐 Token 生成并追加缓存，Detokenize/Stream 将新 Token 增量返回。

  • 文本先 Tokenize，Prefill 并行处理完整 Prompt 并建立各层 KV Cache，Decode 再逐 Token 生成并追加缓存，Detokenize/Stream 将新 Token 增量返回。
  • Continuous Batching 在迭代边界移除完成请求、加入新请求，以动态批次摊薄权重读取并提高设备利用率。
  • 常见误区有三类：认为模型一次前向就产生完整文本，或把流式输出等同总耗时下降。
  • KV Cache 不会让每步 Attention 变成 O(1)，量化和批处理也没有脱离硬件与负载的固定加速倍数。