Mistral 3 開源家族登場：675B MoE 加三個小模型，Apache 2.0 但跑得起來才算 open

重點一：Mistral 在 2026 年 5 月發布 Mistral 3 開源模型家族，包含 Mistral Large 3（675B sparse MoE）與三款 Ministral 3 小模型（14B / 8B / 3B），全部以 Apache 2.0 釋出。

重點二：模型同時上 Hugging Face、Amazon Bedrock、Azure Foundry、IBM WatsonX、OpenRouter、Fireworks、Together AI、Modal、Unsloth AI 等 10 多條通路，NVIDIA NIM 與 AWS SageMaker 標為「即將推出」。

重點三：這次更新的訊號超過「又一個開源模型」。Mistral 把 license、serving stack、雲端通路、邊緣模型放在同一則公告，意思是「open」在每一層的承諾、成本、責任都不一樣——下載前必須先分層問清楚。

---

Mistral 於 2026 年 5 月發布 Mistral 3 開源模型家族，一次給出大、中、小四種尺寸：旗艦的 Mistral Large 3 是 675B total parameters、41B active parameters 的 sparse mixture-of-experts，使用 3000 張 NVIDIA H200 訓練；同時推出 Ministral 3 14B、8B、3B 三款 dense 模型，瞄準邊緣裝置與本地部署。全家族以 Apache 2.0 釋出，base、instruction-tuned、reasoning 版本陸續到位。

但這次公告的焦點超過「又一組開源權重」。Mistral 同時把 NVIDIA、vLLM、Red Hat、TensorRT-LLM、SGLang 的 serving 合作、十多條雲端與第三方 inference 通路、邊緣模型部署選項放進同一則公告。

換句話說：Mistral 3 把「open」拆成法律、模型、推論、通路、維運五層各自獨立的問題。權重可以下載，但每一層的成本與責任，要各自結算。

---

Mistral 3 是兩個家族：Large 3 跑 frontier，Ministral 3 跑邊緣

Mistral 3 一次給了兩條完全不同的部署路徑，採購團隊很容易把它們看成「同一個家族的大小尺寸」——但其實它們解決的是不同焦慮。

Mistral Large 3 解決的是這個焦慮：「我想要接近 frontier 的能力，但不想被 closed model 鎖住。」Mistral 表示 Large 3 是 675B total parameters、41B active parameters 的 sparse MoE，base 與 instruction-tuned 版本同步釋出，reasoning 版本後續推出。Mistral 也表示，在 LMArena OSS non-reasoning 類別中排名第二——這個排名應視為 Mistral 引用的定位，不該直接當成獨立 benchmark 結論。

Ministral 3 解決的是另一個焦慮：「我要在小硬體、邊緣裝置、本地環境上跑模型，可控成本與資料邊界。」14B、8B、3B 三個尺寸都有 base、instruct、reasoning variants，並支援 image understanding，全部 Apache 2.0。

兩條路徑的買單邏輯很不同：

採購問題	Mistral Large 3 路線	Ministral 3 路線
解決的焦慮	Frontier capability + 不要 lock-in	Local / edge + 可控成本
適用硬體	多卡 GPU 叢集 + MoE serving 優化	Jetson、RTX laptop、PC、小型 on-prem
主要對手	GPT-4 級 closed model	Phi、Llama 小模型、Gemma
採購重點	自己 serve 還是叫雲端／inference provider	部署是否能進 device、能力邊界是否能接受
風險	MoE serving 沒人跑得起來、benchmark 變成採購結論	小模型能力被高估

兩邊買的責任、要承擔的工程、能避開的 lock-in，每樣都不一樣。混搭也常見——用 Ministral 跑前端 routing 與快速分類、把難題 escalate 到 Large 3。

---

Apache 2.0 寫了什麼？又沒寫什麼？

Apache 2.0 在這次公告裡扛了大半重量。對開發者，它的綠燈很實在：權重可下載、可商用、可修改、可衍生模型再分發，不像某些研究授權會在商用或衍生上留灰區。

但法律的 open 只解決一件事——法律上能不能用。它不規範下面這些事：

• 資料如何餵進去：合規、隱私、敏感資料是內部政策題
• 輸出責任歸誰：模型輸出造成的損失、誤導、版權問題仍要看你的責任條款
• 稽核與紀錄：誰使用、何時使用、輸入輸出留存——授權沒講
• 資料隔離與權限：哪些員工可以叫模型、哪些不行——授權沒講
• 修改後的安全責任：你 fine-tune 過的 Mistral 3 出問題，授權方不負責

對台灣企業要把 Mistral 3 放進產品線，這些政策題仍要回答。Apache 2.0 只是起點，後面還有資料、權限、稽核與責任邊界。

---

為什麼 Mistral 同時宣布 NVIDIA / vLLM / Red Hat 合作？

公告裡有一整段在講 serving 合作：vLLM、Red Hat、NVIDIA TensorRT-LLM、SGLang、NVFP4 checkpoint、Blackwell attention 與 MoE kernels、prefill/decode disaggregated serving、speculative decoding。

技術術語密度很高，但它們指向同一件事：權重「可以下載」不等於「可以服務化」。

Mistral Large 3 是 sparse MoE——41B active parameters 聽起來不大，但 MoE 的 routing 與 expert loading 對推論硬體有特定要求。沒有 vLLM、TensorRT-LLM、SGLang 與相應 GPU memory／kernel 配置，自己跑 Large 3 會撞到延遲與吞吐量的牆。

對導入團隊來說，這層直接決定 cost：

• 量化（NVFP4 / FP8 / INT8）對你的任務品質掉多少？ 自己測。
• batching、prefill/decode disaggregated serving、speculative decoding 哪些你的 platform team 已經會做？ 沒做過要學。
• 自己 serve 還是叫 inference partner（Fireworks / Together / Modal）？ 兩者 cost curve 隨流量規模翻轉。

Mistral 跟 NVIDIA、Red Hat、vLLM 一起公告，等於承認模型的 open 必須由 inference stack 的 open 補完，否則只是頁面上的 download 按鈕。

---

在哪些雲端可以用？「Available today」有 5 種以上意思

公告上「Available today」一字排開，但讀起來像同一個東西，其實是五種以上不同的「可用」：

通路類型	代表平台	可用的具體意思	採購要看什麼
自管下載	Hugging Face、Modal、Unsloth AI	權重可下載、可自管	自己負責 GPU、serving、監控、patch
第一方 API	Mistral AI Studio	直接叫 Mistral API	Mistral SLA、計費、區域、資料政策
雲端 marketplace	Amazon Bedrock、Azure Foundry、IBM WatsonX	走雲端買	計費與合規走雲端、支援責任在雲端
API aggregator	OpenRouter	多模型 routing	Routing 策略與 fallback 行為
第三方 inference	Fireworks、Together AI	別人替你 serve	Latency / throughput / 計費，與 Mistral 第一方不同

NVIDIA NIM 與 AWS SageMaker 標為「coming soon」。

每一種「可用」都附帶不同的責任邊界：雲端 marketplace 把資料區域、合規檢核、incident response 包進去；自管讓你保留控制權但接管全部維運；第三方 inference provider 走中間路線——通常比較快上線，但 patch、安全升級、故障回退仍要有人負責。

更重要的：這條清單會持續變動。今天的 available today，下個月可能多了 fine-tune 通路、明年可能少了某個 marketplace 的支援級別。

---

導入前先回答這 5 個問題

把這次公告當作工具，先把每一層的 open 拆出來，逐層回答：

1. 法律層：Apache 2.0 對你的合規流程是否夠？資料處理、輸出責任、權限稽核這些政策題誰負責回答？
2. 模型層：你要的是 Large 3 路徑（frontier capability + 自管／marketplace 部署）還是 Ministral 3 路徑（local／edge + 可控成本）？或混合？
3. 推論層：你的 platform team 跑得起來 vLLM / TensorRT-LLM / NVFP4 嗎？還是要叫 inference partner？兩條路徑的 cost curve 在你預期流量上交叉在哪裡？
4. 通路層：Hugging Face / Mistral Studio / Bedrock / Foundry / Together 你選哪一個？SLA、區域、計費、支援級別、合規邊界各自不同。
5. 維運層：patch、安全升級、incident response、版本管理、模型棄用後的回退路徑——誰負責？

Apache 2.0 是免費的——但 GPU、推論、通路、維運的帳單各自獨立。把 Mistral 3 的公告當作這 5 層的對齊測試，比把它當作下一個排行榜更新有用。

---

資料來源：Mistral AI 官方公告、Mistral 文件、Hugging Face model card、LMArena 排行榜