Mistral Large 4を自前ホストする：痛い目から学んだ教訓

Mistralが Mistral Large 4 の重みを公開したとき（約1兆パラメータ、アクティブ約520億パラメータのモデル）、受信箱には同じ質問が溢れました。これ、自社で動かせないの？ オープンウェイトの自前ホストはもはや趣味の夢ではなく、現実的なアーキテクチャ上の選択肢になりました。つまり、これから高くつく失敗をするチームが山ほど出るということです。実際、もうそうした失敗を何件も目にしてきました。本記事は「痛い目に遭って学んだ教訓」をまとめたものです。実践者がどこで自前ホストを誤るのか、そしてその都度どう直すべきかを書きます。

失敗その1：「オープンウェイト」を「好きに使ってよい」と読み違える

最初の失敗はGPUに触れる前に起きます。Mistral Large 4は、修正版MIT系のライセンスで配布されていますが、重要な例外があります。自社または関連会社がモデルのサービス提供（model-as-a-service）事業を運営している場合、商用利用の前にMistralから別途商用ライセンスを取得する必要があります。社内で推論を回す企業、たとえば文書要約や社員向けコーディング支援であれば、おそらく問題ありません。推論の再販を計画しているスタートアップなら、Mistralにメールで確認するまで事実上の停止です。

誤解はどちらの方向にも起きます。プレスリリースの「オープン」という言葉だけを見て、重みの上に商用製品を作ってしまい、資金調達のデューデリジェンス監査の段階で制限に気づくチームがあります。最悪のタイミングです。一方で逆に慎重すぎて、ライセンスは商用利用を全面禁止していると思い込むチームもあります。実際には、対象は競合する推論プロバイダーです。解決策は地味ですが不可欠です。発表記事ではなく、実際のライセンス本文を法務に読んでもらってください。「オープンウェイト」と呼ぶか「ウェイト公開（weight-available）」と呼ぶかは、コミュニティで激しく議論されている区別で、その議論にも一理あります。ただ、エンジニアリング上の判断は、ライセンスが自社事業に何を許しているかで決めるべきです。

もう一つの細かい点として、このライセンスの形式は今や大型の重み公開の標準であり、例外ではありません。アーキテクチャがMistral、Qwenなど複数のフロンティア級重みモデルを切り替える前提なら、一度きりのレビューではなくライセンスの一覧表が必要です。クラスターを組む前に、その表を作ってください。

失敗その2：計算ではなくマーケティングページからハードウェアを見積もる

最も金を燃やす失敗はこれです。エンジニアが「1Tパラメータ」を見て、サーバールームにあるH200が4台あるのを眺め、VRAM 540GBなら十分だろうと考えます。十分ではありません。理由は、計算に90秒しかかからず、やってみれば数か月分の気まずさを防げる単純な算数です。

BF16精度では、1兆パラメータの重みだけで約2TBのメモリが必要です。8ビットに量子化しても約1TB。4ビットでも約500〜560GBです。そこにKVキャッシュ、活性化データ、サービング用のオーバーヘッドが加わります。540GBのサーバーに4ビットモデルが収まるのは、短いコンテキスト長と少数の同時ユーザーで満足できる場合だけです。MoEアーキテクチャ（トークンごとのアクティブパラメータ520億）は、トークンあたりの計算量を減らしますが、メモリには何の助けにもなりません。全1兆パラメータはどこかにアドレス可能な状態で存在しなければなりません。さらにMoEではエキスパートの重みが予測しにくく参照されるため、CPUのRAMへオフロードするとレイテンシが壊滅的になります。密なモデルの場合にはそこまで悪化しません。

解決策は、ハードウェアから考えるのではなく、サービング要件から逆算することです。目標のコンテキスト長、同時接続数、トークン毎秒を先に決め、次に払える量子化レベルを決め、最後にハードウェアを導きます。結果がH200が8台や、NVL72級ノードのペアになり、その数字に顔をしかめたくなるなら、それでいいのです。その顔をしかめる感覚こそ、モデルが意図通りに働いているサインです。隣接する問題については、GPUのVRAMが足りなくなったときの対処法で扱いました。そこで挙げたオフロード、より小さい量子化、より小さいモデルという選択肢は、データセンター規模でもそのまま当てはまります。

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

正直な表にはKVキャッシュとオーバーヘッドが含まれています。重みだけの不誠実な表は、読み込めるけれど3ユーザー以上にはサービスできないモデルを生む典型例です。

失敗その3：量子化をタダのランチだと思う

量子化が必要だと受け入れたチームが次に犯すのは、4ビットは「ほぼ同じモデル」だと思い込むことです。確かにそう言える場合もあります。しかし多くの場合は違い、しかも失敗モードが、まさに最も気にしたい部分に現れます。

何度も見てきたパターンがあります。チームが4ビット版をMMLU風の多肢選択問題でベンチマークし、1%の低下を確認して出荷します。すると本番のユーザーから、複数ファイルにまたがる長いコードのリファクタリングが崩れる、あるいはツール呼び出しのJSONが低確率ながら高頻度で微妙に壊れる、という報告が来ます。強い量子化は、長い視野を要するタスク、構造化されたタスク、低温度のタスクに不均衡に効きます。つまり、そもそもフロンティアモデルを使う理由になっているエージェント的・コーディング的ワークロードこそが最も影響を受けるのです。平均はほとんど動かず、テールが崩れるのです。

解決策は、VRAMが強制する量まで量子化するのではなく、タスク評価が許容する範囲まで量子化することです。自分のワークロードのプロンプトをFP8、4ビット、3ビットのビルドで実行して比べてください。3ビットが評価を通るなら、ハードウェアの請求額は半分になります。おめでとうございます。失敗すれば、どんなベンチマークの平均値も救えません。また、ベンダーが配布しているなら、ネイティブの量子化版を優先してください。Mistralは BF16の重みと並べて NVFP4版を公開しています。測定された品質差のある公式の量子化版は、半日検証しただけのコミュニティ製GPTQ変換に勝ります。

量子化レベルは圧縮設定ではなく品質予算です。ワークロードがその損失を許容できる場所に使いましょう。

失敗その4：APIの価格とGPUの価格を比べてTCO分析と呼ぶ

典型的なスプレッドシートはこうです。「APIは100万出力トークンあたり2.10ドル、予約GPUノードは1時間あたりX円。したがって月Yトークンを超えると自前ホストの元が取れる」。このスプレッドシートはほぼ必ず間違っていて、しかも高くつく方向に間違っています。

抜けているのは稼働率です。APIは他人のキャパシティを100%使えて、課金はトークン単位です。自前のクラスターは、トラフィックのパターンが許す稼働率しか出ません。そして社内ワークロードの多くはバースト的です。業務時間中は混雑し、夜は遊び、リリース前後にスパイクします。ピーク向けに設計したクラスターは、一日の大半で半分ほど空いています。さらにスプレッドシートに載らないコストもあります。vLLMのアップグレード、CUDAドライバの不一致、KVキャッシュが断片化したときの午前2時の呼び出しを含む、サービングスタックのオンコール当番。モデル更新の入れ替え（新しい重みが出るたびに再検証するのか？評価スイートは「する」と言います）。そして、製品を作る代わりにGPUの子守りをしているMLエンジニアの機会損失です。

誰も値付けしない、動き続ける標的の問題もあります。Mistralはこのモデルのプレビュー版から正式版にかけて、APIの価格をほぼ半額にしました。入力トークンは100万あたり1.36ドルから0.70ドルになりました。古い価格で行った自前ホストのROI計算は、すべてフィクションになります。フロンティア推論は四半期ごとの速さで安くなり、ハードウェアは数年単位で減価償却されます。この非対称性こそ、自前ホストのビジネスケースを静かに殺すものです。

解決策は、APIが構造的に提供できない理由がある場合にだけ自前ホストすることです。そうした理由は実在し、現実的です。しかし、ほとんどの企業が実際に運用する規模では、「大規模なら安い」はその理由になることがまれです。

自前ホストが本当に勝つ場面

では、Mistral級の重みをローカルで動かすのはいつAPIに勝つのでしょうか。チームが上手くやる例とやり損なう例を見てきた結果、勝つケースは四つのバケットに集まります。

• データの居住地とデータ主権。 規制産業、防衛関連の業務、厳格な管轄要件を持つEUの組織などです。実際に見た制約の一つに、コンプライアンス上の理由で中国起源のモデルを使えない企業がありました。検証可能な出自を持つ欧州ラボのオープンウェイトは、どのAPI契約でも解決できなかった問題を解決しました。
• エアギャップ環境や断続的にしか接続しない環境。 ネットワークが存在する保証がない場合、ローカルの重みがアーキテクチャの全てになります。このパターンはオフラインで動くLLMの構築で検討しました。
• 持続的で予測可能な大量ワークロード。 24時間、安定したスループットで回すバッチ文書処理は、トークン単価に対して本当に勝ちえます。構造上、稼働率の問題を解決しているからです。
• ファインチューニングと改変。 他人のAPIでは、ファインチューニングエンドポイントが許す範囲を超えてファインチューニングできません。重みを所有するとは、学習ループを所有することです。ドメインコーパスでの継続事前学習、独自のアライメント、小型モデルへの蒸留などが可能になります。

リストにないものにも注意してください。レイテンシです。十分にプロビジョニングされたAPIより低レイテンシにしたいなら、投機的デコーディングやバッチサイズ1向けの最適化に大きく投資する覚悟がない限り、数千億パラメータ級MoEを自前ホストしても、レイテンシは良くなりません。もう一つ、リストにないものがあります。「ベンダー依存を避ける」です。今日ダウンロードした重みは、1年以内に二世代遅れになり、結局また同じ判断に戻ります。これは、一部の実践者が重要な重み公開のローカルコピーを保管しておく、アーカイブ的な習慣の良い根拠にもなります。ストレージは安いですが、選択肢には価値があります。

正直な整理としては、オープンウェイトとAPIは競合ではなく補完関係です。知り合いのチームには、バーストするインタラクティブなトラフィックはAPI、規制対象やバッチ負荷の大きい部分はローカルの重み、というハイブリッド構成を取っているところもあります。スキルは転用できます。vLLMの設定、評価ハーネス、プロンプトのテンプレートは、どちらの世界でも使えます。フロンティア規模に踏み切る前に運用の基礎を押さえたいなら、自分のハードウェアで大規模言語モデルを動かすガイドで、サービングスタック全体を扱っています。

失敗その5：ワークロードではなくベンチマークで評価する

最後の失敗は、それまでの失敗すべてを台無しにするものです。チームはライセンスを確認し、ハードウェアを見積もり、公開ベンチマークで量子化を検証し、全部きちんとやります。そして、ユーザーが嫌うモデルを出荷します。評価がユーザーの実際の使い方を何一つ測っていなかったからです。

公開ベンチマークが答えるのは「このモデルは全般的に有能か」という問いです。「このモデルは、4ビットで、同時接続の負荷のもとで、必要なトーンと形式でサポートチケットを分類できるか」には答えません。以前AIベンチマークが実務の90%を取りこぼす理由について書きましたが、自前ホストではそのギャップがより鮮明になります。APIプロバイダーが昔は管理していた変数すべてに、あなたが責任を持つようになるからです。デプロイのスタック、サンプラーの設定、モデルが学習時に使ったシステムプロンプトの作法。すべて自分で間違える可能性があります。

解決策は、ハードウェアにコミットする前に作る三層の評価です。

1. 本番由来のゴールデンセット。 数百の実際のプロンプトと、レビュー済みの理想的な出力。自社のタスク分布を網羅するもので、長く、雑で、複数ターンにわたるケースも含みます。
2. 回帰テストハーネス。 すべての候補（API対ローカル、FP8対4ビット、旧重み対新リリース）が、ゴールデンセットを自動で実行します。強力な判定モデルとヒューマンによるスポットレビューで採点し、構造化出力では判定モデルを盲信しないでください。
3. シャドウ期間。 ローカル環境をAPIと並べて、ライブトラフィックで2週間動かし、出力を比較し、実際の負荷下での実レイテンシを測ります。KVキャッシュのサイズ設定の誤りや、量子化のテール失敗は、ここで初めて表面化します。

このハーネスは、新しい重みリリースが出たときに元が取れます。「アップグレードすべきか」に、会議での雰囲気ではなく、半日でデータを使って答えられるからです。

本当の教訓：オープンウェイトが変えたのは答えではなく問いである

1年前は「フロンティアモデルを自前ホストすべきか」は仮定の話でした。フロンティアはダウンロードできなかったからです。Mistral Large 4は、他の数多くの1兆パラメータ級リリースとともに、それを現実の金がかかった判断に変えました。ただし、判断の枠組み自体は変わっていません。ただ、必須になったのです。

主権、接続性、持続的な量、モデルを改変する必要が求めるときは自前ホストしてください。トラフィックがバーストし、チームが小さく、差別化要因が推論スタックではなく製品そのものであるなら、APIに払ってください。そして、どちらを選ぶにしても、契約書にサインする前に、90秒のメモリ計算をし、ライセンスを読み、評価ハーネスを作ってください。重みはもう公開されています。残念ながら、失敗も公開されています。