大模型量化推理与部署实战：从原理到vLLM和Ollama

直接进入正题。这篇是“大模型推理优化”系列的 task5，主题是量化推理与部署。前几个 task 我分别聊过 KV Cache、连续批处理（continuous batching）、投机采样和并行策略，这次轮到量化。量化这个话题在大模型社区里热度一直很高，核心原因很简单：它能把推理成本打下来，而且往往不需要你动模型结构、不需要重新训练，属于“性价比极高”的优化手段。这篇文章我会从量化的核心原理讲起，然后落到基于 vLLM 和 Ollama 这两类主流工具的实操部署，最后把我在多个项目里踩过的坑整理成一份排查清单，希望能给正在这个地方摸索的人提供一套可以“抄作业”的完整方案。

1. 量化推理的核心逻辑：为什么换一种数字表示就能提速省钱

1.1 量化的本质：用更少的比特数表达权重和激活值

先做一个非常朴素的解释。大模型里的参数，本质上是无数个浮点数。主流模型默认用的是 FP16（16 位浮点）或者 BF16（bfloat16），每个参数占 2 个字节。一个 70B 的模型，光权重文件就有 140GB，这在单卡 A100/H100（80GB 显存）上根本塞不进去，更别提推理时还有 KV Cache 和激活值要占显存。

量化的思路非常直接：既然 FP16 表示范围那么宽，而模型训练好之后，权重数值往往集中在某个很小的区间里，那我能不能用更少的比特数，比如 8 比特、4 比特，去近似表达这些权重？答案是可以的。把 FP16 权重映射到 INT8 或者 INT4 的过程就叫量化。换算一下，7B 模型用 FP16 要 14GB 显存，用 INT8 只要 7GB，用 INT4 只要 3.5GB。这个差距直接决定了一张 24GB 的消费级显卡能不能跑起 7B 甚至 13B 模型。

可能有人会问：那不用量化，直接用 FP16 跑不行吗？当然行，如果你有足够多的 A100，当然可以很“奢侈”地跑。但问题在于，绝大多数团队和个人开发者，手里的 GPU 资源是有限的，或者是要按量付费的云实例。同样的模型，量化之后能跑在更小的卡上，单位 token 的成本直接下降，这在生产环境里就是纯利润。

注意：量化不是“压缩文件”那种有损压缩的思维。它确实会引入精度损失，但好的量化方案能把损失控制在一个可接受范围内，甚至有些场景下量化后的模型表现和 FP16 几乎无差。

1.2 计算瓶颈与访存瓶颈：量化到底优化了哪个环节

很多人以为量化就是在减少显存占用，这只是表层。量化真正带来的收益，来自它对“访存量”的缩减和“计算效率”的提升。要理解这一点，得先搞清楚大模型推理是“访存密集型”还是“计算密集型”。

在 LLM 的 decode 阶段（也就是一个 token 一个 token 往外蹦的阶段），每次只生成一个 token，但需要读取整个模型的所有权重。假设模型是 7B FP16，每生成一个 token 就要从显存里读取 14GB 的数据。这时候 GPU 的计算单元大多数时间都在“等数据”，而不是“算数据”。这就是典型的访存密集场景——瓶颈在内存带宽，而不在算力。

量化之后，权重用 INT8 或 INT4 存储，读取单个 token 需要搬移的数据量就减少到原来的 1/2 或 1/4。数据搬运少了，GPU 的等待时间就短了，能效自然就上来了。这也是为什么在消费级显卡上，量化的提速效果非常明显；而在 A100/H100 这种大带宽卡上，提速效果相对小一些，但显存节省依然有巨大价值。

另外，在部分支持 INT8/INT4 矩阵运算的硬件（比如 Ada Lovelace 架构的 GPU 拥有 FP16/INT8/INT4 张量核心）上，量化还能让计算单元同时处理更多数据。这就是“硬算力”的直接翻倍（理论峰值）。访存拉低、吞吐提高，这两个收益叠加起来，量化就成了推理优化里避不开的一环。

1.3 常见量化精度选型：INT8、INT4、W8A8 到底怎么选

现在市面上的量化前缀特别多，什么 GPTQ、AWQ、GGUF、W8A8、W4A16，第一次看很容易懵。这里先帮大家梳理一下命名逻辑。形如“W4A16”这类写法，W 指的是 Weight（权重），A 指的是 Activation（激活值），数字代表它们各自的量化位数。比如 W8A8 表示权重和激活值都是 8 比特量化；W4A16 表示权重用 4 比特量化，激活值保持 16 比特。

这里有个重要的区别：权重量化相对安全，因为权重在推理过程中是固定的，可以用很“重”的校准算法去找最优映射；激活值量化就难得多，因为激活值随输入变化，分布波动大。所以早期成熟方案大多只量化权重，保留激活值的高精度，比如 GPTQ 和 AWQ 都是 W4A16 路线的代表。而 INT8 量化则倾向于权重和激活一起量（W8A8），配合支持 INT8 计算的新硬件，在吞吐上优势明显。

那么选型怎么判断？

• 如果你追求极致的显存节省，能在小卡上跑更大模型，优先考虑 4 比特方案（GPTQ/AWQ 算权重，GGUF Q4_K_M 提升兼容）。
• 如果你更看重推理速度，尤其是高并发服务场景，且硬件支持 INT8 张量核心，W8A8 的全量化更合适。
• 如果在 CPU 上推理，或者做边缘部署，GGUF（llama.cpp 的量化格式）几乎是一统天下的选择，从 Q2 到 Q8 都有，丰俭由人。

注意：量化位数越低，精度损失通常越大，但不是线性的。实测中，INT8 的损失几乎可以忽略；INT4 开始有感知差异；3 比特以下就要仔细评估业务场景是否受影响了。

2. 量化方案背后的关键技术原理

2.1 校准数据集在量化中的作用：没有校准数据的量化都是碰运气

在动手量化之前，得先搞明白一个概念：校准（calibration）。像 GPTQ 和 AWQ 这类“训练后量化”（PTQ，Post-Training Quantization）方法，并不是简单地把 FP16 权重除以某个最大值再取整，而是需要用一小批真实输入去“观察”模型每一层激活值的分布范围，然后基于这个范围设计量化区间。

为什么需要这一步？因为量化的本质是把一个连续的大区间映射到离散的小区间。如果区间设置得太宽，小数部分的精度全丢了；如果区间设得太窄，大量超大值会被截断。校准数据集的作用，就是让这个区间设置尽量贴合真实推理时遇到的数据分布。

实操里，校准数据集通常取 128~256 条样本就够了。但是选择什么样的样本，很有讲究。如果你做的是代码生成模型，结果拿一堆新闻文本去校准，激活值分布会偏，量化后的效果很可能不尽如人意。我个人的习惯是：从真实的业务语料里采样，覆盖不同长度、不同风格，尽量平均分布。

2.2 GPTQ 和 AWQ 在做同一件事，但思路不同

GPTQ（Generalized Post-Training Quantization）是目前流传最广的 4 比特量化方法之一，核心思想是“逐层量化 + 误差补偿”。它把每一层的权重量化后，计算量化引入的误差，然后用 Hessian 矩阵（损失对权重的二阶导数）去指导误差补偿，把误差分摊到这一层其他未被量化的权重上。这个思路可以概括为“先破坏，再修复”，用全局的视角减少单点量化带来的精度崩塌。

AWQ（Activation-aware Weight Quantization）则走了另一条路。它的核心洞察是：一个权重矩阵里，不同的通道对模型输出的重要性是不一样的，而重要性可以从激活值的分布里看出来。AWQ 会统计每个通道的激活值尺度，对于容易被量化误差“伤害”的重要通道，给它乘上一个缩放因子，保留更高的有效精度。翻译过来就是“重点通道重点保护”。这种方法的好处是量化速度快，而且不需要像 GPTQ 那样反复迭代补偿。

从效果上看，在 4 比特量化这个档位，AWQ 往往在指令跟随和复杂推理任务上比 GPTQ 稍稳一点，尤其在量化 30B 以上的大模型时差异更明显。但 GPTQ 也不是没有优势，它的生态更成熟，vLLM、Transformers、ExLlama 都原生支持，踩坑资料多，排障也容易。

提示：在动手之前，建议先想清楚自己的场景。不是所有人都有必要把 FP16 模型量化到 INT4。如果显存够用，INT8 在速度和质量上更均衡；如果追求极致调度，INT4 才是正道。先明确约束，再选方案。

2.3 量化粒度：per-tensor、per-channel、group 怎么选择

量化粒度是另一个影响精度的重要参数。Per-tensor 量化是把整层所有权重共用一个缩放因子，最简单，但精度相对差。Per-channel 量化是对权重矩阵的每一行（输出通道）单独计算一个缩放因子，精度明显提升，也是目前最主流的做法。Group 量化（group quantization）则更进一步，比如每 128 个参数一组，每组独立缩放因子，精度最高，但需要存储的缩放因子也更多。

Granularity 的选择其实是“存储开销”和“精度”之间的权衡。组越小，量化越精细，但额外的缩放因子会抵消一部分量化节省的空间。在 INT4 量化里，常见的 Group Size 是 128。这个值不是随便定的，而是经过大量实验得出的平衡点。在实际项目中，如果量化后模型输出质量异常，优先检查一下量化配置文件里的 Group Size 是不是设置得太粗了。

2.4 权重分布中的离群值：量化误差的大头来源

说到量化，绕不开“离群值”（outlier）这个概念。大模型的权重和激活值并不是均匀分布的，大多数数值都集中在均值附近，但偶尔会有一些特别大的离群值。如果量化区间为了容纳这些离群值而无限拉宽，那些密集的“正常值”就会被压到非常窄的量化区间里，精度损失惨重。

AWQ 的思路前面讲了，是通过缩放因子保护重要通道。还有一种常见的做法是“混合精度”，也就是把少数离群值保留为 FP16，其余部分量化到 INT8/INT4，代表方法是 LLM.int8()。这种做法在万亿参数模型上表现稳健，但在小模型上收益没那么明显，而且会额外增加判断逻辑和访存开销。如果你要部署的模型在 7B~70B 这个范围，用 GPTQ/AWQ + Group Size 128 基本就够打了，不必上混合精度这种重型方案。

3. 实操：基于 vLLM 部署量化模型

3.1 环境准备与依赖安装

在动手部署之前，先把环境说清楚。我在生产环境里常用的组合是：Ubuntu 22.04 + CUDA 12.1 + Python 3.10 + PyTorch 2.1 + vLLM 0.4 以上版本。如果你用的是 Docker，可以直接拉 vLLM 官方镜像，省去很多环境编译的麻烦。但我更推荐先在本地装好干净的 Python 环境，因为很多时候排查问题需要跑脚本，容器里反而多了一层隔阂。

# 创建虚拟环境 python -m venv vllm_env source vllm_env/bin/activate # 安装 PyTorch（根据你的 CUDA 版本选择对应 index-url） pip install torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 --index-url https://download.pytorch.org/whl/cu121 # 安装 vLLM pip install vllm==0.4.2

安装完成之后，可以用python -c "import vllm; print(vllm.__version__)"验证一下。vLLM 这个项目迭代速度极快，版本之间 API 会有变化，这里给出的命令针对 0.4.2 这个版本，如果你用的是更新的版本，以官方文档为准。

注意：vLLM 的安装对 GPU 驱动版本和 CUDA 版本有要求，建议先确认nvidia-smi里显示的驱动支持的最高 CUDA 版本，再决定 PyTorch 的 cu 版本，避免安装完才发现 CUDA runtime 不匹配。

3.2 量化模型从哪来：直接下载 vs 自行量化

部署量化模型，第一步是拿到量化后的模型权重。有两条路：一是直接从 Hugging Face 下载社区量化好的权重，二是拿开源量化脚本自己量化。

对于绝大多数场景，我强烈建议直接用社区量化版本。为什么？因为量化是一个需要大量实验的过程——校准数据集、量化参数、验证集效果，每一步都可能影响最终质量。社区里的热门量化版（如 TheBloke 系列）通常经过了大量用户验证，踩坑概率低很多。你需要做的事情就是根据框架要求选一个合适的量化方式。

以 AWQ 为例，在 Hugging Face 上找一个带-AWQ后缀的模型仓库，然后下载下来。HF 的下载可以用huggingface-cli或者直接git clone（如果仓库用 git-lfs）。要注意，量化模型的文件结构和 FP16 不同，会多出quant_config.json之类的配置文件，部署框架需要认读这些文件来正确反量化。

如果项目特别在意数据安全，或者模型是私有微调过的，那就只能自己量化了。自量化推荐用 AutoAWQ 或者 GPTQ-for-LLaMa 的脚本。以 AutoAWQ 为例，最简用法如下：

from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path = "your_fp16_model_dir" quant_path = "your_awq_model_dir" quant_config = {"zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM"} # 加载 FP16 模型 model = AutoAWQForCausalLM.from_pretrained(model_path) tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) # 量化并保存 model.quantize(tokenizer, quant_config=quant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)

这里有个容易踩的坑：quantize方法里的tokenizer参数同时充当了“校准数据加载器”的角色，所以你的 tokenizer 必须能和你的模型配合，能正常把校准文本转成 input_ids。

3.3 vLLM 启动量化模型：一个完整的实测命令

先交代一下我这一步实验的硬件环境：单张 24GB 的 RTX 4090，目标模型是 7B 参数规模的 AWQ INT4 量化模型。显存占用理论上在 5GB 左右，实际跑起来加上 KV Cache 后大概在 8~10GB，24GB 的卡跑起来完全没有压力，并发能力也很不错。

启动命令如下：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/awq-model \ --quantization awq \ --dtype half \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000

解释几个关键参数：

• --quantization awq告诉 vLLM，当前模型是 AWQ 量化格式。如果用的是 GPTQ，就换成--quantization gptq。
• --max-model-len 4096控制上下文长度上限。显存不够用时，调低这个值是最直接的释放显存手段。
• --gpu-memory-utilization 0.9设置 GPU 显存利用率上限。vLLM 会预留一部分显存给模型权重和 KV Cache，这个参数决定它能吃多少显存。

启动之后，如果看到类似Starting vLLM API server on http://0.0.0.0:8000的日志，说明服务已经起来了。然后可以用 curl 请求一下：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/path/to/your/awq-model", "prompt": "quantization 的本质是什么？", "max_tokens": 512, "temperature": 0.7 }'

返回的 JSON 里choices[0].text就是模型生成的文本。这一步只需要确认服务能通，生成速度后面再量化评估。

3.4 量化前后对比：速度、显存与生成质量三维评估

部署完成不等于优化完成。我通常会做三组对比测试：FP16 版本和量化版本在同一个 prompt 上的生成速度、显存占用、以及输出质量。速度可以用 vLLM 日志里打印的Throughput指标，或者自己写个并发脚本测每秒生成 token 数。显存占用直接看nvidia-smi。

在我实测的 7B 模型上，FP16 版本的显存占用大约 14GB，AWQ INT4 版本大约 4.5GB，峰值时包括 KV Cache 也只有 9GB 左右。生成速度上，单卡 4090 上 FP16 大概是每秒 60~80 tokens，INT4 版本能到每秒 110~140 tokens，提升接近一倍。这个提升主要来自访存量的降低，前面讲过原理。

质量评估我推荐两个维度：一是通用基准测试，二是业务场景实测。基准测试可以用 lm-eval-harness 跑一些公开任务（比如 MMLU、GSM8K），量化版本的分数降低通常不超过 1%——如果超过 3%，就要怀疑量化的 calibration 或者参数设置有问题。业务场景实测更直观：拿 20~50 条线上真实 prompt 分别问 FP16 和量化版本，逐条比对回答质量，重点看逻辑性、细节完整度、指令遵循度。这里给大家一个经验值：INT8 几乎无损；INT4 在通用对话场景损失轻微，但在复杂代码生成、长文档摘要这类任务上，偶尔会出现“知道答案但表述不准确”的情况。

提示：如果你是做生产部署，上线前一定要做量化模型的回归测试。不要只看公开 benchmark 分数，把自己的业务测试集跑一遍，用统一评分标准对比量化版和原始版。这一步省不了，也偷不了懒。

4. 本地轻量化部署：Ollama 与 GGUF 的工程化实践

4.1 Ollama 加载 GGUF 量化模型：一条命令跑通本地大模型

除了以 vLLM 为代表的高并发服务端部署，另一个非常常见的部署场景是本地个人电脑、离线环境或者边缘设备。这时候 Ollama 是一个极佳选择。Ollama 本身集成了 llama.cpp 的推理后端，上层封装简洁，拉起一个模型几乎只需要一条命令。

Ollama 默认的模型仓库里已经有很多 GGUF 量化版本。如果你要用的模型不在官方列表里，可以从 Hugging Face 下载 GGUF 文件，然后写一个模型配置文件（Modelfile）加载进来。下面是我常用的步骤：

# 1. 安装 Ollama（Linux/macOS） curl -fsSL https://ollama.com/install.sh | sh # 2. 下载 GGUF 模型文件到本地目录 # 假设你下载了 qwen2.5-7b-instruct-q4_k_m.gguf # 3. 创建 Modelfile # FROM ./qwen2.5-7b-instruct-q4_k_m.gguf # 4. 构建并运行 ollama create qwen2.5-7b-q4 -f Modelfile ollama run qwen2.5-7b-q4

这里需要注意，ollama create的时候，Modelfile 里的FROM路径必须是相对路径或绝对路径，而且模型文件和 Modelfile 最好放在同一个目录下，避免路径解析问题。

4.2 如何选择 GGUF 的量化版本：Q4_K_M 还是 Q5_K_M？

GGUF 格式里有一套独特的命名体系，比如 Q4_K_M、Q5_K_S、Q6_K 等。我简单拆解一下：Q4 表示 4 比特量化；K 表示使用了 K-quant 算法；S/M/L 表示量化粒度的大小——S（small）更小省显存，M（medium）中等，L（large）精度更高。所以在资源有限的时候，Q4_K_M 是一个均衡选择；如果显存宽裕且精度敏感，Q6_K 或者 Q8_0 会更接近 FP16 的效果。

在 16GB 或 32GB 内存的 MacBook 上，7B 模型的 Q4_K_M 版本跑得很流畅；在 8GB 显存的旧 GPU 上，Q4_K_S 可能更稳妥。我的习惯是：先下载最小版本跑通流程，确认推理逻辑没问题，再换更高精度的量化版本做质量对比。千万不要一上来就下最大的版本，万一环境有问题浪费时间不说，还可能因为显存不够炸 OOM。

4.3 量化模型在 CPU 上跑：显存不够时的临时方案

有时候没有 GPU，或者 GPU 显存不够，只能在 CPU 上跑推理。llama.cpp 支持 CPU 推理，Ollama 底层也是 llama.cpp，所以在 CPU 上跑 GGUF 模型是可行的，只是速度较慢。7B 的 Q4 模型在 M1 Pro 上大概能跑到每秒 10~20 token，在旧款 Intel CPU 上大概只有每秒 3~5 token。

对于 CPU 推理，有几个提升体验的技巧：

• 调整线程数：Ollama 支持设置环境变量OLLAMA_NUM_THREADS，比如设置为 CPU 物理核心数，通常能带来可感知的速度提升。
• 使用量化更低的版本：比如 Q4_K_S 或 Q3_K_M，减少内存带宽压力。
• 控制上下文长度：CPU 的内存带宽是瓶颈，上下文越长，KV Cache 越大，解码越慢。如果业务允许，把上下文限制在 2048 或 4096 以内。

注意：CPU 推理能跑，但遇到大并发请求依然会崩。Ollama 默认是单请求串行处理，多用户同时请求会导致排队。如果要在本地给多人提供服务，建议还是上 GPU 加 vLLM。

5. 常见问题与排查技巧实录

5.1 显存够，但生成速度依然上不去

很多人以为显存够就有速度，其实不是。在 vLLM 部署中，影响生成速度的因素很多：batch size 大小、KV Cache 预留多少、模型权重访存量、张量并行设置等。如果你发现显存占用不高但速度低，建议优先检查有没有开连续批处理。vLLM 默认开着，但如果请求模式是稀疏的（单发、间隔长），批处理效果不明显，速度自然上不来。

另外，记得设置--max-num-seqs这个参数，它决定一个 batch 最多能容纳多少条序列。默认值通常偏低，在高并发场景下可以适当调大，比如设成 256，同时留意显存是否够用。我实测下来，并发翻倍带来的吞吐提升在 1.5~2 倍之间，但这个窗口期很有限，建议边调边用nvidia-smi观察显存和 SM 利用率。

5.2 量化后模型回答质量明显下降，甚至胡言乱语

质量下降是量化部署里最让人头疼的问题。先按概率排序排查几个常见原因：

1. 校准数据集与推理域不匹配：如果量化时用的校准语料和线上 prompt 风格相差十万八千里，量化区间根本不对，质量自然血崩。建议用业务真实数据重新校准。
2. 量化参数设置不合理：比如 Group Size 设成了 32 或 256，而不是默认的 128，也会引入额外误差。可以尝试把 Group Size 调小。
3. 模型本身太大，强行用 3 比特或 2 比特量化：现在 70B 模型量化到 3 比特，质量损失会非常明显，如果有条件优先用 4 比特。

还有一个比较隐蔽的问题：如果模型是经过指令微调的（比如 Chat 版本），量化时使用的校准数据集最好包含指令格式的样本，否则模型虽然能生成文本，但“遵循指令”的能力会明显退化。

5.3 模型崩溃、重复输出、输出乱码

这种问题往往不是量化本身的锅，而是部署链路里某个环节没对齐。常见原因包括：

• 模型文件下载不完整（尤其在网速不稳定的时候），建议核对 SHA256 校验值。
• vLLM 版本和模型量化配置不兼容，比如你用新版 vLLM 加载老版本的 AWQ 模型，可能出现奇怪的输出。解决方法是升级 vLLM 版本，或者重新用当前版本支持的量化算法量化一次。
• 模板（prompt template）错误。量化模型通常和原版模型共用同一个模板，如果模板里的特殊 token 写错，模型就会越生成越乱。

5.4 框架兼容性速查表：当前主流量化格式与推理框架

这块单独放一张表，方便大家快速对照选择。

这张表是我平时项目选型时的参考，实际情况还要结合你的硬件条件和业务负载来定。比如在 A100 集群上做高并发 OpenAI 兼容 API 服务，我首选 vLLM + AWQ/GPTQ；在自己的笔记本上验证模型效果，Ollama + GGUF 最省事。

6. 部署之后还可以做的优化：量化与其他推理优化手段的叠加

6.1 量化和 KV Cache 量化的关系

量化不仅可以用在模型权重上，KV Cache 本身也能量化。KV Cache 的大小和序列长度、batch size 线性相关，在长上下文场景下，它的显存占比可能比模型权重还大。vLLM 从某个版本开始支持 KV Cache 的 FP8 量化（V100 以下的老卡不适用），可以在几乎不损失质量的前提下把 KV Cache 显存占用减半，这意味着同样显存能支撑更长的上下文或者更大的并发。

这给我们一个启示：推理优化不是单点作战，而是系统工程。先量化权重，再把 KV Cache 量化，再加上 PagedAttention、连续批处理，才能在有限硬件上压榨出最大吞吐。

6.2 蒸馏 + 量化：让小模型无限逼近大模型

另一个常见的叠加玩法是“蒸馏 + 量化”。先用大模型对大量业务数据做标注，生成高质量的训练语料，再用小模型（比如从 70B 蒸馏到 7B）去拟合这个语料，最后对小模型做 INT4 量化。这一套组合拳下来，一个 5GB 不到的 7B 模型，在特定垂直任务上的表现可能比 140GB 的 FP16 70B 模型还要好。

当然，蒸馏需要训练资源，不是所有团队都有条件做。如果你的场景是标准问答、文本摘要这类通用任务，直接用开源量化模型就行；但如果是非常垂直的业务（比如法律文书解析、医疗报告结构化），蒸馏自研模型再量化部署是一条值得投入的路线。

7. 聊聊实践中的一些经验体会

做推理优化这几年，我最大的体会是：量化不是“模型变笨”的代名词，而是“在约束条件下达成目标”的工程艺术。每当你抱怨模型太大跑不动，先别急着上多卡集群，想想能不能把模型“瘦身”一下。一张 4090 跑 7B INT4 模型，配合 vLLM 的连续批处理，能扛住一个中小型内部工具的并发量，这在三年前是想都不敢想的。

最后分享一个我自己调试时很受益的小习惯：每次部署完量化模型，先把原始 FP16 模型跑同样的 prompt，把两份输出并排放在一起对比。不是所有差异都是问题，但如果量化模型输出了明显错误的逻辑、或者漏掉了关键信息，就说明量化方案有问题，需要回头检查校准数据或者量化参数。这个习惯让我避开了很多“模型能跑但结果完全不能用”的尴尬事故。

如果在实际部署中遇到任何新问题，欢迎在评论区把你的硬件配置、模型版本、量化方式发出来，我也很好奇现在社区里大家在跑什么新组合。