最近把主力机的系统从 Linux 又切回了 Windows 11起因很简单手头这台机器装着 RTX 3060 12GB平时想跑个本地大模型以前总得进 WSL 或者干脆重启到 Linux来回折腾得烦。这次我干脆试了试 Windows 原生跑 Qwen3.6-35B-A3B结果有点出乎意料——实测稳定在 30 t/s 左右聊天、总结、写代码基本是“能用的流畅”而不是那种一个字一个字往外蹦的体验。这篇文章就把这次的配置、调参和踩坑记录整理出来给同样手里有 3060/4060 这类 8 到 12GB 显存显卡、又不想折腾 WSL 和双系统的朋友一个参考。1. 一张 3060 敢跑 35B先把模型底细说清楚很多人看到“35B”第一反应就是“开玩笑吧”毕竟一个 350 亿参数的稠密模型光 FP16 权重就要 70GB哪怕压到 Q4 量化也得 20GB 左右12GB 显存的 3060 连门槛都摸不到。但 Qwen3.6-35B-A3B 这个名字里的“A3B”才是关键它不是一个传统意义上的稠密大模型而是一个 MoE混合专家架构模型。1.1 MoE 架构总参数 35B 与激活参数 3B 的区别MoE 的思路可以类比成一个大型咨询公司公司里挂了 35 个专家的名号但接单的时候不会让 35 个人都上场而是根据客户的问题类型只挑最对口的 2 到 3 个专家去处理其他人继续待命。Qwen3.6-35B-A3B 的总参数是 35B但每次推理时真正参与计算的“激活参数”只有大约 3B。这个区别直接决定了两件事。第一推理时的计算量接近一个 3B 稠密模型而不是 35B 稠密模型所以速度不会慢到无法接受第二模型的知识覆盖面、指令跟随能力和复杂推理能力却保留在 35B 总参数的级别因为专家分工让模型能“记住”更多领域知识。这也是为什么这两年消费级显卡跑大模型越来越现实MoE 架构功不可没。1.2 为什么 A3B 模型适合消费级显卡除了激活参数少MoE 模型还有一个隐性优势权重文件虽然大但实际生成每个 token 时需要从显存读取的权重只覆盖被激活的专家部分。这在推理框架里表现为“内存带宽压力大幅降低”而内存带宽恰恰是本地推理速度的核心瓶颈之一。我这台机器是 3060 12GB显存带宽 360GB/s。如果跑一个 3B 稠密模型的 Q4 量化激活参数对应的权重读取量大概在 1.5GB 左右跑 Qwen3.6-35B-A3B 的 Q3 量化每生成一个 token 需要读取的激活权重也在这个量级。也就是说MoE 模型会把“35B 的重量”藏在硬盘和内存里但把“3B 的敏捷”留给 GPU。这就是它能在 3060 上跑出 30 t/s 的根本原因。1.3 3060 12GB 与 8GB 版本的差距这里必须提醒一下3060 有 12GB 和 8GB 两个版本体验差距非常大。两者的显存带宽都是 360GB/s但容量差 4GB这在跑大模型时就是“能全量塞进显存”和“必须大量 offload 到内存”的分水岭。我实测下来12GB 版本跑 Q3_K_M 量化版本时可以把模型的大部分层都装进显存只有一小部分权重放在内存里速度能稳定在 30 t/s如果是 8GB 版本同样量化下会有将近一半的层跑到内存速度直接掉到 10 t/s 出头而且内存带宽会成为新瓶颈。所以如果你还在选显卡跑模型优先考虑 12GB 版本如果已经是 8GB 版建议用 Q2 量化或者把上下文长度调小能救一点是一点。2. Windows 原生 vs WSL我为什么不再折腾子系统其实两年前的我会毫不犹豫推荐 WSL 2 跑大模型因为当时 Windows 原生环境下的 GPU 加速工具链确实不太成熟。但这次我选择完全在 Windows 原生环境跑不是偷懒而是对比之后的决定。2.1 WSL 2 的痛点IO 慢、内存飘、多一层抽象WSL 2 本质是一个轻量虚拟机虽然它对 NVIDIA GPU 的支持已经不错但还是有几个实际困扰。首先是文件 IO如果模型文件放在 Windows 文件系统下WSL 2 里访问 /mnt/c 的速度明显慢于原生 Linux动不动就卡在加载权重上如果都放在 ext4 虚拟磁盘里Windows 侧的工具又不好直接访问两边同步很别扭。其次是内存占用WSL 2 默认会吃掉大量物理内存作为缓存而且 vmmem 进程的内存占用经常“只涨不降”跑着模型再开个浏览器32GB 内存也会紧张。最后是多一层抽象就意味着多一层排查成本一旦 CUDA 版本对不上、显存报错你得分清楚是 Windows 驱动的问题还是 WSL 里 Linux 内核模块的问题。2.2 Windows 原生推理引擎选型Ollama、LLaMA.cpp、LM Studio现在 Windows 原生跑大模型的方案已经非常成熟主流就是三个方向。第一个是 Ollama它把 LLaMA.cpp 封装的很好提供命令行和 API自动检测 GPU 并加载适合想快速跑起来的人第二个是 LLaMA.cpp 官方编译的 Windows 版可控性最强各种参数都能直接指定适合我这种喜欢盯着细节调参的第三个是 LM Studio带图形界面显存层数、量化版本都能用滑块调对新手最友好。我这次主要用的 Ollama原因有三一是它内部就是 LLaMA.cpp 的 CUDA backend性能不打折二是环境变量可以细粒度控制 GPU 层数方便复现速度数据三是命令简洁一条ollama run就能进入对话不用写一长串参数。如果你更想可视化操作LM Studio 是很好的替代选择。2.3 原生环境的真实表现性能几乎不打折很多人担心 Windows 原生跑 LLaMA.cpp 系推理会比 Linux 慢从我这段时间的体验来看在同样的驱动和 GPU 下两者的性能差距在 5% 以内基本可以忽略。因为推理的瓶颈在显存带宽和权重读取而这些硬件能力完全由 NVIDIA 驱动和 CUDA runtime 决定操作系统层面的调度差异影响很小。真正需要注意的反而是 Windows 的“后台杂音”比如 Windows Update、实时杀毒扫描、Telemetry 服务都有可能在推理过程中抢占 CPU 或内存带宽导致 token 生成速度偶发波动。我跑 30 t/s 的数据是在关掉大部分后台程序之后测的如果你想复现建议先开任务管理器把占用高的进程清一清。3. 实操从零开始在 Windows 上把模型跑起来这一部分我尽量写成“照着做就能跑”的流程。环境、命令、参数都会列清楚但不同机器上的细节可能有差异我会在关键位置标注需要留意的地方。3.1 硬件与系统环境清单先说我这边的配置方便你对照参考CPUAMD Ryzen 7 5700X8 核 16 线程内存32GB DDR4-3200 双通道这个容量很关键后面细讲显卡NVIDIA RTX 3060 12GB驱动版本 551.86系统Windows 11 23H2开启硬件加速 GPU 调度推理引擎Ollama 0.5.x Windows 版内部调用 CUDA runtime如果你的内存只有 16GB跑 Q3_K_M 量化也不是不行但启动阶段加载模型的时候内存会非常吃紧系统可能要频繁写页面文件速度会受影响。我的建议是跑 30B 以上 MoE 模型物理内存至少 32GB否则体验会大打折扣。3.2 一步到位用 Ollama 拉取并运行模型Ollama 在 Windows 上的安装非常简单官网下载安装包双击装完即可它会自动安装 NVIDIA GPU 支持组件。装好后打开 PowerShell 或 CMD执行ollama pull qwen3.6-35b-a3b这个过程会从模型仓库下载对应的 GGUF 量化版本。下载完成后直接用ollama run qwen3.6-35b-a3b就能进入对话界面。首次运行时会加载模型权重如果显存不够Ollama 会自动把一部分层放到内存里这种“自动 offload”策略保证了你至少能跑起来但速度未必是最优。这也是我后面要手动调参数的原因。3.3 细粒度控制设置 GPU 层数和上下文长度Ollama 自动 offload 的默认策略偏保守为了榨出 30 t/s需要手动干预。Windows 下可以用环境变量控制set OLLAMA_GPU_LAYERS41 ollama run qwen3.6-35b-a3bOLLAMA_GPU_LAYERS表示把模型前多少层放进 GPU。Qwen3.6-35B-A3B 这类模型的层数一般在 48 层左右但不同版本有差异你可以在日志里看到“offload XX layers”的提示。我实测把 GPU 层数调到 41也就是让约 85% 的层跑在显卡上剩下的层放内存速度和稳定性达到一个比较理想的平衡点。上下文长度也可以控制默认是 2048我日常用 8192set OLLAMA_CONTEXT_LENGTH8192需要注意的是context 越大KV cache 占用的显存越多对 12GB 显卡来说上到 32768 之后就要明显压缩 GPU 层数否则会显存溢出速度也肉眼可见地下降。3.4 验证速度别只看对话界面的计数器Ollama 对话界面底部会显示 token/s这是最直观的速度反馈。比如我这边跑 Q3_K_M 量化、context 8192、GPU 层数 41 时稳定显示在 28 到 32 t/s 之间取中位数就是 30 t/s。不过对话界面的数字受输入输出长度影响如果想测一个更“干净”的速度可以关掉 Ollama 的 serve 进程用 LLaMA.cpp 自带的性能测试工具llama-bench -m Qwen3.6-35B-A3B-Q3_K_M.gguf -ngl 41 -p 512 -n 128-p 512表示预填充 512 个 token-n 128表示生成 128 个 token。它会分别给出预填充速度和生成速度后者就是我们常说的“每秒生成多少个 token”。这样测出的数据更容易复现也方便和其他人的配置对比。4. 30 t/s 是怎么调出来的量化、显存与参数之间的平衡能跑到 30 t/s不是单纯靠运气而是量化等级、GPU 层数、上下文长度、内存带宽这几件事共同作用的结果。这一章把调参逻辑拆开讲透。4.1 量化选型Q3_K_M 才是 3060 12GB 的“甜点位”模型仓库里通常提供多个量化版本常见的有 Q2_K、Q3_K_M、Q4_K_M、Q5_K_M、Q8_0 等。量化的本质是把模型权重从原来的 2 字节FP16压缩到更低位宽用精度换体积和速度。35B 总参数的模型各量化版本的大致体积如下量化版本权重体积约12GB 显存能否全装我的实测生成速度Q2_K12.5GB勉强需小量 offload38-42 t/sQ3_K_M15GB不能约 3GB 进内存28-32 t/sQ4_K_M19GB不能约 7GB 进内存16-18 t/sQ5_K_M22GB不能大量进内存8-10 t/sQ8_035GB不能大多数层进内存3-5 t/s这里要说明Q2_K 虽然速度最快但模型输出质量下降明显中文长文本经常出现语义漂移我试了几轮之后还是换回了 Q3_K_M。Q3_K_M 的权重体积 15GB放在 12GB 显存里塞不下但只需要把一小部分层 offload 到内存DDR4 双通道的带宽勉强能扛住这部分额外开销所以速度还能保持在 30 t/s 附近。如果你追求又稳又快的日常使用Q3_K_M 是我在 3060 12GB 上的首选。如果你对质量要求更高、能接受慢一点Q4_K_M 可以当备选但 16-18 t/s 的体验已经有点“能感知到卡顿”了。4.2 关键参数逐个说ngl、context、batch、flash attention用 LLaMA.cpp 系推理时有几个参数直接决定速度表现我按重要性排序-ngl或--gpu-layers指定多少层放在 GPU 上。这个参数是速度的核心层数越多需要从内存读取的权重就越少速度越快。我实测从默认的自动分配改成-ngl 41速度直接提升 50% 以上。-c或--context-size上下文长度。KV cache 会随着 context 增大而增加显存占用太长会挤压模型权重的存放空间反而拖慢速度。我用 8192 作为日常值基本够用。-b或--batch-size批处理大小主要影响预填充阶段的速度对生成阶段的 token/s 影响不大。设成 512 是一个比较稳的值太高可能触发显存溢出。--flash-attn开启 Flash Attention 后KV cache 的显存占用和计算量都会下降尤其在长上下文场景下效果明显。3060 支持建议无条件开启。如果你用 Ollama环境变量里虽然没有直接暴露 batch size但OLLAMA_GPU_LAYERS和OLLAMA_CONTEXT_LENGTH已经足够做 90% 的调优。更细的参数还是得回到 LLaMA.cpp 命令行。4.3 为什么 3060 能跑出 30 t/s显存带宽才是天花板这里的“为什么”值得展开说。生成 token 的速度上限基本由“显存带宽 ÷ 每生成一个 token 需要读取的权重字节数”决定而不是 GPU 的算力。Qwen3.6-35B-A3B 激活参数 3B在 Q3 量化下每参数大约对应 0.41 字节3.3 bit 左右。那么每生成一个 token推理框架大约要从显存读取 3B × 0.41 ≈ 1.2GB 的权重。3060 的显存带宽是 360GB/s用这个值除以 1.2GB得到的理论峰值是 300 t/s 左右。但实际达不到理论值因为有效带宽通常只有理论的一半左右还要扣除注意力计算、采样、内存 offload 等开销。这样算下来30 t/s 正好落在一个非常合理的区间里。换句话说这个速度不是“奇迹”而是 MoE 架构把每 token 读取量压到了 1GB 量级之后3060 应该能跑出来的正常水平。4.4 如果速度不达标按这个顺序排查如果你照着配完发现速度只有十几 t/s按照下面的优先级去查基本能解决先看 GPU 层数是否生效。打开任务管理器跑到生成阶段时观察“专用 GPU 内存”是否占到 11GB 以上如果只有 4-5GB说明-ngl没生效或者设置太低。确认没有开启大量 CPU 占用进程。Windows 后台杀毒、Windows Update 都可能抢占内存带宽跑模型前关掉浏览器、微信这类高占用应用。检查 context 是否设得过大。如果改过 32768KV cache 会吃掉大量显存导致模型权重被迫搬到内存速度断崖式下跌。最后看温度。3060 满载 170W 左右如果散热不好GPU 会降频速度也会从 30 掉到 20 出头。用 GPU-Z 盯一下核心频率是否稳定在 1.8GHz 附近。5. 实际使用中的问题与排查实录跑起来只是第一步真正天天用的时候各种小毛病才会冒出来。这一章是我这段时间遇到最多的几个问题的记录直接做成速查表。5.1 显存溢出与“被迫整卡加载”的两难最经典的问题是我把模型调到 Q4 量化后显存直接爆了然后 Ollama 报错退出。解决办法不是盲目降量化而是先看日志里的 offload 比例。我的处理顺序是先固定-ngl 41如果显存溢出就降低-c到 4096再不行才回退到 Q3_K_M。很多人一爆显存就想“把 GPU 层数调少一点”这其实是错误方向——层数少了确实显存占用下降但速度会大幅变慢不如先缩小 KV cache保住 GPU 层数来维持速度。还有一个小技巧Windows 的“硬件加速 GPU 调度”如果开启某些情况下会让显存分配更碎片化反而容易 OOM。如果你反复遇到显存不足但计算量看起来不大可以试着到系统设置里关掉这个开关实测有奇效。5.2 长文本场景KV cache 才是隐形杀手前几秒跑得飞快生成到几百个 token 之后突然变慢这种“中途掉速”十有八九是 KV cache 膨胀 内存 offload 被触发导致的。我试过把 context 拉到 16384 做长文档总结开跑时速度 28 t/s生成到第 800 个 token 时掉到 12 t/s。原因就是 KV cache 越来越大把 GPU 显存吃掉后原来的 GPU 层被挤出去一部分权重读取从显存切到了内存。所以做长文本任务时我建议要么用更小的 context要么主动把-ngl再降两层给 KV cache 留出浮动空间这样速度虽然略低但不会出现中途断崖。5.3 输出质量与速度的矛盾温度、重复惩罚与采样参数本地跑大模型时如果采样参数太保守模型会频繁输出重复内容尤其长文场景。我平时用的采样设置是温度 0.6、top_p 0.9、repeat_penalty 1.1三件套比较稳。如果你追求更高的创造性写故事、头脑风暴可以把温度调到 0.8 以上但做代码解释、结构化数据提取这种任务温度 0.3 甚至 0.2 更合适能明显减少胡编乱造。需要提醒的是降低温度不会明显影响 token/s所以速度吃紧时不需要靠降低温度来“提速”。5.4 常见问题速查表现象可能原因解决办法启动时长时间卡在“load model”大体积 GGUF 从机械硬盘读取把模型放到 NVMe SSD机械硬盘基本没法跑 15GB 以上模型生成速度突然掉一半后台杀毒或 Windows Update 抢资源关闭后台应用查看任务管理器中 System 进程占用提示 CUDA out of memoryKV cache 过大或 GPU 层数过多降低 context降低-ngl切回更小的量化输出开始高频率重复句子采样参数不对调高 repeat_penalty 到 1.15 或 1.2降低温度3060 显存占用只有 5GB 但速度很慢-ngl设置没有被加载确认环境变量是否生效或用 LLaMA.cpp 命令行直接传参温度过高导致降频机箱风道差或硅脂老化限制功耗到 130Wnvidia-smi -pl 130速度损失约 10%但稳定不掉速6. 这波折腾之后我对本地推理的几个判断实测数据聊完了最后分享一点个人观点。第一Windows 原生跑大模型这件事现在已经完全值得认真对待。以前一提本地推理就是 Linux WSL普通用户听到命令行就劝退现在 Ollama 和 LM Studio 的成熟度已经把入门门槛降到了装个软件、点两下、输入一行命令的程度。对绝大多数人来说Windows 原生环境足够用没必要为了跑模型专门装双系统。第二MoE 架构是消费级显卡跑大模型的真正出路。这次 3060 能跑 35B 总参数模型核心不是显卡变强了而是模型架构变聪明了。如果后续 MoE 模型继续扩大专家数量、控制激活参数8GB 显存入门、12GB 显存流畅的日子真的不远了。第三调参的本质是理解资源分配。速度、显存、质量三者不可能同时拉满你要做的不是背参数而是明白模型权重、KV cache、内存 offload 之间的关系。把这几个概念想清楚换任何新模型、新框架你都能很快找到适合自己的配置。我这台机器目前就固定跑 Q3_K_M context 8192 41 层 GPU offload日常当本地知识库助手和代码解释器用稳定用了一周没出过问题。如果你也在 3060 上折腾出了更优的配置欢迎来聊两句这种“甜品卡跑模型”的玩法值得一起把边界再往前提一提。