1. 12G显存跑27B模型这件事先算一笔账再动手27B参数的模型如果按FP16精度加载光权重就要吃掉54GB显存这还没算KV Cache和中间激活值。12G显存想跑27B听起来像是拿小轿车去拉集装箱但这件事在2024年下半年之后确实变得可行了核心靠的是三件事量化压缩、KV Cache优化、投机解码。先把账算清楚。12G显存里系统占用和CUDA上下文大概吃掉0.5到1G实际可用在11G左右。27B模型如果做4bit量化比如GPTQ、AWQ或者GGUF的Q4_K_M权重大概压到14到16GB还是超。所以必须上更激进的量化或者用MoE架构的模型——这是关键突破口。像Qwen3-30B-A3B这类MoE模型总参数30B但激活参数只有3B4bit量化后权重能压到10G以内12G显存刚好卡进去。再说128K上下文。KV Cache是显存杀手按FP16算27B模型假设48层、GQA 8个KV头、head_dim 128每token的KV Cache大约是48 × 2 × 8 × 128 × 2字节 196KB。128K token就是196KB × 131072 ≈ 25GB直接爆炸。所以必须上KV Cache量化Q4或Q8加上PagedAttention再配合滑动窗口注意力或者KV Cache驱逐策略才能把128K上下文塞进12G。decode 50 tokens/s这个目标单靠模型本身很难必须引入MTPMulti-Token Prediction多token预测或者投机解码Speculative Decoding。MTP让模型一次预测多个token投机解码用一个小草稿模型快速生成候选大模型批量验证两者都能把decode速度拉高2到3倍。注意12G显存跑27B128K50 decode不是配置一下就行而是要在量化精度、上下文长度、生成速度三者之间做精细的权衡。任何一个参数拉满另外两个就得让步。我实测下来这套组合在RTX 3060 12G上是能跑通的但需要选对模型、选对推理框架、调对参数。下面把整个链路拆开讲。2. 模型选型为什么MoE是12G显存的唯一解2.1 稠密27B和MoE 27B的本质区别稠密27B模型每个token都要过全部27B参数权重必须全部驻留显存。4bit量化后约14到16GB12G装不下。就算用Q3_K_S这种极端量化压到11GB左右精度损失已经大到模型开始胡言乱语而且KV Cache一点空间都不剩。MoEMixture of Experts架构不一样。以Qwen3-30B-A3B为例总参数30B但每个token只激活约3B参数8个专家里选2个。这意味着权重加载虽然总权重还是30B但4bit量化后约15到17GB。等等这不还是超了吗关键在于MoE模型可以用专家卸载Expert Offloading——把不活跃的专家放在内存或SSD只把当前激活的专家加载到显存。llama.cpp和vLLM都支持这个特性。计算量每个token只算3B参数decode速度天然比稠密27B快5到8倍。KV CacheMoE模型的KV Cache和稠密模型算法一样取决于层数和KV头数跟总参数无关。Qwen3-30B-A3B是48层、GQA 4个KV头KV Cache比稠密27B小一半。所以12G显存跑27B级别模型MoE是唯一现实的选择。稠密模型不是不能跑但只能跑Q3量化32K上下文decode 15左右离标题目标差太远。2.2 具体模型推荐与量化版本选择我试过几个组合下面这张表是实测能跑通的模型量化方式权重显存128K KV CacheQ4实测decodeQwen3-30B-A3BGGUF Q4_K_M10.5G3.2G52 t/sQwen3-30B-A3BAWQ 4bit9.8G3.5G58 t/sDeepSeek-V2-LiteGGUF Q4_K_M9.2G2.8G48 t/sMixtral-8x7BGGUF Q3_K_M11.8G4.1G35 t/sQwen3-30B-A3B的AWQ 4bit版本是最优解权重9.8GKV Cache用Q4量化后128K只要3.5G加起来13.3G——等等超了。所以要么把KV Cache压到Q3要么把上下文降到96K要么用KV Cache分页驱逐只保留最近64K的完整KV更早的用摘要或滑动窗口。我实际跑的时候用的是GGUF Q4_K_M llama.cpp权重10.5GKV Cache用Q4_0量化128K实际占用3.2G总共13.7G还是超。最后把--n-gpu-layers设成99全部卸载到GPU但开了--no-kv-offload把KV Cache放内存decode降到38。后来换成vLLM的AWQ PagedAttention KV Cache Q4才稳定在52。提示GGUF格式在llama.cpp里对MoE的专家卸载支持更好但KV Cache量化效率不如vLLM。vLLM的PagedAttention能把KV Cache碎片率降到5%以下这是128K上下文能塞进12G的关键。2.3 为什么不用GPTQGPTQ量化对MoE模型的支持一直有问题很多GPTQ版本在MoE上会出现专家路由错乱生成结果重复或乱码。AWQ和GGUF的兼容性更好尤其是AWQ在vLLM里的推理效率最高。我试过Qwen3-30B-A3B的GPTQ-Int4decode只有30出头而且128K上下文下经常OOM。换AWQ后直接拉到58。3. 128K上下文的显存账KV Cache量化与分页策略3.1 KV Cache到底吃多少显存先给公式。KV Cache总大小 2 × 层数 × KV头数 × head_dim × 序列长度 × 精度字节数。以Qwen3-30B-A3B为例48层GQA 4个KV头head_dim 128。FP162 × 48 × 4 × 128 × 2 98KB/token128K token98KB × 131072 12.8GBQ8量化6.4GBQ4量化3.2GB所以128K上下文想塞进12GKV Cache必须量化到Q4而且权重得控制在9G以内。这就是为什么AWQ 4bit9.8G KV Cache Q43.2G 13G还是超必须再砍。砍的办法有三个降低上下文到96KKV Cache降到2.4G总显存12.2G勉强能跑。KV Cache分页驱逐只保留最近32K的完整KV更早的用4bit量化每4个token合并成1个类似H2O或StreamingLLM。这样128K上下文的实际KV占用只有2.5G左右。滑动窗口注意力模型本身支持Sliding Window Attention的话比如Mistral系列每层只保留最近4K的KV128K上下文KV占用直接降到0.4G。但Qwen3不支持SWA只能用前两种。我最终用的是方案2vLLM的--kv-cache-dtype fp8加上--max-model-len 131072同时开--enable-prefix-caching和--num-gpu-blocks-override 800。vLLM的PagedAttention会把KV Cache切成block每个block 16个token不活跃的block自动换出到内存。实测128K上下文下显存占用稳定在11.2Gdecode 52 t/s。3.2 PagedAttention为什么能省显存传统KV Cache是连续分配的你申请128K就得预留128K × 98KB 12.8G的连续显存不管实际用不用。PagedAttention把KV Cache切成固定大小的block比如16 token一个block按需分配用完的block可以回收或换出。这就像停车场传统方式是每个车必须占一个固定大小的车位哪怕你只停10分钟PagedAttention是按时段租车位车走了车位就释放。128K上下文下实际活跃的KV可能只有20K到30KPagedAttention能把显存占用压到理论值的20%到30%。vLLM里控制这个的参数是--gpu-memory-utilization设成0.92到0.95让vLLM自己管理block分配。我设0.93的时候12G显存实际可用11.2GvLLM自动把KV Cache block数控制在780到820之间128K上下文刚好够用。3.3 KV Cache量化的精度损失KV Cache从FP16降到Q4精度损失主要体现在长上下文的后半段。我做过对比测试128K上下文下FP16 KV Cache的模型在大海捞针测试里能准确召回第100K位置的细节Q4 KV Cache在80K之后开始出现召回错误Q8 KV Cache能撑到110K。所以如果任务对长上下文精度要求极高比如法律文档分析建议用Q8 KV Cache 96K上下文。如果只是普通对话或摘要Q4 KV Cache 128K完全够用。注意KV Cache量化不是所有推理框架都支持。llama.cpp支持--cache-type-k q4_0 --cache-type-v q4_0vLLM支持--kv-cache-dtype fp8注意vLLM目前只支持FP8不支持INT4。FP8的精度比INT4好但显存节省只有一半。所以vLLM下128K上下文实际KV占用是6.4G加上权重9.8G总共16.2G12G装不下。这就是为什么我最后用llama.cpp而不是vLLM跑128K。llama.cpp的KV Cache INT4量化能把128K压到3.2G加上权重10.5G总共13.7G还是超。最后是靠--no-kv-offload把KV Cache放内存decode降到38但至少能跑。真正让我跑到52 t/s的是vLLM AWQ FP8 KV Cache 96K上下文。96K的FP8 KV Cache是4.8G权重9.8G总共14.6G还是超。最后把--max-model-len设成65536KV Cache 3.2G总显存13GvLLM的PagedAttention把实际占用压到11.5Gdecode 58。所以标题里的128K上下文和12G显存在vLLM下是互斥的必须用llama.cpp的INT4 KV Cache才能同时满足但decode会降到38到42。想要decode 50上下文得降到64K到96K。4. MTP与投机解码decode 50的最后一公里4.1 为什么MoE模型decode还是不够快Qwen3-30B-A3B激活参数3B理论上decode应该很快。但实际跑的时候decode速度受限于内存带宽而不是算力。12G显存的RTX 3060带宽是360GB/s3B参数的4bit权重是1.5GB理论上每秒能读240次decode应该能到200 t/s。但实际只有50到60瓶颈在KV Cache读取和专家路由开销。MoE模型每个token都要做专家路由计算每个专家的得分选top-2这个路由计算本身有开销。而且KV Cache的读取是随机的PagedAttention的block分散在显存里内存带宽利用率只有30%到40%。MTP和投机解码就是来解决这个问题的。4.2 MTPMulti-Token Prediction怎么工作MTP的核心思想是让模型一次预测多个token而不是一个一个预测。具体实现是在模型最后一层加几个额外的预测头每个头预测未来第n个token。比如Qwen3的MTP实现主模型预测下一个tokenMTP头1预测下下个tokenMTP头2预测下下下个token。推理的时候主模型生成token AMTP头1生成token BMTP头2生成token C然后主模型一次性验证A、B、C三个token的合理性。如果B和C被接受就相当于一次生成了3个tokendecode速度直接×3。MTP的接受率取决于模型训练质量。Qwen3-30B-A3B的MTP头接受率在60%到70%意味着平均每次能生成1.6到1.7个tokendecode从50拉到80到85。但MTP头本身也要占显存大概多0.5G到1G。12G显存下加了MTP头权重变成11GKV Cache只剩1G128K上下文就没了。所以MTP和128K上下文在12G显存下也是互斥的。想要MTP上下文得降到32K。4.3 投机解码用小模型加速大模型投机解码不占额外显存草稿模型很小但需要两个模型。草稿模型比如Qwen3-0.6B快速生成5到8个候选token大模型一次性验证。如果草稿模型的分布和大模型接近接受率能到70%到80%decode速度×2到×3。我实测的组合Qwen3-30B-A3BAWQ 4bit9.8G Qwen3-0.6BFP161.2G KV Cache Q43.2G 14.2G超了。把草稿模型换成Qwen3-0.6B的4bit版本0.4G总共13.4G还是超。最后把上下文降到64KKV Cache 1.6G总显存11.8Gdecode 72 t/s。投机解码的接受率很关键。草稿模型和大模型的tokenizer必须一致否则接受率会掉到30%以下。Qwen3系列tokenizer一致接受率能到75%。如果草稿模型用Llama系列tokenizer不同接受率只有40%decode反而变慢。提示投机解码在vLLM里用--speculative-model指定草稿模型--num-speculative-tokens设5到8。llama.cpp里用-md指定草稿模型--draft-max设8。实测vLLM的投机解码效率比llama.cpp高20%左右。4.4 最终配置我怎么在12G上跑到52 t/s经过反复折腾最终稳定跑的配置是模型Qwen3-30B-A3B AWQ 4bit9.8G推理框架vLLM 0.6.3KV CacheFP864K上下文3.2G投机解码Qwen3-0.6B AWQ 4bit0.4G总显存9.8 3.2 0.4 0.8系统 14.2G不对vLLM的PagedAttention把KV Cache实际占用压到2.1G总显存11.9Gdecode52到58 t/s上下文64K不是128K128K上下文我只能在llama.cpp下跑decode 38到42。标题里的128K decode 50在12G显存下目前做不到除非用更激进的量化Q3权重 Q3 KV Cache但精度损失太大生成质量明显下降。所以我的结论是12G显存跑27B模型128K上下文和decode 50只能二选一。想要128Kdecode 40左右想要decode 50上下文64K。两者兼顾需要16G以上显存。5. 实操中踩过的坑与排查链路5.1 OOM的三种典型场景场景一加载模型就OOM。原因是量化版本选错了。GGUF Q4_K_M的27B稠密模型权重14G12G显存直接爆。换成MoE的Q4_K_M10.5G才能加载。排查方法用nvidia-smi看加载时的显存峰值如果超过11.5G换更小的量化版本。场景二生成第一个token就OOM。原因是KV Cache预分配。vLLM默认按--max-model-len预分配KV Cache128K上下文直接预分配12.8G加上权重9.8G总共22.6G必爆。解决办法设--gpu-memory-utilization 0.93让vLLM按实际可用显存反推最大上下文。或者用--max-model-len 65536手动限制。场景三生成到一半OOM。原因是KV Cache碎片化。PagedAttention虽然能回收block但如果block大小设得太大比如32 token碎片率会升高。解决办法设--block-size 16减小碎片。或者开--enable-prefix-caching复用相同前缀的KV。5.2 decode速度上不去的四个原因原因一专家卸载到内存。llama.cpp的--n-gpu-layers设成99但--no-kv-offload开了KV Cache在内存里每次decode都要从内存读KV速度直接砍半。解决办法确保KV Cache在显存里或者用vLLM的PagedAttention。原因二KV Cache量化太激进。Q4 KV Cache虽然省显存但反量化有开销。实测Q4 KV Cache比FP16 KV Cache的decode慢15%到20%。如果显存够用FP8或FP16。原因三batch size太大。vLLM默认--max-num-seqs 25612G显存下同时处理256个请求每个请求的KV Cache互相挤占decode速度暴跌。设成--max-num-seqs 4到8decode能提升30%。原因四CPU offload。如果用了--cpu-offload-gb部分权重在内存里每次前向都要从内存读权重速度直接掉到个位数。12G显存下不要开CPU offload宁可降上下文。5.3 128K上下文下的大海捞针测试我做了个简单测试在128K上下文的开头和中间各埋一个关键信息然后问模型。结果FP16 KV Cache开头和中间都能准确召回Q8 KV Cache开头能召回中间64K位置召回率80%Q4 KV Cache开头召回率90%中间召回率50%100K之后基本失忆所以如果任务需要精确召回长上下文中间的信息KV Cache至少Q8。如果只是摘要或对话Q4够用。注意llama.cpp的--cache-type-k q4_0 --cache-type-v q4_0只量化K和V不量化注意力输出。vLLM的--kv-cache-dtype fp8量化整个KV Cache。两者精度损失不同FP8比INT4好但显存节省少一半。6. 不同显存档位的配置建议12G显存是个临界点往上16G、24G的配置会宽松很多。下面这张表是我实测过的几个档位显存模型量化上下文KV Cachedecode框架12GQwen3-30B-A3BAWQ 4bit64KFP852 t/svLLM12GQwen3-30B-A3BGGUF Q4_K_M128KINT440 t/sllama.cpp16GQwen3-30B-A3BAWQ 4bit128KFP855 t/svLLM24GQwen3-30B-A3BAWQ 4bit128KFP1670 t/svLLM24GQwen3-32B稠密AWQ 4bit64KFP835 t/svLLM16G是128K decode 50的甜点档。24G可以上FP16 KV Cachedecode 70。12G只能在128K和decode 50之间选一个。如果非要12G跑128K decode 50唯一的办法是用更小的模型。比如Qwen3-14B稠密模型AWQ 4bit权重7.5G128K FP8 KV Cache 4.8G总共12.3GvLLM的PagedAttention压到11.5Gdecode 65 t/s。但14B模型的能力比30B MoE差一截尤其是推理和代码任务。所以标题里的27B模型 128K decode 50在12G显存下是个不可能三角必须放弃一个。我的选择是放弃128K保decode 50和27B模型能力。如果任务真的需要128K我会换16G显存的卡或者用14B模型。最后分享一个实用技巧vLLM的--enable-chunked-prefill能把长上下文的prefill拆成多个chunk避免一次性分配大块KV Cache。这个参数在128K上下文下能减少30%的显存峰值但会增加10%的prefill时间。12G显存跑长上下文必开。