在本地运行 MiniMax M3：用 llama.cpp 跨双 GPU 部署，并接入 Pi Coding Agent

MiniMax M3 是一类面向编码、工具调用和长链路 Agent 工作流的开源权重模型。它的几个关键特征很明确：

上下文窗口可达 1M tokens
原生支持文本、图像和视频多模态
使用 MiniMax Sparse Attention，目标是让超长上下文推理更可行

不过，真正在本地部署时，瓶颈不在“模型宣称支持什么”，而在“当前推理引擎实际实现了什么”。如果用 llama.cpp 的实验分支来跑 MiniMax M3，现阶段主要可用的是文本推理，而且注意力实现仍然是 dense attention，不是 Sparse Attention。这会直接影响显存占用、上下文长度和可运行配置。

下面给出一套可直接落地的部署流程：在 2× NVIDIA RTX PRO 6000 上编译支持 CUDA 的 llama.cpp，加载 MiniMax M3 的 GGUF 量化权重，对外暴露 OpenAI 兼容接口和 Web UI，并把这个本地模型接到 Pi Coding Agent。

运行 MiniMax M3 需要什么硬件，哪些配置实际上可行

结论先说：如果目标是本地稳定跑起来，2× NVIDIA RTX PRO 6000、总计 192 GB VRAM，配合 UD-IQ3_XXS 量化，是当前这套方案里最实际的选择。

最低可行配置

运行这套部署，建议满足以下条件：

项目	要求
GPU	`2× NVIDIA RTX PRO 6000`，每张 `96 GB VRAM`，合计 `192 GB VRAM`
存储	至少 `350 GB` 可用磁盘空间
模型量化	`unsloth/MiniMax-M3-GGUF` 中的 `UD-IQ3_XXS`
运行时	支持 CUDA 与多 GPU 的 `llama.cpp`

为什么推荐 `UD-IQ3_XXS`

MiniMax M3 是一个很大的 MoE 模型。推理时不仅要装下权重，还要给运行时开销、prompt 处理和 KV Cache 留空间。

UD-IQ3_XXS 大约 159 GB
这个体积在 192 GB 总显存下仍有余量
更高的 4-bit 量化文件最小也在 208 GB 左右

所以在这套硬件上，不要直接尝试 4-bit MiniMax M3。从文件体积上看就已经超过了可用显存，更不用说运行时开销。

额外边界

还需要明确几个现实限制：

当前方案依赖的是 llama.cpp 的实验性 MiniMax M3 分支
支持文本推理
不包含 MiniMax Sparse Attention
不包含 vision 支持
不包含 MTP/speculative decoding

也就是说，模型本身的能力上限不等于本地部署后的能力上限。

如何准备双 GPU 运行环境

这套流程使用 RunPod PyTorch Pod，直接通过 JupyterLab Terminal 操作，不走 SSH。

Pod 应该怎么配

建议配置如下：

2× NVIDIA RTX PRO 6000 GPUs
模板：最新 RunPod PyTorch
Container Disk: 50 GB
Volume Disk: 300 GB
Expose HTTP Ports: 8910
环境变量：HF_TOKEN，值为你的 Hugging Face Access Token

这里的磁盘划分有明确分工：

50 GB container disk：操作系统、依赖包、临时文件
300 GB volume disk：模型文件、Hugging Face 缓存、构建产物

后续 llama.cpp 服务会监听 8910 端口，对外提供：

Web UI
OpenAI 兼容 API

如果 Pod 暴露了 HTTP 端口，访问地址格式通常是：

https://<POD_ID>-8910.proxy.runpod.net

成本预估

这套 Pod 配置的价格约为：

~$4.23 / hour

第一次编译、下载模型和测试时，建议至少准备：

RunPod credits >= $10
更稳妥是 $15–$20

基础检查与依赖安装

Pod 启动后，打开：

Pod 页面
Connect
JupyterLab
File → New → Terminal

先确认两张 GPU 都可见：

nvidia-smi

预期应该看到两张 NVIDIA RTX PRO 6000，每张显存约 96 GB。

安装构建依赖：

apt-get update && apt-get install -y \
  git \
  cmake \
  build-essential \
  curl

确认 CUDA 可用：

nvcc --version

如果看到 CUDA 12.8 或兼容版本，就可以继续。

为什么必须编译 llama.cpp 的 MiniMax M3 分支

结论很直接：标准版 llama.cpp 不够，需要切到专门的实验分支。

原因是 MiniMax M3 支持还处在实验阶段，所以不能直接依赖常规 release。

拉取并切换分支

在终端中执行：

cd /workspace

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

git fetch origin pull/24523/head:minimax-m3
git checkout minimax-m3

启用 CUDA 编译

接着用 CUDA 打开构建，并编译服务端和命令行工具：

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  -j"$(nproc)" \
  --target llama-server llama-cli

编译完成后，build/bin/ 下会得到两个关键可执行文件：

llama-server：提供 Web 聊天界面和 OpenAI 兼容 API
llama-cli：用于终端直接测试模型

这套构建的限制是什么

这一步最容易被忽略，但其实决定了后续调参策略：

这是实验性实现
只支持文本推理
没有 MiniMax Sparse Attention，而是 dense attention
没有 vision
没有 MTP/speculative decoding

所以虽然模型名义上支持超长上下文，但这套本地构建并不适合一开始就开很大 ctx-size。

模型权重应该怎么下载，放在哪里最合适

结论：下载完整的 UD-IQ3_XXS 文件夹，并保存到 /workspace 这种持久卷目录里。

安装 Hugging Face CLI

先安装最新版 huggingface_hub：

pip install -U huggingface_hub

创建目录并开启更快的下载模式：

mkdir -p /workspace/unsloth

export HF_XET_HIGH_PERFORMANCE=1

下载指定量化版本

执行：

hf download unsloth/MiniMax-M3-GGUF \
  --include "UD-IQ3_XXS/*" \
  --local-dir /workspace/unsloth

这个下载大约：

159 GB
包含 5 个 GGUF 分片文件

因为模型保存在 /workspace，所以 Pod 停止后再重启，文件仍然还在，不需要重复下载。

双 GPU 上应该怎样启动 MiniMax M3，哪些参数不能乱改

结论：先用 8K context 启动，明确使用双卡切分，确认能稳定加载后再逐步增大上下文。

启动前设置可见 GPU

cd /workspace/llama.cpp

export CUDA_VISIBLE_DEVICES=0,1

启动命令

MODEL_FILE="/workspace/unsloth/UD-IQ3_XXS/MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf"

./build/bin/llama-server \
  -m "$MODEL_FILE" \
  --host 0.0.0.0 \
  --port 8910 \
  --ctx-size 8192 \
  --parallel 1 \
  --split-mode layer \
  --tensor-split 1,1 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --jinja \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 40

这些参数分别在解决什么问题

参数	作用
`--host 0.0.0.0`	对外暴露服务
`--port 8910`	Web UI 和 API 统一走这个端口
`--ctx-size 8192`	先从 8K 上下文启动，控制显存风险
`--parallel 1`	保守并发，先保证稳定
`--split-mode layer`	按层切分到多张 GPU
`--tensor-split 1,1`	两张卡平均分配模型张量
`--n-gpu-layers 99`	尽量把模型层都放进 GPU
`--flash-attn on`	开启 Flash Attention
`--jinja`	启用模板渲染支持
`--temp 1.0` `--top-p 0.95` `--top-k 40`	基础采样参数

为什么建议从 `8192` 开始

原因不是模型不支持更大上下文，而是当前 llama.cpp 分支没有 Sparse Attention，实际使用的是 dense attention。上下文一拉大，显存压力会很快上升。

实际建议是：

先用 --ctx-size 8192
稳定后试 --ctx-size 16384
还有余量再试 32768

不要直接跳到 100K 上下文。 在这套实验实现里，很容易 OOM。

如何确认两张 GPU 都在工作

新开一个终端执行：

nvidia-smi

模型加载完成后，两张 GPU 都应该出现明显显存占用。

OpenAI 兼容接口是否真的可用，怎么验证

结论：先查 /v1/models，再打 /v1/chat/completions。只要这两步通了，后面接代理和 IDE 都有基础。

先查看模型 ID

curl -s http://127.0.0.1:8910/v1/models \
  | python3 -c "import sys, json; print(json.load(sys.stdin)['data'][0]['id'])"

预期输出类似：

MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf

再发一个聊天请求

curl http://127.0.0.1:8910/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf",
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that checks whether a number is prime."
      }
    ],
    "temperature": 1.0,
    "top_p": 0.95,
    "max_tokens": 512
  }'

如果服务正常，会返回一段标准的 OpenAI 风格 JSON 响应。

一次实际测试的速度参考

在一组测试里，服务表现大致是：

prompt 处理速度约 357 tokens/s
文本生成速度约 73 tokens/s

返回结果里如果出现：

"finish_reason": "length"

说明输出被 max_tokens: 512 截断了，不是服务异常。

速度会受几项因素影响：

上下文长度
GPU 当前负载
prompt 大小

Web UI 有什么用，适合用来做什么验证

结论：它最适合快速做人类交互测试，确认模型“能聊、能写、能持续输出”。

由于 8910 端口已经暴露，可以在 RunPod 控制台里直接打开对应链接，进入 llama.cpp 自带 Web UI。

这个界面的作用主要有两个：

不用写 curl，直接测试模型行为
快速验证长输出、连续生成、模板效果

在一次编码类测试中，给出“生成一个用于服务机器学习模型的 Python Web 界面”这样的请求，模型生成了比较完整的 FastAPI 方案，包括：

模型切换
JSON 预测请求
CSV 批量上传
WebSocket 实时流
模型注册表
health endpoint
structured logging
tests
Docker 配置

一次较长输出的实测数据大致是：

生成 5,510 tokens
用时 1 分 19 秒
速度约 69 tokens/s

对于一个运行在双 RTX PRO 6000 上的 3-bit 本地量化模型，这个交互速度已经足够做编码任务验证。

如何把本地 MiniMax M3 接到 Pi Coding Agent

结论：Pi 可以直接接 OpenAI 兼容接口，但需要手动写 models.json，并显式声明兼容性限制。

安装 Pi

新开一个终端，保持第一个终端里的 llama-server 持续运行，然后执行：

curl -fsSL https://pi.dev/install.sh | sh

安装过程中如果提示是否安装 Node.js，输入：

安装完成后，如果提示你更新 shell 环境，执行安装器给出的命令，然后重启 shell：

exec bash -l

确认 Pi 已安装：

pi --version

预期可看到版本号，例如：

0.79.10

创建 Pi 配置目录

mkdir -p ~/.pi/agent

写入 provider 配置

cat > ~/.pi/agent/models.json <<'EOF'
{
  "providers": {
    "local-minimax": {
      "baseUrl": "http://127.0.0.1:8910/v1",
      "api": "openai-completions",
      "apiKey": "none",
      "compat": {
        "supportsDeveloperRole": false,
        "supportsReasoningEffort": false,
        "supportsUsageInStreaming": false,
        "maxTokensField": "max_tokens"
      },
      "models": [
        {
          "id": "MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf",
          "name": "MiniMax M3 Local 3-bit",
          "reasoning": false,
          "input": ["text"],
          "contextWindow": 8192,
          "maxTokens": 2048,
          "cost": {
            "input": 0,
            "output": 0,
            "cacheRead": 0,
            "cacheWrite": 0
          }
        }
      ]
    }
  }
}
EOF

为什么这些兼容参数很重要

这部分不是装饰，而是为了避免 Pi 发送本地服务不支持的字段：

supportsDeveloperRole: false
让 Pi 不使用新的 developer role，改走传统 system role
supportsReasoningEffort: false
避免发出本地服务不认识的推理强度字段
supportsUsageInStreaming: false
避免流式统计字段带来的兼容问题
maxTokensField: "max_tokens"
明确使用 llama.cpp 期望的字段名

此外，这里把模型声明为：

text-only
contextWindow: 8192
maxTokens: 2048

这要和启动 llama-server 时的配置保持一致。

Pi 接上本地模型后，怎么做第一次有效测试

结论：先做只读仓库分析，不要一上来就让它改文件。

准备一个项目仓库

cd /workspace

git clone https://github.com/kingabzpro/semantic-web-cache
cd semantic-web-cache

启动 Pi

pi

进入 Pi 后，执行：

/model

搜索 local，然后选择：

MiniMax M3 Local 3-bit

如果配置正确，Pi 会显示本地 provider，并确认当前模型就是刚才配置的 GGUF。

第一次任务建议怎么提

优先给只读任务，例如：

Read the README.md file and explain how this project is structured.

这样 Pi 会先调用终端工具做环境理解，典型行为包括：

ls
read
查看 README.md
检查 .env.example
检查 requirements.txt
查看 notebook 文件

这类任务适合验证三件事：

模型能否理解仓库结构
Agent 能否调用终端工具
本地 OpenAI 兼容接口在多轮交互下是否稳定

一个实际仓库分析案例里，模型能做什么

在一个语义缓存示例仓库中，这种只读分析任务能识别出：

这是一个基于 Olostep 和 Qdrant 的 semantic caching demo
工作流以 notebook 为中心
需要哪些 API 环境变量
cache threshold 和 TTL 配置
项目包含延迟、缓存命中率、credit 节省等评估内容

进一步要求它画一个 ASCII 工作流图，也能给出比较清晰的流程：

用户查询被嵌入
到 Qdrant 中查缓存
判断相似度阈值
命中则直接返回
未命中则发给 Olostep
再把结果写回缓存

这说明在本地双卡 + 3-bit 量化这个级别上，MiniMax M3 已经足够承担仓库理解和基础代码代理任务。

上下文窗口应该怎么调，什么时候该停

结论：按 8K → 16K → 32K 递增测试，不要直接追求超长上下文。

如果你的任务变成：

更大的代码仓库
更多轮对话
更复杂的多步任务

那确实可能需要更大的 ctx-size。方法也很简单：修改 llama-server 启动参数并重启服务。

建议顺序：

8192
16384
32768

如果显存还有余量再继续尝试。核心原则只有一个：当前实现是 dense attention，不是 Sparse Attention。这意味着上下文增长带来的显存成本远高于理想状态。

一旦出现：

启动加载失败
推理过程中 OOM
两张卡显存逼近上限

就应该回退上下文大小，而不是继续堆。

这套方案值不值得跑，本地部署的取舍在哪里

结论很明确：如果目标是做本地私有的编码与 Agent 工作流，MiniMax M3 在这一级硬件上是一个现实可用的平衡点。

它的优势在于：

能跑在 2× RTX PRO 6000 上
有 Web UI
有 OpenAI 兼容 API
能接 Pi 这类 coding agent
生成速度实测在 ~70 tokens/s 量级
仓库探索、README 分析、命令执行辅助、流程图生成都能胜任

但限制也不能忽略：

llama.cpp 支持仍是实验性的
没有 Sparse Attention
没有 vision
上下文窗口不能按模型标称能力去理解
需要比较昂贵的双卡环境

如果拿它和更重型的编码模型相比，这套配置的优势不是绝对性能，而是能以可承受的本地部署成本，获得足够强的 Agent 能力。对于私有代码库、本地 API、浏览器测试和终端代理一体化工作流，这已经是很实用的一档方案。

FAQ

MiniMax M3 的实际参数规模是多少

MiniMax M3 是一个超大规模 MoE 模型，总参数量约为：

428 billion parameters

但推理时每个 token 实际激活的参数大约是：

22 to 23 billion parameters per token

这也是它能通过稀疏机制和量化格式提高可运行性的原因。

MiniMax M3 的开源权重可以直接商用吗

不可以。

当前开放权重使用的是：

non-commercial license

也就是说，商业化产品和企业应用不能直接拿这套开源权重上线。如果是变现产品，应该使用付费 API，或者单独协商商业授权。

MiniMax M3 在编码基准上的表现怎么样

在软件工程和终端代理相关基准上，MiniMax M3 的成绩包括：

59.0% on SWE-Bench Pro
66.0% on Terminal-Bench 2.1

这说明它在编码和 agentic terminal task 上属于第一梯队附近。

如果不本地部署，API 价格大概是多少

标准 API 价格大致为：

输入：$0.60 per million input tokens
输出：$2.40 per million output tokens

虽然支持最高 1M 上下文，但有些 API 提供方会做分层计价，超过 512K 上下文后可能会加价。

关于

关注我获取更多资讯

📢 公众号

💬 个人号