拓冰网站定制 
大模型推理优化这事圈子里聊的人多真正从模型量化一路折腾到服务稳定跑起来的人少。很多朋友一开始以为装上 vLLM 或者 Ollama 就能畅快跑大模型结果不是被显存 OOM 卡死就是出字速度慢得像挤牙膏再或者量化完之后模型精度崩得没法看回答全是胡话。这篇东西我就把自己从零到一处理大模型推理、量化、部署的完整链路拆开讲把每一步背后的为什么和实操中踩过的坑都交代清楚。内容覆盖 GPU 资源评估、主流量化方案选型、vLLM 与 Ollama 的部署调优、常见故障排查目标是让看完的朋友能少走弯路照着思路顺利把模型跑起来。1. 推理优化的三个基本矛盾显存、带宽与延迟1.1 一次前向传播到底在干什么推理优化不是玄学先得搞清楚大模型生成一个 token 时机器里发生了什么。简单说模型权重放在显存里输入 token 经过 embedding 映射成向量然后一层层过 Transformer 的 Attention 和 MLP每一步都要做大规模矩阵乘法最后输出下一个 token 的概率分布。这个流程每生成一个 token 都要完整走一遍而且生成第 N1 个 token 时前 N 个 token 的中间结果也就是 KV cache还得保留着继续用。理解这个流程之后推理性能的三个变量就浮出来了显存容量决定模型能不能装下、能同时服务多少请求显存带宽决定权重从显存搬运到计算单元的速度这直接卡住生成速度计算吞吐决定每秒钟能完成多少次矩阵运算决定批量处理能力。绝大多数大模型推理优化工作本质都是在这三者之间做取舍不存在一劳永逸的方案。做一个生活化的类比模型权重就像一本放在书柜里的菜谱GPU 是厨师。每次按顺序查菜谱上的一个步骤读取权重然后动手做一步矩阵运算。如果菜谱本身体积很大参数多书柜得够大如果翻菜谱的速度慢带宽低做菜速度就被拖住如果厨师能同时做很多道菜吞吐高但每道菜都要看菜谱书柜又被频繁读取抢占。优化就是想办法让书柜更大、翻页更快、厨师更高效但三者往往互相制约。1.2 显存为什么总是最贵的资源显存永远是第一个瓶颈因为大模型权重和 KV cache 都住在里面。以 7B 参数的模型为例FP16 精度下权重就占 14GB 左右一张 24GB 的 RTX 4090 看似装得下但 KV cache 还要抢占空间。KV cache 大小和序列长度、并发数、层数、注意力头数直接挂钩公式大概可以估算为 2键和值乘以层数乘以头数乘以头维度乘以序列长度乘以 batch 大小再乘以精度字节数。实际跑起来并发数一上去KV cache 轻松吃掉 4 到 8GB。所以能用 4090 跑多大的模型这个问题答案从来不是只看参数量。我的经验是估算显存需求时至少要在权重基础上额外预留 30% 给 KV cache 和运行时开销。以 7B FP16 为例14GB 权重加 4-6GB KV cache24GB 的卡就差不多满了想开大并发就得换更激进的量化。如果跑 13B 或 14B 模型FP16 权重就到 26GB 以上非量化基本没戏这时候 INT4 量化几乎是唯一出路权重压到 7-8GBKV cache 空间反而宽裕不少。1.3 带宽瓶颈为什么算得快但出字慢很多人在 GPU 上跑模型发现 GPU 利用率并不高但 token 生成速度上不去卡在显存带宽上。大模型推理是典型的访存密集任务权重数据量远大于计算量。生成一个 token 要把模型全部权重从显存读一遍算完再写回部分结果这个读权重的动作才是大头。RTX 4090 的显存带宽约 1TB/s7B FP16 权重 14GB理论最短读取时间约 14 毫秒对应每秒生成 70 个 token 的乐观上限实际上因为其他开销50 tokens/s 已经算很高了。带宽瓶颈还解释了为什么量化对单卡推理提速最直接同样 7B 模型INT8 权重 7GBINT4 权重 3.5-4GB读权重时间直接减半再减半。这也是为什么笔记型电脑、游戏卡跑大模型时量化几乎是必选项。带宽利用率方面我知道有朋友会想到用 GQA分组查询注意力或者 MQA多查询注意力来缓解 KV cache 带宽压力但这是模型架构层面的事对已经定型的模型没法改。能做的更多是减少模型体积、优化批处理策略。2. 量化用精度换速度的生意经2.1 量化到底改变了什么量化本质是把模型里权重的高精度浮点数FP16 或 FP32转成低精度整数表示比如 INT8、INT4。一个 FP16 数占 2 字节INT8 占 1 字节INT4 占 0.5 字节。7B 模型从 FP16 压成 INT8权重就从 14GB 降到 7GB压到 INT4就是 3.5GB 左右。体积小了带宽压力小了计算也更快代价是精度损失。精度损失怎么理解模型权重里存储的不只是答案还有大量微小的参数关系低精度相当于把这些数四舍五入得更粗略。极端情况下模型会变笨、回答质量下降、甚至输出乱码。但实践中 INT8 量化对大多数模型影响很小INT4 则视模型鲁棒性和量化方案而定优秀的量化策略能把损失控制得很低。这就像把一张 24 位真彩色的照片压缩成 8 位色深的 PNG看起来依然能辨认但细节和渐变略微受损无损压缩做不到这个体积有损方式才是主要手段。量化的粒度也很关键常见的有按张量整个权重矩阵一个缩放系数、按通道每个输出通道独立缩放系数和按组比如每 128 个参数一组。粒度越细精度损失越小但计算和存储开销也更大。主流方案 INT4 基本都是按组量化这是精度和性能的最佳平衡点。2.2 主流量化方案对比GPTQ、AWQ 与 GGUF现在常用的大模型量化方案主要是三条路线分别适配不同的部署场景。GPTQ是学术界最出名的 PTQ训练后量化方案之一核心思路是用二阶近似信息Hessian 矩阵来逐层补偿量化误差。它对权重矩阵做逐列量化同时更新剩余未量化的权重来减少整体误差。GPTQ 量化后的模型主要在 GPU 上跑比如 vLLM、ExLlama 都支持常见档位是 FP16 基础模型量化为 4bit。我个人用下来的感觉是 GPTQ 在较大模型比如 30B 以上上精度保持得不错小模型优势不明显。AWQActivation-aware Weight Quantization则换了个角度观察发现权重里约 1% 的显著参数对模型精度影响巨大这些参数对应的激活值往往也特别大。AWQ 的做法不是简单加大这些显著通道的量化精度而是通过一个缩放系数让这些通道在量化后不容易出大误差。AWQ 量化速度快不需要反向传播精度在 4bit 场景下和 GPTQ 接近甚至更好vLLM 中支持得很完善。实际部署 API 服务时我优先选 AWQ。GGUF是 llama.cpp 生态的格式基于 k-quant 方案支持 2bit 到 8bit 多种档位Q2_K、Q3_K、Q4_K_M、Q5_K_M、Q6_K、Q8_0 等。它的特点是可以把部分层放 GPU、部分层放 CPU实现 CPU/GPU 混合推理内存占用可控非常适合本地电脑、Mac 或低显存环境。Ollama 直接吃 GGUF 格式下载即用这也是 GGUF 在社区最流行的原因。三者的选择逻辑可以总结为一张表方案核心特点最佳场景参考工具GPTQHessian 补偿GPU 友好大模型 GPU 部署、服务端vLLM、ExLlamaAWQ激活感知显著通道保护高并发 API 服务、精度敏感场景vLLM、SGLangGGUFCPU/GPU 混合、多档位本地单机、低显存、Macllama.cpp、Ollama2.3 量化档位选择不是越低越好量化档位看起来越低越好因为模型体积小、速度快但能用和好用差距巨大。我的经验法则是优先 Q8/INT8 起步它和 FP16 的差距微乎其微绝大多数任务体感不出来显存不够再降到 Q6/Q5精度依然稳健Q4 是底线Q4_K_M 这类中档 4bit 在多数模型上仍可接受Q3 及以下只建议拿来测试不要用在正式场景。选档位还要考虑模型原始大小和任务复杂度。一个 70B 的强模型即便量化到 Q4可能还是比一个 7B 的 FP16 模型聪明得多这时候牺牲精度换模型规模是划算的。反过来如果只是做一个翻译或者简单摘要功能小模型的 Q8 也比大模型的 Q3 稳定。没有绝对的最好档位只有针对显存和任务需求的平衡。判断量化效果不能靠感觉要跑量化前后的困惑度perplexityPPL对比PPL 数值越低代表模型对文本的预测越自信量化前后数值不应有太大波动。具体做法是拿一段模型没见过的语料分别让原版和量化版计算 PPL偏差超过 1-2 说明量化方案对该模型不友好需要换档位或者混合精度方案。注意有些模型本身对量化非常敏感特别是小模型1B 以下或者经过大量 RLHF 对齐的模型4bit 量化后会出现明显的输出质量下降、幻觉增多。遇到这种情况优先把 Attention 层保留高精度只量化 MLP 层或者退一档到 Q5/Q6。3. 部署引擎选型vLLM、Ollama 与其余方案3.1 vLLM高并发 API 服务的吞吐之王vLLM 是目前服务端部署大模型的主流选择核心优势在 PagedAttention 和 Continuous Batching。PagedAttention解决了 KV cache 碎片化问题。KV cache 在显存里是一段段连续空间不同请求长度不同如果按最长序列给每个请求预留空间显存浪费巨大。PagedAttention 把 KV cache 分成固定大小的块像操作系统的虚拟内存页面按需分配、按需回收显存利用率大幅提升。实测在同样显存下vLLM 比传统方案能支持的并发请求数高 2 到 4 倍。Continuous Batching则是动态调度策略。传统静态 batching 是攒够一批请求再一起跑有大量等待空档。Continuous Batching 允许请求随时进入、随时退出一个请求生成完了马上腾出位置给新请求GPU 始终在处理有效计算。这个特性让吞吐量显著提升特别适合多用户并发场景。vLLM 对量化模型的支持也很全。启动时直接用--quantization awq或--quantization gptq就能加载对应格式。它还内置了 OpenAI 兼容的 API 服务前端应用几乎不用改代码就能接入。3.2 Ollama本地玩家的最短路径如果你不是跑高并发服务只是想在个人电脑上跑模型Ollama 是最省心的方案。一行ollama run qwen2.5:7b就能把模型拉下来跑起来。Ollama 底层用的是 llama.cpp天然支持 GGUF 格式CPU 和 GPU 都能跑而且自动分配资源。ollama 的 ModelFile 机制支持自定义模型参数比如NUM_CTX上下文长度、温度、top_p 等。也可以从本地 GGUF 文件直接创建模型ollama create mymodel -f ModelfileModelfile 里只要写一行FROM ./qwen2.5-7b-q4_k_m.gguf这样就能把自己量化好的模型导入 Ollama 管理。Ollama 的优势是零成本上手、生态完善Open WebUI 等前端一键接入劣势是吞吐和并发能力有限高负载场景不建议用。3.3 其他部署方案按场景挑选趁手工具除了 vLLM 和 Ollama还有几个值得关注的方案。llama.cpp是 GGUF 生态的源头也是 CPU 推理性能优化的标杆。它对消费级 CPU 有大量汇编级优化纯 CPU 跑小模型也能做到每秒几十个 token。适合无 GPU 的服务器或老电脑。LMDeploy是国产方案里功能很全的一个支持 TurboMind 引擎、AWQ 量化、多卡推理。它的吞吐表现和 vLLM 不相上下支持特性也全像是在批量推理比如离线跑任务场景有独特优势。TensorRT-LLM是英伟达官方方案性能天花板最高但配置门槛也最高需要做模型转换和编译一般适合对延迟有极致要求、有定制化需求的场景。部署引擎选型的参考标准我整理成表引擎核心优势典型场景显存要求vLLM高并发、全功能 API生产服务、多用户高尽量 GPUOllama一键部署、GGUF个人本地、快速体验低可 CPUllama.cppCPU 优化、轻量无独显环境最低LMDeploy全流程国产、批处理离线批量推理中TensorRT-LLM极致性能商业产品、定制高4. 从量化到部署的完整实操流程4.1 前置条件与硬件评估动手之前先把硬件账算清楚。你可以用nvidia-smi查看显卡显存用lscpu和free -h看 CPU 和内存。显存决定能跑多大的模型、多少并发内存决定了能不能做 CPU offload 或者是否支持某些引擎的开销CPU 性能影响 Prefill 阶段初始输入处理和纯 CPU 推理的速度。估算显存需求的实用公式显存约等于权重大小加上 KV cache 再加上约 15% 的运行时开销。以 AWQ 4bit 量化后的 7B 模型为例权重约 4GBKV cache 按 4096 上下文、16 并发估算大约 4GB再加开销10GB 显存就能凑合跑如果量化成 8bit权重翻倍到 8GB总共就要 14GB 左右。选模型时先按这个公式套一圈省得下载半天模型跑到一半 OOM。4.2 GGUF 离线量化实操如果 Ollama 官方仓库没有现成的 GGUF 模型就要自己动手把 Hugging Face 上的原模型转成 GGUF 并量化。以 llama.cpp 为例先更新到最新版并安装 Python 依赖git clone https://github.com/ggerganov/llama.cpp cd llama.cpp pip install -r requirements.txt make -j4然后先把 HF 原模型转成 FP16 GGUF 格式python convert_hf_to_gguf.py ./models/qwen2.5-7b \ --outfile ./models/qwen2.5-7b-fp16.gguf \ --outtype f16下一步生成你要的量化档位比如 Q4_K_M./llama-quantize ./models/qwen2.5-7b-fp16.gguf \ ./models/qwen2.5-7b-q4_k_m.gguf Q4_K_M量化完成后可以跑一次困惑度测试验证精度损失是否可接受./llama-perplexity -m ./models/qwen2.5-7b-q4_k_m.gguf \ -f ./test_data.txt实操中我发现convert_hf_to_gguf.py对模型架构的兼容性偶尔有问题个别新模型要等 llama.cpp 更新支持。建议下载模型后先看仓库说明优先选已经标注支持 GGUF 转换的模型。量化速度方面7B 模型用消费级 GPU 大概 5-10 分钟纯 CPU 会慢很多可以用-t 8参数调线程数。4.3 vLLM 部署与启动配置部署 Python 环境并安装 vLLMpython -m venv vllm_env source vllm_env/bin/activate pip install vllm如果用现成的 AWQ 量化模型启动一个 OpenAI 兼容服务vllm serve ./models/qwen2.5-7b-awq/ \ --quantization awq \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 16 \ --port 8000参数逐个说明--tensor-parallel-size单卡设置 1多卡就填卡数前提是卡间通信够快--max-model-len是最大上下文长度越长 KV cache 占显存越多--gpu-memory-utilization是允许占用的显存比例0.9 是安全值太高容易在模型加载阶段 OOM--max-num-seqs是最大并发序列数数和显存 KV cache 直接相关保守起见 16 起步。启动完成后用 curl 简单验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen2.5-7b-awq, messages: [{role: user, content: 你好}], max_tokens: 100}能正常返回内容说明服务已经就绪。vLLM 在启动时如果做预编译或图模式优化会很慢推荐先用默认模式验证通链路再开优化选项降低排查难度。4.4 Ollama 导入本地 GGUF 模型拿到量化好的 GGUF 文件导入 Ollama 只需要两步。第一创建一个 ModelfileFROM ./qwen2.5-7b-q4_k_m.gguf # 可选设置上下文长度 PARAMETER num_ctx 8192然后执行ollama create qwen2.5-7b-q4 -f Modelfile ollama run qwen2.5-7b-q4如果你是从 Ollama 官方仓库直接拉模型那连这两步都省了。但自己量化导入的好处是能精确控制档位和上下文长度。Ollama 默认会尝试用 GPU显存不够会自动切换到 CPU这种弹性机制让它成为本地部署最不容易出问题的方案。5. 常见问题排查与性能调优实录5.1 显存不足与 OOM 排查OOMOut of Memory是部署大模型时最常见的报错。我的排查思路是逐步缩小变量先看是启动时 OOM 还是运行时 OOM。启动时 OOM大概率是模型权重加预分配缓存超过显存总量调低--gpu-memory-utilization或者换更低档位量化。运行时 OOM大概率是并发数或上下文长度超出预留 KV cache就降低--max-num-seqs和--max-model-len。还有一个隐蔽的坑多卡机器上显存分配不均匀。PyTorch 默认可能把所有显存分配到卡 0跑起来卡 0 OOM 而其他卡空闲。用--tensor-parallel-size多卡部署时先确认CUDA_VISIBLE_DEVICES设置正确再用nvidia-smi实时观察每张卡的使用率。日志里看到的torch.cuda.OutOfMemoryError: CUDA out of memory往往不是真正的显存满了可能只是碎片化严重。尝试设置环境变量PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来改善内存碎片实测在某些场景能抢救回来不少空间。5.2 生成速度慢与吞吐低生成速度慢第一反应不是加硬件而是确认当前是不是真的满负载。如果 GPU 利用率低、显存带宽没用满通常是批处理没生效或者被单请求阻塞。vLLM 场景下检查--max-num-seqs是否太小比如只有一个并发请求时Continuous Batching 再高效也发挥不出来。调大--max-num-seqs、--max-model-len跟 KV cache 的平衡关系试着降低上下文长度换更高并发。CPU 推理场景则先确认线程数设置。llama.cpp 里-t参数设成物理核心数超线程参与可能反而变慢。Ollama 场景可以设置环境变量OLLAMA_NUM_PARALLEL控制并发。还有很关键的一点确保推理时没有其他进程占满 CPU 或 GPU比如残留在后台的 Python 进程会明显拖慢速度。如果只是单请求延迟高重点排查 Prefill 阶段。长输入首次输出慢是正常现象因为初始处理是计算密集。把--max-model-len设置得过长会导致 Prefill 阶段开销暴增建议按实际需要设置为输入加输出的总长度而不是盲目设到模型支持上限。5.3 量化后模型质量下降的排查量化后回答质量明显变差先别急着怪量化方案从以下几点排查第一确认量化基准模型本身够强。有些模型原版就存在幻觉多、指令遵循差的问题量化只是把问题放大了。一个 3B 模型量化到 4bit 之后表现崩不一定量化步骤有问题。第二跑 PPL 对比。拿同一段测试语料分别算原版 FP16 和量化版 PPL如果差异在 1 以内说明量化质量可以接受差异过大说明量化档位太低或者模型对量化敏感。第三尝试混合精度量化。部分框架支持指定某些模块不量化比如 AWQ 可以只量化 MLP 层而保持 Attention 层的浮点精度。有很多模型在lm_head和 embedding 层保留 FP16而其他层用 4bit效果就能明显改善。第四小心量化模型的max_model_len设置。量化后如果总上下文过长KV cache 精度也可能成为问题会导致长文本表现明显劣化适当缩短上下文反而更稳定。5.4 服务稳定性与并发保护跑生产服务时稳定性往往比单次速度更重要。几个实际建议vLLM 的max_num_seqs不要调太高否则突发并发会把显存打爆导致服务整体崩溃。宁可让请求排队等待也比 OOM 后自动重启要好。配合在 API 层面做请求限流比如并发数限制为 32对超出部分排队或返回 429。超时设置也别忽视。大模型生成 token 的时间可能很长如果 API 网关默认超时 30 秒长文本生成会频繁被中断。建议按模型速度和最大输出 token 数设置合理超时比如 120 秒以上。还要给服务加健康检查。vLLM 暴露了/health接口定时探测服务异常时自动拉起避免用户请求打进一个半死不活的服务里。我自己在部署时习惯搭配 Docker 和 systemd 做进程守护重启策略设置好之后稳定性提升非常明显。踩过几次坑之后我一直保留着一个习惯每次部署新模型先把最小可用配置跑通确认模型输出正常再逐步叠加并发、上下文等重负载参数。这个习惯帮我避开过太多配置看起来合理但实际跑崩的场景推给大家参考。无论是做个人工具、开发原型还是上线服务把每一步的变量控制住就能在大模型推理这条路上走得很稳。 从显存评估到vLLM/Ollama调优：大模型推理量化部署全攻略
大模型推理优化这事圈子里聊的人多真正从模型量化一路折腾到服务稳定跑起来的人少。很多朋友一开始以为装上 vLLM 或者 Ollama 就能畅快跑大模型结果不是被显存 OOM 卡死就是出字速度慢得像挤牙膏再或者量化完之后模型精度崩得没法看回答全是胡话。这篇东西我就把自己从零到一处理大模型推理、量化、部署的完整链路拆开讲把每一步背后的为什么和实操中踩过的坑都交代清楚。内容覆盖 GPU 资源评估、主流量化方案选型、vLLM 与 Ollama 的部署调优、常见故障排查目标是让看完的朋友能少走弯路照着思路顺利把模型跑起来。1. 推理优化的三个基本矛盾显存、带宽与延迟1.1 一次前向传播到底在干什么推理优化不是玄学先得搞清楚大模型生成一个 token 时机器里发生了什么。简单说模型权重放在显存里输入 token 经过 embedding 映射成向量然后一层层过 Transformer 的 Attention 和 MLP每一步都要做大规模矩阵乘法最后输出下一个 token 的概率分布。这个流程每生成一个 token 都要完整走一遍而且生成第 N1 个 token 时前 N 个 token 的中间结果也就是 KV cache还得保留着继续用。理解这个流程之后推理性能的三个变量就浮出来了显存容量决定模型能不能装下、能同时服务多少请求显存带宽决定权重从显存搬运到计算单元的速度这直接卡住生成速度计算吞吐决定每秒钟能完成多少次矩阵运算决定批量处理能力。绝大多数大模型推理优化工作本质都是在这三者之间做取舍不存在一劳永逸的方案。做一个生活化的类比模型权重就像一本放在书柜里的菜谱GPU 是厨师。每次按顺序查菜谱上的一个步骤读取权重然后动手做一步矩阵运算。如果菜谱本身体积很大参数多书柜得够大如果翻菜谱的速度慢带宽低做菜速度就被拖住如果厨师能同时做很多道菜吞吐高但每道菜都要看菜谱书柜又被频繁读取抢占。优化就是想办法让书柜更大、翻页更快、厨师更高效但三者往往互相制约。1.2 显存为什么总是最贵的资源显存永远是第一个瓶颈因为大模型权重和 KV cache 都住在里面。以 7B 参数的模型为例FP16 精度下权重就占 14GB 左右一张 24GB 的 RTX 4090 看似装得下但 KV cache 还要抢占空间。KV cache 大小和序列长度、并发数、层数、注意力头数直接挂钩公式大概可以估算为 2键和值乘以层数乘以头数乘以头维度乘以序列长度乘以 batch 大小再乘以精度字节数。实际跑起来并发数一上去KV cache 轻松吃掉 4 到 8GB。所以能用 4090 跑多大的模型这个问题答案从来不是只看参数量。我的经验是估算显存需求时至少要在权重基础上额外预留 30% 给 KV cache 和运行时开销。以 7B FP16 为例14GB 权重加 4-6GB KV cache24GB 的卡就差不多满了想开大并发就得换更激进的量化。如果跑 13B 或 14B 模型FP16 权重就到 26GB 以上非量化基本没戏这时候 INT4 量化几乎是唯一出路权重压到 7-8GBKV cache 空间反而宽裕不少。1.3 带宽瓶颈为什么算得快但出字慢很多人在 GPU 上跑模型发现 GPU 利用率并不高但 token 生成速度上不去卡在显存带宽上。大模型推理是典型的访存密集任务权重数据量远大于计算量。生成一个 token 要把模型全部权重从显存读一遍算完再写回部分结果这个读权重的动作才是大头。RTX 4090 的显存带宽约 1TB/s7B FP16 权重 14GB理论最短读取时间约 14 毫秒对应每秒生成 70 个 token 的乐观上限实际上因为其他开销50 tokens/s 已经算很高了。带宽瓶颈还解释了为什么量化对单卡推理提速最直接同样 7B 模型INT8 权重 7GBINT4 权重 3.5-4GB读权重时间直接减半再减半。这也是为什么笔记型电脑、游戏卡跑大模型时量化几乎是必选项。带宽利用率方面我知道有朋友会想到用 GQA分组查询注意力或者 MQA多查询注意力来缓解 KV cache 带宽压力但这是模型架构层面的事对已经定型的模型没法改。能做的更多是减少模型体积、优化批处理策略。2. 量化用精度换速度的生意经2.1 量化到底改变了什么量化本质是把模型里权重的高精度浮点数FP16 或 FP32转成低精度整数表示比如 INT8、INT4。一个 FP16 数占 2 字节INT8 占 1 字节INT4 占 0.5 字节。7B 模型从 FP16 压成 INT8权重就从 14GB 降到 7GB压到 INT4就是 3.5GB 左右。体积小了带宽压力小了计算也更快代价是精度损失。精度损失怎么理解模型权重里存储的不只是答案还有大量微小的参数关系低精度相当于把这些数四舍五入得更粗略。极端情况下模型会变笨、回答质量下降、甚至输出乱码。但实践中 INT8 量化对大多数模型影响很小INT4 则视模型鲁棒性和量化方案而定优秀的量化策略能把损失控制得很低。这就像把一张 24 位真彩色的照片压缩成 8 位色深的 PNG看起来依然能辨认但细节和渐变略微受损无损压缩做不到这个体积有损方式才是主要手段。量化的粒度也很关键常见的有按张量整个权重矩阵一个缩放系数、按通道每个输出通道独立缩放系数和按组比如每 128 个参数一组。粒度越细精度损失越小但计算和存储开销也更大。主流方案 INT4 基本都是按组量化这是精度和性能的最佳平衡点。2.2 主流量化方案对比GPTQ、AWQ 与 GGUF现在常用的大模型量化方案主要是三条路线分别适配不同的部署场景。GPTQ是学术界最出名的 PTQ训练后量化方案之一核心思路是用二阶近似信息Hessian 矩阵来逐层补偿量化误差。它对权重矩阵做逐列量化同时更新剩余未量化的权重来减少整体误差。GPTQ 量化后的模型主要在 GPU 上跑比如 vLLM、ExLlama 都支持常见档位是 FP16 基础模型量化为 4bit。我个人用下来的感觉是 GPTQ 在较大模型比如 30B 以上上精度保持得不错小模型优势不明显。AWQActivation-aware Weight Quantization则换了个角度观察发现权重里约 1% 的显著参数对模型精度影响巨大这些参数对应的激活值往往也特别大。AWQ 的做法不是简单加大这些显著通道的量化精度而是通过一个缩放系数让这些通道在量化后不容易出大误差。AWQ 量化速度快不需要反向传播精度在 4bit 场景下和 GPTQ 接近甚至更好vLLM 中支持得很完善。实际部署 API 服务时我优先选 AWQ。GGUF是 llama.cpp 生态的格式基于 k-quant 方案支持 2bit 到 8bit 多种档位Q2_K、Q3_K、Q4_K_M、Q5_K_M、Q6_K、Q8_0 等。它的特点是可以把部分层放 GPU、部分层放 CPU实现 CPU/GPU 混合推理内存占用可控非常适合本地电脑、Mac 或低显存环境。Ollama 直接吃 GGUF 格式下载即用这也是 GGUF 在社区最流行的原因。三者的选择逻辑可以总结为一张表方案核心特点最佳场景参考工具GPTQHessian 补偿GPU 友好大模型 GPU 部署、服务端vLLM、ExLlamaAWQ激活感知显著通道保护高并发 API 服务、精度敏感场景vLLM、SGLangGGUFCPU/GPU 混合、多档位本地单机、低显存、Macllama.cpp、Ollama2.3 量化档位选择不是越低越好量化档位看起来越低越好因为模型体积小、速度快但能用和好用差距巨大。我的经验法则是优先 Q8/INT8 起步它和 FP16 的差距微乎其微绝大多数任务体感不出来显存不够再降到 Q6/Q5精度依然稳健Q4 是底线Q4_K_M 这类中档 4bit 在多数模型上仍可接受Q3 及以下只建议拿来测试不要用在正式场景。选档位还要考虑模型原始大小和任务复杂度。一个 70B 的强模型即便量化到 Q4可能还是比一个 7B 的 FP16 模型聪明得多这时候牺牲精度换模型规模是划算的。反过来如果只是做一个翻译或者简单摘要功能小模型的 Q8 也比大模型的 Q3 稳定。没有绝对的最好档位只有针对显存和任务需求的平衡。判断量化效果不能靠感觉要跑量化前后的困惑度perplexityPPL对比PPL 数值越低代表模型对文本的预测越自信量化前后数值不应有太大波动。具体做法是拿一段模型没见过的语料分别让原版和量化版计算 PPL偏差超过 1-2 说明量化方案对该模型不友好需要换档位或者混合精度方案。注意有些模型本身对量化非常敏感特别是小模型1B 以下或者经过大量 RLHF 对齐的模型4bit 量化后会出现明显的输出质量下降、幻觉增多。遇到这种情况优先把 Attention 层保留高精度只量化 MLP 层或者退一档到 Q5/Q6。3. 部署引擎选型vLLM、Ollama 与其余方案3.1 vLLM高并发 API 服务的吞吐之王vLLM 是目前服务端部署大模型的主流选择核心优势在 PagedAttention 和 Continuous Batching。PagedAttention解决了 KV cache 碎片化问题。KV cache 在显存里是一段段连续空间不同请求长度不同如果按最长序列给每个请求预留空间显存浪费巨大。PagedAttention 把 KV cache 分成固定大小的块像操作系统的虚拟内存页面按需分配、按需回收显存利用率大幅提升。实测在同样显存下vLLM 比传统方案能支持的并发请求数高 2 到 4 倍。Continuous Batching则是动态调度策略。传统静态 batching 是攒够一批请求再一起跑有大量等待空档。Continuous Batching 允许请求随时进入、随时退出一个请求生成完了马上腾出位置给新请求GPU 始终在处理有效计算。这个特性让吞吐量显著提升特别适合多用户并发场景。vLLM 对量化模型的支持也很全。启动时直接用--quantization awq或--quantization gptq就能加载对应格式。它还内置了 OpenAI 兼容的 API 服务前端应用几乎不用改代码就能接入。3.2 Ollama本地玩家的最短路径如果你不是跑高并发服务只是想在个人电脑上跑模型Ollama 是最省心的方案。一行ollama run qwen2.5:7b就能把模型拉下来跑起来。Ollama 底层用的是 llama.cpp天然支持 GGUF 格式CPU 和 GPU 都能跑而且自动分配资源。ollama 的 ModelFile 机制支持自定义模型参数比如NUM_CTX上下文长度、温度、top_p 等。也可以从本地 GGUF 文件直接创建模型ollama create mymodel -f ModelfileModelfile 里只要写一行FROM ./qwen2.5-7b-q4_k_m.gguf这样就能把自己量化好的模型导入 Ollama 管理。Ollama 的优势是零成本上手、生态完善Open WebUI 等前端一键接入劣势是吞吐和并发能力有限高负载场景不建议用。3.3 其他部署方案按场景挑选趁手工具除了 vLLM 和 Ollama还有几个值得关注的方案。llama.cpp是 GGUF 生态的源头也是 CPU 推理性能优化的标杆。它对消费级 CPU 有大量汇编级优化纯 CPU 跑小模型也能做到每秒几十个 token。适合无 GPU 的服务器或老电脑。LMDeploy是国产方案里功能很全的一个支持 TurboMind 引擎、AWQ 量化、多卡推理。它的吞吐表现和 vLLM 不相上下支持特性也全像是在批量推理比如离线跑任务场景有独特优势。TensorRT-LLM是英伟达官方方案性能天花板最高但配置门槛也最高需要做模型转换和编译一般适合对延迟有极致要求、有定制化需求的场景。部署引擎选型的参考标准我整理成表引擎核心优势典型场景显存要求vLLM高并发、全功能 API生产服务、多用户高尽量 GPUOllama一键部署、GGUF个人本地、快速体验低可 CPUllama.cppCPU 优化、轻量无独显环境最低LMDeploy全流程国产、批处理离线批量推理中TensorRT-LLM极致性能商业产品、定制高4. 从量化到部署的完整实操流程4.1 前置条件与硬件评估动手之前先把硬件账算清楚。你可以用nvidia-smi查看显卡显存用lscpu和free -h看 CPU 和内存。显存决定能跑多大的模型、多少并发内存决定了能不能做 CPU offload 或者是否支持某些引擎的开销CPU 性能影响 Prefill 阶段初始输入处理和纯 CPU 推理的速度。估算显存需求的实用公式显存约等于权重大小加上 KV cache 再加上约 15% 的运行时开销。以 AWQ 4bit 量化后的 7B 模型为例权重约 4GBKV cache 按 4096 上下文、16 并发估算大约 4GB再加开销10GB 显存就能凑合跑如果量化成 8bit权重翻倍到 8GB总共就要 14GB 左右。选模型时先按这个公式套一圈省得下载半天模型跑到一半 OOM。4.2 GGUF 离线量化实操如果 Ollama 官方仓库没有现成的 GGUF 模型就要自己动手把 Hugging Face 上的原模型转成 GGUF 并量化。以 llama.cpp 为例先更新到最新版并安装 Python 依赖git clone https://github.com/ggerganov/llama.cpp cd llama.cpp pip install -r requirements.txt make -j4然后先把 HF 原模型转成 FP16 GGUF 格式python convert_hf_to_gguf.py ./models/qwen2.5-7b \ --outfile ./models/qwen2.5-7b-fp16.gguf \ --outtype f16下一步生成你要的量化档位比如 Q4_K_M./llama-quantize ./models/qwen2.5-7b-fp16.gguf \ ./models/qwen2.5-7b-q4_k_m.gguf Q4_K_M量化完成后可以跑一次困惑度测试验证精度损失是否可接受./llama-perplexity -m ./models/qwen2.5-7b-q4_k_m.gguf \ -f ./test_data.txt实操中我发现convert_hf_to_gguf.py对模型架构的兼容性偶尔有问题个别新模型要等 llama.cpp 更新支持。建议下载模型后先看仓库说明优先选已经标注支持 GGUF 转换的模型。量化速度方面7B 模型用消费级 GPU 大概 5-10 分钟纯 CPU 会慢很多可以用-t 8参数调线程数。4.3 vLLM 部署与启动配置部署 Python 环境并安装 vLLMpython -m venv vllm_env source vllm_env/bin/activate pip install vllm如果用现成的 AWQ 量化模型启动一个 OpenAI 兼容服务vllm serve ./models/qwen2.5-7b-awq/ \ --quantization awq \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 16 \ --port 8000参数逐个说明--tensor-parallel-size单卡设置 1多卡就填卡数前提是卡间通信够快--max-model-len是最大上下文长度越长 KV cache 占显存越多--gpu-memory-utilization是允许占用的显存比例0.9 是安全值太高容易在模型加载阶段 OOM--max-num-seqs是最大并发序列数数和显存 KV cache 直接相关保守起见 16 起步。启动完成后用 curl 简单验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen2.5-7b-awq, messages: [{role: user, content: 你好}], max_tokens: 100}能正常返回内容说明服务已经就绪。vLLM 在启动时如果做预编译或图模式优化会很慢推荐先用默认模式验证通链路再开优化选项降低排查难度。4.4 Ollama 导入本地 GGUF 模型拿到量化好的 GGUF 文件导入 Ollama 只需要两步。第一创建一个 ModelfileFROM ./qwen2.5-7b-q4_k_m.gguf # 可选设置上下文长度 PARAMETER num_ctx 8192然后执行ollama create qwen2.5-7b-q4 -f Modelfile ollama run qwen2.5-7b-q4如果你是从 Ollama 官方仓库直接拉模型那连这两步都省了。但自己量化导入的好处是能精确控制档位和上下文长度。Ollama 默认会尝试用 GPU显存不够会自动切换到 CPU这种弹性机制让它成为本地部署最不容易出问题的方案。5. 常见问题排查与性能调优实录5.1 显存不足与 OOM 排查OOMOut of Memory是部署大模型时最常见的报错。我的排查思路是逐步缩小变量先看是启动时 OOM 还是运行时 OOM。启动时 OOM大概率是模型权重加预分配缓存超过显存总量调低--gpu-memory-utilization或者换更低档位量化。运行时 OOM大概率是并发数或上下文长度超出预留 KV cache就降低--max-num-seqs和--max-model-len。还有一个隐蔽的坑多卡机器上显存分配不均匀。PyTorch 默认可能把所有显存分配到卡 0跑起来卡 0 OOM 而其他卡空闲。用--tensor-parallel-size多卡部署时先确认CUDA_VISIBLE_DEVICES设置正确再用nvidia-smi实时观察每张卡的使用率。日志里看到的torch.cuda.OutOfMemoryError: CUDA out of memory往往不是真正的显存满了可能只是碎片化严重。尝试设置环境变量PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来改善内存碎片实测在某些场景能抢救回来不少空间。5.2 生成速度慢与吞吐低生成速度慢第一反应不是加硬件而是确认当前是不是真的满负载。如果 GPU 利用率低、显存带宽没用满通常是批处理没生效或者被单请求阻塞。vLLM 场景下检查--max-num-seqs是否太小比如只有一个并发请求时Continuous Batching 再高效也发挥不出来。调大--max-num-seqs、--max-model-len跟 KV cache 的平衡关系试着降低上下文长度换更高并发。CPU 推理场景则先确认线程数设置。llama.cpp 里-t参数设成物理核心数超线程参与可能反而变慢。Ollama 场景可以设置环境变量OLLAMA_NUM_PARALLEL控制并发。还有很关键的一点确保推理时没有其他进程占满 CPU 或 GPU比如残留在后台的 Python 进程会明显拖慢速度。如果只是单请求延迟高重点排查 Prefill 阶段。长输入首次输出慢是正常现象因为初始处理是计算密集。把--max-model-len设置得过长会导致 Prefill 阶段开销暴增建议按实际需要设置为输入加输出的总长度而不是盲目设到模型支持上限。5.3 量化后模型质量下降的排查量化后回答质量明显变差先别急着怪量化方案从以下几点排查第一确认量化基准模型本身够强。有些模型原版就存在幻觉多、指令遵循差的问题量化只是把问题放大了。一个 3B 模型量化到 4bit 之后表现崩不一定量化步骤有问题。第二跑 PPL 对比。拿同一段测试语料分别算原版 FP16 和量化版 PPL如果差异在 1 以内说明量化质量可以接受差异过大说明量化档位太低或者模型对量化敏感。第三尝试混合精度量化。部分框架支持指定某些模块不量化比如 AWQ 可以只量化 MLP 层而保持 Attention 层的浮点精度。有很多模型在lm_head和 embedding 层保留 FP16而其他层用 4bit效果就能明显改善。第四小心量化模型的max_model_len设置。量化后如果总上下文过长KV cache 精度也可能成为问题会导致长文本表现明显劣化适当缩短上下文反而更稳定。5.4 服务稳定性与并发保护跑生产服务时稳定性往往比单次速度更重要。几个实际建议vLLM 的max_num_seqs不要调太高否则突发并发会把显存打爆导致服务整体崩溃。宁可让请求排队等待也比 OOM 后自动重启要好。配合在 API 层面做请求限流比如并发数限制为 32对超出部分排队或返回 429。超时设置也别忽视。大模型生成 token 的时间可能很长如果 API 网关默认超时 30 秒长文本生成会频繁被中断。建议按模型速度和最大输出 token 数设置合理超时比如 120 秒以上。还要给服务加健康检查。vLLM 暴露了/health接口定时探测服务异常时自动拉起避免用户请求打进一个半死不活的服务里。我自己在部署时习惯搭配 Docker 和 systemd 做进程守护重启策略设置好之后稳定性提升非常明显。踩过几次坑之后我一直保留着一个习惯每次部署新模型先把最小可用配置跑通确认模型输出正常再逐步叠加并发、上下文等重负载参数。这个习惯帮我避开过太多配置看起来合理但实际跑崩的场景推给大家参考。无论是做个人工具、开发原型还是上线服务把每一步的变量控制住就能在大模型推理这条路上走得很稳。