上个月我把翻出来的RTX 3060 12G从游戏机房里重新装好给自己定了个有点离谱的目标跑一个27B量级的MoE模型开满128K上下文生成速度稳住50 tokens/s。当时群里几个朋友的第一反应都是“12G显存跑27B你在想什么”我自己心里也没底但折腾完发现这个组合确实能跑而且跑出来的体验远超预期。这篇就把完整的思路、命令、参数和踩过的坑都整理出来给同样手里只有12G到16G显存、想跑大参数MoE模型的人一份可以直接照抄的作业。先说清楚一件事这里说的decode 50是LLM生成token时的速度也就是每秒输出50个token以上跟浏览器里图片解码失败那个decode没有任何关系。下文所有“decode”都指自回归生成阶段的解码速度。1. 27B模型不是显存黑洞先搞清楚它在“吃”什么1.1 别被参数量唬住总参数和激活参数是两回事很多人一看到27B第一反应是“27B×2字节54GB显存”然后直接放弃。这个算法本身没错但它隐含的前提是——模型权重必须全部常驻显存并且每个token都要让全部参数参与计算。对小显存玩家来说这个前提恰好是可以绕开的。先说权重常驻的问题。无论什么模型27B的权重确实都要加载FP16下就是54GB这个逃不掉。所以“显存不够”的第一反应应该是量化把权重从2字节压到0.5字节左右27B就能压到14到18GB。但12G还是不够于是就有了MoE架构这张牌。再说激活参数。传统Dense模型每个token都会激活全部270亿参数但MoE模型不一样。以Qwen3-30B-A3B这种“假30B”为例总参数30.5B但每次推理只会激活约3.3B参数其余参数通过路由器只挑相关的专家计算。打个比方一家两千多人的公司真正每天跑业务的只有几十个人剩下的人平时就坐那待命。MoE让小显存跑大模型成为可能但它并没有解决权重全量加载的问题——待命的员工也在占工位。1.2 下一个问题选什么样的27B12G显存想跑得动首选就是MoE架构而且要选“总参数在27B附近、激活参数比较小”的那种。市面上比较典型的有Qwen3-30B-A3B、MiniMax-M1-27B这类都是原生支持128K长上下文的MoE模型。它们的共同特征是attention部分相对轻FFN专家部分被切成很多个小专家路由后只有少量专家参与计算。这类模型特别适合“GPU只保留核心结构专家层放内存”的玩法——只让大概率被路由到的专家留在GPU或者干脆全部专家放内存反正每次只算少数几个。这也是后面所有优化能成立的基础。1.3 量化等级怎么选不是越省越好权重量化有很多档位GGUF格式里常见的Q2_K、Q3_K、Q4_K_M、IQ4_XS、Q8_0。12G显存跑27B理论上一顿猛压是可以塞进去的但不能只看能不能塞。长上下文场景下量化等级太激进输出质量会肉眼可见地下降说话前言不搭后语的情况会明显增加。我的实际建议是IQ4_XS或Q4_K_M是底线尽量不要低于Q4。这两种量化等级下27B权重大概在15到19GB之间GPU虽然放不下但配合后面的offload策略可以在内存里装得很稳。Q8_0虽然质量最好但同样27B要30GB左右内存和显存都会很紧张除非你的机器内存有64GB以上否则不建议。1.4 重新算一笔显存账真正跑一个模型时显存消耗主要有三块权重、KV Cache、临时激活。三者不是并列关系权重和KV是常驻的临时激活是每个请求算完就释放的。12G显存里要同时塞下权重和KV就必须做取舍方案权重位置KV Cache位置12G显存能否搞定全部塞GPUGPUGPU基本不可能27B权重量化后也要15GB以上全部放内存CPU内存CPU内存能跑但慢decode往往只有个位数专家层放内存attention层放GPU部分GPU部分内存GPU推荐这也是本文的核心方案我最后选的就是第三种。Attention层权重不大加上量化后的KV Cache12G完全够用而占大头的专家层放内存每token只计算其中几个专家内存带宽虽然比不上显存但胜在计算量小速度反而不差。这个方案的具体参数和命令第三章会详细给。2. 128K上下文的隐藏成本KV Cache把显存吃干抹净2.1 KV Cache到底是什么为什么128K这么“刺客”很多第一次跑长上下文的人把模型加载好之后发现显存占用明明不高一但把上下文长度调到128K立刻就报显存不足。原因就出在KV Cache上。自回归生成时模型每输出一个新token都要参考前面所有历史token的Key和Value向量。为了不每次都重新算一遍历史推理引擎会把这些向量缓存下来这个缓存就叫KV Cache。它的大小跟上下文长度成正比——上下文越长缓存的历史越多显存就越大。更关键的是KV Cache的增长是动态的不像权重那样加载完就固定。2.2 给一个具体模型算算账拿一个中型MoE模型举例48层Transformer、8个KV头、每个头128维。128K上下文的KV Cache显存占用可以用这个公式估算KV Cache大小 2K和V× 层数 × KV头数 × head_dim × 上下文长度 × 每个元素字节数按FP162字节算 2 × 48 × 8 × 128 × 131072 × 2 25.8GB是的光一个128K上下文的KV CacheFP16下就能吃掉25.8GB显存比27B模型量化的权重还大。这也是为什么很多人觉得“12G跑128K是做梦”——单看这段账确实像是在做梦。但如果把KV Cache做量化情况就完全不一样了KV Cache精度每元素字节数128K上下文占用FP162字节约25.8GBQ8_01字节约12.9GBQ4_00.5字节约6.4GBQ8_K Q4_V混合平均0.75字节约9.7GBkv cache量化已经是很成熟的技术llama.cpp里直接用--cache-type-k q8_0 --cache-type-v q4_0就能混合量化K用8bit保留召回精度V用4bit省显存。实际效果上长上下文场景下K比V对精度更敏感所以K用8bit、V用4bit这个组合是性价比比较高的选择。2.3 更隐蔽的一点prefill阶段和decode阶段的显存曲线不一样很多人调好KV Cache之后发现decode跑得很稳但一输入长文本就直接爆显存。这是因为prefill阶段和decode阶段的显存增长完全不同。prefill阶段模型一次性读完输入要并行计算所有输入位置之间的attention临时激活值会短暂飙升跟上下文长度直接相关。128K的提示词哪怕KV Cache被压缩了prefill的临时计算量也可能会瞬间吃满显存。decode阶段逐个token生成同一时刻只需要处理1个新token显存增量平缓主要是KV Cache的逐步增长。所以判断能不能跑128K不能只看decode还要看prefill阶段会不会OOM。这个我在第五章的踩坑实录里会具体说。2.4 三条压缩长上下文成本的实际手段KV Cache量化是最直接的手段但还有几条路可以配合上下文滑动rolling context不是所有历史都必须完整保留可以只保留最近N个token的历史更早的内容做摘要压缩。这样做128K就成了“名义支持”实际显存按滚动窗口算。子上下文分片把超长文本拆成多个片段分段处理后再合并避免一次性蓄满KV Cache。减少KV头数带来的收益GQA架构已经帮了大忙8个KV头比32个KV头的KV Cache小4倍。选模型时优先选GQA/MQA架构而不是纯多头注意力。一句话12G显存要跑128K上下文KV Cache的精度和分配策略比模型权重本身更值得花心思。3. 真正跑起来的配置12G显存上的拆分与参数清单3.1 工具选型为什么我选了llama.cpp现在跑本地模型的主要选项有llama.cpp、Ollama、LM Studio、vLLM。Ollama和LM Studio上手简单但对“MoE专家层放CPU、attention层放GPU”这种细粒度控制支持有限尤其是想要精确控制KV Cache量化时很多选项都被藏起来了。vLLM性能很强但对显存要求高12G上跑27B MoE经常因为算子碎片化导致OOM调起来很痛苦。llama.cpp虽然界面朴素但胜在一句话能说清楚所有东西权重放哪、KV Cache用什么精度、Flash Attention开不开、线程用多少全部是命令参数控制。所以我推荐直接用llama.cpp的llama-server它自带OpenAI兼容API配合任何客户端都能用。3.2 我的配置文件可直接抄作业先说清楚llama.cpp不同版本的参数语义有变化尤其是--n-cpu-moe这个参数我在第五章会细说。下面是基于我当时使用的版本一套完整可跑的启动命令llama-server \ -m /models/qwen3-30b-a3b-iq4_xs.gguf \ --ctx-size 131072 \ --n-cpu-moe 1 \ --cache-type-k q8_0 \ --cache-type-v q4_0 \ --flash-attn \ --threads 16 \ --threads-batch 16 \ --mlock逐个拆开解释参数作用为什么这么设-m qwen3-30b-a3b-iq4_xs.gguf指定模型文件30B总参MoEIQ4_XS量化文件约17GB放内存可以接受--ctx-size 131072设置上下文长度为128K目标就是128K--n-cpu-moe 1把所有MoE专家层放到CPU核心操作GPU只保留attention层专家层全在内存--cache-type-k q8_0K矩阵用8bit量化保留召回精度--cache-type-v q4_0V矩阵用4bit量化大幅降低KV Cache显存占用--flash-attn开启Flash Attention减少attention计算和显存decode速度提升明显--threads 16CPU线程数按物理核数设别用超线程数--mlock锁内存防止内存swap导致速度暴跌注意--n-cpu-moe 1在部分构建版本里表示“把1层专家放CPU”而不是“所有专家放CPU”。不同llama.cpp提交对它的语义定义确实不一样。我的经验是查一下llama-server --help里的说明如果描述是“offload all MoE layers to CPU”那传1就对了如果描述是“number of MoE layers on CPU”那就要按模型层数传比如48。3.3 权重文件从哪里来GGUF格式的量化文件Hugging Face和ModelScope上都能找到搜模型名加GGUF就行。优先选社区维护的量化版本比如Qwen3-30B-A3B的GGUF。下载后建议先看下文件大小和md5sum免得拉到损坏文件浪费一晚上。如果实在找不到合适的IQ4_XS可以用Q4_K_M替代效果接近。不要用Q2_K或者Q3_K长文本下文字组织能力下降太明显特别是你要跑128K这种超长上下文模型本身质量不够就很难受。3.4 如何判断真的跑起来了启动之后重点看日志里的三行model loaded模型加载成功KV buffer size比如显示约10GB说明KV Cache已经按预期分配offloaded layers确认有多少层在GPU然后打开nvidia-smi看显存占用训练时那种90%以上占用大概率是正常的。更稳的验证方式是用OpenAI兼容接口发一个长文本请求curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3-30b-a3b, messages: [{role: user, content: 给我讲一段关于显存优化的话至少500字}], max_tokens: 512 }响应里的timings字段会直接给出prompt_per_second和predicted_per_second后者就是decode速度。我第一次跑通时看到predicted_per_second在30多心里已经比较满意了后面又花了一晚上调优把速度拉到了50。4. decode 50的四项调优从30 t/s到55 t/s4.1 先理解瓶颈在哪不是GPU算力不够而是数据在跑当专家层全部放在CPU后decode过程实际上是一个“流水线”GPU负责attention层CPU负责专家FFN层每个token每经过一层中间结果都要在PCIe总线上来回传一次。真正卡住速度的不是计算而是这个来回传输的延迟。好消息是MoE模型每次只激活少数专家需要搬的数据量并不大。以hidden size 2048为例一个token的中间结果大概几千字节即便48层全部来回跑一遍总传输量也就几百KB级别。所以瓶颈被限制在“每一层都要等一次PCIe往返”的延迟上。基于这个理解优化思路就很清晰能少搬就少搬能并行就并行别让任何环节空等。4.2 第一板斧Attention必须留在GPU并且开Flash Attention如果attention层也被放到了CPU那每一层都要在CPU算注意力速度会掉到10 t/s以下。保持--n-cpu-moe的拆分逻辑GPU只做attention这是速度能跑起来的前提。在这个基础上--flash-attn一定要开。Flash Attention不光是省显存它还能显著减少attention计算对显存带宽的占用换来的收益在长上下文场景里尤其明显。开和不开的差距我实测在20%到30%左右。4.3 第二板斧CPU线程数要“克制”专家层在CPU计算线程数很关键。我之前想当然地把--threads设成了32结果速度不升反降。原因很简单超线程带来的虚拟核心对矩阵乘法的并行效率帮助有限线程一多反而频繁切换引入额外开销。正确做法是看物理核心数。我的CPU是8核16线程于是设--threads 16让满线程跑批量计算--threads-batch也设成16保持prefill阶段不吃亏。如果你用12核以上的CPU建议从物理核数开始试再往上加2到4个线程观察速度拐点找到最佳值。4.4 第三板斧内存别被交换出去当专家层在内存里最怕的就是mlock没开操作系统把模型权重的一部分交换到swap。一旦发生速度直接断崖式下跌表现为“前50个token很快后面突然一顿一顿”。--mlock的作用就是把这些内存页锁在物理内存里强制不让系统换出。这里还要提醒一句内存不够时千万别硬上。模型文件17GB加上KV Cache和系统其他应用至少准备32GB物理内存最好有64GB。内存紧张时即使mlock也可能出问题轻则速度不稳重则进程被杀。4.5 第四板斧并发设置别贪多llama-server默认允许一个模型实例服务多个请求--parallel参数控制并发序列数。很多人误以为并发越多越好但在12G显存CPU专家层的架构下并发请求会把attention和CPU专家层的时间片切碎每个请求的速度都会下降。我的实测是--parallel 1下单请求decode能稳定在52到55 t/s如果--parallel 2两个并发请求会各自降到30到35 t/s再往上提速效果微乎其微反而每个请求都卡。如果你只是自己用保持--parallel 1就好。如果要服务多人可以接受“人均速度下降”的代价但别期望它像vLLM在大型GPU上那样接近线性并发。4.6 一个小工具用评测接口看真实速度llama.cpp自带的llama-bench可以测不同配置下的性能但它是模拟场景跟真实聊天交互有差距。我更推荐直接用真实请求看timings。用上面curl命令里的返回内容timings: { predicted_per_second: 54.23, prompt_per_second: 187.4 }prompt_per_second是prefill速度predicted_per_second就是decode速度。有些评测软件只报prefill有些只报decode别搞混了。我当时调优完看到54附近稳定输出终于觉得“12G显存跑27B、128K上下文、decode 50”这句话算是立住了。5. 踩坑实录几次差点放弃的问题与排查链路5.1 问题一启动明明成功一推理就OOM表现是llama-server启动日志一切正常模型加载完但第一次发请求就报llama_kv_cache_unified: failed to allocate buffer。我的排查链路是这样的先看nvidia-smi显存占用几乎满内存还有不少空闲确认KV Cache已经按128K和q8K/q4V分配占了大几十GB内存和约5GB显存再看attention层权重发现也被塞进GPU占了2GB多最后发现是系统为KV Cache预留的buffer比预想的大显存被预分配撞满了。解决方法是把KV Cache精度再降一档--cache-type-k q4_0 --cache-type-v q4_0让KV占显存降到约4GB给attention权重和其他临时变量留出余量。如果还是不够就把上下文降到96K先跑通再考虑慢慢拉长。这个问题的关键在于llama.cpp有时会一次性把整个KV buffer按上下文上限预分配即使当前请求只用了100K它也按131072去占空间。所以显存余量要按“满上下文”算不能按“实际输入长度”乐观预估。5.2 问题二为什么“512 token的上下文”跑得很顺128K却卡成PPT这个坑特别容易让人误判。我一开始用小上下文测decode速度很漂亮但把上下文顶到128K后速度直线掉到个位数。查下来有两个原因叠加一是Flash Attention没有真正生效。llama.cpp要求Flash Attention对应的注意力层全部在GPU上而我某次手动调整参数时把部分attention层也放到了CPU导致--flash-attn失效。日志里会有一个很不起眼的警告我当时没注意。排查方法是在日志里搜flash_attn相关输出同时逐层确认attention层都在GPU。二是KV Cache跨设备碎片化。当显存不够时KV Cache的一部分在GPU、一部分在CPU解码时每次都要跨设备查历史状态128K长上下文的跨设备查找频率很高速度自然崩掉。解决办法是主动缩减上下文让KV Cache完整落在GPU内或者牺牲上下文长度换速度。我的最终选择是KV Cache尽量留GPU、专家层全CPU让跨设备通信只发生在中间结果上而不是发生在KV查找上。5.3 问题三--n-cpu-moe参数在不同版本里“性格”不一样这个问题前面提过一次但它确实是最容易让人怀疑人生的坑。我第一次用某个llama.cpp编译版本时文档写的是“把所有MoE层放到CPU”传了--n-cpu-moe 1功能正常。后来换了个更新版本同一个写法却只放了一层专家到CPU结果模型加载完GPU直接爆掉。排查链路对比两次命令唯一区别是llama.cpp版本打开llama-server --help发现新版对--n-cpu-moe的描述变成了“number of MoE layers to offload to CPU”改为--n-cpu-moe 48后恢复正常。网格排查后其实就一句话换版本前先看看help文本别默认参数语义不变。如果你用的是Ollama或LM Studio这类封装好的工具这个参数更是完全透不出来只能回到llama.cpp。5.4 问题四量化后模型“变笨”了是量化的问题吗有段时间我把模型从IQ4_XS换成Q4_K_M发现长文本质量下降以为是量化等级不够。后来做了对照测试才发现真正的问题是采样参数。llama.cpp的默认采样参数temperature、top_p偏向保守在长上下文场景下容易导致重复和保守短句。把--temp 0.7 --top-p 0.9这类参数调回去之后即使KV Cache用了Q8KQ4V输出质量也恢复了正常。KV量化对质量的影响确实存在尤其在需要精确复述细节的任务上但对一般对话和长文本续写影响没有想象中大。重要建议想判断模型质量是否被量化影响一定要做对照实验。同一个提示词同一版量化模型只改采样参数分别跑一次看差异。别一上来就怀疑量化档位不够。5.5 一处容易被忽略的系统级配置PCIe链路和电源如果条件允许给GPU换一个直连CPU的PCIe插槽速度和稳定性都会有改善。RTX 3060如果是PCIe 3.0 x16带宽理论12GB/s左右实际跑大模型时这个带宽基本够用。但如果显卡插在南桥芯片组的PCIe通道上或者被其他设备挤占了带宽decode会明显受影响。这不是参数能解决的属于硬件层面的排查项。另外电源供电不稳会导致GPU降频decode速度也会跟着波动。跑长时间任务时可以用nvidia-smi -q -d CLOCK看下当前频率和功耗是否正常如果频率被压在很低的位置多半是电源或者散热的问题。最后聊点实际操作里的体会折腾完这套配置我最大的感受是12G显存跑27B模型真正的瓶颈从来不是“显存不够”而是“怎么分配显存最值”。把最强的注意力计算留在GPU把重但稀疏的专家计算放到CPU再用KV量化把长上下文的成本压到可控范围——这三步想通了剩下的都是参数调试。如果看完这篇你也想复现我的建议是先别急着把上下文拉到128K。先用8K上下文把整套流程跑通确认decode速度能到50左右再逐步往64K、128K拉。每一步只改一个变量出问题的时候你才知道是哪个环节没配合好。长上下文推理和常规短文本推理完全是两种体验但一旦搞定你会发现12G显存能做超出预期的事情。