跳转至

LLM 基础工程概念

我不是面试大模型算法岗，所以不需要从 Transformer 公式、训练细节讲到很深。但做 Agent、RAG、Tool Call 这类应用，还是需要理解一些常见工程概念：温度、Top-K、Top-P、KV Cache、Prompt Cache、量化模型。

解码参数：Temperature、Top-K、Top-P

LLM 生成文本时，本质上是在一步步预测下一个 token。模型每一步都会给出一组候选 token 的概率分布，解码参数决定“从这些候选里怎么选”。

Temperature

Temperature 控制输出的随机性。

温度越低，模型越倾向于选择概率最高的 token，输出更稳定、更保守、更可复现；温度越高，低概率 token 也更容易被选中，输出更多样、更有创造性，但也更容易跑偏。

一般来说：

  • 代码生成、事实问答、RAG、工具调用：用低温度，比如 0 到 0.3。
  • 创意写作、头脑风暴、营销文案：可以适当提高，比如 0.7 到 1。

温度不是“智商旋钮”。调高温度不会让模型更聪明，只是让采样更随机。

Top-K

Top-K 的意思是每一步只从概率最高的 K 个 token 里选。

比如 top_k=50，模型先把所有候选 token 按概率排序，只保留前 50 个，剩下的全部丢掉，再从这 50 个里面采样。

K 越小，输出越保守；K 越大，候选范围越宽，输出越多样。

Top-P

Top-P 也叫 nucleus sampling，意思是只保留累计概率达到 P 的那一小批 token。

比如 top_p=0.9，模型会从最高概率 token 开始往下加，直到累计概率达到 90%，只在这批 token 里采样。

Top-K 是固定保留 K 个候选，Top-P 是按概率质量动态决定保留多少个候选。实际使用里，Top-P 比 Top-K 更常见，因为它会根据当前分布自动调整候选集合大小。

怎么调

工程上不要同时把所有参数都调得很激进。一般先固定 Top-P，比如 0.9 或 0.95，再调 Temperature。

对 Agent 和 Tool Call 来说，稳定性通常比创造性重要，所以温度应该偏低。否则模型更容易乱选工具、编参数、输出不稳定格式。

KV Cache

KV Cache 是大模型自回归推理里的基础机制，几乎所有高效推理都离不开它。

Transformer 生成文本时，每生成一个新 token，都要关注前面已经出现过的 token。如果每一步都从头重新计算整段上下文，成本会非常高。

KV Cache 的做法是：把前面 token 在注意力层里算出来的 Key、Value 缓存起来。下一步生成新 token 时，不用重新计算前面所有 token 的 Key、Value，只需要计算新 token 自己的部分，再和缓存里的内容做注意力。

直观理解：

没有 KV Cache：每生成一个字，都重新读完整篇上下文
有 KV Cache：前面读过的内容做成笔记，后面只增量处理新字

KV Cache 的价值是降低生成阶段延迟，尤其是长上下文、多 token 输出时非常重要。代价是占显存或内存，因为缓存会随着上下文长度和并发请求数增长。

所以服务端部署模型时，经常会遇到一个取舍：上下文越长、并发越高，KV Cache 占用越大，能同时服务的请求数就越少。

Prompt Cache

Prompt Cache 和 KV Cache 不是同一层东西。

KV Cache 是推理运行时的底层缓存机制；Prompt Cache 更偏产品/API 层，是后来服务商暴露出来的“跨请求复用相同 prompt 前缀”的能力。它通常建立在前缀预计算和缓存复用之上，但调用者感知到的是一个 API 能力，而不是模型架构本身的新组件。

很多应用的 prompt 前半部分是固定的，比如 system prompt、工具说明、长文档前缀、固定业务规则。不同用户请求都带着同一大段前缀，如果每次都重新计算这段前缀，就很浪费。

Prompt Cache 的思路是：把这段固定前缀预先计算并缓存起来。后续请求如果命中相同前缀，就可以复用缓存，减少首 token 延迟和输入 token 成本。

直观理解：

KV Cache：推理底层机制，同一次生成里别重复算已经生成/读过的 token
Prompt Cache：服务/API 层能力，多次请求之间别重复算相同的 prompt 前缀

量化模型

量化模型就是把模型权重从高精度数值压缩成低精度数值。

常见模型训练和推理会用 FP16、BF16 这类 16 位浮点数。量化会把权重压到 INT8、INT4，甚至更低。这样模型体积更小，占用显存更少，推理也可能更快。

直观理解：

原始模型：每个参数用更精细的数字保存，质量更稳，但更占显存
量化模型：每个参数用更粗的数字保存，省显存、省成本，但可能损失效果

量化的价值：

  • 能在更小显存的机器上跑更大的模型。
  • 降低部署成本。
  • 提高吞吐或降低延迟，具体取决于硬件和推理框架。

量化的代价：

  • 输出质量可能下降，尤其是复杂推理、代码、数学、多语言场景。
  • 量化越激进，风险越大。INT8 通常比较稳，INT4 更省但更容易损失效果。
  • 不是所有硬件和推理框架都能从量化里获得同样收益。

所以选量化模型不能只看“参数量”和“显存占用”，还要在自己的任务上评估。比如客服问答可能 4-bit 也够用，但代码生成、安全审查、复杂 Agent 规划可能需要更高精度。