「オープンウェイトなら、自社のサーバーで動かせばタダで使えるのでは」。10月29日にMistral Large 4の重みが公開されたとき、私が最初に考えたのはそれでした。そこでHugging Faceにある重みファイルの容量を合計してみると、標準版は1,060.6GBでした。いちばん小さい1ビット級の量子化版でも233.0GBあります。
先に答えを書きます。ライセンス上は、社内での利用や、自社製品の決まった機能への組み込みは自由です。別契約が必要になるのは、顧客が入力やパラメータを自由に指定できる形でAPIを提供する場合です。費用の面では、ほとんどの会社にとって現実的なのはAPI(入力100万トークンあたり0.70ドル)です。手元で動かせるのは、ユニファイドメモリ512GBのMac Studioか、大容量のGPUを複数枚積んだサーバーに限られます。
判断に迷いやすいのは、顧客向けにチャットボットを作る受託案件です。ここはライセンスの原文を読んでも結論が一つに定まりません。
1兆パラメータのうち、1トークンごとに動くのは約5%
Mistralの公開発表によると、10月上旬から試験提供していたモデルに約3週間の追加学習を施し、重みと合わせて公開しました。モデルカードでは、総パラメータは約1兆です。1トークンごとに働くのは、埋め込み層と出力層を含めて520億パラメータで、128個の専門家(エキスパート)から4個と共有の1個を使う構成です。文脈は100万トークンまで扱え、画像も入力できます。
料金に直結するのが推論の強さです。low・medium・highの3段階があり、既定はhighです。Hugging Faceの解説記事によると思考は無効にできず、noneを指定してもhighで動きます。
性能はMistralの発表値で、Artificial AnalysisのCoding Agent Indexが48%です。中国のGLM-5.3と並ぶ値で、1タスクに使うトークンは47%少ないとしています。総合のIntelligence Index v5は26で、欧米のオープンウェイトでは最高ですが、中国勢の上位モデルはこれより高いとMistral自身が書いています。配布された重みでの第三者評価は、10月30日時点ではまだ揃っていません。比較に名前が挙がる中国勢は、当サイトのDeepSeek V4.1-Flash-1017の料金と設定やKimi K3のオープンウェイト公開で扱っています。
顧客にAPIとして貸すと別契約。使い方ごとの判定表
ライセンス本文は、MITライセンスを改変したMistral Ecosystem Open-Weight Licenseです。利用者や関連会社が「Model as a Service」事業を営む場合、商用に使う前にMistralと別の商用契約を結ぶ必要があります。
Model as a Serviceの定義は、APIやホスト型のエンドポイントを通じて第三者に推論か追加学習を使わせ、入力・パラメータ・学習データを実質的に制御できるようにすることです。除外は2つあります。特定の機能に組み込んだエンドユーザー向け製品と、他者がホストするモデルへの中継です。さらに、社内利用とMistral公式製品を通じた利用は、この条件の対象外です。
これを日本の会社でよくある使い方に当てはめると、次のようになります。判定は私が原文を読んだ解釈で、法的な助言ではありません。
| 使い方 | 別契約 | 原文の根拠 |
|---|---|---|
| 社員だけが使う社内チャットや文書検索 | 不要 | 社内利用は対象外 |
| 自社SaaSの「要約」ボタンなど決まった機能に組み込む | 不要 | 機能に組み込んだ製品は除外 |
| 他社がホストするエンドポイントへ要求を中継する | 不要 | 単なる中継は除外 |
| 顧客にAPIキーを発行し、プロンプトや設定を自由に使わせる | 必要 | 定義にそのまま当たる |
| 顧客のデータで追加学習し、その推論環境を提供する | 必要 | 追加学習のアクセスも定義に含む |
| 重みを顧客のサーバーに納品し、顧客が社内で使う | 不要と読める | 顧客自身の社内利用になる |
| 自由入力のチャットボットを自社クラウドで顧客に提供する | 判断が分かれる | 入力の実質的な制御に当たるか |
見落としやすいのは「関連会社」の一語です。グループ会社がこのモデルでAPI事業をしていると、自社の商用利用にも別契約が必要になる書き方になっています。社内利用だけは例外です。
私が受託開発の立場なら、表の最後の行に当たる案件は見積もりの前にMistralへ問い合わせます。顧客が何でも打ち込めるチャット欄は、特定の機能への組み込みとも、入力の実質的な制御とも読めるからです。商用契約の料金は公開されていません。重みを配布するときは、著作権表示と許諾表示を残すことも条件に入っています。
手元で動かす:Mac Studio 512GBの2ビット版で、1回の回答に約2分
Hugging FaceのAPIで、公式と主要な量子化版のファイルサイズを合計しました。取得は10月30日13時34分(UTC)で、1GBは10億バイトとして計算しています。
- 標準版(FP8):1,060.6GB
- NVFP4版(NVIDIAのBlackwell世代向け):610.0GB
- GGUFの4ビット版(UD-Q4_K_XL):604.8GB
- GGUFの2ビット版:UD-Q2_K_XLが378.3GB、Q2_Kが380.7GB
- GGUFの最小版(UD-IQ1_S):233.0GB
画像を入力するには、このほかに3.4GBの部品が要ります。Unslothの手順書は、メインメモリとGPUメモリの合計が量子化ファイルのサイズを上回ることを目安にしています。文脈を長くすると、その分のメモリも追加で必要です。
GPUサーバーの場合、標準版を8枚に分けると1枚あたり132.6GBです。80GBクラスのGPUでは8枚でも収まりません。Hugging Faceの推論エンドポイントは、141GBのH200を8枚使う構成です。量子化版なら枚数は減らせます。同じ解説記事では、RTX 6000 Pro 4枚でNVFP4版を動かして生成が毎秒約10トークン、IQ2_XXS版では短い文脈で毎秒30トークンでした。
Macで2ビット版が収まるのは、ユニファイドメモリ512GBのモデルだけです。256GBのMacでは最小版がファイルの上では入りますが、OSや文脈に使える余地がほとんど残りません。品質の目安として、Unslothは元のモデルと最有力の次トークンが一致する割合を、最小版で90.6%、UD-Q2_K_XLで95.6%と報告しています。
速度はさらに厳しい数字です。Hugging Faceの解説記事は、M3 Ultra 1台でQ2_Kを動かしたとき、入力の読み込みが毎秒約90トークン、生成が毎秒15トークンだったと報告しています。後で示す実測から、日本語1万字は約7,000トークンです。この資料を読ませて1,000字(約700トークン)で答えさせると、読み込みに77.8秒、生成に46.7秒で、合計2分強かかります。思考に2,000トークン使えば、さらに133.3秒が加わります。
触って確かめる用途には十分ですが、問い合わせ対応のように毎日何百回も回す業務には向かない速度だと私は見ています。
日本語1万字を読ませて1回0.6〜2.3セント。差を生むのは思考の量
APIの単価は100万トークンあたり、入力0.70ドル、キャッシュされた入力0.07ドル、出力2.10ドルです。日本語が何トークンになるかは公開されているトークナイザーで数えられるので、実際に測りました。
- 私が用意した業務メールの例文:217文字で153トークン(1文字あたり0.71)
- 同じ内容の英文:553文字で116トークン。日本語は英語の1.32倍
- 当サイトの既存記事3本の本文:13,401文字で8,851トークン(1文字あたり0.66)
1文字0.7トークンと置き、1万字の資料を読ませて1,000字で答えさせる場合を計算します。思考トークンは出力として課金されるものと仮定しています。Mistralの料金ページでは、思考トークンの扱いを明記した記述を見つけられませんでした。
入力 7,000 ÷ 1,000,000 × 0.70ドル = 0.0049ドル
出力 (700 + 思考トークン) ÷ 1,000,000 × 2.10ドル
思考 0 → 合計 0.00637ドル(月1,000回で 6.37ドル)
思考 2,000 → 合計 0.01057ドル(月1,000回で10.57ドル)
思考 8,000 → 合計 0.02317ドル(月1,000回で23.17ドル)
入力の費用は変わらず、思考の量だけで1回の費用が最大3.6倍に開きます。思考は切れず既定はhighなので、要約や分類のような定型作業では、Mistralのドキュメントにあるreasoning_effortをlowに指定するのが第一の節約策です。急がない処理なら、料金ページが50%引きと説明するバッチ処理も候補になります。
自社の文書が何トークンになるかは、次の手順で数えられます。トークナイザーは約28MBで、ダウンロードにアカウントは要りません。sample.txtに数えたい文章を保存してから実行してください。
curl -L -o tokenizer.json https://huggingface.co/mistralai/Mistral-Large-4-1T-A52B/resolve/main/tokenizer.json
uv run --with tokenizers python -c "from tokenizers import Tokenizer; t = Tokenizer.from_file('tokenizer.json'); s = open('sample.txt', encoding='utf-8').read(); n = len(t.encode(s, add_special_tokens=False).ids); print(len(s), n, round(n / len(s), 3))"
出力は文字数、トークン数、1文字あたりのトークン数の順です。uvがない環境では、pip install tokenizersの後に、2行目のpython -c以降をそのまま実行しても同じ結果になります。
まずAPIで試す。重みを持つのは3つの条件がそろうときだけ
私の結論は、ほとんどの会社はAPIで十分というものです。重みを自社で持つ意味があるのは、データを社外に出せない、自社データで追加学習したい、大容量GPUを複数枚積んだ環境か512GBのMac Studioをすでに用意できる、の3つがそろう場合です。どれか一つでも欠けるなら、1万字の資料1回で数セントに収まるAPIのほうが安く、速く済みます。
それでもこの公開には価値があります。APIで作った仕組みを、同じ重みのまま自社環境へ移せる逃げ道が用意されたからです。閉じたモデルでは選べない選択肢です。今日できることは2つあります。自社の使い方を上の判定表に当てはめ、顧客に自由入力を渡す案件ならMistralに確認すること。そして自社の文書を数えてトークン数を出し、上の式に入れてみることです。

コメント