大模型部署性能优化：从"跑得动"到"跑得好"的实战全景

30%。

这是 Anyscale 在 2026 年初发布的一份报告里，统计到的企业级 GPU 集群平均利用率。

你没看错。一块 H100 每小时租金 2-4 美元，一天就是 50-100 美元。但其中 70% 的时间，它在发呆。

更扎心的是，这不是小公司的问题。报告里调研的大部分是有专业 MLOps 团队的中大型企业。他们买了最贵的卡，用了最热门的框架，跑了最流行的模型——然后 GPU 的大半时间在等数据、等内存、等调度。

问题出在哪？

不是硬件不够好，是部署方式不对。大模型推理是一套精密的流水线，每个环节都可能成为瓶颈。量化方案选错了，浪费内存；推理引擎没调好，浪费算力；架构设计没跟上，浪费钱。

今天我就把这条链路从头到尾拆一遍。不讲论文，不堆术语，就聊你明天就能用上的东西。

为什么你的 GPU 在"摸鱼"？

要搞清楚优化方向，你得先理解大模型推理到底在干嘛。

打个比方：大模型生成文字，就像一个厨师做菜。整个过程分两步：

第一步，备料（Prefill）：把你输入的所有 token 一次性"消化"掉，生成一个巨大的中间状态——叫 KV Cache。这一步是计算密集型的，GPU 的算力跑满，很爽。

第二步，炒菜（Decode）：一个 token 一个 token 地往外蹦。每生成一个字，都要回去查一遍 KV Cache。这一步是内存密集型的，GPU 的计算单元大部分时间在等数据从显存搬过来。

问题就在这里：备料用的是算力，炒菜用的是带宽。两个阶段对硬件的需求完全不同，但你让同一块 GPU 干两件事。

就像让一个厨师又切菜又掂锅——他不可能同时高效地做这两件事。

大模型推理的两个阶段：Prefill 是计算密集型，Decode 是内存密集型

更要命的是，在实际的在线服务中，Decode 阶段占了整个推理时间的 80%-95%。也就是说，你的 GPU 大部分时间处于"有力气没地方使"的状态。

理解了这一点，后面的所有优化就有了方向：要么减少内存占用（量化），要么提高内存利用效率（KV Cache 优化），要么把两个阶段拆开各自优化（Prefill-Decode 分离）。

GPU 不是不够快，是你喂不饱它。

量化：4 位精度如何跑出 16 位的效果？

如果只能选一招来优化部署成本，我选量化。没有之一。

量化是什么？简单说，就是把模型的"体重"降下来。

你拍了一张 RAW 格式的照片，50MB。转成 JPEG，2MB。画质损失了多少？肉眼几乎看不出来。量化干的就是同样的事——把模型权重从 16 位浮点数（FP16）压缩到 8 位、4 位、甚至 3 位整数。

效果有多猛？一个 70B 参数的模型，FP16 下需要 140GB 显存，两块 A100（80GB）才装得下。4 位量化之后？35GB，一块 H100 绑绑有余，甚至一块消费级 RTX 5090（32GB）都能勉强跑起来。

内存省了 75%，推理成本直接砍到四分之一。

但量化方案不止一种。2026 年主流的三个方案——GPTQ、AWQ、GGUF——各有各的脾气。

常见误解

很多人以为"量化 = 精度下降"。实际上，现代量化技术通过"对重要权重差异化处理"，可以在 4 位精度下保留 95%-99% 的原始模型能力。如果你不是在做需要极致精度的数学推理，量化后的模型表现几乎与原始模型无异。

三大量化方案怎么选？

GPTQ：GPU 部署的老牌选择。它用少量校准数据做"后训练量化"，不需要重新训练模型。优势是对 NVIDIA GPU 优化最成熟，生态最完善，vLLM 和 TensorRT-LLM 都原生支持。缺点是量化过程需要几个小时，且只针对 GPU 优化，CPU 跑不动。

AWQ（Activation-aware Weight Quantization）：MIT 提出的"聪明量化"。核心思想是——权重并不同等重要。它只保护 1% 的关键权重，其余大胆压缩。结果？比 GPTQ 快 1.45 倍，精度还更好。如果你在意代码生成或创意写作的质量，AWQ 是更好的选择。

GGUF：消费级硬件的救星。它是 llama.cpp 生态的原生格式，CPU 推理效率极高，也支持 GPU 加速。Ollama 用的就是 GGUF。如果你在本地笔记本上跑模型，或者用的是 Mac，GGUF 是唯一合理选择。

方案	最佳场景	精度保留	推荐硬件
GPTQ	NVIDIA GPU 生产部署	~95%	A100 / H100
AWQ	高质量 GPU 推理	~97%	A100 / H100 / RTX 5090
GGUF	本地 / CPU / Mac 部署	~92%（Q4_K_M）	任意 CPU+GPU

实际操作中，一行命令就能完成量化部署：

# 用 Ollama 拉取 GGUF 量化模型，本地直接跑
ollama run qwen3:32b-q4_K_M

# 用 vLLM 加载 AWQ 量化模型，启动 API 服务
vllm serve Qwen/Qwen3-32B-AWQ --quantization awq

一个选型建议：先试 AWQ。它在精度和速度之间的平衡点目前是最好的。如果你的场景是本地开发或边缘部署，换 GGUF Q4_K_M。只有当你需要极致吞吐量、且模型长期不更换时，才考虑 GPTQ + TensorRT-LLM 的组合。

量化不是偷工减料，是聪明的断舍离。

推理引擎怎么选？vLLM、SGLang、TensorRT-LLM 实战对比

量化解决了"装不下"的问题。接下来的问题是——装下之后，怎么跑得快？

这就轮到推理引擎登场了。

2026 年的推理引擎生态，三足鼎立：vLLM、SGLang、TensorRT-LLM。选错引擎，就像在高速公路上骑自行车——硬件再好也白搭。

但这里有个坑：很多评测文章只看"每秒 token 数"这个指标，然后告诉你"XX 引擎最快"。

这是错的。

推理引擎的选择，取决于你的工作负载特征，不是峰值跑分。就像选交通工具——高铁最快，但你家到公司 3 公里，骑电动车才是最优解。

数据说话

在 H100 上跑 Llama 3 70B 的 2026 年实测数据：SGLang 和 LMDeploy 均达到 ~16,200 tokens/sec，vLLM 为 ~12,500 tokens/sec。但在 DeepSeek V3 的 MLA 架构上，SGLang 反超所有对手，达到 vLLM 的 3.1 倍。引擎和模型架构的适配度，比引擎本身的"快慢"重要得多。

vLLM：最稳的全能选手。PagedAttention 技术让它的显存管理极其高效（浪费率从 60-80% 降到 4% 以下）。社区最大，模型支持最全，API 兼容 OpenAI 格式。如果你不确定选什么，选它不会错。

SGLang：前缀缓存之王。它的 RadixAttention 把 KV Cache 组织成一棵基数树，重复前缀只算一次。如果你的场景是 RAG、多轮对话、或者 system prompt 很长——SGLang 能给你 6.4 倍的吞吐提升。这不是优化，这是降维打击。

TensorRT-LLM：NVIDIA 的亲儿子。底层直接调用 CUDA kernel，针对 NVIDIA GPU 做了极致的算子融合和内存优化。在高并发场景下，吞吐量比 vLLM 高 30-50%。代价是：编译时间长、模型更新麻烦、只能跑在 NVIDIA 卡上。

说个真实的踩坑故事。我见过一个团队，选了 TensorRT-LLM 部署一个 RAG 服务。跑分确实快。但每次模型更新都要重新编译 2-3 小时，而他们的模型每周都在迭代。一个月后，他们换回了 vLLM——因为"快"不只是推理速度，还有迭代速度。

我的建议很简单：

通用场景、快速迭代 → vLLM（10 分钟跑起来，模型随时换）
RAG / 多轮对话 / 长 system prompt → SGLang（前缀缓存带来质变）
单一模型长期部署、极致吞吐 → TensorRT-LLM（编译一次，跑一年）

选引擎不是选最快的，是选最适合你路况的。

内存才是真正的战场？

你可能注意到了，前面几乎每个优化都跟"内存"有关。量化是压缩内存占用，引擎优化是减少内存浪费，选 GPU 要看的也是显存带宽而不是算力。

这不是巧合。2026 年大模型推理的核心瓶颈，就是内存。

为什么？因为 Decode 阶段每生成一个 token，都要把整个 KV Cache 从显存读一遍。一个 70B 模型处理 4K 上下文，KV Cache 就有几十 GB。GPU 的计算速度是够的——但显存带宽跟不上。

打个比方：你是一个读书极快的人（GPU 算力），但书架在隔壁房间（显存）。你每读一页都要跑一趟隔壁取书。你的读书速度再快，也被"跑腿"的时间卡死了。

这就是所谓的"内存墙"（Memory Wall）。

怎么破？三板斧：

第一斧：PagedAttention——让书架不浪费空间

传统做法是给每个请求预分配一大块连续显存。问题是，你不知道用户会说多长的话，所以只能按最大长度分配。结果？60-80% 的显存被白白占着。

vLLM 的 PagedAttention 借鉴了操作系统的虚拟内存管理——把 KV Cache 切成小页（page），按需分配，用完回收。就像图书馆不再给每个读者包一整面书架，而是按需分配格子。

效果：显存浪费率从 60-80% 降到 4% 以下，同样的 GPU 能同时服务的请求数翻了好几倍。

第二斧：FlashAttention——让取书的路更短

FlashAttention 的思路完全不同：既然搬数据慢，那就少搬。它重新设计了注意力计算的顺序，让数据尽量留在 GPU 的高速缓存（SRAM）里，减少对慢速显存（HBM）的访问。

FlashAttention 4 已经进入 SGLang 等主流引擎，配合最新的 Blackwell 架构 GPU，inter-token 延迟（ITL）下降 29-69%。

实战建议

如果你用 Ollama 本地跑模型，记得设置 OLLAMA_FLASH_ATTENTION=1 环境变量开启 Flash Attention。这一个配置就能让推理速度提升 20-30%，完全免费。

第三斧：KV Cache 压缩——让书变薄

Google 今年发布的 TurboQuant 把 KV Cache 压缩到 3 比特，内存占用直降 6 倍，而且零精度损失——不需要重新训练，不需要微调，直接在推理时压缩。

这意味着什么？原来一块 H100（80GB）只能处理 4K 上下文的请求，压缩后能处理 24K。同样的硬件，上下文窗口翻了 6 倍。

大模型推理的瓶颈，从来不在算力，在内存带宽。谁能把数据搬运做到极致，谁就能把 GPU 的潜力榨干。

Prefill-Decode 分离：生产环境的架构杀手锏？

前面聊的都是单卡或单节点级别的优化。如果你的服务已经到了多卡、多节点的规模，还有一个更根本的架构优化——把 Prefill 和 Decode 拆开部署。

回到厨房的比方。之前是一个厨师又切菜又炒菜。现在，你请两个人：一个专门备料，一个专门炒菜。备料的人用大砧板（算力高的 GPU），炒菜的人用快灶台（带宽高的 GPU）。

这就是 Prefill-Decode Disaggregation（预填充-解码分离）。

传统混合部署 vs Prefill-Decode 分离架构

为什么要分？因为在传统的连续批处理（Continuous Batching）中，一个新请求的 Prefill 会"插队"到正在 Decode 的请求前面。Prefill 是计算密集型的，可能占用 GPU 几百毫秒。这段时间里，所有正在等 Decode 的请求都被堵住了——用户感知到的就是"卡了一下"。

分离之后，Prefill 节点随便算多久，都不会影响 Decode 节点稳定输出。用户看到的 token 流是匀速的，体验质感完全不同。

insider 视角

LMSYS 团队用分离架构部署 DeepSeek-R1，成本降到了 DeepSeek 官方 API 的 五分之一。vLLM 的分离模式已经在 Meta 和 Hugging Face 的生产环境中跑通。这不再是实验性特性，而是 2026 年大规模 LLM 服务的默认架构。

当然，分离架构也不是银弹。Prefill 节点算完后，需要把 KV Cache 通过网络传给 Decode 节点，这引入了新的网络延迟。如果你的请求量不大（比如日均 QPS 个位数），分离架构带来的复杂度可能得不偿失。

一个简单的判断标准：当你的单卡 GPU 利用率已经超过 60%，且用户开始抱怨"有时候很快有时候很慢"时——是时候考虑分离架构了。

拆开干，才能一起快。

你的下一步

一句话总结今天的全部内容：大模型部署优化不是一招鲜，而是一条从模型到架构的优化流水线。每一层独立生效，叠加起来可以降低 80% 的推理成本。

今天回去，试一件事：

找一个你正在用的大模型（不管是 API 还是自部署的），跑一个简单的基准测试。记录三个数字：

首 token 延迟（Time to First Token, TTFT）——用户按下回车到看到第一个字的时间
token 间延迟（Inter-Token Latency, ITL）——每个字之间的间隔
每百万 token 成本——不管是 API 账单还是 GPU 租金均摊

然后对照这张清单，看看哪一层你还没做：

模型层：是否做了量化？AWQ / GGUF Q4_K_M 是起手式
引擎层：是否用了合适的推理引擎？RAG 场景一定要试 SGLang
内存层：FlashAttention 开了没？KV Cache 压缩用了没？
架构层：QPS 上来之后，是否考虑了 Prefill-Decode 分离？

如果四层你都做了——恭喜，你的 GPU 利用率大概率已经在 70% 以上了。

如果一层都没做——也恭喜，因为你有巨大的优化空间，每一步都能看到立竿见影的效果。

大模型时代，算力是租来的，但效率是工程师挣出来的。