導入
「ELYZA-13Bを社内サーバーで動かしたいのですが、GPUはRTX 4090が1枚あれば十分でしょうか？」
企業のITインフラ担当者の間で、このような疑問が頻繁に話題に上るようになりました。生成AIのセキュリティリスクやデータガバナンスを懸念し、クラウドAPIから自社専用のオンプレミス環境（ローカルLLM）への移行を検討する企業が増加しているためです。中でも、日本語性能に優れたELYZA-13Bは、その筆頭候補として注目を集めています。
この問いに対する答えは、利用規模によって「イエス」でもあり「ノー」でもあります。個人が検証目的で動かすのであればイエスと言えますが、数十人の社員が日常業務で同時に利用する環境であれば、明確にノーと判断せざるを得ません。
さらにインフラ設計において考慮すべき重要な変化として、ハードウェアの急速な世代交代が挙げられます。これまでローカルLLM用途の定番とされてきたRTX 4090はすでに販売を終了しており、現在では中古市場でのみ流通している状況です。これからの新規調達においては、大容量の32GB VRAM（ビデオメモリ）を搭載するRTX 5090をはじめとした、最新のRTX 50シリーズを前提としたシステム構成が不可欠となっています。
多くの技術記事では「モデルを読み込んで動かすこと」自体をゴールに設定しがちですが、ビジネスにおける真のゴールはそこではありません。「実用的な速度で」「安定して」「コスト効率よく」応答し続ける環境の構築が求められます。特に見落とされがちなのが、一度に処理する文章の長さ（コンテキスト長）と同時アクセス数が、VRAMの消費量に与える指数関数的なインパクトです。
「とりあえず最新世代の24GBや32GBのGPUを買っておけば問題ないだろう」という安易な見積もりは、プロジェクトの中盤で「複数人の同時利用時に応答が遅すぎて実業務で使い物にならない」という事態を招き、予期せぬ追加投資の稟議に追われる原因となります。
本記事では、専門的なアーキテクチャ設計の視点から、ELYZA-13Bをオンプレミスで運用するためのGPUリソース計算ロジックを紐解きます。単なる感覚論ではなく、数式とビジネスKPI（重要業績評価指標）に基づいた、最新のハードウェア環境に即した選定メソッドを分かりやすく解説します。
なぜ「VRAM容量」がオンプレミスLLM成功の先行指標となるのか
LLM（大規模言語モデル）のオンプレミス構築において、CPUの処理速度やシステムメモリ（RAM）の容量よりも圧倒的に重要なのが「GPUのVRAM容量」と「メモリ帯域幅（データの転送速度）」です。これらは単なるスペックの一部ではなく、プロジェクトの成否を分ける先行指標と言えます。
モデルロード可否だけではないVRAMの役割
「VRAMが足りなければ動かない（OOM: Out Of Memory）」というのは半分正解で、半分間違いです。現代の推論ライブラリ（llama.cppなど）やGPUの仕組みは、VRAMが不足した場合にシステムメモリ（メインメモリ）へデータを一時的に退避させる機能を持っています。
しかし、ここに大きな落とし穴が潜んでいます。例えば、最新世代のフラグシップGPUであるRTX 5090のメモリ帯域幅が約1,800 GB/s（RTX 4090でも約1,000 GB/s）に達するのに対し、システムメモリへのデータ転送速度は約30-60 GB/s程度にとどまります。桁が2つも違うのです。つまり、データがVRAMからあふれた瞬間に、AIの応答速度は実用的なレベルから、待てど暮らせど返答が来ないレベルへと劇的に低下してしまいます。
ビジネスユースでは、チャットボットが返答に30秒もかかれば、ユーザー体験は崩壊します。VRAM容量内にモデルと計算データをすべて収めきれるかどうかが、実用的なAIアプリケーションの境界線なのです。
コンテキスト長とKVキャッシュが消費する隠れたメモリ
多くのエンジニアが計算ミスをするのがここです。モデル本体（AIの脳にあたる重みパラメータ）のサイズは固定されていて計算しやすいですが、推論時に動的に消費される「KVキャッシュ（会話の文脈を覚えておくためのメモリ領域）」のサイズは変動します。
KVキャッシュは、文脈を保持するために必要なメモリ領域です。例えば、2026年2月時点のLlama 3.3では、汎用チャット用途で128kもの長大なコンテキスト対応が推奨されています（最新の仕様は公式ドキュメントでの確認をおすすめします）。ユーザーが入力するプロンプトが長くなればなるほど、そしてAIが生成する文章が長くなるほど、消費メモリは比例して増加します。
- モデルの重み: 固定値（例: 8B〜13Bクラスのモデルで約5〜13GB ※圧縮度合いによる）
- KVキャッシュ: 変動値（ユーザー数 × 文脈長に比例）
「モデルが入るギリギリのVRAM」を選定してしまうと、長い文章を要約させたり、過去の会話履歴を含めて質問したりした瞬間にメモリ不足に陥ります。これを防ぐには、運用時の最大コンテキスト長を見越した余裕のある設計が不可欠です。
投資対効果（ROI）を決定づけるハードウェア選定の失敗例
オンプレミス環境の構築において、コスト削減のためにVRAM 16GBの一般向けGPUを選定するケースが散見されます。データを圧縮する技術（4bit量子化）を使えば、8B〜13Bクラスのモデルサイズは約5〜8GBに収まるため、残りのVRAMで十分運用できると判断しがちです。
しかし、実証実験（PoC）で複数人が同時にアクセスした際、システムが頻繁にフリーズに近い遅延を起こすリスクがあります。原因は、同時接続によるKVキャッシュの爆発的な増加です。1人での利用なら快適でも、複数人環境ではVRAMが枯渇し、低速なシステムメモリへのデータ退避が発生してしまいます。
さらに最新の動向を踏まえると、英語中心のLlamaの日本語性能を補完するため、ELYZA Llama-3-ELYZA-JP-8BやLlama Swallowといった日本語特化の派生モデルを導入するアプローチが推奨されています。また、より高度な仕組みを持つLlama 4や、70Bクラスの巨大なモデルを将来的に検討する場合、モデル単体でさらに膨大なVRAMを要求されるため、ギリギリのハードウェア選定は致命的なボトルネックになり得ます。
適切なスペック選定は、無駄な買い直しを防ぎ、最初から安定したサービスを提供することで、AI導入の投資対効果を最大化します。最新モデルの要件と将来の拡張性を見据えた余裕あるリソース計画こそが、成功への近道です。
参考リンク
ELYZA-13B運用のための主要成功指標（KPI）定義
ハードウェアを選ぶ前に、まずは「どのような性能が必要か」を数値で定義する必要があります。ビジネス用途によって、追うべき目標値は異なります。
Time to First Token (TTFT)：初期応答の許容値
TTFTは、ユーザーが質問を送信してから最初の文字が表示されるまでの時間です。チャットボットや対話型AIアシスタントの場合、この指標が最も重要になります。
- 快適: 0.5秒未満
- 許容範囲: 1.0秒未満
- ストレス: 2.0秒以上
TTFTは主にGPUの計算能力とメモリの転送速度に依存します。オンプレミス環境では通信の遅延がほぼゼロであるため、純粋なハードウェア性能が直結します。
Tokens Per Second (TPS)：実用的な生成速度の基準
TPSは、1秒間に生成されるトークン（単語の断片）の数です。これは「人間が文章を読む速度」と比較して設定するのが合理的です。
- 人間の黙読速度: 約15〜30トークン/秒（日本語の場合）
- 音声読み上げ速度: 約10〜15トークン/秒
チャットボット用途であれば、30 TPS以上あれば、人間がテキストが表示されるのを待つストレスはなくなります。逆に、大量のドキュメントを夜間に要約するような一括処理用途であれば、TPSよりも単位時間あたりの総処理量を重視すべきです。
同時接続数（Concurrency）とメモリ消費量の相関
社内ツールとして展開する場合、「何人が同時に使うか」がVRAM設計の肝になります。
1人が使う場合と、10人が同時に使う場合では、モデルの重み（固定）は変わりませんが、文脈を記憶するKVキャッシュは10倍必要になります。ビジネス要件として「全社員100人のうち、ピーク時に最大10人が同時利用する」といった具体的な利用シーンを想定し、それをハードウェア要件に落とし込む作業が必要です。
精緻なVRAM所要量の算出：パラメータ数×精度＋αの公式
ここからは、具体的な数値を算出していきましょう。「なんとなく」を排除するための公式を提供します。特に、ベースとなるLlama 2アーキテクチャから最新のLlama系へ移行を検討する際にも、この計算ロジックは共通して適用可能です。
ベースモデル（FP16/BF16）と量子化モデル（Int8/Int4）のメモリ試算
まずは静的なモデル本体のサイズです。ELYZA-13Bのパラメータ数は約130億（13B）です。
計算式：
$$VRAM_{model} (GB) \approx Parameters (Billion) \times Size_{dtype} (Bytes)$$
- FP16 (16-bit浮動小数点): 2 Bytes/param
- $13 \times 2 = 26 \text{ GB}$
- Int8 (8-bit量子化): 1 Byte/param
- $13 \times 1 = 13 \text{ GB}$
- Int4 (4-bit量子化 - GPTQ/AWQ/GGUF): 0.5 Bytes/param + オーバーヘッド
- $13 \times 0.5 + \alpha \approx 7.5 \sim 8.0 \text{ GB}$
この時点で、圧縮していないFP16のオリジナルモデルを動かすには、24GBのVRAM（RTX 3090/4090）では足りないことがわかります。A100 (40GB/80GB) や RTX 6000 Adaなどの業務グレード、あるいは2枚のGPUでの分散処理が必要です。
一方、4bit量子化という圧縮技術を使えば約8GBまで小さくでき、一般向けGPUでも余裕を持って読み込めます。現在の技術水準では、4bit量子化による精度の低下はわずかであり、多くのビジネスユースケースで実用十分です。
コンテキストウィンドウサイズによるKVキャッシュ計算式
次に、動的に変動するKVキャッシュの計算です。ELYZA-13B (Llama 2ベース) の標準コンテキスト長は4096トークンですが、ここで重要な注意点があります。
【重要：Llama 2系列のサポート終了と最新モデルへの対応】
Llama 2系列は2024年10月30日にサポート終了となりました。現在、新規構築や入れ替えを検討する場合は、最新のLlamaや、それらをベースとした最新の日本語モデルが推奨されます。
最新モデルでは一度に処理できる文章量（コンテキスト長）が大幅に拡張されているため、以下の計算式を用いたVRAM見積もりがより重要になります。
計算式（1リクエストあたり）：
$$VRAM_{KV} \approx 2 \times Layers \times HiddenSize \times ContextLength \times Size_{dtype}$$
ケースA：ELYZA-13B (Llama 2ベース) の場合
- Layers: 40
- Hidden Size: 5120
- Context Length: 4096
- FP16 (Size=2)
$$2 \times 40 \times 5120 \times 4096 \times 2 \approx 3.35 \text{ GB}$$
ケースB：最新のLlama系 8Bモデル（Context 8k想定）の場合
最新のLlama系はメモリ効率を改善する技術（GQA）を採用していますが、扱える文章量が長いため、総量は増大する傾向にあります。
この計算から導かれる結論として、RTX 4090（24GB）でELYZA-13Bの4bit量子化モデル（8GB）を動かす場合：
- 空き容量: $24 - 8 = 16 \text{ GB}$
- 最大同時接続数: $16 \text{ GB} / 3.35 \text{ GB} \approx 4.7$
つまり、RTX 4090 1枚で、限界まで長い文章（4096トークン）を扱うリクエストを同時に処理できるのは4〜5並列までとなります。これが「とりあえず24GB」の限界値です。
最新モデルへ移行し、さらに長い文章を扱う場合は、このKVキャッシュがVRAMを枯渇させる主な原因となります。システム設計時は、モデル本体だけでなく、想定する最大コンテキスト長に基づいたKVキャッシュの確保が不可欠です。
推論ライブラリ（vLLM, llama.cpp）によるメモリ効率の違い
上記の計算は理論値ですが、使用する推論エンジンによって効率は変わります。
- vLLM: メモリの断片化を防ぎ、無駄なくメモリを使う技術（PagedAttention）を備えています。最新モデルにも迅速に対応しており、処理量重視のサーバー用途では必須の選択肢です。
- llama.cpp: 幅広い環境で動く柔軟性がありますが、サーバーとしての並列処理性能ではvLLMに劣る場合があります。
ビジネス運用では、vLLMを採用し、GPUメモリの利用率ギリギリまで処理を詰め込む構成が一般的です。特にモデルの進化が早い現在、新しい仕組みへの対応速度もツール選定の重要な指標となります。
投資判断のためのコスト対パフォーマンス（ROI）分析
必要なスペックが見えてきたところで、経営層や財務部門を説得するためのコスト分析を行います。
コンシューマ向けGPU（RTX 4090）vs データセンター向けGPU（A100/L4）
オンプレミス構築の最大の悩みどころは、GPUのグレード選定です。
RTX 4090 (24GB) x 1〜2枚
- コスト: 約30〜60万円（サーバー本体含まず）
- メリット: 圧倒的なコストパフォーマンス。推論速度も非常に速い。
- デメリット: 規約上、データセンターへの設置が制限される場合がある。複数枚での連携効率が悪い。エラー訂正機能がない。
- 推奨: 社内での検証、小規模な社内ツール、開発環境。
NVIDIA L4 (24GB) / L40S (48GB)
- コスト: 数十万〜100万円超
- メリット: 推論向けに最適化された最新設計。省電力。
- デメリット: RTX 4090より単体での速度が低い場合がある。
- 推奨: コストバランスの良い本番環境サーバー。
NVIDIA A100 (80GB) / H100 (80GB)
- コスト: 200万円〜数百万円
- メリット: 広大なメモリ帯域と容量。大規模な同時接続や、将来的な巨大モデルへの移行にも対応可能。
- デメリット: 非常に高価。13Bモデルを動かすだけならオーバースペック気味。
- 推奨: 全社規模のAI基盤、絶対に止まらないことが求められる用途。
クラウドAPI利用料との損益分岐点シミュレーション
稟議書には以下のロジックを盛り込むと説得力が増します。
- 前提: クラウドAIの月額利用料と、自社サーバーの償却期間（3〜5年）を比較。
- 分岐点: 月間の処理量が数億トークンを超える、または機密保持のために専用のクラウド環境契約が必要な場合、自社でサーバーを持った方がトータルコストが安くなるケースが多いです。
さらに、「データが社外に出ないことによるセキュリティリスク回避」という金額に換算しづらい価値も、明確なメリットとして強調します。
電力効率と冷却コストを含めたTCO（総保有コスト）
見落としがちなのが電気代です。RTX 4090はピーク時に450Wを消費します。2枚なら900W。常にフル稼働させると、電気代だけで月数万円のコスト増になります。
一方、推論専用のL4 GPUなどは72W程度で動作します。長期的な運用（24時間365日）を考えると、初期費用が高くても、省電力なデータセンター向けGPUの方がトータルコストが安くなる可能性があります。
運用フェーズでのモニタリングとスケーリング指標
導入はゴールではなくスタートです。安定稼働を維持するための監視ポイントを解説します。
GPU使用率とメモリ使用率の健全な閾値
運用監視ツールを用いて、以下の数値を常時監視してください。
- GPU Memory Usage: 常に90%未満を目指します。95%を超えるとメモリ不足で停止するリスクが高まります。
- GPU Utilization: 常に100%に張り付いている場合、計算能力が不足しています。逆に低すぎる場合は、一度に処理する量を増やして効率を上げられる余地があります。
プロンプトキャッシュヒット率の計測
定型文やシステムへの共通指示（「あなたは親切なAIです」など）は、KVキャッシュとして再利用可能です。vLLMなどの最新エンジンは、この機能に対応しています。
キャッシュの再利用率が高ければ、実質的な計算量を減らし、見かけ上の応答速度を向上させることができます。運用データから再利用率を分析し、共通部分をプロンプトの先頭に持ってくるなどの工夫が有効です。
モデル更新やRAG導入を見越した将来的な余力確保
現在はELYZA-13B単体で運用していても、将来的には「社内文書を検索して回答する仕組み（RAG）」を組み込みたくなるはずです。
RAGを導入する場合、以下の追加リソースが必要になります。
- Embeddingモデル: テキストを数値化するモデル（0.5〜2GB程度）。
- Vector DB: 数値化されたデータを保持するメモリ。
- コンテキスト長の増大: 検索結果をAIに読み込ませるため、入力する文章量が数千トークン単位で増加します。
RAGを見越すなら、現在の必要VRAMに対して1.5倍〜2倍の余裕を持たせたハードウェア選定、あるいは後からサーバーを追加しやすい構成にしておくことが、賢明なアーキテクチャ設計と言えます。
まとめ
ELYZA-13Bのオンプレミス運用におけるGPU選定は、単なるスペック合わせパズルではありません。それは、自社のAI活用における「期待する応答速度」「同時利用者数」「将来の拡張性」というビジネス要件を、物理的なハードウェアの制約に落とし込む論理的な作業です。
- VRAMは命綱: モデルサイズだけでなく、会話の文脈を記憶するメモリの動的消費を計算に入れる。
- ROI視点: 一般向けGPUとデータセンター向けGPUを、トータルコストと信頼性の観点で比較する。
- 監視と予測: 運用開始後のデータ監視で、次なる投資のタイミングを逃さない。
「とりあえず動く」から「ビジネスを加速させる」インフラへ。この記事の計算式と実証データに基づいたアプローチを活用し、自信を持って最適なGPUを選定してください。
コメント