国产开源 LLM 本地部署 2026 完整指南：从 27B Dense 到 754B MoE 怎么挑硬件

2026 年 4 月，国产开源大模型集中放权重。智谱 GLM-5.1（4 月 7 日，MIT）、阿里 Qwen3.6-35B-A3B（4 月 16 日，Apache 2.0）和 Qwen3.6-27B（4 月 22 日，Apache 2.0）一个月内接连开源，DeepSeek V4 也跟着放出权重。SWE-Bench Pro 上 GLM-5.1 拿到 58.4% 的开源 SOTA，Qwen3.6-27B 以 27B 参数把自家 397B MoE 前辈压了下去。

“国产开源能用了”这句话过去说过很多次，2026 年是第一次能直接拿来跑生产。

但开源不等于免费午餐。GLM-5.1 全精度部署要 1TB 以上显存，Qwen3.6-27B 单卡跑得动但跑得快需要琢磨量化。这篇文章按预算分级拆解，每一档给出实际能买的卡、量化方案、推理框架和延迟数字，帮你判断到底要不要自托管。

TL;DR — 24GB 消费卡能跑 Qwen3.6-27B Q4_K_M（约 18GB 显存占用，25 tok/s）；80GB 单卡可跑 Qwen3.6-27B BF16 或承担 GLM-5.1 AWQ INT4 的一部分；GLM-5.1 全量必须 8×H200 FP8 或 4×H200 AWQ INT4。预算不够 / 调用量不大就走 ofox.ai API，一个 Key 同时调 Qwen3.6、GLM-5.1、Claude、GPT，成本和运维都省一截。

三大国产开源旗舰先过一遍

先把规格摆出来，下面的硬件计算都基于这张表。

Qwen3.6-27B 是 Dense，所有参数都在前向计算里走一遍，部署直观。GLM-5.1 和 DeepSeek V4 都是 MoE：参数总量大但每次推理只激活一小部分专家，显存要装下全部权重，但计算量按激活参数算。后面的硬件清单都是从这一条推出来的。

第一级：消费级 GPU（预算 5K-20K，跑 Qwen3.6-27B Q4_K_M）

这是国产开源模型本地部署最划算的入门档。Qwen3.6-27B 发布第一天就上了 GGUF，Unsloth 和 bartowski 同步放出多档量化文件。

llama.cpp 启动一个 Qwen3.6-27B Q4 服务器三行命令搞定：

huggingface-cli download bartowski/Qwen_Qwen3.6-27B-GGUF Qwen3.6-27B-Q4_K_M.gguf --local-dir ./models
./llama-server -m ./models/Qwen3.6-27B-Q4_K_M.gguf -c 65536 --port 8080 -ngl 99

-ngl 99 表示尽量把所有层卸载到 GPU，24GB 卡能完整装下；16GB 卡把 -ngl 调到 30-40，剩下层走 CPU+RAM。

这档的真正问题不在硬件，而在量化损失。Q4 相对 BF16 有 1-3% 的能力下降，编程任务里能感知到。IDE 补全这种延迟敏感场景可以接受，做严肃 agent 工作流建议至少 Q5_K_M。

想跑 OpenClaw 配置国产模型的可以看 OpenClaw 国内加速 + 国内模型推荐，本地 27B 跑通后接 OpenClaw 当 Coding 后端是不错的省钱路径。

第二级：单卡数据中心 GPU（预算 8 万-25 万，跑 Qwen3.6-27B BF16）

到了 80GB 这档，Qwen3.6-27B 可以完整 BF16 部署，质量等同原版权重。但 GLM-5.1 还是装不下，它要的不是计算力而是显存容量，1 张 80GB 卡只能装大约 1/10 的权重。

vLLM 跑 Qwen3.6-27B BF16 的典型命令：

vllm serve Qwen/Qwen3.6-27B \
  --dtype bfloat16 \
  --max-model-len 131072 \
  --tensor-parallel-size 1 \
  --port 8000

技术上跑得起来，经济账不一定算得过来。一张 H100 租 8 小时大约能跑 800-1200 tok/s，单价折下来比走 ofox.ai API 调 Qwen3.6 还高。日调用量超过 200 万 token、或者数据敏感性要求本地化，单卡 80GB 才值得买。

如果只是想要 Qwen 系列的 API 接入，看 Qwen API 接入指南 一步到位，不用买卡。

第三级：多卡集群（预算 50 万+，GLM-5.1 全量部署）

GLM-5.1 是 754B 总参数的 MoE，全精度 BF16 要 1.5TB 显存。FP8 量化质量损失极小但能砍一半：

vLLM v0.19.0+ 原生支持 GLM-5.1 的 MoE 架构，推荐的启动配置是 tensor parallel + expert parallel 双开：

vllm serve zai-org/GLM-5.1 \
  --tensor-parallel-size 8 \
  --quantization fp8 \
  --enable-expert-parallel \
  --max-model-len 200000 \
  --port 8000

--enable-expert-parallel 是 MoE 模型的关键优化，专家被分布到不同 GPU 上做并行，吞吐量能再涨 30-50%。AWQ INT4 版本对 SWE-Bench Pro 这类编程基准影响 1-3 个点，可以接受；如果做 8 小时长程 agent 任务，建议守 FP8。

这档的预算门槛非常陡。8×H200 服务器整机报价 200-300 万人民币，租云大概一小时 200-400 美元。如果不是大厂内部场景、不是百亿 token 级别的 SaaS，自托管 GLM-5.1 算不过账。

CPU 兜底方案：让 GLM-5.1 在工作站上跑起来

Unsloth 文档 给出了一个意外可行的方案：CPU + 单卡 + 内存换显存。

llama.cpp + MoE 专家卸载（--n-cpu-moe）把不活跃的专家放到 RAM，激活的专家临时调到 GPU。前提是工作站要有足够的 RAM 通道带宽（DDR5 或 HBM3 服务器内存最佳），不然瓶颈在内存搬运而不是计算。

这条路适合一种场景：单人或小团队想验证 GLM-5.1 能力但没集群预算。出 demo、跑选型对比、做 RAG 知识库，3-5 tok/s 慢但能跑，比租 H100 集群每月烧 5 万美元划算得多。

量化怎么选

四档量化的能力损失实测（基于 SWE-Bench Pro 这类编程任务）：

• BF16 / FP16：原版精度，质量基线。Qwen3.6-27B 这一档约 54GB 显存
• FP8：质量损失 <0.5%，H100/H200 SXM5 有原生 tensor core，速度反而比 BF16 快。GLM-5.1 官方推荐
• AWQ INT4 / GPTQ INT4：显存砍到 1/4，质量损失 1-3%。Coding 任务可感知，但日常任务问题不大
• GGUF Q4_K_M：llama.cpp 生态主流，单卡消费级 GPU 首选。质量略劣于 AWQ INT4，但工具链最成熟

简单的话：生产编码用 FP8 或 BF16，开发测试用 AWQ INT4，个人玩用 Q4_K_M。

推理框架对比

生产环境闭眼选 vLLM 没问题。SGLang 在长上下文、结构化 JSON 输出、tool use 场景下吞吐和延迟比 vLLM 略好，但生态稍小。llama.cpp 是个人开发和 homelab 圈的事实标准，新模型几乎都首日有 GGUF。

不想折腾？API 是更划算的默认选项

把上面三档算下来结论很现实：大多数团队都不该自托管国产开源 LLM。原因有三条：

1. GPU 折旧、电费、运维都是真金白银。一张 H100 三年期总持有成本约 25-35 万人民币，按 60% 利用率算每百万 token 成本接近 API 价格
2. 量化和服务端调优是工程活，vLLM 参数、KV cache、batch size、speculative decoding 调一遍要一两周
3. 模型迭代比硬件折旧快。今天部署 Qwen3.6-27B，三个月后 Qwen3.7 一出，量化文件、推理框架配置全要重做

ofox.ai 上 Qwen3.6-27B 走 bailian/qwen3.6-27b 入口，256K 上下文，$0.6/$3.6 per M token；GLM-5.1 走 z-ai/glm-5.1，$1.4/$4.4 per M token。一个 Key 同时调这两个加 Claude、GPT、Gemini，OpenAI SDK 兼容，model 字段一改就能切换。

Python 调用 Qwen3.6-27B 三行：

from openai import OpenAI
client = OpenAI(api_key="sk-xxx", base_url="https://api.ofox.ai/v1")
resp = client.chat.completions.create(
    model="bailian/qwen3.6-27b",
    messages=[{"role": "user", "content": "解释 MoE 架构"}]
)

切 GLM-5.1 只换 model 参数：

resp = client.chat.completions.create(
    model="z-ai/glm-5.1",
    messages=[{"role": "user", "content": "解释 MoE 架构"}]
)

什么场景一定要自托管

不是劝退所有自托管。下面四种场景 API 真的不合适：

1. 数据出境合规问题。金融、医疗、政府场景，数据完全不能走出本地网关
2. 高频小请求。嵌入式场景每秒几百次 4K token 的推理，API 网络往返成本占大头
3. 超大批量离线推理。例如一次跑几亿 token 的数据标注，租 GPU 包月比按 token 计费便宜
4. 二次微调需求。拿到权重做 LoRA 或全参微调，把业务知识注进去

不属于这四种，直接走 ofox.ai 模型广场 调 API 更划算。

一句话决策

国产开源 LLM 到 2026 年第一次能直接拿来跑生产。但硬件门槛从消费卡到 H200 集群跨了三个数量级，先把调用量、延迟要求、数据敏感性、技术储备四件事过一遍，再决定要不要自托管。

想看更深入的能力对比读 Qwen3.6 vs GLM-5.1：国产开源权重对决 或 2026 大模型排行榜与选型指南；想直接接入云端 API 读 GLM-5 API 接入完全指南。