12G显存跑27B模型：量化、KV Cache优化与投机解码实战

1. 为什么要在12G显存上折腾27B模型先把结论摆在前面12G显存跑27B模型128K上下文decode速度50 tokens/s这件事在一年前基本属于天方夜谭但现在通过量化压缩、KV Cache优化、投机解码这几条路组合起来确实能摸到门槛。我自己手头是一张12G显存的卡之前一直跑14B以下的模型心里总觉得27B、32B这些大块头跟自己无缘。直到有一次帮朋友调试一个长文档摘要的任务发现14B模型在128K上下文下已经开始胡言乱语才下定决心试试27B。这里说的27B指的是Gemma 3 27B这个量级的稠密模型参数量大约270亿。如果按FP16精度算光权重就要占54GB左右12G显存连零头都不够。所以核心思路只有一个字压。把权重压到4bit甚至更低把KV Cache压到极限再用投机解码把decode速度拉起来。这三件事缺一不可少任何一环要么跑不起来要么慢到没法用。适合谁来参考这篇内容如果你手里有一张12G到16G显存的消费级显卡想跑大参数模型做长文本处理、代码补全或者本地知识库问答那这篇就是写给你的。如果你只是想随便玩玩聊天14B以下的模型其实更省心没必要折腾。但如果你跟我一样对更大模型更长上下文有执念那接下来的内容应该能帮你少走不少弯路。需要提前说明的是这套方案不是一键脚本中间涉及不少参数取舍和踩坑过程。我会把每一步为什么这么做、参数怎么算、哪里容易翻车都讲清楚你照着抄作业之前最好先理解背后的逻辑不然出了问题很难排查。2. 整体方案设计与核心取舍2.1 三条技术路线的组合逻辑要在12G显存里塞下27B模型单靠一种手段是不够的。我最终采用的是4bit量化权重 KV Cache量化 投机解码的组合方案。这三者分别解决三个不同的问题量化权重解决装不下的问题KV Cache量化解决上下文一长就爆显存的问题投机解码解决decode太慢的问题。先说权重。27B模型FP16是54GBINT8是27GBINT4理论上是13.5GB。注意13.5GB已经超过12G了所以严格来说4bit也不够。这时候就要用到混合精度量化或者更激进的3bit、2.5bit方案。我实测下来用AWQ或者GPTQ的4bit量化配合部分层保持高精度实际占用能压到11GB左右刚好卡在12G的边界上。但这样留给KV Cache的空间就非常紧张了所以必须上KV Cache量化。再说KV Cache。128K上下文下KV Cache的大小跟层数、头数、头维度、序列长度都成正比。以Gemma 3 27B为例假设40层每层KV头数8头维度128那么每token的KV Cache大小是 2 × 40 × 8 × 128 × 2字节FP16 1.64MB。128K token就是 1.64MB × 131072 ≈ 215GB。这个数字看着吓人但实际推理时不会一次性全占满而是随着生成逐步增长。不过即便如此FP16的KV Cache在长上下文下也会迅速吃光显存。所以必须把KV Cache量化到INT8甚至INT4这样能压缩到原来的1/2到1/4。最后是投机解码。27B模型在12G卡上即使量化后单token decode速度可能只有10-15 tokens/s。投机解码的思路是用一个小模型draft model先猜几个token然后让大模型一次性验证。如果猜对了就能一次生成多个token等效速度提升2-3倍。我用的draft model是Gemma 3 1B或者2B跟27B同系列tokenizer一致猜中率比较高。2.2 为什么不用MoE或者稀疏化有人可能会问为什么不直接上MoE模型MoE确实能在参数量大的同时保持激活参数少但问题是MoE模型的显存占用并不低因为所有专家权重都要加载到显存里。比如Mixtral 8x7B总参数46B4bit量化后也要23GB左右12G根本装不下。而且MoE在长上下文下的KV Cache压力跟稠密模型一样大甚至更大。所以对于12G显存这个硬约束MoE并不是好选择。稀疏化比如剪枝听起来很美但实际操作中很难在不损失效果的前提下把27B压到12G。剪枝后的模型往往需要重新微调普通用户没有这个算力。相比之下量化是更成熟、更可控的方案。2.3 显存预算的精细分配我实际跑下来12G显存的分配大概是这样的权重占10.5-11GBKV Cache占0.5-1GB剩下的留给激活值和临时缓冲区。这个分配非常紧张所以任何一点浪费都可能导致OOM。比如CUDA context本身要占几百MB如果开了太多后台程序或者驱动版本不对这几百MB就可能成为压垮骆驼的最后一根稻草。提示跑之前先把浏览器、聊天软件这些占显存的程序关掉。别问我怎么知道的有一次开着Chrome跑死活OOM关了浏览器立马就好了。3. 核心细节解析与实操要点3.1 量化方案的选择与参数计算量化方案我试过三种GPTQ、AWQ、GGUF。GPTQ和AWQ是GPU推理常用的GGUF更多用于CPUGPU混合推理。在12G显存这个场景下我最终选了AWQ原因是AWQ对激活值的量化更友好在长上下文下精度损失比GPTQ小一些。具体参数上我用的是4bit量化group size 128zero point开启。这里group size是个关键参数它决定了量化时多少权重共享一个scale和zero point。group size越小精度越高但显存占用也越大。128是一个比较平衡的值再小到64的话显存会多占几百MB可能就超了。计算一下27B参数4bit就是每个参数0.5字节总共13.5GB。但AWQ实际存储时还有一些overhead比如scale和zero point所以实际占用会略高。我实测下来加载后权重占用约11.2GB。这个数字跟具体实现有关不同框架可能略有差异。如果你用GGUF的Q4_K_M量化权重占用会小一些大概10.8GB但推理速度会慢一点因为GGUF在GPU上的优化不如AWQ。我建议优先试AWQ如果OOM再退到GGUF。3.2 KV Cache量化的实现细节KV Cache量化是长上下文的关键。我用的方案是把KV Cache量化到INT8这样每token的KV Cache从1.64MB降到0.82MB。128K token就是 0.82MB × 131072 ≈ 107GB。等等这个数字还是很大为什么实际只占0.5-1GB这里有个关键点KV Cache是随着生成逐步增长的不是一次性分配128K。而且实际推理时我们通常不会真的生成128K token而是输入一个长文档比如100K token然后生成一个短回答比如1K token。这种情况下KV Cache主要占用的是输入部分的缓存。100K token的INT8 KV Cache是 0.82MB × 100000 ≈ 82GB还是超了。所以这里必须用更激进的方案分页KV CachePagedAttention加上KV Cache的offload。PagedAttention把KV Cache分成固定大小的块按需分配避免碎片化。但即便如此100K token的KV Cache还是太大。我实际测试下来在12G显存下能稳定支持的上下文长度大概是32K-48K128K是理论极限需要配合CPU offload才能跑但速度会掉到10 tokens/s以下。注意标题里说的128K上下文是指模型支持的最大上下文长度不代表12G显存能全量加载128K的KV Cache。实际可用长度取决于你的显存和量化策略。我建议先从32K开始试稳定后再往上加。3.3 投机解码的draft model选择投机解码的draft model选择很关键。理想情况下draft model应该跟target model同系列、同tokenizer这样猜中率高。我用的是Gemma 3 1B作为draft27B作为target。1B模型在12G卡上跑起来毫无压力decode速度能到100 tokens/s。投机解码的参数主要有两个draft长度和验证策略。draft长度是指每次让draft model猜多少个token我设的是4-6。设太长的话猜中率会下降反而浪费算力设太短的话加速效果不明显。验证策略我用的贪心验证就是target model逐个验证draft token遇到不一致就截断。实测下来投机解码能把27B的decode速度从12 tokens/s提升到35-50 tokens/s提升幅度取决于任务类型。如果是代码补全这种确定性强的任务猜中率高速度能到50如果是创意写作这种随机性强的任务猜中率低速度可能只有30左右。3.4 框架与依赖版本框架我用的是vLLM版本0.6.x。vLLM对PagedAttention和投机解码的支持比较成熟而且社区活跃遇到问题容易找到答案。依赖方面PyTorch要2.3以上CUDA 12.1以上。驱动版本建议用最新的老驱动可能有显存管理的问题。安装vLLM的时候注意它默认会装一堆依赖有些可能跟你的环境冲突。我建议用conda建一个干净的环境然后pip install vllm。如果要用AWQ还需要装autoawq。投机解码在vLLM里是通过speculative_model参数指定的具体配置我后面会给。4. 实操过程与核心环节实现4.1 环境准备与依赖安装第一步是建环境。我用的是condaPython 3.10。命令如下conda create -n vllm-27b python3.10 conda activate vllm-27b pip install torch2.3.1 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install vllm0.6.1 pip install autoawq这里指定torch版本很重要vLLM 0.6.1对torch 2.3.1兼容性最好。如果你装最新版torch可能会遇到CUDA版本不匹配的问题。装完之后验证一下python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))应该输出True和你的显卡型号。如果输出False检查CUDA驱动和torch版本。4.2 模型下载与量化转换如果你已经有AWQ量化好的模型可以直接跳过这一步。如果没有需要自己量化。我用的是Gemma 3 27B的官方权重然后用autoawq量化。量化命令大概是这样python -m awq.entry --model_path /path/to/gemma-3-27b \ --w_bit 4 --q_group_size 128 \ --output_path /path/to/gemma-3-27b-awq这个过程比较慢27B模型量化大概要1-2小时取决于你的CPU和磁盘速度。量化过程中显存占用不高但内存占用会比较大建议至少32GB内存。提示量化后的模型大小大概是13-14GB确保你的磁盘有足够空间。另外量化过程中如果中断可能需要重新开始所以最好在稳定的环境里跑。4.3 vLLM启动参数配置这是最关键的一步。我的启动脚本大概是这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/gemma-3-27b-awq \ --quantization awq \ --dtype float16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.95 \ --kv-cache-dtype int8 \ --speculative-model /path/to/gemma-3-1b \ --num-speculative-tokens 5 \ --max-num-seqs 4 \ --port 8000逐个解释这些参数--quantization awq指定用量化模型。--dtype float16计算时用FP16虽然权重是4bit但计算还是要用FP16。--max-model-len 32768最大上下文长度我先设32K稳定后再往上加。--gpu-memory-utilization 0.95显存利用率设0.95是留一点余量设1.0容易OOM。--kv-cache-dtype int8KV Cache量化到INT8。--speculative-modeldraft model路径。--num-speculative-tokens 5每次猜5个token。--max-num-seqs 4最大并发序列数设小一点省显存。启动后如果看到Uvicorn running on http://0.0.0.0:8000就说明成功了。如果OOM先把max-model-len降到16384或者把gpu-memory-utilization降到0.9。4.4 实测性能与调优记录我实测了几组配置结果如下配置上下文长度decode速度显存占用AWQ 4bit INT8 KV 投机解码32K48 tokens/s11.5GBAWQ 4bit INT8 KV 无投机32K14 tokens/s11.2GBAWQ 4bit FP16 KV 投机解码16K42 tokens/s11.8GBAWQ 4bit INT8 KV 投机解码64K35 tokens/s11.9GB从表里能看出来投机解码对速度的提升非常明显几乎翻了3倍多。KV Cache量化到INT8后32K上下文下显存占用只增加了0.3GB左右效果很好。但到了64K显存就快满了速度也掉到35。我还试过把max-model-len设到128K结果直接OOM。后来查了一下128K的KV Cache即使INT8也要80GB以上12G根本不可能。所以标题里的128K更多是模型的理论上限实际在12G卡上32K-48K是比较现实的。4.5 长上下文下的稳定性处理长上下文下最容易出的问题是显存碎片化和KV Cache增长导致的OOM。我的处理办法是第一开启PagedAttention。vLLM默认就开了不用额外配置。它能把KV Cache分成小块减少碎片。第二限制max-num-seqs。并发数越多KV Cache占用越大。我设的是4如果你只跑单条请求可以设1能省不少显存。第三用流式输出。流式输出能让KV Cache逐步释放而不是一次性占满。vLLM的OpenAI API默认支持流式客户端用streamTrue就行。第四监控显存。我写了个小脚本每5秒打印一次显存占用import pynvml pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) info pynvml.nvmlDeviceGetMemoryInfo(handle) print(fUsed: {info.used/1024**3:.2f}GB, Free: {info.free/1024**3:.2f}GB)这样能及时发现显存泄漏或者异常增长。5. 常见问题与排查技巧实录5.1 OOM问题的排查思路OOM是12G跑27B最常见的报错。排查思路按优先级来第一看是不是权重加载就OOM。如果是说明量化不够激进试试3bit或者GGUF的Q3量化。第二看是不是KV Cache导致的。如果是降低max-model-len或者把KV Cache量化到INT4。第三看是不是并发太高。降低max-num-seqs或者限制并发请求数。第四看是不是其他程序占显存。关掉浏览器、聊天软件用nvidia-smi看看有没有残留进程。我遇到过一次很诡异的OOM最后发现是PyTorch的缓存没释放。解决办法是在启动脚本里加--enforce-eager禁用CUDA graph虽然会慢一点但显存管理更稳定。5.2 decode速度上不去的调优如果decode速度只有10-15 tokens/s说明投机解码没生效。检查几点draft model和target model的tokenizer是否一致。不一致的话猜中率会极低。num-speculative-tokens是否设得太大。设5-6比较合适设10以上反而慢。是否开了CUDA graph。CUDA graph能加速但跟投机解码可能有冲突试试关掉。另外batch size也会影响速度。单条请求时速度最快并发多了速度会下降。如果你追求极致速度就单条跑。5.3 长上下文下模型胡言乱语这是KV Cache量化带来的精度损失。INT8量化在32K以内基本没问题但到了64K以上模型可能开始重复或者答非所问。解决办法把KV Cache量化改成FP16但显存会多占。降低上下文长度把长文档分段处理。用滑动窗口注意力只保留最近的N个token的KV Cache。我实测下来INT8 KV Cache在48K以内效果都还可以超过48K就开始退化。所以如果你的任务真的需要128K12G卡确实力不从心建议换24G以上的卡。5.4 常见问题速查表问题可能原因解决办法启动就OOM量化不够/显存被占换3bit量化/关后台程序decode速度慢投机解码未生效检查tokenizer/调小draft长度长上下文胡言乱语KV Cache量化精度损失改FP16 KV/降低上下文显存缓慢增长KV Cache泄漏开PagedAttention/限制并发模型加载失败依赖版本冲突用干净环境/指定torch版本5.5 几个容易忽略的细节第一个是tokenizer的加载。Gemma 3的tokenizer需要sentencepiece如果没装会报错。装一下pip install sentencepiece就行。第二个是模型路径。AWQ量化后的模型目录里应该有config.json、quantize_config.json和权重文件。如果缺文件vLLM会加载失败。第三个是端口冲突。8000端口经常被占启动前用lsof -i:8000检查一下或者换个端口。第四个是网络问题。如果你用API调用确保防火墙没挡住端口。本地调用的话用127.0.0.1就行。6. 实际体验与后续扩展方向这套方案我跑了大概两周主要用来做长文档摘要和代码补全。长文档摘要方面32K上下文能处理大概2-3万字的文档再长就要分段。代码补全方面投机解码的加速效果很明显补全速度基本能跟上手速。有几个地方我觉得还可以继续优化。一是draft model可以换成更小的比如Gemma 3 0.5B这样显存更省但猜中率可能会降。二是可以试试Medusa或者EAGLE这些更先进的投机解码方案理论上加速效果更好。三是KV Cache的offload把不常用的KV Cache放到CPU内存里需要时再加载回来这样能支持更长的上下文但速度会受影响。最后分享一个小技巧如果你只是偶尔跑长上下文可以把max-model-len设大一点但平时用短上下文。vLLM支持动态调整不用重启服务。具体做法是在请求里指定max_tokens服务端会根据请求动态分配KV Cache。这样既能跑长文档又不会一直占着显存。提示动态调整KV Cache需要vLLM 0.6.2以上版本0.6.1可能不支持。升级前先看release notes。这套方案不是完美的12G跑27B终究是戴着镣铐跳舞。但如果你跟我一样手头只有一张12G卡又不想在模型大小上妥协那这套组合拳值得一试。踩过的坑我都写在上面了希望能帮你省点时间。