32 篇博文 含有标签「Performance」

系统提示词（system prompt）正在成为 LLM 推理成本里最容易被忽略的部分。一个正经的 Agent 通常要背几十条指令、工具 schema、few-shot 示例和安全约束，动辄几千 token。每次请求都要编码这些 token，decode 时每个生成 token 又要对它们做 attention——长度是线性成本，而吞吐是用户的账单。

2026 年 8 月 19 日，Shopify Engineering 公开了他们在生产环境落地的一项技术：gisting。他们把自己的 GraphQL Agent 系统提示词从约 6000 token 压到约 1500 个 gist token（4:1 压缩），在预测质量不掉的前提下，把 350 RPM 流量下的 TTFT 从 438ms 降到 354ms（-19%）、端到端延迟从 6.8s 降到 4.2s（-38%）、吞吐从 20.2 QPS 提到 23.4 QPS（+16%），最终少用了 14% 的 GPU。这篇文章拆解它背后的原理、训练细节和部署方式。

流式输出（streaming）已经是 LLM 应用的默认形态——用户等不了非流式的 TTFB，ChatGPT 系的打字机效果也成了产品预期。但对后端工程师来说，SSE 协议本身只有半小时的学习成本，真正的工程难点在异步管道的生命周期管理：客户端慢了怎么办？上游断了怎么办？用户关页面了，上游还在生成、还在烧钱，怎么办？这篇文章聊的就是这些。

2026 年 8 月，两条看起来不相关的新闻放在一起读，信息量很大：

1. Tom's Hardware 报道 DRAM 价格 12 个月涨了约 500%，HBM/GDDR 的供应紧张让"显存"成了整个 AI 产业链最贵的消耗品；
2. 一位 Linux 图形栈开发者（pixelcluster.dev）多年打磨的 VRAM 管理补丁合入主线、随 Linux 7.3 发布：当 GPU 显存被"超卖"（overcommit）时，系统不再随机崩溃，而是尽量优雅地降速。

第一条讲的是"显存为什么不够用"，第二条讲的是"不够用了之后系统该怎么办"。第二条对 AI 推理工程师尤其有参考价值——因为 vLLM 的 CPU offload、llama.cpp 的 mmap、推理服务的显存超卖，本质上是同一个问题：物理显存放不下，被迫把数据换到 PCIe 那头的内存里，系统怎么把损失降到最小。

很多后端工程师第一次接触 LLM 推理都会困惑：为什么 prefill 快如闪电，decode 却一个字一个字地蹦？为什么 8B 模型的 fp16 权重才 16GB，vLLM 却要求 40GB 以上显存？答案都指向同一个东西：KV Cache。它既是 decode 速度的根基，也是推理服务显存和带宽的最大开销。这篇文章从显存账本算起，讲清楚 KV Cache 为什么是推理性能的隐形瓶颈，PagedAttention 如何用「虚拟内存」的思路解决碎片化，以及 GQA、MLA、量化、prefix caching 各自省掉了什么、代价是什么。文末附一个可运行的 numpy 最小实现和生产环境踩坑清单。

前两篇分别聊了向量数据库选型（向量数据库选型对比）和检索链路的分块/重排序（RAG 检索优化深度拆解），但都把 Embedding 模型当成了黑盒——喂进去文本，吐出来一串浮点向量。这篇把盒子拆开，聚焦一个高级后端工程师做规模化 RAG 时迟早会撞上的问题：向量又大又多，存储和检索延迟怎么砍？

先算笔账。一个 100 万 chunk 的语料库，用 1536 维 float32 的 Embedding（比如 text-embedding-3-small），单是向量本体就是：

1,000,000 × 1536 × 4 字节 ≈ 6.1 GB

这还没算 HNSW 图索引的开销（通常再乘 1.2 到 1.5 倍）。规模涨到 1000 万 chunk，向量本体就 61GB，单机内存放不下，得上分布式。但真相是：绝大多数检索场景根本用不到 1536 维的全精度浮点。今天聊的三件事——对比学习怎么训出 Embedding、Matryoshka 怎么一个模型任意维度截断、量化怎么把向量压 8 到 32 倍——就是把这笔账砍下来的三条路。

先抛一个反直觉的结论：RAG 效果不好的时候，九成问题出在检索，而不是生成。生成模型再强，检索漏掉的 chunk 永远不会出现在 context 里——"垃圾进，垃圾出"在 RAG 里是一条铁律。业界普遍共识是「检索质量决定 RAG 上限」：生成只能在上限之内修修补补，把答案写得通顺，但补不回没检索到的事实。

本文不聊"如何搭一个 hello-world RAG"，而是拆解检索链路里真正决定召回率的三个环节——分块（Chunking）、检索融合（Hybrid Search）、重排序（Re-ranking）——每一环给出可运行代码、性能量级和生产踩坑记录。这是我在多个生产 RAG 系统里反复调过的地方。

先摆一个反差数字：Llama-2-70B 的 FP16 权重约 140 GB，量化到 4-bit 后约 35 GB，压缩 75%，而它在 WikiText2 上的 perplexity 只上升 0.1~0.3。这意味着原本要两台 A100-80G 才装得下的模型，量化后一台就够，decode 速度反而更快——因为权重小到能塞进更大的显存余量里，KV cache 也能放得更长。

为什么「省显存」和「不掉精度」能同时成立？答案藏在 LLM 推理的真实瓶颈里。这篇拆四条主流量化路线（GPTQ / AWQ / GGUF / NF4）的原理、可运行代码和选型，写给要在生产里真刀真枪跑量化的人。

如果你做过 Web 后端，对"请求合并批量处理再返回"应该不陌生。但在 LLM 推理领域，这个模式完全行不通——传统静态 batching 的吞吐只有 Continuous Batching 的 十分之一不到。本文从后端工程师的视角，拆解这两种 batching 的根本差异。

「一个 70B 模型、每天 10 万请求、p95 TTFT 小于 1 秒，需要多少张 H100？」如果你问云厂商销售，答案取决于他的季度指标；如果你问架构师，答案应该取决于一张纸上的数学。LLM 推理的性能不是靠 benchmark 榜单「测」出来的，而是可以被两条硬件参数——峰值算力和内存带宽——从第一性原理「算」出来的。

本文沿用 Roofline 模型的分析框架（参考 Sid Babu 2026 年 5 月的同名长文），把 prefill 与 decode 两个阶段的吞吐、延迟写成可计算的代数式，再用 70B 模型在 H100/B200 上的具体数字验证，最后给出一个完整的容量规划实例。看完你会理解三件事：为什么 decode 阶段「大 batch 包治百病」是错的、为什么长上下文是推理成本的真正杀手、以及为什么 FLOPs 越高不代表推理越快。

自回归解码的本质是「一步一个 token」：生成第 t 个 token 必须等前 t-1 个 token 全部算完，而且每个 token 都要跑一遍完整的前向传播。在 decode 阶段，Transformer 的算力利用率通常只有个位数百分比——因为激活很小、瓶颈在显存带宽（memory-bound），GPU 上几 TB/s 的 HBM 带宽被浪费在搬运权重上。这就是投机解码（Speculative Decoding）要解决的核心矛盾：能不能用便宜的计算提前猜出未来几个 token，让大模型一次前向同时验证 K 个猜测？

答案是能，而且无损失。本文拆解投机解码的数学原理、三条主流实现路线（独立草稿模型 / Medusa 多解码头 / EAGLE 特征级草稿）、以及 vLLM 中的生产配置与收益边界。