第一次做模型服务化部署的时候，我搜到最多的一个名字就是 Model-Optimizer。一开始我以为它是一个具体的模型，后来才知道它更像是一整套围绕模型压缩、推理加速和部署调优的方法论与工具链。真正让我下决心把整套东西吃透的，是一次很狼狈的上线经历：手里只有一张 24G 显存的卡，7B 模型 FP16 权重加载完，显存直接去掉大半，剩下那点空间连稍长一点的上下文请求都接不住，服务一并发就崩。之后我把整整两周时间搭在 Model-Optimizer 这条链路上，从模型量化、推理引擎替换到服务参数调优一步不落，最后在单卡上把 7B 模型跑成了能并发、能稳定出服务的状态。这篇不写原理综述，只讲我实际做过的选型、步骤、参数、验证方法，以及在坑里爬出来的教训。正在做 LLM 私有化部署、微调后上线，或者想把模型塞进单卡环境的朋友，可以直接照着抄。
1. Model-Optimizer是谁：模型训完为什么还要二次优化
1.1 optimizer在训练和推理里其实是两个意思
用过 PyTorch 的人对 optimizer 不会陌生，训练时它是 AdamW、SGD，负责根据梯度更新模型参数。但你做推理部署时说的 Model-Optimizer，含义完全不同，它针对的是已经训练好的模型，做的是压缩与加速。我更喜欢把训练比作健身，optimizer 是教练帮你长肌肉；而推理阶段的 Model-Optimizer 是装备师，上场前帮你把装备调整到能发挥出实力的状态。两个阶段目标不同，手段也不同。
模型在训练阶段只关心收敛速度和最终精度，推理部署关心的则是内存占用、时延、吞吐量这些工程指标。也就是说，Model-Optimizer 关注的不是“参数学的准不准”，而是“参数能不能更快、更省地被用起来”。你选择模型结构、训练方式的时候，可能根本不会在意显存里的 KV Cache 是怎么排布的；但一旦进入推理部署，这些细节全都变成了真金白银的成本。
1.2 推理成本的三座大山
把一个大模型部署成服务，瓶颈基本集中在三块。
第一是显存容量。模型权重、KV Cache、中间激活、CUDA context，全都要住在显存里。权重是静态大头，KV Cache 是动态大头。7B 模型 FP16 权重大约 14GB，看着 24G 显存挺够，可一旦上下文一长、并发一上来，KV Cache 会把剩下的空间吃干榨净。
第二是计算速度。理论算力摆在那里，但实际利用率取决于算子融合、量化指令、batch 大小等因素。很多传统推理框架在低并发下，GPU 算力利用率不到两成，大量计算单元都在空转。
第三是内存带宽。自回归生成是逐 token 输出的，每个 token 都需要把整个模型权重从显存搬到计算单元，这个环节高度依赖带宽。所以你会发现，即使模型很小、算力很强，生成速度依然可能上不去，瓶颈不在算，在于“搬”数据的速度。
这三座大山对应三条不同的优化路径：显存不够靠量化压缩，计算不足靠推理引擎的调度与算子优化，带宽受限则靠减小每次搬运的数据量——量化在这方面同样有效。Model-Optimizer 的链路，本质就是围绕这三件事展开的。先解决显存，再解决引擎调度，最后解决参数取舍，每一步都有明确的受益对象。
1.3 我给自己定的优化目标
为了避免优化做到一半方向跑偏，我在动手前先定了一个明确目标：在一张 24G 显存显卡上，部署一个 7B 级别模型，FP16 基线跑不起来的场景，要实现三件事。能跑：模型权重加 KV Cache 的总显存占用控制在可接受范围内，不只是加载成功，而是要能容纳真实业务的请求长度和并发量。跑得快：单请求生成速度稳定在每秒 40 token 以上，首 token 时延不能让人明显等待。跑得稳：并发 10 路请求时，吞吐量明显高于逐个排队，并且 P95 延迟不能溃烂。
这个目标听起来不复杂，但每一步都对应一个真实的坑。接下来从量化压缩开始讲，因为这是我整条链路里收益最大、也最容易做错的一步。
2. 量化压缩是第一道坎：不同量化方案的原理与选型
2.1 量化为什么能省钱
量化说白了就是把模型里的高精度浮点数，换成精度较低的形式。FP16 用 16bit 表示一个数，INT8 是 8bit，INT4 是 4bit，直接内存占用就降到一半、四分之一。7B 模型的 FP16 权重大概 14GB，量化成 4bit，权重部分只有 3.5GB 左右，省下来的显存全都可以用于 KV Cache 和并发请求。
精度损失主要来自权重分布的表达。模型权重大部分落在 0 附近，但总有几个“离群”的大数值，它们对输出影响很大。量化时我们要给整组权重定义一个映射范围，范围太窄，离群点被截断；范围太宽，0 附近的细节又会被抹平。解决思路是用缩放因子和零点做线性映射：q = round((x / scale) + zero_point)。per-tensor 量化整层共用一个 scale，per-channel 每个通道一个，group 量化则是把权重分组，每组一个 scale，组越小精度越好，但计算和存储开销略增。
我常拿图片压缩做类比：RAW 原图改成 JPG，手机上看几乎没区别，但拿去修图、放大裁剪，差异就出来了。量化对模型的影响也类似，日常聊天看不出太大差别，但代码生成、数学推理这类对精确计算敏感的任务，会最先暴露问题。所以选量化方案，本质是在“省资源”和“保精度”之间找平衡点。
2.2 主流量化方案实测对比
我在这套流程里实际对比过四种方案：GPTQ、AWQ、BitsandBytes（BNB）、GGUF。先说结论：NVIDIA 卡跑 GPU 推理，我优先选 AWQ；如果模型生态里只有 GPTQ 权重，我也能接受；BNB 我一般只用来快速验证，不作为生产选择；GGUF 更适合 CPU 或者 CPU+GPU 混合部署。
| 方案 | 量化位宽 | 显存节省 | 推理速度 | 精度 | 适用场景 |
|---|---|---|---|---|---|
| GPTQ | INT4/INT8 | 高 | 较快 | 良好 | GPU 部署，成熟权重多 |
| AWQ | INT4 | 高 | 快 | 优秀 | GPU 部署，激活感知保护重要通道 |
| BitsandBytes | NF4/INT8 | 高 | 一般 | 良好 | 加载时量化，适合快速试验 |
| GGUF | 多种位宽 | 高 | CPU下不错 | 多样 | CPU/混合部署，单机无独显也可 |
GPTQ 的思路是基于二阶导数信息逐层压缩权重，目标是让压缩后的权重整体误差最小，相当于把一个高维优化问题拆成一层层来做。AWQ 则盯着激活值，它发现不是所有权重通道都同等重要，有些权重对应的激活分布特别大，量化时要“保护”这些通道，于是根据激活统计给通道加权。实测下来，AWQ 在相同位宽下精度损失往往更小，某些场景生成速度还略占优，这是我最终选择它的原因。
2.3 量化验证环节：精度和部署都要管
光把模型量化完还不够，我吃过一个教训：AWQ 量化后第一版测试，感觉模型“变笨了”，问答偶尔答非所问。后来查下来有两个原因，一个是业务 prompt 的表达和校准数据的分布差太远，另一个是我用了一组对它特别不友好的数学题来测。这里我的建议是，别只看几个孤例，要做两件事。
第一，用困惑度做快速体检。Perplexity 是一个粗略但好算的指标，量化前跑一遍原模型，量化后再跑一遍，如果数值没有明显变差，基本可以确认没有结构性损伤。第二，用业务的真实测试集做回归。如果部署的是客服模型，就用客服问答集覆盖关键场景；如果是代码模型，就准备一组成对样例，分别跑原模型和量化模型，对比输出质量。
部署层面同样有个容易被忽略的事：量化格式必须和推理引擎匹配。比如我在 vLLM 里跑 AWQ，就需要模型目录里有正确的量化配置，不能随便拿一个 4bit 权重硬加载进去。这个坑我在第 5 节的踩坑记录里会详细展开。
3. 推理引擎替换：PagedAttention、Continuous Batching与Prefix Caching
3.1 传统引擎为什么在并发场景下卡顿
一开始我用的是 HuggingFace transformers 默认的 generate 方法。单个请求勉强能跑，一旦并发上来就明显不行。原因有两个：第一，每个请求都会预分配一整块 KV Cache，不管实际用多少，显存都会被按最大序列长度占住；第二，请求之间互相隔离，动态调度能力差，来一个请求就占一块地方，显存碎片越来越多。可以类比成一家只接受包场预订的餐厅，每桌都按最大人数摆菜，哪怕只有两个人来，也给你留 20 人的菜量。
这个问题的本质是资源分配方式和实际需求严重不匹配。context 短的时候浪费显存，context 长的时候又不够用，而多个并发请求叠加之后，碎片化会让情况雪上加霜。我在切到 vLLM 之前，一直以为是自己显存不够，后来才发现是资源管理方式不对。
3.2 PagedAttention：把显存当虚拟内存用
vLLM 最核心的改进就是 PagedAttention，思路几乎照搬操作系统虚拟内存。KV Cache 不再按请求顺序连续分配，而是切成固定大小的物理块，逻辑上连续的序列可以被映射到散落各处的物理块上。这样你不需要预留整块连续显存，按需分配，显存利用率会明显提升。而且因为物理块可以共享，多个请求如果有相同前缀，就能共享同一批 KV Cache 块，省内存又省重复计算。
这个设计我第一次看到时有点恍惚：一个推理引擎居然把操作系统的内存管理思想搬进来了。但效果是实在的，同样一张卡，同一批请求，从传统框架切到 vLLM，显存占用立刻下去一大截，能容纳的并发请求数翻倍都不稀奇。如果你的部署场景是长上下文或者高并发，这一步带来的收益甚至比量化还直观。
提示：PagedAttention 的共享机制是自动发生的，不用你手动配置，但它要求上游引擎实现前缀感知，所以尽量保持推理引擎版本相对较新。
3.3 Continuous Batching：动态调度请求
另一个大杀器是 Continuous Batching，也就是持续批处理。旧方案的流程是把一批请求同时喂进去，全部完成后才处理下一批，效率很低，尤其当请求长度差异大的时候，短的等长的，GPU 空转严重。Continuous Batching 则是每步解码完都检查一下：哪个请求已经生成结束，立刻把它移出，空出的位置塞进一个排队中的新请求。这就像餐厅动态翻台，有人吃完马上收拾，让新客人坐下，而不是等所有桌子都吃完了才统一翻一轮。
对应到 vLLM 的参数上，max_num_seqs 控制最多同时处理的序列数，max_batch_tokens 限制一个批次里的 token 总量。响应延迟和吞吐量这两个指标，很大程度上由这两个参数决定。我在调参阶段试过把 max_num_seqs 拉到很大，吞吐确实涨了，但每个请求的尾延迟也跟着涨，在线服务场景并不都好受。这个取舍在下一章专门展开。
3.4 Prefix Caching：被低估的加速手段
我一开始完全没在意 Prefix Caching，后来在 RAG 和多轮对话场景里被它惊艳到。原理很简单：如果两个请求的 prompt 前缀完全一样，之前算好的 KV Cache 可以直接复用，没必要重新算一遍。典型场景就是系统提示词固定、RAG 里同一批检索段落被多个用户共享、多轮对话里前几轮内容不变。
在 vLLM 里开启 prefix caching 之后，我实测了一组固定系统提示词的请求，TTFT 明显下降，因为最耗时的长 prompt 预填充阶段被直接跳过了。这个优化几乎不额外占显存，只是计算复用，属于躺着捡钱级别的收益。部署时记得确认引擎版本默认行为，老版本可能需要显式开启。
4. 服务参数调优：从TTFT到吞吐量的平衡
4.1 先搞懂四个指标
调优之前，先要明白你要优化什么。很多人上来就问“模型每秒能生成多少 token”，这个指标太粗了。我把日常盯的指标拆成四个，方便对号入座。
| 指标 | 含义 | 在线对话 | 离线批量 |
|---|---|---|---|
| TTFT | 首 token 延迟 | 敏感 | 不敏感 |
| TPOT/ITL | 单 token 生成间隔 | 敏感 | 一般 |
| Throughput | 总吞吐 | 适度关注 | 核心指标 |
理解这些指标之后，你才会明白为什么有些参数不能一味求大。在线聊天场景，用户等第一个字很焦虑，所以 TTFT 必须压住；离线批量分析场景，用户根本不关心首 token 多快，只要总吞吐高、单位成本低就行。优化目标不同，参数选择完全不同。
4.2 显存分配与 KV Cache 预算
vLLM 会给模型权重留足显存后，把剩余显存尽可能划给 KV Cache。关键参数是 gpu-memory-utilization。这个值决定了模型权重、KV Cache 以及其他运行时开销的预算，默认 0.9，意思是用掉 90% 显存，剩下 10% 做余量。如果你设得太激进，比如 0.95，可能在某些推理长度下出现 OOM；设得太保守，KV Cache 就太小，并发能力上不去。
KV Cache 有多大，可以按公式估算：单 token KV Cache 大小 = 2 × 层数 × KV 头数 × 头维度 × 字节数。以 7B 级别、32 层、32 头 MHA 结构为例，FP16 下每 token 大约 512KB，8K 上下文就是 4GB。如果换成 GQA 结构，KV 头数量小很多，同样 8K 上下文可能只要 1GB。这也是为什么新出的模型普遍用 GQA——它在长上下文场景里省的是真金白银。
max-model-len 不要贪大。你把上限设成 16K，vLLM 就会按 16K 去预留 KV Cache 空间，实际请求只有 2K 长度，剩余空间等于被锁死。我通常先按业务真实分布取 90 分位长度再加一点余量，而不是直接拿模型理论最大长度。
4.3 并发量与延迟的平衡
并发参数是最需要反复试的一组值。max_num_seqs 设得小，请求排队时间长，GPU 却空着；设得大，单 batch 变大，每个 token 的生成延迟上升，TPOT 会变差。我的做法是用真实流量压测，记录不同并发下的 P50/P95 TTFT 和 TPOT，然后选一个让 P95 还能被用户接受的临界值。
max_batch_tokens 同理。如果你的请求平均长 1K token，把 batch 上限定在 4096 以内基本够用，强行拉到 8192 只会让调度器把更多请求揉进一个 batch，长尾延迟很难看。找到最优值的过程其实就是一次小规模的容量评估，没有什么黑魔法。
4.4 一个简单但有效的压测方法
不引入复杂的压测平台，脚本也能看出趋势。先用 OpenAI 兼容接口拉起服务，再用 Python 脚本并发请求并按指标统计。
import time import requests from concurrent.futures import ThreadPoolExecutor url = "http://127.0.0.1:8000/v1/chat/completions" payload = { "model": "model-optimizer-demo", "messages": [{"role": "user", "content": "用三句话介绍量子计算"}], "max_tokens": 128 } def send(): start = time.time() resp = requests.post(url, json=payload, timeout=120) assert resp.status_code == 200 return time.time() - start with ThreadPoolExecutor(max_workers=10) as pool: times = list(pool.map(lambda _: send(), range(50))) times.sort() avg = sum(times) / len(times) p95 = times[int(len(times) * 0.95)] print(f"avg: {avg:.2f}s, p95: {p95:.2f}s")注意这个脚本测的是端到端完整响应时间，你还需要把请求改成流式 SSE，单独解析首个 token 的时间，才能得到真正的 TTFT。脚本本身不复杂，但它能把参数调节前后的差异量化出来，我在选 max_num_seqs 时就用它筛出了甜点区间。
提示：压测时不要只测一台机器本机回环，最好从另一台机器发起，否则 CPU 调度和网络栈会干扰最终结果，延迟数据偏乐观。
5. 实测踩坑记录：我在这套流程里翻过的车
5.1 量化后“变笨”：是错觉还是精度真损失
第一版 AWQ 模型上线测试，我发现它偶尔答非所问，和 FP16 原版对比明显变差。第一反应是量化精度崩了，差点放弃这个方案。后来冷静下来做了几件事：先跑困惑度，数值只有轻微上升；再准备一组业务常用 prompt 做盲测，发现 90% 的答案质量一致，真正变差的是数学计算和代码填空这类精细任务。原来根源是我的测试集选得太极端，把不合理的期望投射到了量化模型上。
这个教训是：量化模型的回归测试，必须用和线上分布一致的数据。你做的是对话机器人，就别拿十道高数题来判死刑；你做的是代码助手，就要接受它在某些边界情况可能不如 FP16。关键是提前知道它在哪些场景掉点，而不是追求全面无损。如果掉点的场景刚好是业务核心，再去想办法换更大的模型基座或者用混合精度策略。
5.2 一切调好却 OOM：KV Cache 和权重的比例没算清
有段时间配置看着没问题，显存占用 70%，可并发一高就 OOM。查了很久才发现是 max-model-len 设得太高，KV Cache 按最大长度预留，每个请求不管实际多短都占了相应配额。好比你租了一间仓库，却按最大货量租了一整层，货没来仓库当然空，货一多却连进门的位置都不够。
解决方式是把 max-model-len 从 16384 调到 8192，再把 gpu-memory-utilization 从 0.95 调回 0.9，OOM 立刻消失。这个坑说明调参前真的要按照第 4.2 节的公式算一遍显存预算，不能凭感觉。特别是模型层数多、上下文又长的组合，KV Cache 会以惊人的速度吃显存。
5.3 版本一升级，配置就失效
vLLM 版本更新很快，参数和默认行为经常变。我有一次升级到新版本后，服务直接起不来，报错指向一个旧的启动参数，查了一个多小时才发现是参数被移除。同时，transformers 版本太新或太旧也可能导致量化权重加载失败，两个库之间还有依赖关系，很容易互相踩。
现在我的习惯是：每次部署都锁定一套经过验证的版本组合，比如 vLLM 的某个特定版本加对应 transformers 版本加对应 CUDA 环境。模型和引擎的更新先单列出来做回归测试，不在线上直接动。这类环境问题看着低级，实际最耽搁时间，锁定版本是性价比最高的操作。
5.4 差一个预热，首请求超时
还有一个很容易忽略的坑：服务刚启动时，CUDA graph 尚未编译，模型也没加载到最热状态，第一个请求会格外慢，有时直接触发超时。我第一次上线时没做预热，监控里看到一个 30 多秒的超时，以为是宕机，后来发现只是冷启动。
解决很简单：服务启动后，先发一个短请求把 CUDA graph、显存分配拉起来，等响应正常后，再把服务切到对外状态。我把这段预热逻辑写进了部署脚本里，之后首请求超时这个坑再没出现过。这件事也提醒我，任何上线流程都要把“冷启动”当成一个正常状态来对待，而不是假设服务一启动就是满血。
6. 从“能跑”到“够省”的进阶路：工程化落地建议
6.1 优化完不等于结束：监控和回归要跟上
模型上线后，我的监控面板至少保留四类指标：显存使用率、KV Cache 余量、队列长度、P50/P95 延迟。长期跑下来你会发现，显存使用率上升但延迟也在变好，未必是坏事，可能是缓存命中率高了；真正要盯的是队列长度，一旦长期超过 max_num_seqs，说明并发瓶颈到了。另外，模型每做一次微调更新，量化权重必须重新走一遍校准和验证流程，不能把旧的量化结果直接挪到新权重上。权重分布变了，量化保护通道也会变，省事往往会埋雷。
这里多说一句：量化文件不是一个孤立产物，它和原始模型的版本、校准数据集强绑定。模型更新后重新生成量化文件，是部署流程里必须固定的一步，而不是可选步骤。
6.2 单卡优化的天花板在哪里
单卡方案总有顶到墙的时候。当并发要求持续上升、吞吐上不去时，可以考虑两条路线。一是投机采样，用一个更小的草稿模型先预测多个 token，再由大模型一次性验证，适合批量生成场景，能显著提升解码速度。二是横向扩展成多卡或服务集群，把负载分散开。这些都属于 Model-Optimizer 更高阶的玩法，但如果单卡基础还没调明白，先别急着上。单卡环境是整个优化链路最好的试验场，把这里的每一步都吃透，后面扩容只是重复同一套流程。
6.3 我目前的参考配置
作为一个可以直接复制的例子，我放一份在 24G 单卡上跑 7B 模型的配置参考。
| 项目 | 配置 |
|---|---|
| 模型 | 7B 对话模型 AWQ 4bit |
| 推理引擎 | vLLM + OpenAI 兼容接口 |
| gpu-memory-utilization | 0.9 |
| max-model-len | 8192 |
| max-num-seqs | 16 |
| quantization | awq |
| 预热 | 启动后空请求预热 |
对应启动命令：
python -m vllm.entrypoints.openai.api_server \ --model /path/to/7b-awq \ --quantization awq \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 16 \ --served-model-name model-optimizer-demo \ --port 8000这套配置在我这边单流生成速度能稳定在每秒 40 token 以上，并发 10 路时吞吐可达每秒 500 token 左右，同时 P95 TPOT 保持在一个可接受的区间。不同硬件稍有差异，但这个参数组合是一个很稳的起点。
6.4 一点个人体会
整套流程走完，我最想跟后来者说的是：优化是个系统工程，顺序比技巧重要。先把模型量化做对，再选推理引擎，最后调服务参数，每一步都在前一步的基础上放大收益；反过来，如果你一开始就去调并发参数，权重没压下来、引擎没升级，调来调去都是原地打转。先把能省钱的地方省下来，再考虑跑得快，方向对了，剩下的只是时间和耐心。
