Solar Open2 250B 必要スペック早見表 — VRAM 89〜191GBを量子化別に整理

Upstage の Solar-Open2-250B をローカルで動かす際の必要ストレージ・メモリは、GGUF 量子化の IQ4_XS で合計約127GB、Q2_K で約89GB、ほぼ無損失とされる Q6_K で約191GB が目安である。公式が示す推奨ハードウェアは NVIDIA H200 を最低4枚・推奨8枚とするサーバ構成だが、量子化を選べば単一の96GB級GPUや、Apple Silicon のユニファイドメモリ環境でも動作させられる。本記事では2026年9月時点で判明している事実（GGUF量子化の実測サイズ、公式推奨構成、アーキテクチャの特徴）をもとに、環境別の現実的な動かし方を整理する。

上記のサイズは重みファイルの容量のみの目安であり、実際の推論に必要なメモリはこれにコンテキスト長やバッチサイズに応じた推論オーバーヘッド（KVキャッシュ・アクティベーション等）が加わる点に注意が必要である。特に長文脈を使う場合はここからさらに数GB〜数十GB上乗せされる可能性がある。

Solar-Open2-250B は韓国 Upstage が2026年7月22日にオープンウェイトとして公開したモデルである。総パラメータ250Bに対し、1トークンあたりに活性化するのは15Bのみという Mixture-of-Experts（MoE）構成を採る。エキスパートは320個の routed expert と1個の shared expert からなり、推論時は routed のうち8個と shared 1個、合計9個のエキスパートが活性化する。アーキテクチャは「Hybrid-Attention MoE」と呼ばれ、linear attention 層3に対し softmax attention 層1という比率を12回繰り返す計48層構成を取り、位置エンコーディングとして一般的な RoPE（回転位置エンコーディング）を一切使用しない点が特徴である。学習データは約12兆トークン、NVIDIA B200 で約200万GPU時間を投じ、英語・韓国語・日本語を主要言語として扱う。前世代の Solar Open 1（102B）からの選択的な重み転移で初期化されており、アーキテクチャ変更により生き残った約2.3%のみが転移され、残りはランダム初期化されたとされる。コンテキスト長は最大1Mトークンで、拡張推論（extended reasoning）は最大131Kトークンまで対応し、OpenAI互換APIでのtool callingにも対応する。

1Mトークンという長いコンテキスト長が現実的な選択肢になっている背景には、Hybrid-Attention構成によるKVキャッシュの軽さがある。48層のうち、KVキャッシュを保持する必要があるのは softmax attention を使う12層のみで、残り36層の linear attention 層はキャッシュを必要としない。この結果、1トークンあたりのKVキャッシュは約48KiBという小さな値に収まる。一般的な全層softmax attentionのモデルであれば長文脈時にKVキャッシュが急速に肥大化しVRAMを圧迫するが、Solar-Open2-250Bではこの負荷が大幅に軽減されるため、長文脈用途でもメモリ設計がしやすい。ただし、これはKVキャッシュ自体の話であり、モデル重み本体の容量とは別枠で加算される点は変わらない。

量子化レベルと手元のハードウェアの組み合わせによって、現実的な選択肢は変わる。代表的な環境ごとの目安は以下の通りである。

- Apple Silicon（ユニファイドメモリ）: IQ1_M（約56GB）なら64GBメモリ機でも収まる可能性がある。IQ4_XS（約127GB）は192GB以上のMac Studio級が現実的なライン
- 単一96GB GPU: Q2_K（約89GB）であればオフロードなしで単一カードに載せられ、Q6_K比で約2.5倍高速に動作するとされる。ただし perplexity の劣化は大きい
- マルチGPU: IQ4_XS〜Q6_Kまで含め、複数枚のGPUに分散して確実に動かしたい場合はマルチGPU構成が安全。公式推奨のH200×4〜8枚はこの延長線上にある
- CPU+GPUハイブリッドオフロード: IQ4_XSでは-ncmoe 15のようなオプションでMoEレイヤーの一部をCPU側RAMにオフロードし、VRAM約92GB＋システムRAM約35GBのように分担する運用が現実解になる

APEX-Agents のようなエージェント系ベンチマークで他モデルを上回る数値が示されており、コーディング・エージェント用途を意識した設計であることがうかがえる。総パラメータ250Bに対しアクティブ15Bという構成は、推論コストを抑えつつ大規模モデル相当の性能を狙う近年のMoEモデルの流れに沿ったものである。

Solar-Open2-250B の Hybrid-Attention MoE アーキテクチャは、2026年9月時点で mainline の llama.cpp では未対応である。動かすには対応パッチを当てたカスタムビルドが必要になる点をまず押さえておきたい。

- バッチサイズは -ub 512 または -ub 4096 を使う。-ub 2048 はCUDAクラッシュを起こすため避ける
- MoEレイヤーのCPUオフロードには -ncmoe オプションを使う（IQ4_XSでは-ncmoe 15が一つの目安）
- 全量子化レベルにおいて attention と embedding は Q6_K のまま保持されており、これは検索・retrieval精度を落とさないための設計である
- GGUF量子化は prometheusAIR/Solar-Open2-250B-GGUF として配布されているほか、NotaAI からも INT4 / NVFP4 の量子化版が提供されている

本番運用や複数ユーザーへの同時提供を想定する場合、Upstage が公式に推奨する実行系は vLLM である。推奨構成はテンソル並列8・エキスパート並列を組み合わせ、Triton backend を用いるというもので、これはハードウェア要件である H200×8枚とセットになった構成と考えてよい。H200×4枚を最低ラインとしつつ、実運用のスループットや同時接続数を確保するには8枚構成が推奨されている。API経由での利用としては、2026年9月時点で主要なAPIプロバイダによるホスティング提供は確認されておらず、事実上セルフホストが前提となる。

Solar-Open2-250B は Apache 2.0 派生の「Upstage Solar License」で提供される。商用利用は可能だが、Apache 2.0 単体とは異なり、このモデルをファインチューニングするなどして派生モデルを作成・配布する場合には、モデル名に「Solar」というプレフィックスを付けることと、Upstage への帰属表示を行うことが求められる。自社サービスに組み込む形での利用（ファインチューニングを伴わない推論利用など）では大きな制約にはならないが、独自の派生モデルとして公開・配布する計画がある場合は、命名規則と帰属表示の要件を事前に確認しておく必要がある。

GLM-5.3-Flash や Qwen3.8-Flash-Next の詳細な必要スペックは、GLM-5.3-Flash 必要スペックとQwen3.8-Flash-Next 必要スペックでそれぞれ量子化別に整理している。総パラメータやアクティブパラメータの数字だけでなく、KVキャッシュの軽さやアーキテクチャの違いも実運用時のメモリ要件に大きく影響するため、あわせて確認することを推奨する。