K-EXAONE 2.0 750B-A37Bとは — 自前で動かす条件とVRAM試算

K-EXAONE 2.0 750B-A37Bは総パラメータ750B・アクティブ37BのMoEで、重みだけでBF16なら約1.5TB、FP8で約750GB、4bit級に落としても375〜420GBが必要です。 1枚のコンシューマGPUはもちろん、単一ノードでもBF16はそのままでは載らず、実運用にはKVキャッシュや活性化の余裕を含めた複数ノード構成を前提にする必要があります。ライセンスはApache 2.0で商用利用が可能、対応10言語に日本語が含まれる点が実務上の見どころです。この記事では公開された諸元、精度別の重みサイズ試算、動かし方の現実、そして小型版への逃げ道を整理します。

K-EXAONE 2.0は、LG AI Researchが2026年7月31日にHugging Faceで公開したオープンウェイトLLMです。韓国科学技術情報通信部が主導する「ソブリンAI基盤モデルプロジェクト」の第2世代モデルにあたり、リポジトリ名はLGAI-EXAONE/K-EXAONE-2.0-750B-A37B。総パラメータ750B・アクティブパラメータ37BのMoE構成で、レイヤ数は78（dense層2＋sparse層76＋MTP層1）、エキスパートは256個中トークンあたり8個をアクティブ化し、常時稼働するshared expertを1個持ちます。知識カットオフは2025年第2四半期です。

重みサイズは「パラメータ数×1パラメータあたりのバイト数」で概算できます。750Bパラメータに対して、BF16（2byte/パラメータ）なら750B×2byte≒1.5TB、FP8（1byte/パラメータ）なら750B×1byte≒750GB、NVFP4などの4bit級（0.5byte/パラメータ）なら750B×0.5byte≒375GBが理論値です。4bit級はブロック単位のスケール係数などのメタデータが上乗せされるため、実際のダウンロードサイズは375〜420GB程度になるとみておくのが安全です。この数値はあくまで重みだけの下限であり、実運用にはKVキャッシュ・活性化・通信バッファの余裕が別途必要になります。

- KVキャッシュ: コンテキスト長262,144トークンを実際に使うと、同時実行数に比例して支配的な要因になる
- 活性化（アクティベーション）: 推論実行時の中間テンソルがGPUメモリを占有する
- 通信バッファ: マルチノード構成ではノード間のテンソル並列・エキスパート並列通信用にメモリを確保する必要がある
- メモリフラグメンテーション: 実運用では理論値ぴったりでは動かず、一定の余裕を積む必要がある

表の「H100/H200◯基〜」は重みが載るかどうかの下限に過ぎません。「◯基で動く」という断定ではなく、実運用ではKVキャッシュや活性化のぶん、表の基数より一回り多いノード構成を見込んでおくべきという理解が実態に近いです。特にBF16・FP8はマルチノードでのテンソル並列／エキスパート並列を伴う構成が前提になり、単純に合計GPUメモリが足りていればよいわけではありません。

LGは同時に、より小さいK-EXAONE-236B-A23Bと、その量子化版であるK-EXAONE-236B-A23B-GGUFも公開しています。同じ計算式を236Bパラメータに当てはめると、BF16で236B×2byte≒472GB、FP8で236B×1byte≒236GB、4bit級で236B×0.5byte≒118GB（メタデータ込みで実質130GB前後）となり、750B版より一段現実的な数字になります。手元のワークステーションやMacで試したい場合は、750B-A37Bではなく236B-A23BのGGUF量子化版から検討するのが妥当です。必要VRAMの目安はVRAM計算ツールでも確認できます。

K-EXAONE 2.0の実務上のポイントは、性能そのものよりもライセンスと対応言語にあります。Apache 2.0は商用利用・改変・再配布を認める寛容型ライセンスであり、オンプレミス環境や自国内（オンショア）でのホスティングに制約が少ない点が、データを外部に出せない業種（官公庁・金融・医療など）にとって選定理由になり得ます。対応10言語に日本語が明記されている点も、韓国発モデルでありながら日本語案件での採用を検討する余地を残します。

この表は総パラメータ・アクティブパラメータ・ライセンス・コンテキスト長という公開されている諸元の並びであり、性能の優劣を示すものではありません。総パラメータではKimi K3やDeepSeek V4が大きく、K-EXAONE 2.0は750Bとやや小ぶりですが、Apache 2.0という制約の少ないライセンスと日本語を含む10言語対応は、他のオープンウェイトモデルと比較したときの選定材料になります。

K-EXAONE 2.0を推論エンジンで動かす場合、対応状況にはばらつきがあります。SGLangとvLLMは、公式配布ページで案内されているadd-k-exaone2ブランチのカスタムforkを使う必要があり、標準リリース版ではまだ動作しない可能性があります。Transformersはサポートされており、llama.cppは量子化版（GGUF）経由での利用が案内されています。

- vLLM: add-k-exaone2ブランチのカスタムforkが必要。標準リリースへのマージ時期は本稿執筆時点で未確認
- SGLang: 同じくadd-k-exaone2ブランチのカスタムforkが必要
- Transformers: サポートあり。まず動作確認したい場合の入口になる
- llama.cpp: 量子化（GGUF）経由での利用が前提。236B-A23B-GGUFなど派生リポジトリが手がかりになる

つまり、weightsが公開された当日から本番のvLLM/SGLangクラスタにそのまま投入できるわけではありません。カスタムforkを追跡する運用コストが発生するため、まずはTransformersや量子化版で挙動を確認し、本番投入はadd-k-exaone2ブランチが安定してから、という段取りが現実的です。

LG AI Researchが公表している主なベンチマークは、MMLU-Pro 83.5、SWE Bench Verified 68.2、長文理解のOpenAI-MRCR 94.4、安全性のKGC-Safety 99.8です。24ベンチマークの平均スコアは70.1で、前世代（1.0世代）の63.3から向上したと説明されています。これらはいずれも開発元の公表値であり、自社タスクでの性能は別途評価が必要です。

K-EXAONE 2.0 750B-A37Bは、重みだけでBF16なら約1.5TB、FP8で約750GB、4bit級でも375〜420GBという大型MoEで、コンシューマGPU1枚では動きません。手元で試したいなら236B-A23BのGGUF量子化版から、本番でフル性能を狙うならBF16／FP8を前提に複数ノードのGPUクラスタと、vLLM/SGLangのカスタムforkを追跡する運用体制が必要になります。

一方で、Apache 2.0という制約の少ないライセンスと、日本語を含む10言語対応は、データを外部に出せない案件やオンプレ・自国内運用を検討する組織にとって実務的な価値があります。数値・対応ランタイム・派生リポジトリは公開直後で更新される可能性があるため、導入判断の際はHugging Faceの配布ページを直接確認してください。