高显存本地编码模型——依然首选 Qwen 3.6 27B 吗？
摘要
用户分享了使用 Qwen 3.6 27B 进行本地编码任务的经验，并寻求适合拥有 224GB 显存系统的更大模型（100B 以上）的推荐。
相似文章
Qwen 35B-A3B 在 12GB 显存下非常可用。
一位用户在12GB的RTX 3060上对Qwen 35B-A3B（一个35B参数的MoE模型）进行了基准测试，发现12GB显存是运行该模型并支持32k上下文时的实用甜点区，生成速度可达约47 token/秒。
在 8GB 显存和 32GB 内存上运行 Qwen3.6 35b a3b，~190k 上下文
作者分享了一种高性能的本地推理配置，使用支持 TurboQuant 的修改版 llama.cpp，在硬件受限（8GB 显存、32GB 内存）的情况下运行 Qwen3.6 35B A3B，实现了 ~37-51 tok/sec 的生成速度，并支持 ~190k 上下文。
Qwen 3.6 27B 简直是个猛兽
有开发者实测，新的 27B Qwen 3.6 模型在 24GB 显存笔记本上跑得飞起，所有 PySpark/Python 数据转换基准全部通过，再也不用买云算力订阅了。
@DeepTechTR: Qwen 3.6 27B 在16 GB VRAM下速度极快！Pure Quant技术带来的影响——27B模型流畅运行的时代已来临……
Qwen 3.6 27B 在16 GB VRAM上运行快速，得益于'Pure Quant'技术，通过MTP达到40 tokens/s，并支持64k上下文，使得本地AI能在RTX 4060 Ti等消费级GPU上运行。
有人在32GB Mac上使用opencode、claude code或类似工具，通过Qwen3.6-35B-A3B-UD-Q4_K_M实际完成编码工作吗？
我在一台配备32GB RAM的M2 Macbook Pro上运行Qwen3.6-35B-A3B-UD-Q4_K_M。我使用的是相当新版本的llama.cpp和opencode。为了避免llama-server因内存耗尽而直接崩溃，我必须将上下文窗口设置为32768个token。这一点后来被证明很重要。作为一次希望能有些参考价值的测试，我给opcode布置了一个之前Claude Code配合Opus 4.7能够完成的任务。项目不算大，但任务涉及深入挖掘应用程序的前后端，并找出一个连我（作为原始开发者，在AI之前）都没有一眼看出的问题。