MiniMax M3 自架 GPU 雲部署分析
MiniMax M3 有 229.9B MoE 權重、1M context 和多模態輸出，但要自架就得準備很大的 GPU 記憶體與成本。
MiniMax M3 是一款 229.9B MoE 開源權重模型，能跑 1M token 的多模態工作負載，但自架成本很高。
說真的，這模型很猛。MiniMax M3 在 2026 年 6 月 1 日發表後不久，Spheron 就釋出部署指南。這速度很誇張，也代表大家真的在盯它。
原因很直接。它有 229.9B 總參數，9.8B 每 token 啟用參數，還有 1,048,576 token 的 context。再加上原生圖片和影片理解，這不是一般聊天模型的玩法。
| 指標 | MiniMax M3 | 代表什麼 |
|---|---|---|
| 發表日期 | 2026/06/01 | 很新的 open-weight 模型 |
| 總參數 | 229.9B | 完整權重要放進 VRAM |
| 每 token 啟用參數 | 9.8B | 推理成本比 dense 巨獸低 |
| Context 長度 | 1,048,576 tokens | 可處理 1M token 輸入 |
| SWE-Bench Pro | 59.0% | 軟體工程能力不差 |
M3 不是聊天玩具，是長上下文工作機
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
M3 的定位很清楚。它不是拿來做幾句寒暄的玩具。它是 MiniMax 的 Mixture-of-Experts 模型，裡面有 256 個細粒度 experts。每個 token 只會啟用 9.8B 參數，但整包 229.9B 權重都得留在記憶體附近。
這種設計很有意思。它讓推理成本不會像 dense 巨型模型那樣爆掉，但模型容量還是很大。對做 agentic coding、長文件分析、或多模態研究的人來說，這種取捨很實際。
MiniMax 也公開了 SWE-Bench Pro 的 59.0% 分數。這種 benchmark 比單純 code completion 更接近真實開發情境，因為它看的是模型能不能分步修 bug。
- 229.9B 總參數
- 9.8B 每 token 啟用參數
- 256 個 experts
- 59.0% SWE-Bench Pro
- 1,048,576 token context
1M context 靠的是 MSA，不是魔法
1M context 能成立，核心是 MiniMax Sparse Attention，簡稱 MSA。一般 full attention 的計算量會隨 context 長度快速炸開。到 1M tokens 時，普通 long-context 服務架構幾乎直接卡死。
MiniMax 表示，MSA 在 1M context 下，比 M2 有超過 9 倍 prefill 加速，decode 也超過 15 倍。每 token 計算量大概只有 M2 的 1/20。講白了，這才像能上線的東西，不是 demo 場面話。
“Sparse attention is the key to long-context efficiency.” — Tri Dao, FlashAttention-2 paper
這句話不是專門講 M3，但意思很對。你要拉長 context，又不想把 GPU 成本燒爆，attention 就得變聰明。M3 把這件事做得更完整，還把多模態輸入一起塞進去。
對開發者來說，實際好處很直白。整個 codebase、長聊天紀錄、法務文件、研究筆記，都可以放在同一次 request 裡。少一點切 chunk 的膠水程式，agent loop 也比較好寫。
- MSA prefill 加速：超過 9 倍
- MSA decode 加速：超過 15 倍
- 1M context 的每 token 計算量：約 M2 的 1/20
- Context 長度：1,048,576 tokens
GPU 成本先看記憶體，再看精度
自架 M3，本質上是記憶體問題，接著才是成本問題。因為它是 MoE 模型，你不能只把 active experts 放進 VRAM，剩下的丟 CPU 期待沒事。那樣延遲會很難看。
Spheron 的數字很有參考價值。BF16 需要大約 460 GB VRAM。FP8 會降到約 230 GB。AWQ INT4 則降到約 115 GB，才有機會塞進較小的卡。
但 context 會再吃掉一層記憶體。KV cache 會跟 token 數一起長，就算 MSA 把 attention 計算壓下來也一樣。到了 1M context，FP8 的 KV cache 單獨就大約 120 GB，所以 2x H200 還不夠完整跑滿。
| 精度 | 模型 VRAM | 常見 GPU 配置 | 能跑 1M context？ |
|---|---|---|---|
| BF16 | 約 460 GB | 4x H200 SXM5 或 6x H100 SXM5 | 可以 |
| FP8 | 約 230 GB | 4x H200 SXM5 或 8x H100 SXM5 | 可以 |
| AWQ INT4 | 約 115 GB | 1x H200 SXM5 或 2x H100 SXM5 | 只適合較短 context |
價格也很現實。Spheron 在 2026 年 6 月 12 日的公開報價顯示，2x H200 SXM5 FP8 方案，spot 是每小時 3.64 美元，on-demand 是每小時 9.68 美元。4x H100 SXM5 FP8 則是 spot 5.72 美元，on-demand 15.68 美元。
所以 H200 比較像 FP8 服務的正解。H100 則是在你想要更多卡、又能接受較高時薪時才划算。真正該看的不是卡數，而是你要不要把 context 拉到 1M。
- BF16 模型記憶體：約 460 GB
- FP8 模型記憶體：約 230 GB
- AWQ INT4 模型記憶體：約 115 GB
- 2x H200 spot：3.64 美元/小時
- 4x H100 spot：5.72 美元/小時
vLLM 是最實際的服務路線
vLLM 很適合想快速做出 OpenAI 相容 API 的團隊。Spheron 會選它，不是沒原因。它支援 tensor parallelism、expert parallelism，還能處理 FP8 KV cache，這些都跟 M3 很對味。
部署流程也不複雜。先在 Spheron 開 GPU node，再裝 CUDA 12.4 以上和需要的 Python 套件，接著從 Hugging Face 把模型抓下來，最後用正確的 parallelism 和 cache 參數啟動服務。
但有一個坑要注意。MSA 需要後端明確支援，所以你不能假設隨便一版 vLLM 都能跑。先鎖定支援 M3 的版本，再測 context、吞吐量、KV cache 行為，不然上線後才改就很痛。
如果你已經在用 SGLang，邏輯也差不多。當 context 拉到 128K 以上，服務框架的重要性會下降，GPU 預算才是主角。
這對真的要交付產品的團隊代表什麼
M3 讓 open-weight 模型的討論變得更務實。它把三件常常分開出現的能力合在一起：不錯的 coding 能力、多模態輸入、還有夠大的 context。對 coding agent、文件分析、研究助理這類產品，這組合很有吸引力。
但代價也很直白。你要完整吃到 1M token，代表你買的是多 GPU 基礎設施，不是單卡試玩。如果你的工作量只到 128K 或 256K，經濟性就會好很多，部署壓力也小一截。
我自己的判斷是，多數團隊一開始不會真的用滿 1M。比較可能的路線，是先拿 M3 做 128K 到 256K 的任務，再把完整 context 留給除錯、跨整個 codebase 的推理，或超長文件整理。
如果你正在規劃部署，先問自己一個問題：你要的是多模態長上下文，還是只要一個強一點的 open model？如果兩個都要，M3 值得你算 GPU 帳。若不是，選更小的模型通常更省事，也更省錢。
先別急著上 1M，先算清楚你的場景
MiniMax M3 的價值，不在於它很大而已，而在於它真的能把大 context 跑起來。這對台灣很多做 SaaS、內部知識搜尋、或 code assistant 的團隊，都很有參考性。
但我會很直接地說，1M context 不是每個產品都需要。你如果只是做客服摘要、文件問答、或一般 coding helper，128K 到 256K 通常就夠用了。先把需求切乾淨，再決定要不要付這張 GPU 帳單。
如果你最近剛好在評估自架 LLM，我建議先從 2x H200 或 4x H100 的成本模型開始算。把 token 成本、KV cache、吞吐量和延遲一起列出來，比只看 benchmark 分數有用多了。真的，這才是上線前該做的功課。