大模型推理优化的几个关键技术点

Wed, 15 Apr 2026 00:00:00 +0000

为什么推理优化越来越重要

训练一次大模型成本高，但跑起来之后每天都要服务大量用户，长期来看推理成本远高于训练成本。一个 70B 模型如果用 FP16 直接跑，单卡 A100 80G 都装不下，更不用说提供低延迟服务。所以推理优化不是锦上添花，而是落地的前提。

下面整理几个工程上最常用、收益最显著的优化方向。

1. KV Cache 是性能的核心

Transformer 自回归生成时每生成一个 token 都要重新计算所有历史 token 的 K 和 V，这是 O(n²) 的浪费。KV Cache 把之前算过的 K/V 缓存下来，每步只算新 token 的 K/V，复杂度降到 O(n)。

但 KV Cache 本身会吃巨量显存：一个 13B 模型、序列长度 4K、batch 16，KV Cache 就要十几 GB。所以衍生出一系列优化：

PagedAttention（vLLM 提出）：把 KV Cache 按"页"管理，避免连续显存碎片化，吞吐能提 2-4 倍
GQA / MQA：让多个 Query Head 共享同一组 K/V Head，KV Cache 大小直接砍几倍，Llama 3 就用了 GQA
量化 KV Cache：把 KV Cache 从 FP16 量化到 INT8 甚至 INT4，显存减半但精度损失很小

2. 量化：用精度换显存和速度

权重量化的核心思路是：模型权重是 FP16 (16 bit)，但实际有效信息可能只需要 4 bit 就能表达。常见方案：

Prompt 工程的几种核心模式与实战示例

Sat, 28 Mar 2026 00:00:00 +0000

引言

Prompt 工程不是玄学。表面看是"会不会写话"，本质上是对模型能力边界的工程性利用。下面整理我在生产项目中验证有效的几种核心模式。

模式一：角色 + 任务 + 约束 + 输出格式

最基础但被严重低估的模式。一个完整的 Prompt 至少要包含这四块：

你是一名资深的 SQL 性能专家（角色）。
请审查以下 SQL 查询并指出可能的性能问题（任务）。
要求：
- 只关注会导致全表扫描或 N+1 问题的写法（约束）
- 不要建议添加索引（约束）
输出 JSON 格式（输出格式）：
{
"issues": [
{"line": 行号, "problem": "...", "fix": "..."}
]
}

为什么有效：每一块都在收窄模型的"概率云"。少了角色，模型不知道用什么专业度回答；少了输出格式，下游无法解析。

模式二：Few-shot 示例

模型从描述中学习有上限，但从示例中学得很快。一两个高质量示例往往胜过 500 字的描述。

关键原则：

示例要覆盖边界情况，而不是只展示典型情况
示例之间要有对比性，让模型理解为什么这样而不是那样
示例数量 1-5 个最佳，太多反而稀释主任务

实战例子：做情感分类时，光给"好评/差评"两个示例不够，加上"中性评论"“讽刺好评"“含吐槽的好评"等边界案例，效果显著提升。

模式三：Chain of Thought

让模型先"思考"再回答，复杂推理任务的标配。两种触发方式：

显式触发：

请一步步思考，先分析问题再给出最终答案。

隐式触发（更优）：

请按以下步骤完成：
1. 列出问题中的所有已知条件
2. 识别需要求解的目标
3. 选择合适的求解方法
4. 执行计算
5. 验证答案的合理性

第二种把"思考"结构化，模型不会跳步，且每一步都可以单独检查。

模式四：自我校验与反思

让模型质疑自己的输出。有两种实现：

LLM on AI 拾遗笔记