你好 👋

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

背景 Agent 框架今年井喷，光开源的就十几个。最近为公司一个新项目调研选型，把主流的几个都跑了一遍，记录下来供参考。 评测维度：核心抽象、上手难度、可控性、可观测性、多智能体支持、生产可用性。 LangGraph LangChain 团队的下一代产品，基于"图"抽象。每个节点是一个函数（可以是 LLM 调用、工具执行、条件判断），边定义流转逻辑。 核心抽象：StateGraph（有状态有向图）、Node、Edge、Checkpoint。 优点： 控制流极其清晰，可视化调试方便（LangSmith） 内建 checkpoint 机制，天然支持人在回路（Human-in-the-loop） 状态管理设计精良，能优雅处理长流程的中断与恢复 和 LangChain 生态无缝衔接 缺点： 概念多，学习曲线陡 写起来比较繁琐，简单任务也得搞一堆样板代码 性能一般，每次状态更新都有序列化开销 适合：复杂工作流、需要中断恢复、对可观测性要求高的生产系统。 AutoGen 微软出品，主打对话驱动的多智能体协作。每个 Agent 都有自己的角色和系统提示，通过对话相互协作完成任务。 核心抽象：ConversableAgent、GroupChat、UserProxyAgent。 优点： 多智能体协作的范式最自然，符合直觉 写代码几乎不需要新语法，就是配置 Agent 然后开始对话 v0.4 重构后引入 Actor 模型，并发能力大幅增强 微软背景，Studio 工具链完善 缺点： 控制流隐式，调试困难，经常不知道为什么某个 Agent 突然不发言了 上下文管理粗糙，长对话容易爆 context 早期版本 API 变动大，v0.2 → v0.4 是破坏性升级 适合：研究性质、原型探索、需要多角色协作的场景（如代码评审、辩论、头脑风暴）。 CrewAI 后起之秀，强调"角色 + 任务"的工作分配模式。每个 Crew 包含多个 Agent，每个 Agent 有明确的 role/goal/backstory，按 Task 顺序执行。 核心抽象：Crew、Agent、Task、Process（顺序/层级）。 优点： 上手最快，10 行代码能跑起来一个多智能体团队 角色定义直观，业务人员也能看懂 文档清晰，社区增长快 缺点： ...

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

为什么要本地部署 不是所有任务都适合调 API： 数据敏感：金融、医疗、法务领域不允许数据出本地网络 成本可控：高频调用时本地推理成本远低于 API（哪怕算上电费和折旧） 延迟稳定：不受外网波动影响 可定制：可以微调、量化、修改采样策略 下面按使用场景介绍几种主流方案。 方案一：Ollama —— 个人开发首选 最适合"我想在 Mac 上跑个 Llama 玩玩"的场景。 安装与使用： brew install ollama ollama run llama3.1:8b 完事。一行命令拉模型，一行命令开始对话。还提供 OpenAI 兼容 API： curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "llama3.1:8b", "messages": [...]}' 优点： 安装零摩擦，模型管理像 Docker 自动选择最优后端（Metal / CUDA / CPU） 支持 Modelfile 自定义系统提示词 模型库丰富（Llama、Qwen、Mistral、DeepSeek 等都有） 缺点： 性能不是最优，吞吐一般 不适合多用户并发场景 对自定义模型格式支持有限 方案二：llama.cpp —— CPU/边缘设备之王 底层是 Ollama 用的引擎，但直接用 llama.cpp 能拿到更多控制权。 核心优势是 GGUF 量化格式： 量化等级 模型大小（13B） 质量损失 推荐场景 Q2_K 5.4 GB 明显 极限场景 Q4_K_M 7.9 GB 很小 推荐默认 Q5_K_M 9.2 GB 几乎无 高质量需求 Q8_0 13.8 GB 无 接近 FP16 实测在 M2 MacBook 上，Q4 量化的 Llama 3 8B 能跑到 30+ tokens/s，Q4 量化的 70B 也能跑到 5-8 tokens/s，离线使用完全够用。 ...

为什么 Embedding 选型很重要 RAG 系统的天花板在很大程度上由 Embedding 模型决定。Embedding 不准，后面的 Rerank 和生成再厉害也救不回来。 中文场景比英文复杂：词的边界模糊、同义词多、行业术语差异大，对模型的理解力要求更高。 下面整理目前（2026 年初）值得选用的中文 Embedding 模型，按使用场景分类。 通用首选：BGE 系列 智源（BAAI）出品，目前中文 Embedding 的事实标准。 主力型号： bge-large-zh-v1.5：1024 维，1.3GB，通用场景最佳 bge-base-zh-v1.5：768 维，400MB，性能/速度平衡 bge-small-zh-v1.5：512 维，100MB，资源受限场景 特点： C-MTEB 中文榜单长期前列 训练数据覆盖广，开箱即用 HuggingFace、ModelScope 都有，部署友好 典型用法： from sentence_transformers import SentenceTransformer model = SentenceTransformer('BAAI/bge-large-zh-v1.5') embeddings = model.encode(texts, normalize_embeddings=True) 注意：BGE 在做相似度查询时，建议给 query 加前缀 "为这个句子生成表示以用于检索相关文章："，能提升 1-2 个点。 多语言场景：BGE-M3 如果业务有跨语言需求（中英混合查询、跨语言检索），BGE-M3 是最强选择。 核心特点： 同时支持稠密向量、稀疏向量、ColBERT-style 多向量 100+ 语言原生支持 单模型出三种检索信号，下游融合方便 适合场景： 跨境电商、出海业务 中英文混合的技术文档检索 需要多路召回的高级 RAG 系统 高性能选择：GTE 系列 阿里通义出品，性能在某些 benchmark 上反超 BGE。 ...