怎么读这一页。本书把知识分成两层（0.2）：原理层写进正文，工具层集中在这里和各章的虚线侧栏。这一页的全部内容都会过期——这是设计，不是缺陷。它的存在是为了让正文能长期保持稳定，把易变的部分隔离在一处、低成本更新。
每一节都标注了「截至 YYYY-MM」。如果日期距今已久，请默认它已经过期；具体参数与价格一律以官方文档为准。本页不给任何价格数字——价格是变化最快的一类信息，写进来只会误导。
| 框架 | 特点 | 适合 |
|---|---|---|
| vLLM | PagedAttention 的出处与参考实现；生态最广，社区活跃 | 大多数自托管场景的默认选择 |
| SGLang | RadixAttention 自动跨请求前缀复用；结构化输出支持好 | 多轮对话、few-shot、前缀共享度高的负载 |
| TensorRT-LLM | NVIDIA 硬件上的 kernel 级优化 | 确定用 NVIDIA 硬件且追求极致性能 |
| TGI | HuggingFace 生态集成度高；已进入维护模式，仓库已归档，上游建议新项目改用 vLLM / SGLang（2026-09 核实） | 存量部署；新项目不建议 |
| llama.cpp / Ollama | CPU 与端侧推理，GGUF 格式 | 本地开发、离线部署、消费级硬件 |
--gpu-memory-utilization：控制可用于 KV cache 的显存上限。OOM 时调低，并发不足时调高。
--max-num-seqs：批内最大并发序列数，控并发上限。
--max-num-batched-tokens：单次迭代的 token 预算，同时影响 prefill 切块大小。它是 TTFT 与 TPOT 平衡的主要手柄（2.1）。
--enable-prefix-caching：自动前缀缓存。当前版本对支持的模型默认已开启，需要关闭时用 --no-enable-prefix-caching（2.2）。
--block-size：KV cache 分页块大小，通常无需改动。
调参前先明确瓶颈：是显存受限还是算力受限（2.4）。方向搞错时，任何参数都调不出效果。
| 格式 | 量化对象 | 适用 |
|---|---|---|
| GPTQ / AWQ | 仅权重，4-bit | 显存受限；社区有大量预量化权重可直接下载 |
| FP8 | 权重 + 激活 | 较新硬件（Hopper 及之后）；高并发服务端吃到低精度算力的主要路线之一 |
| FP4（NVFP4 / MXFP4） | 4-bit 浮点格式；具体配方可能只量化权重（如 W4A16），也可能权重 + 激活一起量化（如 W4A4），激活精度按模型与推理后端确认 | Blackwell 及之后原生支持 FP4 计算；可降低被量化张量的占用，整机显存、带宽与速度取决于 W4A16 / W4A4 配方、模型、负载和后端，质量需按任务评测 |
| GGUF（Q4_K_M 等） | 仅权重，多档位 | 本地 / CPU / 端侧；2-bit 档位质量风险明显 |
| KV cache 量化（FP8/INT8） | KV cache | 与权重量化正交可叠加；直接放大并发上限，性价比常被低估 |
选型顺序：先问「是显存装不下，还是速度不够？」显存问题 → 4-bit 仅权重 + KV cache 量化；速度问题且硬件支持 → 在目标硬件、模型与负载上比较 FP8 和可用的 FP4 配方，实测吞吐、延迟与质量后再选。无论选哪条，都必须在自己的 eval 集上跑回归（1.4、6.4）。
已有关系型数据库、数据量百万级以内 → 优先用现有数据库的向量扩展（PostgreSQL + pgvector、Elasticsearch / OpenSearch）。省掉一整套运维，且天然支持与业务字段的联合过滤（权限、时间范围）——这恰恰是纯向量库的弱项，也是企业场景的刚需。
规模更大或需要专门能力 → Qdrant、Weaviate、Milvus 等专用向量库，或对应的托管服务。
已有 Elasticsearch / OpenSearch → 混合检索几乎是免费的：BM25 与向量检索原生共存，且内置 RRF 融合（3.3）。这通常优于引入新组件。
选型必查的一项：元数据过滤能力。权限、时间范围、文档类型的过滤必须能在检索层完成，而不是召回后再筛（后者会导致「过滤完不够 k 条」）。
Embedding：开源侧有 BGE、E5、GTE 等系列（含多语言版本），闭源侧各厂商均有对应 API。
选型看三点，都不是榜单排名：① 是否支持你的语言与领域；② 向量维度（直接决定存储与检索成本，高维不总是更好）；③ 最大输入长度必须 ≥ 你的 chunk 大小——超出会被静默截断，这是一个极隐蔽的 bug。
Rerank：开源侧 BGE-reranker 等，闭源侧多家提供 rerank API。延迟与候选数成正比，务必计入 TTFT 预算。
两条硬提醒：
① 公开榜单分数对你的领域可能无参考价值——BEIR 一类工作表明稠密检索的跨领域泛化有明显折损（3.3），必须在自己的数据上重测。
② 换 embedding 模型 = 全量重建索引，不同模型的向量空间不通用。选型时就要把这笔迁移成本算进去。
起点配置：结构感知切分优先；无结构文档退回固定长度，chunk 取 256–512 token、重叠 10–20%。按 token 数切，不要按字符数切（中英文比例差异极大）。
PDF 解析是最大的坑：多栏排版、页眉页脚、跨页表格、扫描件。解析质量往往比切分策略更能决定 RAG 效果——上线前务必肉眼检查解析后的纯文本。
框架默认值不可信：各编排框架的默认 splitter 是为通用场景选的。至少把切分结果抽样打印几十条看一遍，这是五分钟避免一整类线上问题的检查（3.2）。
| 工具 | 特点 | 适合 |
|---|---|---|
| Axolotl | YAML 配置驱动，覆盖 SFT / LoRA / QLoRA / DPO，社区配置丰富 | 「照着已验证配置改」的团队 |
| Unsloth | 速度与显存优化见长，notebook 开箱即用 | 单卡场景、快速可行性验证 |
| LlamaFactory（原名 LLaMA-Factory） | 模型覆盖广、带 Web UI，中文社区活跃 | 快速试多个基座 |
| peft + trl + bitsandbytes | 底层组件，最大灵活性 | 建议至少手写一次训练脚本 |
LoRA 起点配置：r=16, alpha=32（保持 α/r = 2），adapter 加在注意力全部投影 q/k/v/o 加 MLP。调参顺序：先固定 α/r 扫 r，r 定了再调学习率——同时改两个耦合参数，得到的结论没有意义（5.2）。
最容易出错且最难发现的两处：chat template 必须与推理时完全一致（差一个特殊 token 都显著影响效果）；loss mask 通常只应计算在助手回复部分。这两处配错时训练照常完成、loss 曲线正常，只是效果莫名其妙地差——排查时优先检查它们。
部署：vLLM、SGLang 支持直接加载 LoRA adapter 并多 adapter 动态切换（一个基座服务多个任务），这是 LoRA 相对全量微调最实际的生产优势。
去重：datasketch（MinHash LSH）做大规模近似去重。务必抽样看一眼被判为重复的样本对，阈值过松会误删有价值的多样性。
数据集管理：HuggingFace datasets + 版本管理（DVC 或带哈希的对象存储）。「哪个模型是用哪版数据训的」必须可追溯。
合成数据：Distilabel、各家批处理 API（通常有明显折扣）。生成时注意提高多样性——同一 prompt 反复生成会得到高度相似的样本，去重后所剩无几。
两条合规前置项（应在数据管线第一步做，而非事后补）：① 用商业模型输出训练模型前核对该服务的使用条款；② 生产日志中的个人信息脱敏。
最有价值却最常被跳过的一步：人工通读 100 条最终训练样本。半天工作量，几乎每次都能发现自动化流程漏掉的系统性问题（5.3）。
LLM 可观测性平台：Langfuse（开源可自托管）、LangSmith、Braintrust、Arize Phoenix、Helicone（2026-03 并入 Mintlify，进入维护模式）。核心价值是省掉自建 trace 存储与 UI。
已有成熟可观测性栈的团队：用 OpenTelemetry 把 LLM 调用作为 span 接进现有系统，通常优于引入独立平台——LLM 调用只是系统的一环，割裂成监控孤岛会让端到端排查更难。
评估框架：promptfoo（轻量、配置驱动，适合接 CI）、DeepEval、RAGAS（RAG 专用指标）、以及上述平台自带的评估编排。
使用 LLM-as-judge 的前提：必须先用 50–100 条人工标注校准一致率，且评委模型或 prompt 变更后要重测。优先用二元判定而非 1–10 打分；能程序判定的（JSON 合法性、引用是否存在、枚举值）一律用代码（6.4）。
LLM 网关：LiteLLM、Portkey、Cloudflare AI Gateway——统一接口、自动重试、多供应商回退、限流与缓存。注意它本身也是一个新的单点，需要高可用设计，否则只是把故障点搬了个家。
弹性库：Python 的 tenacity、Java 的 Resilience4j 等。不要手写重试逻辑——退避、抖动、错误分类、熔断状态机都有成熟实现，手写极易漏掉抖动或重试了不该重试的错误。
生产环境模型标识：一律使用带版本后缀的具体标识，绝不用 latest 别名；并把模型版本记进 trace（6.5）。
安全：OWASP Top 10 for LLM Applications 可作为安全评审的检查清单起点。注入检测分类器（Llama Guard 等；早期常被引用的 Rebuff 已于 2025-05 归档）是纵深防御的一层，不是安全边界——真正的边界在执行侧的权限控制（6.2）。
约束解码 / 结构化输出：Outlines、XGrammar，以及 vLLM / SGLang 内置的语法约束；商业 API 普遍提供 structured outputs 或严格模式。凡是「格式不稳定」的问题，先用它解决，不要用微调。
流式事件：主流 API 的流式接口都区分 delta 与终态事件（完成 / 失败 / 截断），事件名与字段以各家文档为准。业务副作用只能在终态且通过全部验证之后触发，delta 只用于展示（6.6）。
Structured outputs 的边界：严格模式通常只支持 JSON Schema 的一个子集，且只保证形状——字段值的事实、权限与业务语义校验仍在应用侧，schema 通过不等于可以执行。
采样与复现：不同供应商对 temperature / top-p / seed 的支持与默认值不同。trace 里记录实际模型版本与采样配置；模型或 SDK 升级后重跑分布性回归，不把 seed 当跨版本保证。
幂等：SDK 自动重试不等于业务幂等。应用自己生成稳定的 operation_id，在副作用落点建唯一约束；供应商的请求级幂等能力只是额外防线，不能替代自己的提交点设计。
把易变内容集中在这里，是为了让更新成本可控。维护时遵循三条：
① 只改这里和侧栏，不动正文。如果某次工具更新让你觉得正文需要改，那通常说明当初有一句原理层内容被写进了工具层判断，或反之——这时应该回头修正分层，而不是顺手改正文。
② 更新时同步日期戳。日期戳的意义是让读者有理由怀疑它。没改内容就不要改日期——虚假的新鲜度比明确的陈旧更有害。
③ 不写价格、不写具体版本号。它们的变化速度远快于本书的更新周期，写进来必然误导。成本相关内容一律给计算方法与假设（2.4），让读者代入自己拿到的报价重算。
如果你在很久之后读到这一页：具体的工具名可能已经换了一轮，但选型时要问的问题大概率没变——瓶颈是显存还是算力？收益是延迟还是吞吐？这个判断能程序化吗？换掉它的迁移成本有多大？这些问题属于正文，它们比本页的任何一个工具名活得更久。