前阵子一个朋友问我3060这种三年前的甜品卡凭什么跑35B的大模型我的回答是Windows原生、GGUF量化、MoE稀疏激活这三样凑齐之后RTX 3060 12GB跑Qwen3.6-35B-A3B不仅能跑实测还能稳定到30t/s左右。这篇就是把这套方案从原理到实操完整拆开把每一步为什么这么做讲清楚方便手里正好有3060、又不想折腾Linux和WSL2的朋友直接照做。内容会比较长但含金量都在这了。不急慢慢看。1. 一张3060跑35B不是标题党1.1 先看懂Qwen3.6-35B-A3B这个名字很多人一看到35B就吓到了觉得35B参数至少得几十GB显存起步。实际上这个名字里的“A3B”才是关键。A是Activated3B是3 Billion意思是虽然整个模型有35B参数但推理时真正参与计算的参数只有约3B。理解这个点可以打个比方一家公司有35个部门名义上很庞大但每次开项目会只需要3个核心部门到场其他部门都在待命。CPU和GPU只需要集中资源处理这3个部门的活就行了其余32B参数更像是“存着备用”不参与本轮计算。这就是MoE混合专家架构最大的好处——参数规模大但计算量不跟参数规模成正比。所以3060跑Qwen3.6-35B-A3B这件事本质上不是“小马拉大车”而是“马刚好拉得动一辆设计得很巧的车”。这也是为什么实测能到30t/s而不是像跑34B稠密模型那样只有3-5t/s的卡顿体验。Qwen3.6系列本身是Qwen3的延续在代码、指令跟随、多轮对话上都有不少优化。需要注意的是我这里实测的是GGUF量化版本也就是已经把FP16权重压缩到4-bit左右的格式。后面会专门讲量化。1.2 为什么是Windows原生而不是WSL2/Docker本地跑大模型的教程里绝大多数会推荐WSL2或Docker。理由是Linux下NVIDIA驱动兼容性好、内存管理干净、社区脚本多。这套方案对服务器玩家没毛病但对Windows桌面用户来说多套虚拟化层确实多一份麻烦。我先说结论Windows原生跑Ollama或llama.cpp性能损耗完全可以接受实测t/s差距通常在5%以内很多场景甚至感觉不出来。WSL2本质上是一个轻量虚拟机GPU透传通过DXG调用底层驱动虽然已经很成熟但遇到长上下文、高频生成时偶尔会有调度延迟。Docker Desktop在Windows下跑GPU容器时也需要额外配置WSL2后端绕一圈又回到同一个地方。如果只是自己玩模型、做开发调试、局域网开个服务Windows原生更省心。直接装Windows版Ollama或者下载llama.cpp的Windows release点了就能跑。没有虚拟化层没有文件系统转换开销也没有“Docker里GPU突然不可用”这种诡异问题。2. 装机前的准备驱动、工具和模型选型2.1 检查显卡驱动和CUDA环境这一步最容易被忽略但恰恰能决定成败。Windows上装大模型推理不需要手动装CUDA Toolkit因为Ollama和llama.cpp的预编译包都自带CUDA runtime。你唯一需要保证的是NVIDIA驱动版本够新。我这台机子用的是551.86以上的驱动实测Ollama能正确识别CUDA 12能力。如果你驱动还停留在500系列甚至更早建议先更新。判断标准很简单在NVIDIA控制面板里看“产品名称”旁边有没有“CUDA”字样或者直接用命令nvidia-smi只要能看到显卡信息右上角显示CUDA Version大于等于12.0就基本没问题。3060 12GB版本和8GB版本在这套方案里的体验差很多我强烈建议12GB显存起步。8GB版本不是不能跑而是KV Cache和batch稍大一点就很容易爆显存30t/s这种速度会很难稳定。内存方面最低16GB能用但建议32GB。因为GPU放不下的参数和KV Cache会落到内存里内存太小会直接触发Windows的内存压缩机制导致速度断崖式下跌。2.2 Ollama还是llama.cpp这是Windows玩家常见的纠结。我的建议是先用Ollama跑通再深入用llama.cpp调参。Ollama的优势是省事拉模型、起服务、对接聊天界面全是一行命令。它对GPU offload做了比较聪明的默认处理新手不需要关心层数分配也能跑出不错的效果。缺点是黑盒程度高想精确控制哪个层放GPU、哪个层放CPU就得写Modelfile或者走API参数。llama.cpp的优势是完全可控。-ngl参数决定多少层放在GPU-t控制CPU线程数-b控制batch size每个变量都能自己调。对于追求极限性能和参数可复现的人来说llama.cpp是必选项。实际操作中我两个都装了。Ollama用来日常对话和快速验证llama.cpp用来做压力测试和精调。2.3 量化版本怎么选Qwen3.6-35B-A3B的原始FP16权重非常大35B参数换算下来大约70GB3060那点显存想都不用想。所以必须上GGUF量化版本。常见的量化等级有q2_K、q3_K、q4_K_M、q5_K_M、q6_K、q8_0。我最推荐q4_K_M。它在体积、速度、质量之间取得了一个很好的平衡点。q4_K_M的“K_M”代表混合精度量化重要张量保留更高精度次要张量压到4-bit效果比单纯的q4_0好一个档次体积却差不多。q2_K和q3_K虽然更小但中文输出质量下降明显经常出现半中半英、逻辑跳脱的问题。q5_K_M和q6_K质量更好但体积大一圈在3060上会占用更多显存/内存拖慢速度。q4_K_M是我实测30t/s的关键选择之一。3. 实操全程从拉模型到稳定30t/s3.1 用Ollama拉取并创建模型先下载安装Windows版Ollama。装完后确认服务正常运行ollama --version如果Ollama官方模型库里已经有了Qwen3.6-35B-A3B的GGUF版本直接拉取最方便ollama pull qwen3.6-35b-a3b:q4_K_M如果官方库暂时没有这个tag也没关系。先去HuggingFace找到对应的GGUF文件一般会放在Qwen/Qwen3.6-35B-A3B-GGUF这类仓库下选择文件名里带q4_K_M的版本然后写一个Modelfile导入FROM C:/models/qwen3.6-35b-a3b-q4_K_M.gguf PARAMETER num_ctx 8192 PARAMETER temperature 0.7 PARAMETER top_p 0.9保存为Modelfile执行ollama create qwen3.6-35b-a3b -f Modelfile这时候模型就算装好了。注意PARAMETER num_ctx 8192代表上下文长度这个值既影响能记住多少历史对话也直接影响KV Cache占用的显存和内存。我先用8192测试后面会解释为什么不是越大越好。3.2 控制GPU offload层数避免显存溢出Ollama默认会尽量把模型层加载到GPU但如果模型太大它也会自动进行部分offload。问题在于自动策略不一定是速度最优的。想让3060跑出好成绩需要手动指定放到GPU的层数。Ollama中修改Modelfile加一行PARAMETER num_gpu 20然后在命令行重新创建模型ollama create qwen3.6-35b-a3b -f Modelfile数字20不是拍脑袋定的而是3060 12GB在q4_K_M量化、8192上下文下比较稳的起点。你可以从20开始往上调到24、28观察显存占用和速度变化。如果出现“CUDA out of memory”或Ollama服务崩溃说明放多了降到下一档。这个参数的原理是Transformer模型是一层一层堆起来的num_gpu决定前N层放GPU其余层放CPU。GPU层越多参与并行计算的权重越多速度越快但超过显存容量后Windows会强行把多余数据换到内存速度反而崩溃。所以这不是“越多越好”而是“刚好装满最好”。如果直接用llama.cpp跑对应参数是llama-cli -m qwen3.6-35b-a3b-q4_K_M.gguf -ngl 20 -t 6 -c 8192其中-t 6表示使用6个CPU线程-c 8192设置上下文长度。3.3 跑起来之后怎么复现30t/s模型创建好后跑一句简单指令ollama run qwen3.6-35b-a3b第一次加载会比较慢大概需要10-20秒因为要把几十GB的模型文件从磁盘读进内存。这是正常现象。加载完成后连续问几个问题速度会逐渐稳定下来。我实测的稳定值是30t/s左右。怎么复现这个数据首先保证显卡驱动、Ollama都是新版本其次确保系统没有后台高负载程序再一个上下文别拉太长。我用num_ctx 8192作为基准连续对话到中后段KV Cache变大后速度会降到24-27t/s这仍然属于正常范围。如果直接使用llama.cpp可以用带计时的方式观察llama-cli -m qwen3.6-35b-a3b-q4_K_M.gguf -ngl 20 -t 6 -c 8192 --verbose-prompt -p 写一段关于Windows本地部署大模型的介绍输出末尾会明确打印eval time和t/s数据。我测试下来的结果Generation速度稳定在28-32t/sPrompt Process速度更高通常在200-400t/s因为prefill阶段并行度高。4. 性能背后的原理MoE、混合推理和量化4.1 MoE的稀疏激活刚才说过Qwen3.6-35B-A3B是MoE架构参数35B激活3B。这里再往深挖一层为什么稀疏激活对推理速度影响这么大稠密模型每生成一个token都要让全部参数过一遍计算图。35B稠密模型就是35B参数全量参与计算。而MoE模型在每一层里放了多个“专家”子网络每次输入只会根据路由器的决定选择其中少数专家进行计算。3B激活参数意味着每token的计算量大约只相当于一个3B稠密模型。这就产生了一个很有意思的结果模型容量很大知识储备丰富但每次回答的算力成本却接近小模型。3060的性能刚好能覆盖3B激活参数的计算需求于是30t/s这个数字就出现了。4.2 GPU/CPU混合部署既然显存装不下整个模型那为什么速度没有慢到无法接受这就要说混合推理了。默认情况下q4_K_M量化后的Qwen3.6-35B-A3B大约20GB上下。3060 12GB肯定装不完但也不需要全装完。把前20层放在GPU其余层放在内存模型在生成每个token时GPU负责前20层的张量计算CPU负责剩余层的计算两者之间通过PCIe总线搬运数据。听起来好像每次都要跨设备传输速度应该很惨。但实际MoE模型因为激活参数只有3B每一层计算量都不大传输的数据量也相对有限。只要PCIe通道和内存带宽不出问题就会出现“CPU负责的部分还没算完GPU已经算完在等数据”的状态。这时候瓶颈在CPU侧GPU反而有富余。所以我建议用6-8个CPU线程来跑offload层。线程多了容易互相抢内存带宽线程少了计算力不够。我实测6线程比4线程快了约15%比8线程差别不大甚至8线程在某些长上下文场景下反而更慢因为内存带宽饱和了。4.3 Q4_K_M量化量化说白了就是用更少的bit表示一个浮点数。FP16是16bitQ4_K_M大约4.5-5.5bit体积省了三分之二以上但精度损失被算法控制得很小。K_M量化在实现上会把模型的权重张量分成不同块block每个块独立计算量化尺度和缩放因子。重要部分比如attention里的某些权重用更高精度不那么重要的部分用更低精度。这是一种“把钱花在刀刃上”的策略。所以Q4_K_M跑出来的中文质量比起FP16原始模型在日常对话和代码生成场景下区别很难察觉。只有在极端长文、复杂数学推理、专业翻译等场景下才可能看到细微差异。3060玩家选Q4_K_M是完全理性的选择不是妥协。5. 实测数据怎么看5.1 t/s的真实含义t/s等于token per second也就是每秒生成的token数。一个汉字按1.5-2个token估算的话30t/s大约相当于每秒生成15-20个汉字。作为对比正常阅读速度大约是每秒10-15个汉字。换句话模型生成文字的速度已经超过了人眼阅读的速度这在交互体验上就是“打字机效果”的流畅感。需要说明的是t/s指的是生成阶段速度不是“每秒能处理多少字的对话”。同一个模型输入一大段提示词的预填充速度和逐字生成速度是两个指标。30t/s是逐字生成速度也是日常对话最直观的体验指标。5.2 不同配置的横向对比我专门做了几组对照测试都是Qwen3.6-35B-A3B的q4_K_M版本只是部署方式不同部署方式GPU层数内存实测生成速度纯GPU推理12GB显存不够需小量化全部16GB往往OOM不推荐GPUCPU混合20层32GB28-32t/sGPUCPU混合12层32GB20-24t/s纯CPU0层32GB5-8t/sGPUCPU混合超长上下文20层32GB22-26t/s从表里能看得很清楚GPU层数越多速度越快但前提是不触发显存溢出。CPU推理虽然也能用但只能应急日常对话会明显感觉到停顿。这也是为什么我在前面反复强调num_gpu参数。还有个隐蔽影响因素是内存频率。DDR4 3200和DDR5 6000在CPU offload层数较多时速度差距可以达到10%-20%。如果你手上是双通道内存务必插满两根单通道内存带宽减半混合推理会非常吃亏。5.3 对日常使用的参考价值30t/s这个成绩放到本地大模型领域已经属于“日常可用”甚至“日常好用”。拿来做翻译、写代码、整理文档、本地知识库问答响应速度都不会让人烦躁。如果需要更高的质量比如写硬核技术方案、复杂推理可以把温度调低到0.6或者换q5_K_M量化速度降一点但稳定度提升。不要被“35B”这个数字吓到也不要被“3060”这个型号框住。这套方案给我最大的启发是大模型本地化的核心不是买最贵的显卡而是选对架构、选对量化、调好offload策略。6. 常见问题与排查清单6.1 显存不足或CUDA OOM症状Ollama启动后立刻退出日志里出现CUDA out of memory或者llama.cpp直接报ggml_cuda_assign_buffers失败。原因GPU层数设置太多或者KV Cache占用太高。解决先把num_gpu调低比如从20降到16。如果是8GB显存版本建议从12开始。同时把num_ctx从8192降到4096。记住一个原则上下文长度越大KV Cache占用越高它和模型权重一样都吃显存。6.2 速度忽高忽低症状前几个回复能跑到30t/s聊一会就掉到10t/s以下再过一会又恢复。原因一个是Windows后台服务抢占CPU资源另一个是内存不够时系统把模型页换到磁盘了。Windows的“内存压缩”和“页面文件”机制在物理内存不足时会偷偷接管内存页但由于模型文件需要频繁读取一旦落盘速度就崩。解决关闭不必要的后台程序尤其是浏览器多标签页。把Windows虚拟内存设置为“系统管理的大小”不要手动设太小。有条件就加内存条32GB是这套方案的舒适区。6.3 中文输出质量差症状回答里中英混杂或者偶尔输入中文模型回复英文。原因量化等级偏低、采样参数过激、上下文中有大量英文示例数据。我以前用q2_K跑这类模型中文质量确实明显下降。解决至少要q4_K_M推荐q4_K_M起步。temperature控制在0.6-0.8之间超过1.0容易胡言乱语。top_p保持0.9左右。如果问题依旧把系统提示词明确写成“请始终使用中文回答”。6.4 模型加载失败或闪退症状执行Ollama create或llm命令时直接闪退没有明确错误信息。原因最常见的是模型文件路径包含中文或空格Windows下某些扩展名解析有问题其次是旧版本Ollama对GGUF文件的兼容性问题。解决把模型文件放到纯英文路径下例如C:/models/。Ollama和llama.cpp都更新到最新版。再用ollama serve前台启动日志看一下完整报错不要依赖窗口闪退那几秒钟的信息。6.5 一次加载很慢但后续生成很快这不是bug是正常现象。GGUF文件从磁盘读到内存几百MB/s到几个GB/s的读取速度决定首次加载时间。如果每次运行都重新加载很久可以尝试使用llama.cpp的--path、--keep相关机制或者保留Ollama服务常驻不要每次用完都退出。Windows 11的内存缓存机制会在第二次运行时自动热数据实测二次加载能快30%以上。跑完这一整套再回头看那个“3060实测30t/s”的标题其实没有太多神秘感。Windows原生的好处是省掉虚拟化折腾Qwen3.6-35B-A3B的MoE架构把有效计算量压到了3B级别q4_K_M量化把体积缩到了20GB上下最后靠num_gpu手动分配GPU层数把速度顶上去。每一步单独拿出来都不算难组合在一起就是一套可复现、可抄作业的本地大模型方案。我个人在实际操作中的体会是num_gpu这个参数永远值得多花时间调不要用默认设置一跑了之。每个电脑的内存带宽、PCIe通道、CPU型号都不一样只有实测出来的层数才是最优解。另外如果你后续想接Open WebUI做网页聊天界面Ollama的服务模式已经预留了完整API直接对接就行不需要额外改模型配置。这套方案跑通之后本地大模型的很多玩法都能继续往下延伸了。