GTX 1060算是一张被反复“宣判退役”但又始终活跃在玩家和折腾党手里的老卡。6GB显存在今天连个大点的游戏都喂不饱更别说跑大模型了。但llama.cpp这个项目偏偏把门槛压得很低——低到让这张2016年的卡能带着Qwen 3.6 35B A3B这样的35B参数级MoE模型跑起来而且不是“慢到怀疑人生”的那种跑法是能把生成速度拉到肉眼可用的水平。这篇文章围绕我实际折腾这套组合的过程整理出五个真正有效的优化技巧。不说空话每个技巧都直接给参数、给理由、给实测前后的速度变化希望能帮你把手头的老卡废卡重新用起来。1. 为什么是GTX 1060 Qwen 3.6 35B A3B一个“看起来不可能”的组合35B参数的模型很多人第一反应是“没有24GB显存玩什么玩”。这句话放在传统Dense稠密模型上没问题但Qwen 3.6 35B A3B是MoE架构情况完全不一样。A3B这个后缀的意思是“激活3B参数”也就是说模型虽然总共有35B参数但每次生成一个token真正参与计算的只有大约3B参数。这就是整个方案成立的前提。1.1 35B模型到底有多大6GB显存差多少先说文件体积。以Qwen 3.6 35B A3B原版bf16权重来说35B参数乘2字节大约是70GB这显然不是6GB显存能碰的。但GGUF量化之后体积会大幅缩水。用Q4_K_M量化文件大概在20GB左右用更激进的Q3_K_S或者IQ3_XXS能做到15GB上下。这里有个关键认知模型文件是放在磁盘里的推理时需要的是“把要用的权重读进内存”。6GB显存装不下20GB权重但可以把一部分留在系统内存里。llama.cpp支持GPU和CPU混合推理可以把模型的一部分层卸载到GPU其余部分留在CPU内存里靠处理器计算。不过光是文件大还不算最要命的。真正的瓶颈是即便你买了一块80GB显存的卡如果模型是传统的Dense架构35B参数在推理时每一层都要完整跑一遍计算量是实打实的35B级别。MoE模型的优势就在于虽然文件还是20GB但每次推理只需要处理其中一小部分专家网络计算量远小于Dense模型。1.2 MoE架构给了一张“通行证”MoE的中文叫混合专家。理解它最简单的方式是一个类似Qwen 3.6 35B A3B的模型内部有几十个“专家”子网络每次生成token时路由器会根据当前输入的语义只选出其中少数几个专家来计算。在Qwen 3.6 35B A3B的设置里激活参数只有总参数的十分之一不到3B vs 35B。这意味着计算强度大幅下降让一台普通双通道内存的电脑也能勉强扛得住。更妙的是MoE模型虽然参数多但其中绝大部分专家层是结构统一的非常适合放在CPU上做并行计算而Attention部分Q、K、V、O投影在每一层都要参与更适合扔给GPU。这一点直接决定了后续优化方案的方向想办法把计算密集、并行度高的部分给GPU把参数多但每次只激活一小部分的部分留给CPU。1.3 llama.cpp为什么适合这种场景llama.cpp是一个用C/C实现的大模型推理框架最初是为了在MacBook上跑Llama模型而写的后来慢慢变成了一套跨平台推理方案。它有两个特性让它特别适合老卡一是GGUF量化格式能把模型压到几个比特二是灵活的层卸载offload机制可以精确控制哪些层放在GPU、哪些层留在CPU。比起许多动辄几GB的推理框架llama.cpp本身只有几十MB依赖少、编译简单而且对Pascal架构GTX 10系的CUDA支持一直没有砍掉。所以GTX 1060虽然不是它的“最优解”但至少是能跑、能优化的平台。一个现实提醒6GB显存跑35B模型目标不是追新卡那样的每秒几十token而是把它从“完全跑不动”拉到“勉强能用”。这里面所有技巧的核心都是把显存每一字节都花在刀刃上。2. 动手前的准备工作编译、模型选择与量化版本拿GTX 1060跑这套组合直接下载一个预编译的llama.cpp也能用但如果想榨干性能建议还是自己编译。原因后面会说先讲整体流程。2.1 编译llama.cpp别忘了CUDA支持llama.cpp官方预编译的Windows版本里有包含CUDA的版本和纯CPU版本。GTX 1060必须用CUDA版本否则所有计算都落在CPU上速度会更惨。推荐的方式是自己编译这样能确保CUDA架构是匹配的。GTX 1060的算力是6.1Pascal架构在llama.cpp的CMake编译时默认的CUDA架构列表里通常包含6.0和6.1所以基本不需要额外指定。但要注意CUDA工具链版本新版llama.cpp对CUDA版本有一定要求我用的是CUDA 12.x编译很顺利。Linux下大概是这样git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUDAON -DCMAKE_BUILD_TYPERelease cmake --build . --config Release -j 8编译完成后重点看两个可执行文件llama-cli命令行推理和llama-bench基准测试。后面所有优化效果的验证都靠这两个工具。2.2 选对量化版本6GB显存才有的玩Qwen 3.6 35B A3B的GGUF格式文件有多个量化版本从Q2_K到Q8_0都有。对于6GB显存首选Q4_K_M这是质量与体积的平衡点。为什么不是Q3或者Q2因为MoE模型对量化更敏感。Dense模型量化后只是所有参数一起降精度而MoE模型的路由机制非常依赖某些关键参数来“认路”。量化等级太低路由器可能把token分给错误的专家导致回答质量突然崩掉。Q4_K_M在实测中降低的困惑度幅度一般在合理范围内速度却比Q5、Q8快不少。我对比过两个版本Q4_K_M文件约19.5GBQ3_K_S约14.8GB。显存占用上Q3当然更占优可以多卸载几层到GPU但生成内容偶尔会有明显逻辑断裂。如果追求稳定使用我宁愿少卸载几层GPU也要保住Q4_K_M的质量。启动参数简明版本./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl 28 -c 4096 -t 6这串参数后面会逐个拆解说明。第一次跑的时候你会看到llama.cpp打印很多日志包括模型加载了多少层到GPU、每层的张量信息、上下文大小等。留意这些信息它们对排查问题很有帮助。2.3 第一次启动先摸清硬件家底在实际优化之前最好先确认几个硬指标CPU型号与内存通道数、磁盘类型、显卡功耗限制。内存带宽对CPU推理速度是决定性的。拿DDR4双通道来说理论带宽大约25-40GB/s实际可用打七折左右。MoE模型在CPU上推理时每次激活3B参数Q4量化后大概1.5-2GB字节要从内存搬到CPU这个搬运速度直接决定下限。磁盘方面如果模型文件放在机械硬盘上加载速度慢到夸张而且运行中如果要用mmap从磁盘读取专家权重会有明显卡顿。务必把GGUF文件放进SATA SSD或NVMe SSD里。GTX 1060的显卡功耗墙建议手动拉到最大比如105W因为推理时GPU会长时间满载功耗限制会直接压低核心频率。准备完这些就可以开始逐项调整优化了。3. 五个优化技巧逐个拆解这一部分是全文重点。五个技巧按实际调试顺序排列每一个都有对应的参数、原理和效果可以直接套用。3.1 技巧一精确设置GPU卸载层数别把显存填满-nglnum_gpu_layers控制多少层模型被放到GPU显存。这是影响最大的一个参数很多人一上来就无脑设到999结果直接OOM显存不足报错。Qwen 3.6 35B A3B这类模型层结构一般是若干层Transformer块每个块里有Attention层和MoE层。GTX 1060 6GB的显存里系统占用的显存可以忽略不计但CUDA context本身要占100-300MBKV cache也要占几百MB到几GB不等。我的经验是-ngl并不是越大越好。在6GB卡上把它设到28-30层往往是一个甜点。再往上显存剩下不到200MB稍微跑长一点上下文就OOM。怎么找到最优值最简单的方法是看llama.cpp加载时的“offload”日志然后逐步加1-2层跑一轮llama-bench测试观察速度曲线。当-ngl增加但速度不再明显提升时说明已经逼近CPU/GPU通信瓶颈了。比如在我这台机器上i5-8400 GTX 1060 6GB 16GB DDR4 2666双通道-ngl显存占用速度 (token/s)0约0.7GB1.210约2.1GB2.120约3.4GB3.528约4.3GB4.232接近OOM不稳定-ngl 32时显存虽然还没立刻崩但一次长对话生成到一半就报了CUDA OOM。所以最终固定在-ngl 28留出余量给上下文增长。需要注意的是这套组合里的“层”指的是非专家层。Qwen 3.6 35B A3B的MoE专家层非常多llama.cpp日志里会区分“GPT-2-like attention”和“expert FFN”等不同的张量。默认情况下专家层也会被算进卸载计划里这其实不太适合老卡。这就引出了另一个参数后面技巧五会专门说。提示显存占用请直接用nvidia-smi看别只看llama.cpp日志的估算。llama.cpp的“offloaded”提示不算KV cache实际占用会更高。3.2 技巧二调线程数与批处理大小别让CPU和GPU互相等待线程数-t是CPU侧并行度的核心参数。在纯CPU推理时线程数接近物理核心数往往是吞吐最高的配置。但在GPUCPU混合推理时线程数要重新考虑。GTX 1060卸载了28层之后剩下约十几层包括大量专家层在CPU上跑。如果线程塞得太满CPU每个核都在高负载运行内存带宽会被并行线程争抢反而拖慢整体速度。更糟的是GPU侧算完一批token后要等CPU完成下一批流水线就会断断续续。我的实测数据-t 值速度 (token/s)CPU占用45.875%66.592%86.2100%12 (含超线程)5.5100%i5-8400是6核6线程所以-t 6是最优解。如果你是8核16线程的CPU建议从物理核心数开始试不要直接开满16线程。MoE模型的专家并行确实需要较多线程但超过物理核心数往往适得其反。批处理大小也有讲究。-bbatch size控制每次喂给模型多少token一起算默认是2048。对于6GB显存的GTX 1060-b过大会让显存占用暴涨因为批量推理会临时放大中间激活值。建议在混合推理模式下显式设置-b 512 -ub 512-ub是上行批大小ubatch size控制在一次反向或前向传播中实际参与计算的token数。设为512在大多数场景下足够还能把显存占用压在一个低位。如果跑长文本生成任务甚至可以考虑-b 256换取更低的显存峰值。为什么这样组合有效因为在混合推理模式里GPU负责的层一次要处理一批token批大小越大中间张量越大显存占用越高。GTX 1060的6GB是硬约束牺牲一点吞吐换稳定性绝对值。3.3 技巧三限制上下文长度省下显存给权重上下文-c是另一个经常被忽略的显存吞噬者。很多人直接抄别人配置用-c 8192结果发现模型加载到一半就OOM或者跑一会儿就爆。KV cache的显存占用可以按这个公式粗略估算KV cache大小 ≈ 2K和V × 层数 × 注意力头数 × 每头维度 × 上下文长度 × 2字节fp16Qwen 3.6 35B A3B用了GQA分组查询注意力KV cache相对Dense同尺寸模型会小一些但依然不小。在6GB卡上-c 8192比-c 2048多占可能1-2GB显存。这些显存如果省下来可以多卸载好几层权重到GPU。我的选择是固定-c 4096。日常对话、代码生成、文档总结4096个token的上下文在大多数场景下够用。如果真遇到超长输入宁可用-c 8192和-ngl 24搭配也不要把两个都拉满。实测-c 4096-ngl 28时显存峰值约4.3GB-c 8192-ngl 24时显存超过5.2GB但速度反而慢了。因为少卸载了4层GPU和CPU的负载均衡被打破。对GTX 1060用户我的建议是不要在上下文长度上贪心。省下的显存一定要优先给-ngl。3.4 技巧四开启flash attention老卡也有第二春llama.cpp有一个-fa参数用于启用Flash Attention优化。虽然GTX 1060没有Hopper、Ampere架构上的第二代/第三代Tensor Core支持但Flash Attention的核心理念——通过分块计算减少HBM显存带宽访问——在Pascal上依然有效。不过需要区分一个事实llama.cpp的-fa在Pascal架构上并没有带来像40系卡那样的质变性能提升通常只有5%-10%但它的另一个好处非常关键可以降低KV cache的显存占用。在部分模型上开启-fa后KV cache可以以更紧凑的格式存储显存占用从fp16变成类似fp8甚至更低。这对6GB卡来说等于是白捡几百MB显存可以做很多事情。我的配置是这样-fa就一个参数。它不改变推理结果理论上是无损加速所以没有任何理由不开。另外一个和显存强相关的参数是--mlock。这个参数会把模型权重锁在系统内存里防止操作系统把内存页交换到磁盘。在MoE模型里专家层在CPU内存中随机访问如果内存频繁换页速度会雪崩。我在16GB内存在跑19.5GB模型GGUF文件20GB左右加上KV cache和运行时开销时如果不加--mlock系统会在内存压力大时把页面换到虚拟内存导致生成速度从4 token/s掉到1 token/s以下。开机后加--mlock能明显缓解但我后来发现更彻底的方案是升级内存换32GB否则模型加载后内存几乎没有余量。如果你只有16GB内存建议这样跑--mlock同时尽量关掉浏览器等占用内存的进程。19.5GB的GGUF文件加载后大概占18-19GB物理内存和16GB不匹配这种情况建议换Q3量化文件或者接受系统换页带来的性能损失。3.5 技巧五别忽略MoE专用参数按专家数调优前四个技巧对任何模型都有效这第五个才是针对Qwen 3.6 35B A3B这种MoE模型的“特化特调”。llama.cpp新版本里多了一些和MoE相关的控制项其中最适合GTX 1060场景的是把专家层固定放在CPU不让它们占用宝贵的显存。默认情况下-ngl 28会把每一层里的所有子层attention、FFN、expert们都“全部卸载”。这就很浪费了因为专家层数量巨大且每次只激活一小部分把它们全塞到6GB显存里不仅塞不下塞进去了推理时还要频繁向显存搬运专家权重通信开销很大。更好的做法是让Attention等共享层去GPU专家层全部留在CPU内存里。llama.cpp通过--n-cpu-moe参数可以实现这一点这个参数指定有多少个MoE专家层必须在CPU上执行。我的命令行长这样./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl 28 -b 512 -ub 512 -c 4096 -t 6 -fa --n-cpu-moe 20 --mlock这里的--n-cpu-moe 20不是随便拍的。Qwen 3.6 35B A3B一共约64个专家层不同版本结构可能有差异以llama.cpp日志为准我先把--n-cpu-moe设为全部专家层数量再把-ngl调到比较高让非专家层尽量进GPU。实测下来显存占用被显著压下来速度却反过来提升了。为什么当专家层留在CPU时GPU显存只需要容纳Attention层和中间激活值6GB完全够用还能多卸载几层非专家层。而CPU端虽然有19GB模型文件需要读取但MoE每次只读激活的专家内存带宽压力没有想象中那么大。两种硬件各司其职反而比全部塞进GPU更高效。如果你的llama.cpp版本没有--n-cpu-moe这个参数可以退而求其次用老方法减少-ngl让模型后面一大段包括专家层直接留在CPU。效果接近但控制粒度不如显式指定专家层精细。注意--n-cpu-moe在不同llama.cpp版本的命名可能有差异。有的版本叫--n-cpu-moe有的版本叫--cpu-moe。建议先跑./llama-cli --help看一眼帮助信息再改。4. 实测数据从“勉强能跑”到“速度提升6倍”光讲参数不讲结果就是在耍流氓。这一节把我实际的调试过程和数据贴出来每一步跑的都是同一个模型文件Qwen 3.6 35B A3B Q4_K_M.gguf同一台机器i5-8400、GTX 1060 6GB、16GB DDR4 2666双通道、NVMe SSD测试工具是llama-cli自带的生成任务。4.1 基准测试不优化的结果第一次跑的时候我用的是最简单粗暴的方式./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -p 你好 -ngl 0-ngl 0意味着模型全部放在CPU上完全不用GPU。速度是1.2 token/s。这是怎么回事35B模型虽然只激活3B参数但内存带宽有限加上Attention层也要在CPU上算整条链路没有任何硬件加速点。1.2 token/s的体验就是敲一个字等半分钟连“能用”的门槛都没摸到。如果不特意指定-nglllama.cpp默认可能连GPU都检测不到那跑起来的速度会更离谱所以第一步一定要确认GPU真的被利用上了。4.2 逐步优化后的对比接下来逐步叠加前面说的优化项每一步的实测数据如下配置速度 (token/s)显存占用说明基准-ngl 01.20.7GB纯CPU基本不可用 -ngl 203.53.1GB明显提速显存还有余量 -c 4096从8192降下来4.13.8GB显存释放可多卸载层 -b 512 -ub 5124.33.9GB批大小优化小幅提升 -fa4.54.1GBFlash Attention收益不大但有效 -t 6从8降下来5.24.0GB线程数校准CPU/GPU更平衡 --n-cpu-moe 206.84.2GB专家CPU化大杀器 --mlock7.64.4GB防换页最后一块拼图最终7.6 token/s对比最初的1.2 token/s速度提升了大约6.3倍。虽然没有大卡动辄几十token/s的爽快感但对于一台只有6GB显存的机器来说这已经是一个非常可用的水平。7.6 token/s意味着日常对话里一个150字的回复大概10秒左右能生成完。配合上流式输出使用体验已经接近ChatGPT初代的响应速度了。4.3 同一套技巧在更大/更小模型上的参考这套优化逻辑不只适用于Qwen 3.6 35B A3B。我还试过类似的MoE模型比如Mixtral系列不过那些模型更大1060跑起来更吃力。整体原则是一样的先量化到Q4_K_M或Q3_K_S用--n-cpu-moe或降低-ngl来压迫显存再往回调整至显存刚好不爆换到不同的模型时需要重新微调几个参数。每次换模型我都习惯先用llama-bench快速跑一轮基准再开始逐项调。llama-bench可以这样用./llama-bench -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl 28 -b 512 -ub 512 -n 32它会输出一个标准的性能报告包含prompt处理速度和生成速度比用肉眼数token靠谱得多。5. 常见问题与排查技巧实录整个调试过程不是一帆风顺的。我把最常遇到的几个问题整理出来附带排查思路和解决方案直接照着查就行。5.1 CUDA OOM显存不足现象程序运行到一半直接退出打印类似于CUDA error: out of memory的信息。排查思路确认当前-ngl是多少层调低-c尤其是如果上下文设置过高看是否用了--mlock有时--mlock会把内存锁住但不会影响显存检查是否有其它程序占用显存解决方案降低-ngl2-5层或把-c调低一档。显存通常是可以余量省出来的记住不要贪心。5.2 速度一会儿快一会儿慢现象同一个提示词前后两次测速差异很大甚至生成中途掉速。排查思路观察nvidia-smi的GPU占用率是否稳定如果GPU占用率波动大说明CPU喂不上数据检查内存是否爆了解决方案15GB以上内存加--mlock如果内存紧张把模型换成Q3量化。此外如果CPU不是高频把-t往下调比如6降到4减少内存带宽争抢。5.3 生成质量不稳定逻辑断裂现象输出内容有明显重复、离谱推理或者回答开头自信但后半段混乱。排查思路首先检查是否用了过低量化Q2/Q3且关注路由的选择是否正确检查--temp采样参数大模型默认温度是0.8但MoE模型有时对高温度更敏感解决方案采用Q4_K_M及以上量化--temp 0.6左右配合--top-p 0.9能明显改善稳定性。如果主要是跑结构化任务建议--temp 0.4。5.4 启动时直接“Killed”现象模型文件加载到一半进程被杀直接Killed。排查思路这个通常是系统内存不足不是显存的问题确认GGUF文件大小与系统内存解决方案换小量化模型或者加内存。另外可以关闭--mlock看看能否载入但这样推理速度会下降。5.5 常见问题速查表症状最可能原因立即可用的修复CUDA OOM显存超用降-ngl、降-c速度慢CPU内存带宽不足加--mlock、降-t生成逻辑混乱量化过低或温度过高换Q4_K_M、--temp 0.6中途Killed系统内存不足换Q3量化、加内存条显存占用高但没报错KV cache过大降-c开-fa排查时最有效的手段永远是先拆分变量只改动一个参数其他保持不变跑一次llama-bench看结果。一次改两三个参数出了问题你很难定位到底是哪个导致的。写在最后GTX 1060原本是很多玩家手里的“垃圾佬快乐卡”如今能带着35B级MoE模型跑起本地推理最大的功臣其实是模型架构的进步和llama.cpp这个项目的持续迭代。对普通用户来说这套组合的意义不在于它能替代云端大模型而在于它把“本地运行大模型”的硬件门槛降到了一个非常亲民的位置。回到具体操作上我个人的体会是真正影响最终速度的往往不是某一个“神之一手”的参数而是把显存、内存、CPU线程和GPU卸载这四个变量联合起来看。先保住模型质量量化别太低再压上下文然后把MoE专家层扔给CPU让Attention层进GPU最后微调线程数和批大小整个过程花不了半小时但收益非常直观。如果你手头正好有一块6GB显存的旧卡手里也没有太新的大显存设备别急着吃灰。拿这套思路跑一跑说不定“跑不动大模型”这个想法就要改写了。
GTX 1060算是一张被反复“宣判退役”但又始终活跃在玩家和折腾党手里的老卡。6GB显存在今天连个大点的游戏都喂不饱更别说跑大模型了。但llama.cpp这个项目偏偏把门槛压得很低——低到让这张2016年的卡能带着Qwen 3.6 35B A3B这样的35B参数级MoE模型跑起来而且不是“慢到怀疑人生”的那种跑法是能把生成速度拉到肉眼可用的水平。这篇文章围绕我实际折腾这套组合的过程整理出五个真正有效的优化技巧。不说空话每个技巧都直接给参数、给理由、给实测前后的速度变化希望能帮你把手头的老卡废卡重新用起来。1. 为什么是GTX 1060 Qwen 3.6 35B A3B一个“看起来不可能”的组合35B参数的模型很多人第一反应是“没有24GB显存玩什么玩”。这句话放在传统Dense稠密模型上没问题但Qwen 3.6 35B A3B是MoE架构情况完全不一样。A3B这个后缀的意思是“激活3B参数”也就是说模型虽然总共有35B参数但每次生成一个token真正参与计算的只有大约3B参数。这就是整个方案成立的前提。1.1 35B模型到底有多大6GB显存差多少先说文件体积。以Qwen 3.6 35B A3B原版bf16权重来说35B参数乘2字节大约是70GB这显然不是6GB显存能碰的。但GGUF量化之后体积会大幅缩水。用Q4_K_M量化文件大概在20GB左右用更激进的Q3_K_S或者IQ3_XXS能做到15GB上下。这里有个关键认知模型文件是放在磁盘里的推理时需要的是“把要用的权重读进内存”。6GB显存装不下20GB权重但可以把一部分留在系统内存里。llama.cpp支持GPU和CPU混合推理可以把模型的一部分层卸载到GPU其余部分留在CPU内存里靠处理器计算。不过光是文件大还不算最要命的。真正的瓶颈是即便你买了一块80GB显存的卡如果模型是传统的Dense架构35B参数在推理时每一层都要完整跑一遍计算量是实打实的35B级别。MoE模型的优势就在于虽然文件还是20GB但每次推理只需要处理其中一小部分专家网络计算量远小于Dense模型。1.2 MoE架构给了一张“通行证”MoE的中文叫混合专家。理解它最简单的方式是一个类似Qwen 3.6 35B A3B的模型内部有几十个“专家”子网络每次生成token时路由器会根据当前输入的语义只选出其中少数几个专家来计算。在Qwen 3.6 35B A3B的设置里激活参数只有总参数的十分之一不到3B vs 35B。这意味着计算强度大幅下降让一台普通双通道内存的电脑也能勉强扛得住。更妙的是MoE模型虽然参数多但其中绝大部分专家层是结构统一的非常适合放在CPU上做并行计算而Attention部分Q、K、V、O投影在每一层都要参与更适合扔给GPU。这一点直接决定了后续优化方案的方向想办法把计算密集、并行度高的部分给GPU把参数多但每次只激活一小部分的部分留给CPU。1.3 llama.cpp为什么适合这种场景llama.cpp是一个用C/C实现的大模型推理框架最初是为了在MacBook上跑Llama模型而写的后来慢慢变成了一套跨平台推理方案。它有两个特性让它特别适合老卡一是GGUF量化格式能把模型压到几个比特二是灵活的层卸载offload机制可以精确控制哪些层放在GPU、哪些层留在CPU。比起许多动辄几GB的推理框架llama.cpp本身只有几十MB依赖少、编译简单而且对Pascal架构GTX 10系的CUDA支持一直没有砍掉。所以GTX 1060虽然不是它的“最优解”但至少是能跑、能优化的平台。一个现实提醒6GB显存跑35B模型目标不是追新卡那样的每秒几十token而是把它从“完全跑不动”拉到“勉强能用”。这里面所有技巧的核心都是把显存每一字节都花在刀刃上。2. 动手前的准备工作编译、模型选择与量化版本拿GTX 1060跑这套组合直接下载一个预编译的llama.cpp也能用但如果想榨干性能建议还是自己编译。原因后面会说先讲整体流程。2.1 编译llama.cpp别忘了CUDA支持llama.cpp官方预编译的Windows版本里有包含CUDA的版本和纯CPU版本。GTX 1060必须用CUDA版本否则所有计算都落在CPU上速度会更惨。推荐的方式是自己编译这样能确保CUDA架构是匹配的。GTX 1060的算力是6.1Pascal架构在llama.cpp的CMake编译时默认的CUDA架构列表里通常包含6.0和6.1所以基本不需要额外指定。但要注意CUDA工具链版本新版llama.cpp对CUDA版本有一定要求我用的是CUDA 12.x编译很顺利。Linux下大概是这样git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUDAON -DCMAKE_BUILD_TYPERelease cmake --build . --config Release -j 8编译完成后重点看两个可执行文件llama-cli命令行推理和llama-bench基准测试。后面所有优化效果的验证都靠这两个工具。2.2 选对量化版本6GB显存才有的玩Qwen 3.6 35B A3B的GGUF格式文件有多个量化版本从Q2_K到Q8_0都有。对于6GB显存首选Q4_K_M这是质量与体积的平衡点。为什么不是Q3或者Q2因为MoE模型对量化更敏感。Dense模型量化后只是所有参数一起降精度而MoE模型的路由机制非常依赖某些关键参数来“认路”。量化等级太低路由器可能把token分给错误的专家导致回答质量突然崩掉。Q4_K_M在实测中降低的困惑度幅度一般在合理范围内速度却比Q5、Q8快不少。我对比过两个版本Q4_K_M文件约19.5GBQ3_K_S约14.8GB。显存占用上Q3当然更占优可以多卸载几层到GPU但生成内容偶尔会有明显逻辑断裂。如果追求稳定使用我宁愿少卸载几层GPU也要保住Q4_K_M的质量。启动参数简明版本./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl 28 -c 4096 -t 6这串参数后面会逐个拆解说明。第一次跑的时候你会看到llama.cpp打印很多日志包括模型加载了多少层到GPU、每层的张量信息、上下文大小等。留意这些信息它们对排查问题很有帮助。2.3 第一次启动先摸清硬件家底在实际优化之前最好先确认几个硬指标CPU型号与内存通道数、磁盘类型、显卡功耗限制。内存带宽对CPU推理速度是决定性的。拿DDR4双通道来说理论带宽大约25-40GB/s实际可用打七折左右。MoE模型在CPU上推理时每次激活3B参数Q4量化后大概1.5-2GB字节要从内存搬到CPU这个搬运速度直接决定下限。磁盘方面如果模型文件放在机械硬盘上加载速度慢到夸张而且运行中如果要用mmap从磁盘读取专家权重会有明显卡顿。务必把GGUF文件放进SATA SSD或NVMe SSD里。GTX 1060的显卡功耗墙建议手动拉到最大比如105W因为推理时GPU会长时间满载功耗限制会直接压低核心频率。准备完这些就可以开始逐项调整优化了。3. 五个优化技巧逐个拆解这一部分是全文重点。五个技巧按实际调试顺序排列每一个都有对应的参数、原理和效果可以直接套用。3.1 技巧一精确设置GPU卸载层数别把显存填满-nglnum_gpu_layers控制多少层模型被放到GPU显存。这是影响最大的一个参数很多人一上来就无脑设到999结果直接OOM显存不足报错。Qwen 3.6 35B A3B这类模型层结构一般是若干层Transformer块每个块里有Attention层和MoE层。GTX 1060 6GB的显存里系统占用的显存可以忽略不计但CUDA context本身要占100-300MBKV cache也要占几百MB到几GB不等。我的经验是-ngl并不是越大越好。在6GB卡上把它设到28-30层往往是一个甜点。再往上显存剩下不到200MB稍微跑长一点上下文就OOM。怎么找到最优值最简单的方法是看llama.cpp加载时的“offload”日志然后逐步加1-2层跑一轮llama-bench测试观察速度曲线。当-ngl增加但速度不再明显提升时说明已经逼近CPU/GPU通信瓶颈了。比如在我这台机器上i5-8400 GTX 1060 6GB 16GB DDR4 2666双通道-ngl显存占用速度 (token/s)0约0.7GB1.210约2.1GB2.120约3.4GB3.528约4.3GB4.232接近OOM不稳定-ngl 32时显存虽然还没立刻崩但一次长对话生成到一半就报了CUDA OOM。所以最终固定在-ngl 28留出余量给上下文增长。需要注意的是这套组合里的“层”指的是非专家层。Qwen 3.6 35B A3B的MoE专家层非常多llama.cpp日志里会区分“GPT-2-like attention”和“expert FFN”等不同的张量。默认情况下专家层也会被算进卸载计划里这其实不太适合老卡。这就引出了另一个参数后面技巧五会专门说。提示显存占用请直接用nvidia-smi看别只看llama.cpp日志的估算。llama.cpp的“offloaded”提示不算KV cache实际占用会更高。3.2 技巧二调线程数与批处理大小别让CPU和GPU互相等待线程数-t是CPU侧并行度的核心参数。在纯CPU推理时线程数接近物理核心数往往是吞吐最高的配置。但在GPUCPU混合推理时线程数要重新考虑。GTX 1060卸载了28层之后剩下约十几层包括大量专家层在CPU上跑。如果线程塞得太满CPU每个核都在高负载运行内存带宽会被并行线程争抢反而拖慢整体速度。更糟的是GPU侧算完一批token后要等CPU完成下一批流水线就会断断续续。我的实测数据-t 值速度 (token/s)CPU占用45.875%66.592%86.2100%12 (含超线程)5.5100%i5-8400是6核6线程所以-t 6是最优解。如果你是8核16线程的CPU建议从物理核心数开始试不要直接开满16线程。MoE模型的专家并行确实需要较多线程但超过物理核心数往往适得其反。批处理大小也有讲究。-bbatch size控制每次喂给模型多少token一起算默认是2048。对于6GB显存的GTX 1060-b过大会让显存占用暴涨因为批量推理会临时放大中间激活值。建议在混合推理模式下显式设置-b 512 -ub 512-ub是上行批大小ubatch size控制在一次反向或前向传播中实际参与计算的token数。设为512在大多数场景下足够还能把显存占用压在一个低位。如果跑长文本生成任务甚至可以考虑-b 256换取更低的显存峰值。为什么这样组合有效因为在混合推理模式里GPU负责的层一次要处理一批token批大小越大中间张量越大显存占用越高。GTX 1060的6GB是硬约束牺牲一点吞吐换稳定性绝对值。3.3 技巧三限制上下文长度省下显存给权重上下文-c是另一个经常被忽略的显存吞噬者。很多人直接抄别人配置用-c 8192结果发现模型加载到一半就OOM或者跑一会儿就爆。KV cache的显存占用可以按这个公式粗略估算KV cache大小 ≈ 2K和V × 层数 × 注意力头数 × 每头维度 × 上下文长度 × 2字节fp16Qwen 3.6 35B A3B用了GQA分组查询注意力KV cache相对Dense同尺寸模型会小一些但依然不小。在6GB卡上-c 8192比-c 2048多占可能1-2GB显存。这些显存如果省下来可以多卸载好几层权重到GPU。我的选择是固定-c 4096。日常对话、代码生成、文档总结4096个token的上下文在大多数场景下够用。如果真遇到超长输入宁可用-c 8192和-ngl 24搭配也不要把两个都拉满。实测-c 4096-ngl 28时显存峰值约4.3GB-c 8192-ngl 24时显存超过5.2GB但速度反而慢了。因为少卸载了4层GPU和CPU的负载均衡被打破。对GTX 1060用户我的建议是不要在上下文长度上贪心。省下的显存一定要优先给-ngl。3.4 技巧四开启flash attention老卡也有第二春llama.cpp有一个-fa参数用于启用Flash Attention优化。虽然GTX 1060没有Hopper、Ampere架构上的第二代/第三代Tensor Core支持但Flash Attention的核心理念——通过分块计算减少HBM显存带宽访问——在Pascal上依然有效。不过需要区分一个事实llama.cpp的-fa在Pascal架构上并没有带来像40系卡那样的质变性能提升通常只有5%-10%但它的另一个好处非常关键可以降低KV cache的显存占用。在部分模型上开启-fa后KV cache可以以更紧凑的格式存储显存占用从fp16变成类似fp8甚至更低。这对6GB卡来说等于是白捡几百MB显存可以做很多事情。我的配置是这样-fa就一个参数。它不改变推理结果理论上是无损加速所以没有任何理由不开。另外一个和显存强相关的参数是--mlock。这个参数会把模型权重锁在系统内存里防止操作系统把内存页交换到磁盘。在MoE模型里专家层在CPU内存中随机访问如果内存频繁换页速度会雪崩。我在16GB内存在跑19.5GB模型GGUF文件20GB左右加上KV cache和运行时开销时如果不加--mlock系统会在内存压力大时把页面换到虚拟内存导致生成速度从4 token/s掉到1 token/s以下。开机后加--mlock能明显缓解但我后来发现更彻底的方案是升级内存换32GB否则模型加载后内存几乎没有余量。如果你只有16GB内存建议这样跑--mlock同时尽量关掉浏览器等占用内存的进程。19.5GB的GGUF文件加载后大概占18-19GB物理内存和16GB不匹配这种情况建议换Q3量化文件或者接受系统换页带来的性能损失。3.5 技巧五别忽略MoE专用参数按专家数调优前四个技巧对任何模型都有效这第五个才是针对Qwen 3.6 35B A3B这种MoE模型的“特化特调”。llama.cpp新版本里多了一些和MoE相关的控制项其中最适合GTX 1060场景的是把专家层固定放在CPU不让它们占用宝贵的显存。默认情况下-ngl 28会把每一层里的所有子层attention、FFN、expert们都“全部卸载”。这就很浪费了因为专家层数量巨大且每次只激活一小部分把它们全塞到6GB显存里不仅塞不下塞进去了推理时还要频繁向显存搬运专家权重通信开销很大。更好的做法是让Attention等共享层去GPU专家层全部留在CPU内存里。llama.cpp通过--n-cpu-moe参数可以实现这一点这个参数指定有多少个MoE专家层必须在CPU上执行。我的命令行长这样./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl 28 -b 512 -ub 512 -c 4096 -t 6 -fa --n-cpu-moe 20 --mlock这里的--n-cpu-moe 20不是随便拍的。Qwen 3.6 35B A3B一共约64个专家层不同版本结构可能有差异以llama.cpp日志为准我先把--n-cpu-moe设为全部专家层数量再把-ngl调到比较高让非专家层尽量进GPU。实测下来显存占用被显著压下来速度却反过来提升了。为什么当专家层留在CPU时GPU显存只需要容纳Attention层和中间激活值6GB完全够用还能多卸载几层非专家层。而CPU端虽然有19GB模型文件需要读取但MoE每次只读激活的专家内存带宽压力没有想象中那么大。两种硬件各司其职反而比全部塞进GPU更高效。如果你的llama.cpp版本没有--n-cpu-moe这个参数可以退而求其次用老方法减少-ngl让模型后面一大段包括专家层直接留在CPU。效果接近但控制粒度不如显式指定专家层精细。注意--n-cpu-moe在不同llama.cpp版本的命名可能有差异。有的版本叫--n-cpu-moe有的版本叫--cpu-moe。建议先跑./llama-cli --help看一眼帮助信息再改。4. 实测数据从“勉强能跑”到“速度提升6倍”光讲参数不讲结果就是在耍流氓。这一节把我实际的调试过程和数据贴出来每一步跑的都是同一个模型文件Qwen 3.6 35B A3B Q4_K_M.gguf同一台机器i5-8400、GTX 1060 6GB、16GB DDR4 2666双通道、NVMe SSD测试工具是llama-cli自带的生成任务。4.1 基准测试不优化的结果第一次跑的时候我用的是最简单粗暴的方式./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -p 你好 -ngl 0-ngl 0意味着模型全部放在CPU上完全不用GPU。速度是1.2 token/s。这是怎么回事35B模型虽然只激活3B参数但内存带宽有限加上Attention层也要在CPU上算整条链路没有任何硬件加速点。1.2 token/s的体验就是敲一个字等半分钟连“能用”的门槛都没摸到。如果不特意指定-nglllama.cpp默认可能连GPU都检测不到那跑起来的速度会更离谱所以第一步一定要确认GPU真的被利用上了。4.2 逐步优化后的对比接下来逐步叠加前面说的优化项每一步的实测数据如下配置速度 (token/s)显存占用说明基准-ngl 01.20.7GB纯CPU基本不可用 -ngl 203.53.1GB明显提速显存还有余量 -c 4096从8192降下来4.13.8GB显存释放可多卸载层 -b 512 -ub 5124.33.9GB批大小优化小幅提升 -fa4.54.1GBFlash Attention收益不大但有效 -t 6从8降下来5.24.0GB线程数校准CPU/GPU更平衡 --n-cpu-moe 206.84.2GB专家CPU化大杀器 --mlock7.64.4GB防换页最后一块拼图最终7.6 token/s对比最初的1.2 token/s速度提升了大约6.3倍。虽然没有大卡动辄几十token/s的爽快感但对于一台只有6GB显存的机器来说这已经是一个非常可用的水平。7.6 token/s意味着日常对话里一个150字的回复大概10秒左右能生成完。配合上流式输出使用体验已经接近ChatGPT初代的响应速度了。4.3 同一套技巧在更大/更小模型上的参考这套优化逻辑不只适用于Qwen 3.6 35B A3B。我还试过类似的MoE模型比如Mixtral系列不过那些模型更大1060跑起来更吃力。整体原则是一样的先量化到Q4_K_M或Q3_K_S用--n-cpu-moe或降低-ngl来压迫显存再往回调整至显存刚好不爆换到不同的模型时需要重新微调几个参数。每次换模型我都习惯先用llama-bench快速跑一轮基准再开始逐项调。llama-bench可以这样用./llama-bench -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl 28 -b 512 -ub 512 -n 32它会输出一个标准的性能报告包含prompt处理速度和生成速度比用肉眼数token靠谱得多。5. 常见问题与排查技巧实录整个调试过程不是一帆风顺的。我把最常遇到的几个问题整理出来附带排查思路和解决方案直接照着查就行。5.1 CUDA OOM显存不足现象程序运行到一半直接退出打印类似于CUDA error: out of memory的信息。排查思路确认当前-ngl是多少层调低-c尤其是如果上下文设置过高看是否用了--mlock有时--mlock会把内存锁住但不会影响显存检查是否有其它程序占用显存解决方案降低-ngl2-5层或把-c调低一档。显存通常是可以余量省出来的记住不要贪心。5.2 速度一会儿快一会儿慢现象同一个提示词前后两次测速差异很大甚至生成中途掉速。排查思路观察nvidia-smi的GPU占用率是否稳定如果GPU占用率波动大说明CPU喂不上数据检查内存是否爆了解决方案15GB以上内存加--mlock如果内存紧张把模型换成Q3量化。此外如果CPU不是高频把-t往下调比如6降到4减少内存带宽争抢。5.3 生成质量不稳定逻辑断裂现象输出内容有明显重复、离谱推理或者回答开头自信但后半段混乱。排查思路首先检查是否用了过低量化Q2/Q3且关注路由的选择是否正确检查--temp采样参数大模型默认温度是0.8但MoE模型有时对高温度更敏感解决方案采用Q4_K_M及以上量化--temp 0.6左右配合--top-p 0.9能明显改善稳定性。如果主要是跑结构化任务建议--temp 0.4。5.4 启动时直接“Killed”现象模型文件加载到一半进程被杀直接Killed。排查思路这个通常是系统内存不足不是显存的问题确认GGUF文件大小与系统内存解决方案换小量化模型或者加内存。另外可以关闭--mlock看看能否载入但这样推理速度会下降。5.5 常见问题速查表症状最可能原因立即可用的修复CUDA OOM显存超用降-ngl、降-c速度慢CPU内存带宽不足加--mlock、降-t生成逻辑混乱量化过低或温度过高换Q4_K_M、--temp 0.6中途Killed系统内存不足换Q3量化、加内存条显存占用高但没报错KV cache过大降-c开-fa排查时最有效的手段永远是先拆分变量只改动一个参数其他保持不变跑一次llama-bench看结果。一次改两三个参数出了问题你很难定位到底是哪个导致的。写在最后GTX 1060原本是很多玩家手里的“垃圾佬快乐卡”如今能带着35B级MoE模型跑起本地推理最大的功臣其实是模型架构的进步和llama.cpp这个项目的持续迭代。对普通用户来说这套组合的意义不在于它能替代云端大模型而在于它把“本地运行大模型”的硬件门槛降到了一个非常亲民的位置。回到具体操作上我个人的体会是真正影响最终速度的往往不是某一个“神之一手”的参数而是把显存、内存、CPU线程和GPU卸载这四个变量联合起来看。先保住模型质量量化别太低再压上下文然后把MoE专家层扔给CPU让Attention层进GPU最后微调线程数和批大小整个过程花不了半小时但收益非常直观。如果你手头正好有一块6GB显存的旧卡手里也没有太新的大显存设备别急着吃灰。拿这套思路跑一跑说不定“跑不动大模型”这个想法就要改写了。
