本地模型推理（二）：五个开源模型的本地部署方案

Posted on 2026-04-09 :: Source Code :: local llm

zai-org/GLM-5.1 gemma-4-31b glm-4.7-flash Qwen3.5-397B-A17B-GGUF Qwen/Qwen3-Coder-Next MiniMax-M2.5 Llama 4

写在前面

这篇文章我专门用 grok-search 查了一轮，截至 2026-04-09，把下面 5 个模型的本地部署路径整理一下：

zai-org/GLM-5.1
google/gemma-4-31B
MiniMaxAI/MiniMax-M2.5
Qwen/Qwen3.5-397B-A17B
Qwen/Qwen3-Coder-Next

我主要关心三件事：

官方推荐用什么后端部署
本地怎么起服务
对硬件到底友不友好

这里先说明一个很容易踩坑的点：

MoE 模型的“激活参数”影响算力和吞吐，但“总参数”依然决定你要存下多少权重。

也就是说，A17B、A3B 这种命名看起来很美好，不代表它们能像 17B / 3B 的 dense 模型一样轻松塞进一张消费级显卡里。

先给结论

模型	模型形态	官方/主流本地后端	我给的部署结论
`GLM-5.1`	744B-A40B MoE	`vLLM`、`SGLang`、`xLLM`、`KTransformers`	更像机房级/实验室级部署，不适合普通个人工作站
`Gemma 4 31B`	30.7B dense，多模态	`Transformers`、`vLLM`、`SGLang`、`llama.cpp`、`Ollama`、`MLX`	这 5 个里最容易真正落地到个人机器
`MiniMax-M2.5`	230B-A10B MoE	`vLLM`、`SGLang`、`Transformers`	官方就是冲多卡服务器去的，单机本地不现实
`Qwen3.5-397B-A17B`	397B-A17B MoE，多模态	`Transformers`、`vLLM`、`SGLang`、`llama.cpp`、`MLX`	能本地，但前提是你说的“本地”是 8 卡级别
`Qwen3-Coder-Next`	80B-A3B MoE，代码模型	`Transformers`、`vLLM`、`SGLang`、`llama.cpp(GGUF)`	最适合做本地 coding agent 的一档

如果只从“真能在个人机器上用起来”这个角度看，我的排序是：

Gemma 4 31B
Qwen3-Coder-Next
MiniMax-M2.5 的社区量化版
Qwen3.5-397B-A17B
GLM-5.1

我这里的硬件判断口径

为了避免把“模型榜单”写成“显卡许愿单”，先把口径写清楚。

1. 权重体积的粗略算法

BF16 / FP16：约 2 bytes / 参数
FP8 / INT8：约 1 byte / 参数
4-bit：约 0.5 bytes / 参数

然后我会再额外预留一部分给：

KV cache
runtime buffer
CUDA / 框架开销
长上下文的额外内存

所以文里的“能跑”通常只是最低可行，不等于“跑得舒服”。

2. 长上下文特别吃内存

这些模型很多都在打 128K、196K、256K 甚至 1M 上下文。

真要本地跑，上下文长度往往比模型本体更容易把你顶爆显存。所以我的建议通常会分成两档：

实验 / 自用：先把 context 收到 16K ~ 64K
生产 / 多用户并发：再去考虑满血长上下文

1. GLM-5.1

模型情况

官方仓库：zai-org/GLM-5
官方博客：GLM-5.1
权重页：zai-org/GLM-5.1
规格：744B-A40B

GLM-5 官方 README 里写得很直接：GLM-5.1 和 GLM-5 都是 744B-A40B，同时放出了 BF16 和 FP8。

官方支持的本地后端

官方仓库明确给了这几个后端：

vLLM
SGLang
xLLM
KTransformers

其中 vLLM 和 SGLang 是主线方案，Ascend NPU 还单独给了 ascend.md。

代表性部署方式

vLLM 官方 recipe 直接给了 GLM-5.1-FP8 的示例：

vllm serve zai-org/GLM-5.1-FP8 \
  --tensor-parallel-size 8 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --served-model-name glm-5.1-fp8

SGLang 官方仓库里的示例也是同一个思路：

SGLANG_ENABLE_SPEC_V2=1 sglang serve \
  --model-path zai-org/GLM-5.1-FP8 \
  --tp-size 8 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --served-model-name glm-5.1-fp8

硬件判断

这部分官方信息已经足够说明问题了：

vLLM 官方 recipe 明写的示例硬件是 8x H200 / H20，141GB x 8
BF16 权重按参数量估算大约在 1.5TB 级别
就算换成 FP8，权重本体也还是 700GB+ 级别

所以 GLM-5.1 的现实判断很简单：

适合：8 卡以上服务器、实验室、企业集群、NPU 环境
不适合：单卡消费级、普通家用工作站、Mac mini 这类设备

如果只是想“研究一下能不能离线跑”，社区量化版也许能让它在超大内存机器上勉强起来，但这已经不是我理解的“实用本地部署”了。

2. Gemma 4 31B

模型情况

官方文档：Gemma docs
模型卡：Gemma 4 model card
权重页：google/gemma-4-31B
规格：30.7B dense，支持图文输入，256K context

Gemma 4 系列有 dense 和 MoE 两条线，31B 这颗是 dense，因此它的部署判断反而简单很多。

官方/主流本地后端

Gemma 4 的生态是这几颗里最完整的一档：

Transformers
vLLM
SGLang
llama.cpp
Ollama
MLX

Google 官方文档里明确说可以直接用最新版 Transformers 起步，而社区生态又很快把 GGUF、Ollama、MLX 都补齐了。

最简单的本地起步

官方文档给的 Transformers 写法很直接：

from transformers import AutoProcessor, AutoModelForCausalLM

MODEL_ID = "google/gemma-4-31B-it"
processor = AutoProcessor.from_pretrained(MODEL_ID)
model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    dtype="auto",
    device_map="auto",
)

如果你想直接变成 OpenAI 兼容服务，更建议上 vLLM / SGLang；如果你更在意“本地桌面机真能跑”，那就直接看 GGUF、Ollama、MLX。

硬件情况

Gemma 官方文档给出了很清楚的推理内存参考：

精度	大致内存需求
BF16	`58.3 GB`
8-bit	`30.4 GB`
4-bit	`17.4 GB`

所以它的本地落地范围非常清晰：

4-bit：单张 24GB 显卡、32GB 以上统一内存的 Mac、或者 16GB VRAM + RAM offload 都有机会
8-bit：更适合 48GB 级别显卡 / 64GB+ 统一内存
BF16：更像 80GB 级别卡或双卡环境

这也是为什么我会把 Gemma 4 31B 放在“最适合认真做本地部署”的第一梯队。

3. MiniMax-M2.5

模型情况

官方仓库：MiniMax-AI/MiniMax-M2.5
权重页：MiniMaxAI/MiniMax-M2.5
规格：约 230B 总参数，约 10B 激活参数，196K 单序列 context

MiniMax 这次比较厚道的一点是：官方把部署文档写得很实，不是只给一个模型卡就结束了。

官方支持的本地后端

官方仓库直接给了三份部署文档：

我个人会这么分：

Transformers：只适合验证模型能不能起
vLLM：更适合正式服务
SGLang：也很适合正式服务，尤其 agent / structured generation 场景

代表性部署命令

官方 vLLM 的 4 卡命令：

SAFETENSORS_FAST_GPU=1 vllm serve \
  MiniMaxAI/MiniMax-M2.5 --trust-remote-code \
  --tensor-parallel-size 4 \
  --enable-auto-tool-choice \
  --tool-call-parser minimax_m2 \
  --reasoning-parser minimax_m2_append_think

官方 SGLang 的 4 卡命令：

python -m sglang.launch_server \
  --model-path MiniMaxAI/MiniMax-M2.5 \
  --tp-size 4 \
  --tool-call-parser minimax-m2 \
  --reasoning-parser minimax-append-think \
  --trust-remote-code \
  --mem-fraction-static 0.85

硬件情况

这部分官方说得非常具体：

权重需求：220GB
KV Cache：每 100 万 tokens 额外约 240GB
官方建议：
- 96GB x 4 GPU：总 KV cache 大约可到 400K
- 144GB x 8 GPU：总 KV cache 可到 3M

这意味着：

MiniMax-M2.5 不是给 4090 / 5090 单卡用户准备的
哪怕你有多卡，也更像是 4x 96GB 起步的工作站或服务器模型
如果只是个人折腾，只能走社区量化版、GGUF、MLX 之类路径，但那已经不是官方主线方案

一句话总结：它能本地，但不是“普通人本地”。

4. Qwen3.5-397B-A17B

模型情况

官方仓库：QwenLM/Qwen3.5
官方博客：Qwen3.5
权重页：Qwen/Qwen3.5-397B-A17B
规格：397B-A17B，原生多模态，262K context，可扩展到更长

Qwen3.5 官方仓库里写得很清楚，2026-02-16 首发就是这颗 397B-A17B。

官方/主流本地后端

Qwen 团队在总仓里明确写了：

Transformers
llama.cpp
MLX
SGLang
vLLM

而对这颗旗舰模型，官方又额外放出了：

FP8
GPTQ-Int4

所以它的实际部署逻辑是：

想保性能：vLLM / SGLang
想保“能在自己机器上试起来”：优先看量化版

部署思路

Qwen3.5 总仓给的是通用示例，小规格模型默认 tp=4。但针对 397B-A17B 这颗旗舰版，官方模型页和 grok-search 检索到的维护者示例都更偏向 tp=8：

vllm serve Qwen/Qwen3.5-397B-A17B-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --reasoning-parser qwen3

如果走 GPTQ-Int4 / SGLang，也是同一类思路：

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-397B-A17B-GPTQ-Int4 \
  --tp-size 8 \
  --context-length 262144 \
  --reasoning-parser qwen3

硬件判断

这一颗的难点和 MiniMax-M2.5、GLM-5.1 类似，都是 MoE 看起来激活参数不大，但总权重仍然巨大。

按参数量估算：

BF16：大约 794GB 权重量级
FP8：大约 397GB 权重量级
Int4 / 4-bit：大约 200GB 权重量级

所以更靠谱的判断是：

FP8 / 原生服务：面向 8 卡级别部署
Int4：也依然需要很夸张的总显存或总内存，比较像多卡工作站实验
单卡 / 普通双卡：不现实

如果你的目标是“我想在家里自己 host 一个很强的 Qwen”，那我会建议直接往 Qwen3-Coder-Next 或更小的 Qwen3.5 子型号看，而不是死磕这颗旗舰版。

5. Qwen3-Coder-Next

模型情况

官方仓库：QwenLM/Qwen3-Coder
权重页：Qwen/Qwen3-Coder-Next
规格：基于 Qwen3-Next-80B-A3B-Base，256K context，面向 coding agent

这颗模型我觉得特别适合做“个人电脑上的 coding agent 主力模型”，原因就在于它是典型的 总参数不小，但激活参数很克制 的路线。

官方支持的本地后端

Qwen 官方资料和模型页里比较明确的几条线是：

Transformers
vLLM
SGLang
llama.cpp(GGUF)

并且官方仓库还专门强调了：

Qwen3-Coder-Next-FP8
Qwen3-Coder-Next-GGUF

这意味着它从一开始就不是“只给机房跑”的模型，而是认真考虑过本地开发者怎么用。

两种推荐部署路线

路线 A：做本地 API 服务

如果你想接 OpenCode、Roo Code、Claude Code 风格的 agent 工具链，那就直接走 vLLM / SGLang：

vllm serve Qwen/Qwen3-Coder-Next \
  --port 8000 \
  --tensor-parallel-size 2 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

或者：

python -m sglang.launch_server \
  --model Qwen/Qwen3-Coder-Next \
  --port 30000 \
  --tp-size 2 \
  --tool-call-parser qwen3_coder

路线 B：做个人电脑离线 coding 模型

如果你就想自己机器上长期挂着跑，优先看 GGUF + llama.cpp：

./llama-cli \
  -m Qwen3-Coder-Next-Q5_K_M.gguf \
  --jinja \
  -ngl 99 \
  -fa on \
  -c 40960

硬件判断

根据 grok-search 检索到的官方 GGUF 模型页摘要，Qwen3-Coder-Next 的几档量化大致是：

量化	大致体积
`Q4_K_M`	`48.4GB`
`Q5_K_M`	`56.7GB`
`Q6_K`	`65.5GB`
`Q8_0`	`84.8GB`

所以它的本地部署非常现实：

Mac 64GB / 96GB / 128GB 统一内存：很适合
单张 24GB 显卡 + 大内存 RAM offload：可以尝试
48GB 级别显卡：体验会明显更好
256K context：本地建议别一上来就拉满，先用 32K 或 64K

如果你的目标是：

本地代码补全
本地 agent
本地仓库问答
本地 terminal agent

那 Qwen3-Coder-Next 是这次 5 个模型里我最看好的一个。

最后给一版选型建议

1. 只有单卡消费级显卡

优先考虑：

Gemma 4 31B 的 4-bit / 8-bit 版本
Qwen3-Coder-Next 的 GGUF 版本

不建议碰：

GLM-5.1
MiniMax-M2.5
Qwen3.5-397B-A17B

2. 你是 Mac Studio / Mac mini 高统一内存用户

优先考虑：

Gemma 4 31B
Qwen3-Coder-Next

如果你是 128GB+ 统一内存并且愿意接受社区量化：

可以研究 MiniMax-M2.5 的量化版

3. 你有多卡工作站或服务器

优先考虑：

MiniMax-M2.5
Qwen3.5-397B-A17B
GLM-5.1

其中：

想做工程 agent：GLM-5.1
想做综合 agent / office / search：MiniMax-M2.5
想做 Qwen 体系的旗舰多模态：Qwen3.5-397B-A17B

我自己的结论

如果我要真的在自己机器上长期部署，而不是只做一次 benchmark，我会这样选：

通用本地大模型：Gemma 4 31B
本地 coding agent：Qwen3-Coder-Next
多卡服务器旗舰：MiniMax-M2.5
更大规模旗舰实验：Qwen3.5-397B-A17B
机房级大工程模型：GLM-5.1

一句话概括就是：

Gemma 4 31B 是最均衡的本地选手
Qwen3-Coder-Next 是最像“个人开发者能长期用”的代码模型
MiniMax-M2.5 / Qwen3.5-397B-A17B / GLM-5.1 都更像“强，但得有机器”