高级 13 分钟Qwen

本地运行 Qwen3.7 Max：开放权重模型中的佼佼者 可自主部署

Qwen3.7 Max 是阿里巴巴迄今最大的开放权重模型：这是一个前沿级混合专家（MoE）模型，旨在与高端专有模型竞争。在本地运行它（qwen3.7 max local）并非面向普通大众的操作——需要强大的硬件和一定的方法。本指南介绍哪些量化方案确实能在每张显卡 24 至 48 GB 的显存中运行、如何将模型分配到多个 GPU 上、可以期待怎样的吞吐量，以及在哪些情况下它能明显胜过云端 API。

作者： Mohamed Meguedmi·更新于 2026-06-03·已在 Windows、macOS 和 Linux 上测试

#为何选择Qwen3.7 Max

在 2026 年底几乎所有公开基准测试中，Qwen3.7 Max 都位居开放权重模型榜首：多步推理、代码、数学、中英文长指令遵循——法语水平也已经完全拿得出手。达到这一水平后，除非需要极高的吞吐量，否则从技术上已没有理由将自己的提示发送给云服务提供商。

该模型采用 Tongyi Qianwen 许可证发布（大部分权重采用 Apache-2.0 许可证）。Instruct、Coder 和 Thinking 变体发布在 Hugging Face 上，也收录于 ollama.com/library。对于拥有配置完善的 AI 工作站的用户而言，它目前是最有实力与 GPT-5 Mini 或 Claude Sonnet 4 竞争的开放权重模型。

i
本指南面向谁
您至少需要一块RTX 4090、一台Mac Studio M5 Ultra，或一套双GPU配置（3090/4090）。如果您只有一块12-16GB显存的显卡，请继续使用Qwen3.6 35B-A3B或Qwen3 32B——Qwen3.7 Max不适用于您。

#模型简介

本地 AI 套件

只需 1 小时，即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档，无需云端。

  • 在线空间，终身可用
  • PDF + 文件
  • 30 天内退款
本地 AI 套件 →或 所有套件终身使用权 — 49 € →
架构
混合专家模型。总参数约 4800 亿，每个 token 激活约 460 亿参数（从 128 个专家中路由选择 8 个）。
原生上下文支持
通过 YaRN 支持 256 k tokens，实验性扩展支持 1 M tokens。绝大多数实际应用场景仍低于 32 k。
Tokenizer
Tiktoken 风格的多语言 BPE，法语分词结果较紧凑（每词约 1.4 个 token，与 GPT-4 相当）。
变体
Qwen3.7-Max-Instruct（通用对话）、-Coder（编程）、-Thinking（类似 DeepSeek R1 的显式推理）。
许可证
主要模型权重采用 Apache-2.0 许可证。允许商业使用和再分发，没有严格的禁止竞争条款。
!
MoE = 全部权重都需驻留内存
即使每个 token 仅激活 46B 参数，全部 480B 参数仍必须保持可访问。路由器会在处理每个 token 时切换所选专家——若要“卸载”未激活的专家，就必然付出灾难性的 I/O 开销。请据此规划所需的总显存。

#硬件要求

显存总量（Q4_K_M）
模型加上 KV 缓存预计需要约 270 GB。这是使用多 GPU 或配备 256 GB 内存的 Mac Studio Ultra 时所瞄准的目标。
最低可行工作站配置
Mac Studio M2 Ultra 192 GB（Q3_K_M，8k 上下文）——唯一无需双 GPU 就能胜任的消费级单机配置。
配置充裕的工作站
4× RTX 4090 24 GB（总计96 GB，Q2_K + offload），或2× RTX 6000 Ada 48 GB，或Mac Studio M3 Ultra或M5 Ultra 256 GB以支持完整的Q4_K_M。
系统 RAM
如果打算将部分专家卸载到系统内存，至少需要 128 GB 系统内存。如果仅使用系统内存加载模型，建议配备 256 GB（速度非常慢，但可以运行）。
磁盘
Q4_K_M约270 GB，FP16约1 TB。必须使用NVMe Gen4 SSD——否则初始加载时间将超过20分钟。
Runtime
2026 年 10 月之后的 llama.cpp 构建版本（支持 MoE 张量并行）、vLLM ≥ 0.7，或 Ollama ≥ 0.6（如果已发布 GGUF 变体）。

#能装入 24–48 GB 内存的量化版本

实际问题是：哪些模型能装得下，又不会让系统出问题？下列内存占用包括模型、用于 8k 上下文的 KV 缓存和运行时开销。这些估算假定您将所有显卡的显存容量相加。

IQ1_M（≈ 110 GB）
可装入 2×48 GB 的显存或 128 GB 的 Mac Studio 内存。代码和较长推理过程的质量有所下降——适合实验，不适合生产使用。
IQ2_XS（≈ 140 GB）
192 GB 内存的 Mac Studio，或 4× RTX 4090（共 96 GB 显存，另将约 40 GB 的模型数据卸载到系统内存）。这是法语通用聊天中第一个称得上像样的档位。
Q3_K_M (≈ 200 GB)
Mac Studio M3 Ultra 或 M5 Ultra，配备 256 GB 内存；或 2× RTX 6000 Ada，显存共 96 GB，搭配 128 GB RAM 用于卸载部分模型。质量与成本之间的良好折中。
Q4_K_M（≈ 270 GB）
质量方面的最佳平衡点。256 GB 内存的 Mac Studio Ultra 在上下文较短时能容纳该模型；否则可用 4 块 48 GB 的 A6000（共 192 GB），并将部分模型卸载到系统内存，或使用 DGX 节点。
Q5_K_M（≈ 330 GB）
仅适用于 H100 80 GB ×4、MI300X 192 GB ×2 或集群。实际使用中，相比 Q4 的提升很有限。
Q8_0（≈ 510 GB）
仅适用于数据中心。到了这个规模，不如在 8 张 H100 上用 vLLM 以张量并行方式提供推理服务。
→
合适的默认选择
如果您的目标是认真使用本地模型，就选择Q4_K_M量化，并接受为足够的总显存容量投入资金。低于Q3的量化一旦用于简单聊天之外的任务，就会出现明显的能力退步，典型例子是生成长代码或遵循包含多项约束的指令。

#安装

根据您的硬件，有三种选择：Ollama 简单易用，llama.cpp 便于掌控，vLLM 用于为多个用户提供服务。

#路径 1：Ollama (Mac Studio Ultra)

在 Mac Studio Ultra 上，Ollama 会自动管理统一内存。守护进程在 http://localhost:11434 上监听。

终端
# Vérifier qu'Ollama est à jour
ollama --version

# Télécharger la variante adaptée
ollama pull qwen3.7-max:q3_K_M

# Premier lancement (chargement long ~3 min)
ollama run qwen3.7-max:q3_K_M

加载过程中，请在另一个终端监控ollama ps。SIZE列应显示预期大小（Q3_K_M约为200 GB）。

#方案 2：llama.cpp（多块 NVIDIA GPU）

从 Hugging Face 下载 Q4_K_M 格式的 GGUF 模型（搜索：Qwen3.7-Max-Instruct-GGUF，由 Qwen 团队或 bartowski 发布）。下载大小为 270 GB，请预留足够的带宽。

llama.cpp 张量并行服务器
./llama-server \
  -m ./models/Qwen3.7-Max-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  -c 16384 \
  --tensor-split 24,24,24,24 \
  --main-gpu 0 \
  --flash-attn \
  --cache-type-k q8_0 --cache-type-v q8_0
--tensor-split 24,24,24,24
将模型层平均分配到 4 个 GPU 上。请根据每张显卡的可用显存容量（GB）调整，例如使用 2 个 GPU 时可设为 24,24。
--cache-type-k q8_0
量化 KV-cache，释放约 30% 的 VRAM，质量损失可忽略不计。
--flash-attn
对于这种参数规模，上下文长度超过 8k 时，这项设置必不可少。
-c 16384
16 k 的上下文长度是一个不错的折中选择。对于 480B 模型，提升至 32 k 会额外占用数 GB 内存。

#路径 3：vLLM（生产环境，多用户）

若服务于团队，vLLM 通过张量并行更高效地利用 PCIe 带宽，提供显著更高的批量吞吐量。

vLLM 启动
vllm serve Qwen/Qwen3.7-Max-Instruct-AWQ \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --quantization awq \
  --gpu-memory-utilization 0.92 \
  --enable-expert-parallel
i
AWQ与GGUF对比
vLLM 更适合使用针对 NVIDIA GPU 优化的 AWQ 或 GPTQ 量化格式。对于 CPU、Mac 和异构硬件，GGUF 仍是首选。对于单台仅使用 NVIDIA GPU 的机器，在批处理吞吐量方面，vLLM 中的 AWQ 4 位量化优于 llama.cpp 中的 GGUF Q4_K_M，吞吐量可达到后者的 2 至 3 倍，具体取决于负载。

#多 GPU 分配

根据您的硬件和负载情况，提供三种不同的策略。

  1. 01
    按层拆分（llama.cpp 的默认方式）
    每个 GPU 分配到一组连续的模型层。这种方式简单，支持不同型号的 GPU 混用（例如：3090 + 4090）。瓶颈在于：同一时刻只有一个 GPU 进行计算，其他 GPU 都在等待。吞吐量受最慢的显卡限制。
  2. 02
    张量并行（vLLM、较新版本的 llama.cpp）
    每一层都在所有GPU之间水平切分，各GPU并行计算。需要足够的PCIe带宽（Gen4 x16或NVLink）以及同构显卡。在4张GPU上，吞吐量为逐层切分方式的1.8至2.5倍。
  3. 03
    专家并行（专为MoE设计）
    将专家分配到多个 GPU 上。对于在 4 块显卡上运行、包含 128 个专家的 Qwen3.7 Max，每个 GPU 负责 32 个专家。这能减少每块显卡的显存占用，但每个 token 都会激活多个 GPU 上的专家——如果使用 PCIe Gen5 或 NVLink，这是一个不错的选择。
→
PCIe 在这里确实很重要
对于这种规模的 MoE，token 在专家之间的路由会持续产生 GPU 间通信流量。如果消费级主板的第二个插槽只有 PCIe Gen4 x4，吞吐量就会降低 30% 至 50%。如果搭建四 GPU 配置，请选择提供完整 PCIe 通道的 ThreadRipper 或 Xeon 整机平台。
检查模型在多个 GPU 上的分配情况
# Sous Linux, surveille la conso VRAM en direct
watch -n 1 nvidia-smi

# Avec llama.cpp, vérifie que tous les GPU travaillent
nvidia-smi dmon -s u -c 30

#预期的令牌处理速度（tokens/sec）

测试采用 Q4_K_M 量化（另有说明的除外），上下文长度为 4k，使用短提示词，生成 512 个 token，批次大小为 1。吞吐量随上下文长度增加而呈对数下降——超过 16k 个 token 后，提示词评估（prompt eval）阶段的耗时会急剧增加。

Mac Studio M3 Ultra 或 M5 Ultra 256 GB（Q3_K_M）
≈ 18–24 个标记/秒生成速度。提示词评估阶段仍保持稳定（约600 个标记/秒）。适合持续单独使用，安静运行 24/7。
Mac Studio M2 Ultra 192 GB (IQ2_XS)
≈ 22–28 tok/s，质量下降。适合测试，不适合生产使用。
2× RTX 6000 Ada 48 GB（Q3_K_M，层分割）
≈ 28–35 tok/s。适合专业工作站的优质选项。
4× RTX 4090 24 GB（Q4_K_M，llama.cpp张量并行）
在聊天模式下约为每秒35到45个token，批处理模式（batch=4）下为每秒80到120个token。在自制配置中实现了最佳的性能/价格比。
4× RTX 4090（vLLM AWQ 张量并行）
单人聊天约 50–65 个 token/秒，大批次处理的总吞吐量可达 300 个 token/秒以上。为团队提供服务时优先推荐。
2× H100 80 GB (Q4_K_M, NVLink)
聊天时约为每秒 75–90 个 token。面向专业市场，但对于这类模型，NVLink 能带来根本性的改变。
i
这些数字并未体现的细节
对于这种规模的 MoE 模型，在 32k 上下文下，首个 token 的生成延迟可能达到 8 到 15 秒。对于 RAG 或长提示，请缓存提示前缀（使用 llama.cpp 的 --prompt-cache 选项或 vLLM 的前缀缓存功能）——这样才能让使用体验变得可以接受。

#前沿开放权重模型 vs 云端模型

在性能相当的情况下，为何要本地运行 Qwen3.7 Max 而不选择付费 API？

真正的隐私保护
提示词绝不会离开您的网络。对于律师、医疗部门和人力资源团队而言，这是不可妥协的要求——任何云端“零数据保留”政策都无法与物理隔离相提并论。
零边际成本
硬件投资收回成本后，每个 token 都是免费的。对于高强度工作负载（合成数据集生成、批量分析），本地部署的投资回报率会在几个月内超过云端方案。
深度定制能力
您可以进行微调、修改默认系统提示词、接入自制工具，以及截获 logprobs。没有任何前沿模型 API 能提供这些功能。
不依赖供应商
没有配额，没有请求频率限制，也不会有模型在下一次价格调整时消失。模型会保留在您的磁盘上。
可预测的延迟
没有服务器拥堵，也不会在向客户演示的过程中出现“the model is overloaded”。
!
云端仍然领先的方面
对于偶尔使用、要求极低延迟的交互场景，或每秒需要处理数百次请求的场景，云端方案仍更经济。本地部署的 Qwen3.7 Max 擅长处理持续的批量负载，而非偶发的负载高峰——这与自建服务器和 SaaS 之间的取舍逻辑相同。

#故障排除

在四块 4090 上加载时出现 OOM 错误
检查 --tensor-split 各项之和是否确实对应实际可用的显存容量（而非显示的显存容量）。每张显卡预留 1–2 GB 的余量，用于 CUDA 额外开销。
低于 10 个 token/秒的吞吐量
很可能是 GPU 显存不足，部分数据转移到了系统内存。nvidia-smi 会显示显存已占用 100%，而 GPU 利用率最高只有 30%。请降低量化精度，或增加显存。
首令牌延迟 > 30秒
提示词评估阶段已饱和。请启用--flash-attn，对KV缓存进行量化，并将num_ctx缩减至严格必要值。如果可能，对请求进行批处理。
质量远低于基准测试表现
请确认您使用的是 Instruct 版本（而非 Base 版本），已应用聊天模板（Ollama 会自动应用，llama.cpp 则需要 --chat-template），且量化级别没有降到 Q3 以下。
运行数小时后崩溃
通常存在过热问题：4个GPU负载达到100%会加热机箱。请检查结温，调整风扇曲线，降低电压50至100mV。参见散热指南。
首次提示响应极慢
模型从SSD加载——270 GB大小需2至5分钟。只要模型保留在内存中，后续提示将即时响应。

#深入了解

运行 Qwen3.7 Max 需要相当大的硬件投入。以下相关指南可帮助您在购买前确定合适的硬件配置：

使用 llama.cpp 配置多 GPU
将大型模型分配到 2 或 4 张 NVIDIA GPU 上的实用指南，以及 PCIe 和 NVLink 的常见陷阱。
在 Mac Studio (M2/M3/M4 Ultra, 64–512 GB) 上运行哪个 LLM？
比较在运行这一级别的模型时，Apple 统一内存与 NVIDIA 多 GPU 配置各自能实现什么。
在生产环境中部署 vLLM
若 Qwen3.7 Max 需要同时服务多个用户，采用张量并行的 vLLM 是合适的组件。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。