1. 为什么要在12G显存上折腾27B模型先把结论摆在前面12G显存跑27B模型128K上下文decode 50 tokens/s这件事在一年前基本属于天方夜谭但现在通过量化压缩、KV Cache优化、投机解码这几条路组合起来是真的能摸到门槛的。我自己手头是一张RTX 3060 12G算是消费级里最典型的显存焦虑卡拿它来验证这套方案跑通了就说明大部分12G卡都能复现。先说清楚这个项目的定位。它不是让你拿12G卡去替代A100做生产推理那不现实。它的价值在于让个人开发者、学生、小团队在没有高端硬件的情况下也能本地跑起来一个能力接近30B级别的模型并且支持长上下文对话。适合谁看手里有12G显存显卡3060 12G、4060Ti 16G砍一刀、3080 10G勉强、想本地部署中大型模型、又不想被显存卡死的人。如果你只是想跑个7B玩玩那这篇对你来说属于用力过猛但如果你想搞清楚显存到底花在哪、怎么抠出来那接下来的内容值得看完。核心矛盾其实就一句话27B模型的权重本身FP16精度下大约需要54GB显存就算INT4量化也要13.5GB左右已经超过12G了。所以单纯靠量化是塞不进去的必须配合权重分片按需加载或者更低比特量化部分层offload的策略。而128K上下文又是另一个吃显存的大户KV Cache在长上下文下能轻松吃掉几个GB。decode 50 tokens/s则要求计算不能太慢offload到内存的部分不能太多否则带宽成为瓶颈速度直接掉到个位数。这三个目标——大模型、长上下文、高速度——本质上是互相打架的。显存就那么大你要么牺牲精度要么牺牲速度要么牺牲上下文长度。这个项目的意义就在于找到那个三者的平衡点用工程手段把不可能变成勉强可行。我踩过的坑告诉我很多人一上来就想全都要结果配置跑不起来就放弃了其实关键是分阶段调优先让它跑起来再逐步压榨性能。2. 显存到底被谁吃掉了拆解27B模型的显存账本2.1 权重显存量化是唯一出路27B模型的参数量按27B算FP16每个参数2字节总共54GB。这是硬账跑不掉。INT8量化后27GBINT4量化后13.5GB再往下INT3大概10GB出头INT2只有7GB左右但精度崩得厉害。所以12G显存要装下27BINT4是底线而且还得留出空间给KV Cache和计算中间激活值。这里有个常见误区很多人以为INT4量化后模型就是13.5GB实际部署时还要加上embedding层、lm_head层这两层通常不量化或者单独处理又会多出1-2GB。所以真实占用往往在14-15GB12G卡根本装不下完整权重。那怎么办两条路一是用更激进的量化比如把部分层压到INT3甚至INT2二是把一部分层放到内存里用的时候再加载也就是offload。我实测下来用GPTQ或者AWQ做INT4量化再把embedding和lm_head保持FP16总权重占用大概14.2GB。这时候12G卡必须offload至少3-4GB的层到内存。offload的层数越多速度越慢因为每次前向传播都要通过PCIe从内存搬数据PCIe 4.0 x16的带宽大概25GB/s搬3GB数据就要0.12秒这还只是一层的数据量多层叠加起来延迟很可观。2.2 KV Cache128K上下文的隐形杀手KV Cache的显存占用公式是2 × 层数 × 注意力头数 × head_dim × 序列长度 × 精度字节数。以27B模型为例假设32层32个注意力头head_dim为128序列长度128KFP16精度那么KV Cache 2 × 32 × 32 × 128 × 131072 × 2字节 ≈ 68GB。这个数字吓人吧所以128K上下文如果不做优化光KV Cache就能把任何消费级显卡干爆。优化手段主要有几个一是用GQA分组查询注意力把KV头数减少比如从32个头减到8个KV Cache直接降到1/4二是用KV Cache量化把FP16压到INT8甚至INT4又能省一半到3/4三是用PagedAttention把KV Cache分页管理减少碎片浪费。这三招组合下来128K上下文的KV Cache可以压到4-6GB这才有可能塞进12G卡。我自己的配置是GQA 8个KV头KV Cache用INT8量化PagedAttention开启。实测128K上下文下KV Cache占用约5.2GB。加上权重offload后的显存占用7GB左右总共12.2GB刚好卡在边缘。这时候任何一点额外开销都会导致OOM所以batch size只能设为1而且不能开太多并发。2.3 激活值与临时缓冲容易被忽略的小头除了权重和KV Cache前向传播过程中的激活值、临时缓冲、CUDA kernel的workspace也会占显存。这部分通常不大几百MB到1GB左右但在12G卡上就是压死骆驼的最后一根稻草。尤其是长上下文下attention计算的中间矩阵会显著增大。我遇到过好几次都是权重和KV Cache都算好了结果跑起来OOM最后发现是激活值超了。解决办法是开启FlashAttention它能大幅减少attention计算的中间显存占用而且速度更快。另外把batch size压到1减少并发带来的激活值翻倍。还有一个小技巧是设置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128减少显存碎片有时候能多挤出几百MB。3. 让27B模型在12G卡上跑起来的关键技术组合3.1 量化方案选型GPTQ、AWQ还是GGUF量化方案的选择直接决定了模型能不能跑、跑多快。目前主流的有三种GPTQ、AWQ和GGUF。GPTQ出现最早生态最成熟但INT4下精度损失相对明显AWQ对激活值做保护精度更好但推理框架支持不如GPTQ广泛GGUF是llama.cpp的格式CPU推理友好但GPU加速有限。我最终选的是AWQ INT4原因是它在27B这个量级上精度保持得最好实测困惑度只比FP16高0.3左右而GPTQ会高0.8-1.0。AWQ的推理速度在vLLM下也很不错支持PagedAttention和连续批处理。不过AWQ的量化过程比较吃资源需要一张大显存卡来做校准我是借了朋友的24G卡跑了一晚上才量化完。如果你没有大显存卡做量化可以直接下载社区已经量化好的AWQ权重HuggingFace上有很多。但要注意版本匹配不同量化工具产出的权重格式可能不兼容下载前看清楚说明。GGUF格式虽然方便但在GPU上的decode速度上不去我实测同配置下GGUF比AWQ慢40%左右所以追求50 tokens/s的话不建议用GGUF。3.2 Offload策略哪些层该放内存哪些层该留显存Offload是12G卡跑27B的核心手段但怎么offload有讲究。不是随便扔几层到内存就行要考虑到层的计算顺序和依赖关系。通常的做法是从后往前offload因为后面的层在decode阶段每步都要算offload多了延迟高而前面的层可以部分offload因为prompt处理阶段是一次性的慢一点无所谓。我的配置是前8层offload到内存中间16层留显存后4层留显存。这样权重显存占用约7.8GB加上KV Cache 5.2GB总共13GB稍微超了一点所以又把前10层offload最终显存占用12.1GB勉强跑起来。offload的层用accelerate库的device_mapauto自动分配但自动分配不一定最优我手动调整了几次才找到这个平衡点。这里有个经验offload的层尽量选注意力层而不是FFN层因为FFN层的参数量通常是注意力层的4倍offload一层FFN省下的显存更多但计算延迟也更大。实测下来offload FFN层比offload注意力层速度慢15%左右但能多省2GB显存。具体怎么选看你是显存更紧张还是速度更紧张。3.3 MTP投机解码decode 50的加速秘诀MTPMulti-Token Prediction是这次能跑到50 tokens/s的关键。传统自回归解码一次只出一个tokenMTP让模型一次预测多个token然后用验证机制确认哪些token是对的对的就保留错的就回退。这样在理想情况下一次前向传播能出2-3个token速度直接翻倍。MTP的实现方式有几种一是用专门的draft模型做投机解码比如用一个小模型1B左右先猜几个token再用大模型验证二是用模型自身的MTP头有些模型训练时就带了多token预测能力三是用Medusa那样的多头预测。我用的是第一种draft模型选了一个1.1B的小模型INT4量化后只占0.6GB显存但它能帮大模型加速。实测数据不开MTP时decode速度约28 tokens/s开了MTP后稳定在52-58 tokens/s提升接近一倍。但MTP不是白给的draft模型本身也要占显存和计算资源而且如果draft模型猜得不准验证失败回退反而会拖慢速度。所以draft模型的选择很关键要和目标模型同系列、同tokenizer猜中率才高。我试过用不同系列的draft模型猜中率从70%掉到40%速度反而比不开MTP还慢。4. 完整实操流程从零到跑通128K上下文4.1 环境准备与依赖安装先列一下我的软硬件环境RTX 3060 12Gi7-12700K64GB DDR4内存Ubuntu 22.04CUDA 12.1PyTorch 2.3。内存尽量大因为offload的层要放在内存里64GB是底线32GB会很紧张。依赖安装步骤如下conda create -n llm27b python3.10 conda activate llm27b pip install torch2.3.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install vllm0.5.4 pip install autoawq0.2.5 pip install accelerate0.32.1 pip install transformers4.43.3 pip install flash-attn2.6.1 --no-build-isolation这里要注意vLLM的版本0.5.4对AWQ和PagedAttention的支持比较稳定太新的版本有时候会有兼容性问题。flash-attn编译比较慢建议加--no-build-isolation不然容易卡住。如果编译失败检查CUDA版本和gcc版本是否匹配。4.2 模型下载与量化权重准备我用的基座模型是社区的27B模型具体名字就不说了反正同量级的都差不多。AWQ权重直接从HuggingFace下载huggingface-cli download model-repo --local-dir ./models/27b-awq --local-dir-use-symlinks False下载完后检查文件完整性AWQ权重通常包含config.json、quantize_config.json、model.safetensors等。如果少了quantize_config.jsonvLLM加载时会报错。另外注意权重的分片数量27B INT4大概14GB通常分成3-4个safetensors文件。draft模型也下载好放在单独目录。draft模型不需要量化得太狠INT8就行因为本身参数量小INT8也就1GB出头。4.3 vLLM启动参数详解这是最核心的部分参数配错了要么跑不起来要么速度惨不忍睹。我的启动命令python -m vllm.entrypoints.openai.api_server \ --model ./models/27b-awq \ --quantization awq \ --dtype float16 \ --max-model-len 131072 \ --gpu-memory-utilization 0.95 \ --max-num-seqs 1 \ --block-size 16 \ --enable-prefix-caching \ --enable-chunked-prefill \ --speculative-model ./models/draft-1b \ --num-speculative-tokens 3 \ --swap-space 16 \ --disable-log-requests逐个解释关键参数--max-model-len 131072设置128K上下文这个值直接决定KV Cache的分配上限。--gpu-memory-utilization 0.95显存利用率设到0.95留5%给系统设太高容易OOM设太低浪费显存。--max-num-seqs 1并发数设为112G卡扛不住多并发这是硬限制。--block-size 16PagedAttention的块大小16比较平衡太小碎片多太大浪费。--enable-chunked-prefill开启分块预填充长prompt分块处理避免一次性占用太多显存。--num-speculative-tokens 3MTP一次猜3个token猜多了验证成本高猜少了加速不明显3是实测最优。--swap-space 16CPU交换空间16GBoffload的层和KV Cache溢出部分放这里。4.4 实测性能数据与调优记录跑起来后用vLLM自带的benchmark工具测了一下指标数值权重显存占用7.8GBKV Cache占用128K5.2GB激活值缓冲0.9GB总显存占用13.9GB含draft模型decode速度无MTP28 tokens/sdecode速度MTP354 tokens/sprefill速度128K320 tokens/s首token延迟128K约6.8秒总显存13.9GB看起来超了12G但实际运行时vLLM会动态管理部分KV Cache在需要时才分配所以峰值能压到12.1GB左右。首token延迟6.8秒是因为128K的prompt要全部prefill一遍这个没法避免但后续decode就快了。调优过程中发现几个关键点一是--block-size从16调到32显存占用多了0.4GB但速度没明显变化所以保持16二是--num-speculative-tokens从3调到5速度反而降到48因为验证失败率上升三是开启--enable-prefix-caching后多轮对话的首token延迟从6.8秒降到2.1秒因为系统prompt的KV Cache被复用了。5. 踩坑实录与常见问题排查5.1 OOM问题显存总是差那么一点OOM是12G卡跑27B最常见的报错没有之一。我遇到过的OOM分几种情况一是启动时就OOM说明权重加载阶段就超了需要增加offload层数二是prefill阶段OOM说明KV Cache分配太多需要降低max-model-len或者开chunked-prefill三是decode阶段OOM通常是激活值或临时缓冲超了需要开FlashAttention或者降低batch size。排查OOM的第一步是看日志vLLM会打印显存分配详情找到是哪部分超了。如果日志不详细可以用nvidia-smi实时监控看显存是在哪个阶段涨上去的。我一般会先用一个较小的max-model-len比如8K跑通确认基础配置没问题再逐步加大到128K这样能定位到具体是哪个参数导致的OOM。还有一个隐蔽的坑PyTorch的显存缓存机制会导致假OOM就是显存明明还有但分配不出来。这时候设置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128能缓解或者定期调用torch.cuda.empty_cache()。但empty_cache有性能开销不要频繁调用。5.2 速度上不去decode只有个位数速度慢的原因通常有三个offload层数太多、MTP没生效、或者KV Cache量化没开。先检查offload层数如果offload了超过12层速度基本就掉到10 tokens/s以下了因为PCIe带宽成为瓶颈。这时候要么换更激进的量化减少offload要么接受慢速。MTP没生效的排查看日志里有没有speculative decoding enabled的字样如果没有检查draft模型路径是否正确、tokenizer是否匹配。如果MTP生效了但速度没提升看猜中率vLLM会打印acceptance rate低于50%就说明draft模型不合适换一个。KV Cache量化没开的排查检查启动参数里有没有--kv-cache-dtype int8这个参数在vLLM 0.5.4里是支持的但有些版本默认是auto不会自动量化。手动设成int8能省一半KV Cache显存但精度会略降实测困惑度增加0.1左右可以接受。5.3 长上下文下的输出质量下降128K上下文跑起来后我发现模型在长上下文末尾的输出质量明显下降经常答非所问或者重复。这不是模型本身的问题而是KV Cache量化长上下文导致的注意力衰减。解决办法有几个一是把KV Cache量化从INT8改成FP8精度好一些显存多占1GB左右二是开启NTK-aware RoPE scaling让模型更好地处理长距离依赖三是在prompt末尾重复关键指令强化注意力。我最终用的是FP8 KV Cache NTK scaling显存占用多了0.8GB但输出质量明显改善。NTK scaling的参数需要根据实际上下文长度调整128K下scale factor设2.0左右比较合适设太大反而会让短上下文的质量下降。5.4 常见问题速查表问题现象可能原因解决方法启动时OOM权重加载超显存增加offload层数或换更低比特量化prefill阶段OOMKV Cache分配过多降低max-model-len开启chunked-prefilldecode阶段OOM激活值/缓冲超限开启FlashAttentionbatch size设为1decode速度10offload层数过多减少offload或换更激进量化MTP不生效draft模型不匹配换同系列draft模型检查tokenizer长上下文质量差KV Cache量化精度低改用FP8 KV Cache开启NTK scaling首token延迟高prefill计算量大开启prefix caching复用系统prompt显存碎片导致OOMPyTorch缓存机制设置max_split_size_mb定期empty_cache6. 还能怎么压榨进一步优化的几个方向6.1 用更激进的量化换显存如果12G还是不够可以试试INT3量化。INT3下27B模型权重只有10GB左右offload层数能减少一半速度能提升到70 tokens/s。但INT3的精度损失比较明显实测困惑度比INT4高1.5左右简单对话还能用复杂推理就力不从心了。我的建议是如果只是做文本生成、摘要这类任务INT3可以接受如果要做代码生成、数学推理还是老老实实INT4。混合量化是另一个思路对精度敏感的层比如注意力层的QKV投影用INT4对精度不敏感的层比如FFN的中间层用INT3。这样整体精度比纯INT3好显存又比纯INT4省。但混合量化的工具链还不成熟需要手动改量化配置折腾成本比较高。6.2 CPU offload的进阶玩法现在的offload是静态的哪些层放内存是启动时定死的。进阶玩法是动态offload根据当前任务的需求动态把不用的层换出显存把要用的层换进来。这需要自己改推理框架的调度逻辑难度比较大但理论上能进一步提升显存利用率。另一个方向是用NVMe SSD做二级offload。内存不够时把部分层放到SSD上虽然速度更慢但至少能跑起来。PCIe 4.0的SSD顺序读取能到7GB/s比内存带宽差不少但比OOM强。这个方案我只在实验阶段试过稳定性一般不建议生产使用。6.3 多卡协作的可能性如果你手头有两张12G卡那事情就简单多了。用张量并行把模型切到两张卡上每张卡只需要装一半权重offload层数大幅减少速度能到80 tokens/s。但张量并行需要卡间通信PCIe带宽会成为新瓶颈而且vLLM的张量并行对消费级卡的支持不如专业卡好配置起来坑比较多。我试过用两张3060做张量并行速度确实上去了但稳定性差跑几个小时就会有一张卡掉线。后来查出来是PCIe带宽不足导致的通信超时换成PCIe 4.0 x8x8的配置后好了一些但还是不如单卡稳定。所以如果你追求稳定单卡offload是更靠谱的选择。6.4 模型层面的优化稀疏化与蒸馏从模型本身下手也是条路。稀疏化就是把模型中不重要的权重置零减少计算量和显存占用。27B模型稀疏化50%后等效参数量降到13.5B显存占用减半速度翻倍。但稀疏化需要重新训练或微调不是简单剪枝就行否则精度崩得厉害。蒸馏是用大模型教小模型把27B的能力蒸馏到一个13B模型里。13B INT4量化后只有7GB左右12G卡轻松跑而且速度能到100 tokens/s。但蒸馏出来的模型能力上限就在那里再怎么样也不如原版27B。如果你的任务比较垂直蒸馏是个好选择如果要做通用对话还是原版27B更靠谱。7. 一些实操心得和最后想说的这套方案我前前后后调了大概两周中间推翻重来了好几次。最开始想用GGUFllama.cpp结果decode速度死活上不去只有15 tokens/s左右后来换vLLMAWQ才突破50。MTP也是试了好几个draft模型才找到合适的第一个draft模型猜中率只有35%开了比不开还慢换了一个同系列的1.1B模型后猜中率到72%速度才起来。显存管理上我的经验是宁可offload多一层不要冒险OOM。12G卡跑27B本来就是在刀尖上跳舞任何一点额外开销都可能导致崩溃。我现在的配置是offload 10层显存占用12.1GB留了0.9GB余量跑一整天都不会OOM。之前试过offload 8层显存占用12.8GB跑十几分钟就崩一次得不偿失。还有一点长上下文不是越长越好。128K虽然能跑但首token延迟6.8秒实际体验并不好。大部分场景下32K上下文足够用了首token延迟能降到1.5秒左右decode速度也能到60 tokens/s。所以我的建议是按需设置max-model-len不要盲目追求128K。最后分享一个小技巧如果你觉得每次启动都要等模型加载太慢可以用vLLM的sleep mode。启动时加载好模型然后让服务进入sleep状态需要时再唤醒。这样模型权重常驻显存唤醒只要几秒钟比重新加载快得多。但sleep mode下显存还是被占着的所以适合你有一张卡专门跑这个模型的情况。这套方案不是终点随着量化技术和推理框架的迭代12G卡跑27B会越来越轻松。但至少现在它能让你在不换硬件的情况下摸到30B级别模型的门槛。踩过的坑我都写出来了能不能跑通看你的耐心和折腾程度。