LLM

为什么推理优化越来越重要 训练一次大模型成本高，但跑起来之后每天都要服务大量用户，长期来看推理成本远高于训练成本。一个 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 工程不是玄学。表面看是"会不会写话"，本质上是对模型能力边界的工程性利用。下面整理我在生产项目中验证有效的几种核心模式。 模式一：角色 + 任务 + 约束 + 输出格式 最基础但被严重低估的模式。一个完整的 Prompt 至少要包含这四块： 你是一名资深的 SQL 性能专家（角色）。 请审查以下 SQL 查询并指出可能的性能问题（任务）。 要求： - 只关注会导致全表扫描或 N+1 问题的写法（约束） - 不要建议添加索引（约束） 输出 JSON 格式（输出格式）： { "issues": [ {"line": 行号, "problem": "...", "fix": "..."} ] } 为什么有效：每一块都在收窄模型的"概率云"。少了角色，模型不知道用什么专业度回答；少了输出格式，下游无法解析。 模式二：Few-shot 示例 模型从描述中学习有上限，但从示例中学得很快。一两个高质量示例往往胜过 500 字的描述。 关键原则： 示例要覆盖边界情况，而不是只展示典型情况 示例之间要有对比性，让模型理解为什么这样而不是那样 示例数量 1-5 个最佳，太多反而稀释主任务 实战例子：做情感分类时，光给"好评/差评"两个示例不够，加上"中性评论"“讽刺好评"“含吐槽的好评"等边界案例，效果显著提升。 模式三：Chain of Thought 让模型先"思考"再回答，复杂推理任务的标配。两种触发方式： 显式触发： 请一步步思考，先分析问题再给出最终答案。 隐式触发（更优）： 请按以下步骤完成： 1. 列出问题中的所有已知条件 2. 识别需要求解的目标 3. 选择合适的求解方法 4. 执行计算 5. 验证答案的合理性 第二种把"思考"结构化，模型不会跳步，且每一步都可以单独检查。 模式四：自我校验与反思 让模型质疑自己的输出。有两种实现： ...