工程实践

为什么推理优化越来越重要 训练一次大模型成本高，但跑起来之后每天都要服务大量用户，长期来看推理成本远高于训练成本。一个 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 就能表达。常见方案： ...

写在前面 过去一年深度参与了三个生产级 RAG 系统的搭建，从最初的 demo 到稳定服务百万级查询，踩过的坑足够写本书。这里挑几条最有共鸣的经验。 1. 文档切分策略远比你想的重要 很多人直接 RecursiveCharacterTextSplitter 切 500 字一段就完事了，效果当然不好。 真正有效的切分原则： 按语义边界切：标题、段落、列表项是天然分割点。Markdown 文档优先按标题层级切（H1/H2/H3），保留上下文层级 保留元数据：每个 chunk 至少要带：文档来源、章节标题路径、原始位置。检索时这些都是重要信号 重叠策略：chunk 之间保留 10-20% 重叠，避免把关键信息切在边界 chunk 大小自适应：FAQ 类用 200-400 token，技术文档用 500-800 token，叙述性文档用 1000+ token 实测：从"无脑切 500"换到"按 Markdown 标题切 + 携带 H1>H2>H3 路径"，准确率提升约 15%。 2. 单纯向量检索不够，混合检索才是基线 Embedding 擅长语义相似，但对精确匹配（产品代号、人名、专有术语）非常弱。生产环境基本都是混合检索： 最终得分 = α × 向量相似度 + (1-α) × BM25 得分 进阶玩法： 多路召回 + RRF 合并：BM25、向量、ColBERT、关键词扩展各召回一批，用 Reciprocal Rank Fusion 合并 Query 重写：用小模型把用户口语化提问改写成检索友好的形式 HyDE：让 LLM 先针对问题"幻觉"出一个假设答案，用这个假设答案的 embedding 去检索（适合长尾问题） 3. Rerank 是性价比最高的优化点 向量检索召回 50-100 条，再用 Cross-Encoder 模型对这些候选打分排序，只把 Top 5 喂给 LLM。 ...

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