🧠选择并调好您的模型
在您的机器上跑哪个本地模型？2026 年 open-weight 模型的全景（尤其是中国的），以及把它们卡进您 RAM 的简单规则。
这是一个不太爱听的真相：不是您选择您的模型，是您的机器选择。 您可以梦想跑地球上最大的 open-weight 巨兽，但如果您只有 32 GB RAM，它永远跑不起来。好消息是，到 2026 年，本地的全景已经变得极好, 前提是瞄准得当。我们先立下决定一切的规则（尺寸匹配），再看目录，最后切入真正的问题：什么时候您的 mini-PC 够用，什么时候 Claude 还是领先。
尺寸匹配的规则（决定一切的那条）
在模型的名字之前，先讲物理。一个模型，就是数十亿个参数（即「权重」），每一个都占内存。心算的公式一行就够：
所需 RAM ≈（参数量 × 每权重字节数）+ 上下文缓存（KV cache）
每权重的字节数取决于精度（讲到量化时再说）。实践中，在 Q4_K_M, 标准格式, 下，按每十亿参数约 0.56 GB算。给系统加 0.5 到 2 GB，如果您用长上下文或多个并行请求，再加 30% 到 50%。
几个 Q4_K_M 下的参照，给您练练眼力：一个 Llama 8B 装进约 6 GB，一个 32B 的稠密（dense）模型约 19 GB，一个 Llama 70B 要 40-43 GB。这是一张随手备查的表，按内存档位划分：
| 可用内存 | 您能跑什么（Q4） | 推荐模型 |
|---|---|---|
| 16 GB | 一个 7-8B 稠密，或一个紧凑的小 MoE | qwen2.5-coder:7b |
| 32 GB | 一个 30B Q4，轻松 ✅ | qwen3-coder:30b |
| 64 GB | 一个 70B Q4/Q5，或 GLM-4.5-Air | 到这儿，本地开始动真格了 |
| 96 GB + | 长上下文的 KV 余量，量化得当的大 MoE | 随您挑 |
| 250 GB + | 那些巨兽（Qwen3-Coder 480B、GLM-4.6、Kimi） | 仅限工作站 |
捷径：让工具替您做尺寸匹配
刚才立下的整条规则（数 GB、掂量量化、认出 MoE），有个开源小工具两秒钟就替您算完：llmfit（MIT 许可，仓库 AlexsJones/llmfit）。它扫描您的机器（RAM、CPU 核心、VRAM、多 GPU）和已装的运行时（Ollama、llama.cpp、LM Studio、MLX、Docker Model Runner），跟一份模型和量化的目录交叉比对，给您一个打过分的排名：哪些装得下、哪些跑得快、该瞄准哪个量化。免得白白拉一个 20 GB 的模型回来。
安装它
用您惯用的包管理器，按您的系统来：
# macOS / Linux（Homebrew）
brew install AlexsJones/llmfit/llmfit
# macOS / Linux（快速脚本）
curl -fsSL https://llmfit.axjns.dev/install.sh | sh
# Windows（Scoop）
scoop install llmfit
# 什么都不长期安装：Docker
docker run ghcr.io/alexsjones/llmfit
跑分析
不带参数，您会得到一个交互式终端界面（外加一个 web 仪表盘，在 http://<机器IP>:8787）。想要纯表格或便于脚本处理的 JSON？选项都在。
llmfit # 交互界面 + web 仪表盘
llmfit --cli # 终端里的经典表格
llmfit recommend --json --use-case coding --limit 3 # 代码场景前 3，输出 JSON
2026 年的模型全景
今年的标志性事实：中国的实验室主导着 open-weight。 两种有用的轮廓浮现出来。巨型 MoE（总参数 ≈1 万亿、约 30B 激活）面向云端或工作站。还有紧凑型 MoE（总约 30B、约 3B 激活），它们才真正能在 mini-PC 上跑。我们关心的就是第二个家族。
以下是面向本地机器的现实选择：
| 模型 | 类型 / 大小 | 干什么 | 您跑得动吗？ |
|---|---|---|---|
| Qwen3-Coder 30B | MoE，30B 总 / 3.3B 激活 | 代码、重构、调试、256K 上下文 | ✅ 32 GB 起, mini-PC 的最佳选择 |
| Qwen2.5-Coder 7B/14B/32B | 稠密 | 自动补全（FIM）、补全 | ✅ 视 RAM 而定（7B 从 16 GB 起） |
| GLM-4.5-Air | MoE，约 106B | 本地能跑的现实版 GLM | ⚠️ 如果您有 64-96 GB |
| Gemma 4 | MoE，约 26B（Google） | 一个诚恳的非中国起点 | ✅ 在一台像样的机器上 |
| GLM-4.6 | 约 357B，MIT 许可证 | 在真实代码上达到 Claude Sonnet 4.x 水平 | ❌ 工作站 / API |
| DeepSeek-V3.2 | MoE + 稀疏注意力 | 顶级「智力」，长上下文极佳 | ❌ 对 mini-PC 太大 |
| Kimi K2.6（Moonshot） | 1000B MoE / 32B 激活 | open-weight 智能体基准之王 | ❌ API / 大工作站 |
在 mini-PC 上首选就是 qwen3-coder:30b，毫不犹豫。后台跑的自动补全，qwen2.5-coder:14b 或 32b 都很完美。而如果您有一台配置不错的机器（64-96 GB），GLM-4.5-Air 就是那个装得下的 GLM。
把量化讲清楚
您看到过像 Q4_K_M 这样的名字。来解码一下。GGUF 是本地模型的文件格式，后缀表示精度：每个权重保留多少比特。比特越少 = 文件越轻 = 装进越少的 RAM。代价是质量略有损失。
| 等级 | 质量 | 何时使用 |
|---|---|---|
Q8_0 | 近乎完美 | 对代码很少值得（太重） |
Q6_K / Q5_K_M | 极佳 | 关键推理，如果您有内存余量 |
Q4_K_M | 非常好 | 事实上的标准, 您的默认选择 |
< Q4 | 可见的退化 | 只在内存逼您时 |
Q4_K_M 大约只有原始 FP16 模型的 28% 重，而损失仅约 2-3%。专门对代码而言，它经得起考验, 升到 Q5 或 Q6 并不会让代码生成有可感知的改善。您只有在被迫时才会降到 Q4 以下，而且您会很快察觉（代码和推理是最先遭殃的）。
在 Ollama 里接上正确的量化
实践中很简单：在 Ollama 里，标签（tag）已经编码了量化。您通过把精度写进名字里来选择它。
按正确的量化拉取模型
标签后面的后缀就是量化。不带后缀的话，Ollama 取一个默认值（通常是 Q4_K_M）。
# 默认值（一般是 Q4_K_M）, 开始用很完美
ollama pull qwen3-coder:30b
# 或者显式的量化，如果您想确保万无一失
ollama pull qwen3-coder:30b-a3b-q4_K_M
把上下文卡到真实需要上
上下文耗 RAM（那个出了名的 KV cache）。默认 OLLAMA_CONTEXT_LENGTH 是 2048，对代码来说低得离谱。但把它调得太高会撑大 RAM，可能把您推进 swap, 这是「Ollama 很慢」的头号原因。把 num_ctx 设到任务真正需要的量，别条件反射地拉满。
说实话：本地还是 Claude？
我们不会给您卖梦。到 2026 年中，本地的状况就在这里，不加滤镜。
对于边界清晰且私密的任务, 短窗口生成、重构、自动补全、定点调试, 本地真的有竞争力。它私密、按使用免费，而且在基准上的差距已经明显收窄（GLM-4.6 紧贴 Claude Sonnet 4.x，Kimi K2.6 在智能体上很硬）。还有一点常被忽略：一个 open-weight 模型在好的框架里（一个配置得当的 OpenCode）表现，比在裸聊天里好得多。
但有两个局限要说清楚：
- 绝对的顶点仍然是 Claude。 Claude Fable 5 在 SWE-bench Verified 上约 ~95%，明显高于 open-weight 的集群（~80%）。
- 最好的开放模型在 mini-PC 上跑不了。 Kimi（1000B）、GLM-5.2、MiniMax M3, 那是 API 或工作站的事。本地能装下的（Qwen3-Coder 30B、GLM-4.5-Air）在长链智能体可靠性和工具使用上低一档。