「自社のサービスに国産のLLM（大規模言語モデル）を組み込みたい」というニーズが、多くの企業で急増しています。特に、機密情報の保護やデータ主権の観点から、外部のAPIに依存するのではなく、自社のKubernetesクラスター上で推論サーバーを直接運用したいというケースは珍しくありません。
背景には、外部APIへの過度な依存に対するリスク管理の側面もあります。例えば、OpenAI APIでは2026年2月にGPT-4oなどのレガシーモデルが提供終了となり、GPT-5.2やGPT-5.3-Codexといった新世代モデルへの移行が求められるなど、プラットフォーム側の仕様変更に追従するコストが発生します。こうした影響を最小限に抑え、コントロール可能な基盤を構築する手段として、オンプレミスや自社クラウドでの運用が注目されているのです。
「Kubernetesを利用すれば、オートスケーリングは簡単に実現できるのではないか？」
このような疑問を持つ方も多いでしょう。確かにKubernetesは非常に優れたオーケストレーターです。最新のバージョン1.35では、Podを再起動せずにCPUやメモリを調整できる「In-place Podリソース更新」機能が導入されるなど、リソース管理の柔軟性は日々進化しています。しかし、ことLLMの推論ワークロードに関しては、従来のWebアプリケーションと同じ感覚で設定を行うと、予期せぬトラブルを招く危険性があります。
商用環境でのLLM運用で最も懸念すべきは、「スケールしない」ことによるレイテンシの増大とユーザー体験（UX）の低下、あるいは「スケールしすぎ」て想定外のインフラコストを発生させるクラウド破産（Cost Blowout）です。GPUリソースは非常に高価であり、無計画なスケーリングは致命的な結果をもたらします。
本記事では、ELYZAやCyberAgent、Rinnaといった国産LLMをKubernetes上で運用する際に直面する「オートスケーリングのリスク」と、それを技術的にどう制御し、ビジネスリスクを最小化するかについて、システム全体のアーキテクチャの視点から掘り下げていきます。
単なる設定手順の解説書ではなく、本番環境でシステム全体を俯瞰し、潜在的な問題を早期に発見・回避するための実践的なリスク管理ガイドとしてお役立てください。
なぜLLMのオートスケーリングは従来のWebアプリより危険なのか
Webアプリケーション（GoやNode.jsで書かれたマイクロサービスなど）と、LLM推論サーバーとでは、リソースの消費特性と起動挙動が根本的に異なります。
これを理解せずに、標準的なHPA（Horizontal Pod Autoscaler）を適用することは、システムを不安定にする要因となります。現在、KubernetesではAIワークロード向けの機能強化が進んでいますが、基本的なリソース管理の原則を見誤れば、依然としてシステム障害や想定外のコスト超過につながります。
CPUバウンドとGPUバウンドの決定的な違い
Webアプリの多くはCPUバウンド、あるいはI/Oバウンドです。トラフィックが増えればCPU使用率が上がり、それをトリガーにPodを増やせば、比較的リニアに処理能力が向上します。
しかし、LLMの推論は「GPUメモリ（VRAM）バウンド」かつ「計算集約型」です。特にパラメータ数が多いモデルを動かす場合、GPUのVRAMにモデル全体を展開し続ける必要があります。
ここで問題になるのが、Kubernetes標準のメトリクスである「CPU使用率」が、推論負荷を正しく反映しないことです。GPUがフル稼働していても、CPUはデータの転送待ちで待機していることがよくあります。つまり、CPU使用率をトリガーにしていると、「ユーザーからのリクエストが滞留しているのにスケールしない」という事態に陥ります。システム全体を俯瞰する観点から言えば、ボトルネックがどこにあるのかを正確に把握する可観測性（オブザーバビリティ）の欠如が、致命的なサイレント障害を引き起こす原因となります。
モデルロード時間（コールドスタート）が招くSLA違反
もう一つの大きな違いは、アプリケーションの起動時間です。
軽量なGoのコンテナなら数秒で起動し、リクエストを受け付け始めます。しかし、LLM推論サーバーは異なります。
- コンテナイメージのプル: 推論用コンテナはCUDAライブラリなどを含め数GBから十数GBになることがあり、ダウンロードに時間がかかります。
- モデルデータのロード: 数GBから数十GBに及ぶモデルの重みファイルをストレージから読み出し、GPUメモリへ転送する必要があります。
これらを合わせると、新しいPodが立ち上がってから実際に推論可能になるまで（Ready状態になるまで）、早くて数十秒、ネットワーク環境やモデルサイズによっては数分かかることも珍しくありません。
この「数分のラグ」は、リアルタイム性が求められるチャットボットや要約機能においては致命的です。ユーザーは画面の前で数分も待つことは困難です。結果として、オートスケーリングが発動してもトラフィックのスパイクに間に合わず、SLA（サービス品質保証）違反を引き起こすことになります。
国産LLM（7B/13B/70B）ごとのリソース特性
日本語対応LLM（国産モデルやLlamaベースの日本語チューニングモデル等）を扱う場合、そのパラメータサイズやアーキテクチャによってインフラ戦略も大きく変わります。
最新の動向として、Llamaシリーズをはじめとする基盤モデルは、小規模（1Bクラス）から超大規模（400B超クラス）まで幅広いサイズを展開しています。また、MoE（Mixture of Experts）アーキテクチャの導入や、長大なコンテキストウィンドウのサポートにより、リソース要件はより複雑化しています。日本語用途においては、Llamaベースの派生モデル（SwallowやELYZAなど）やQwenベースのモデルなど選択肢が増加しており、用途に応じた適切な選定が求められます。
- 軽量モデル（1B〜8Bクラス）: 一般的な推論用GPU（NVIDIA L4やA10など）1枚に収まりやすく、比較的扱いやすいサイズです。しかし、それでも数GBのVRAMを常時占有します。なお、ハードウェアの最新スペックや対応状況については、常に公式ドキュメントで確認することをお勧めします。
- 中規模モデル（13B〜30Bクラス）: 従来の13Bモデルや、より高性能な中規模モデルが該当します。量子化なしでは24GB以上のVRAMが必要になるケースがあり、GPU選定のハードルが上がります。コンシューマー向けGPUではメモリ不足に陥りやすいラインです。
- 大規模・MoEモデル（70B〜400B超クラス）: 複数GPUへの分散推論（Tensor Parallelism）が必須となります。MoEモデルの場合、推論時にアクティブになるパラメータは一部であるため計算効率は向上しますが、モデル全体をメモリに保持するためのVRAM要求は依然として巨大です。そのため、オートスケーリングの難易度は指数関数的に跳ね上がります。
これらのモデルを動かすGPUインスタンスは非常に高価です。だからこそ、「必要な時に必要な分だけ」リソースを使いたいと考えるわけですが、その制御は想像以上にシビアなのです。
リスク評価①：スケーリング遅延による「ユーザー体験の崩壊」
では、具体的にどのようなリスクがあるのか、シナリオベースで見ていきましょう。まずは「足りない」リスク、つまりスケーリング遅延です。
HPAの反応遅延と推論待ち行列の滞留
例えば、提供しているサービスへのアクセスが急増したと仮定します。
標準的なHPAの設定では、メトリクス収集の周期（デフォルトでは数十秒〜1分）があります。負荷が高まってからKubernetesが「スケールアウトが必要だ」と判断するまでに、すでにタイムラグが生じます。
LLMの推論は、1リクエストあたりの処理時間が長いです。短い返答でも数百ミリ秒、長い文章生成なら数秒かかります。リクエストが同時多発的に来ると、GPUの処理待ち行列（キュー）があっという間に積み上がります。
Webアプリなら数ミリ秒で処理できるリクエストが、LLMでは数秒かかる。つまり、キューが溜まる速度に対して、消化する速度が圧倒的に遅いのです。
Pod起動時間 vs トラフィック急増のタイムラグ
HPAがスケールアウトを指示したとします。しかし、前述の通り、新しいPodが稼働するまでには「モデルロードの壁」があります。
この数分間、既存のPodは限界を超えたリクエストを抱え込みます。vLLMやTGI（Text Generation Inference）といった推論サーバーは、バッチング処理で効率化を図りますが、それにも限界があります。VRAMが溢れればスワップが発生するか、OOM（Out of Memory）でクラッシュする可能性もあります。
タイムアウト多発によるサービスの信頼性低下
結果として何が起きるでしょうか。
クライアント側（Webブラウザやアプリ）では、タイムアウトエラーが多発します。ローディング表示がいつまでも消えず、最終的にエラーが表示される状態では、せっかくの高機能な国産LLMも十分に活用できません。
特に日本語生成においては、トークン生成速度がユーザーの体感速度に直結します。リソース不足で生成速度が秒間数トークンまで落ち込むと、ユーザーはサービスが機能していないと判断して離脱してしまいます。
これが、オートスケーリングの遅延が招く「UXの崩壊」です。
リスク評価②：過剰スケーリングによる「クラウド破産（Cost Blowout）」
UXを守るためにスケーリングの感度を高く設定すればよいと考えるかもしれませんが、そこにはもう一つの大きな課題が待っています。「クラウド破産」です。
GPUインスタンスの単価と請求リスク
AWSやGoogle Cloudなどのパブリッククラウドにおいて、GPUインスタンスは最も高価なリソースの一つです。
例えば、NVIDIA A100を搭載したインスタンスは、1時間あたり数ドル〜十数ドルかかります。もし設定ミスで、必要以上に数十台のPodが立ち上がってしまった場合、1時間あたり数百ドル、1日で数千ドルと、非常に大きなコストが発生します。これは企業のキャッシュフローに深刻な影響を与えかねない金額です。
スケーリング・ストーム（振動）の発生メカニズム
オートスケーリングの設定でよくある課題が「フラッピング（Flapping）」または「振動」と呼ばれる現象です。
- 負荷が閾値を超える -> スケールアウト（Pod追加）
- Podが増えて負荷が下がる -> 閾値を下回る -> スケールイン（Pod削除）
- Podが減って負荷が上がる -> またスケールアウト
これを短期間に繰り返す現象です。LLMの場合、モデルロードに時間がかかるため、この振動が起きると「常に起動処理中のPodばかりで、まともにリクエストを処理できるPodがない」という深刻な状況に陥ることもあります。
さらに、クラウドプロバイダーによっては、インスタンスの起動・停止自体に課金単位（最低1分や1時間など）があるため、無駄なコストが積み上がります。
終了処理の遅れによる無駄な課金時間
スケールイン（縮退）の際も注意が必要です。推論中のリクエストを強制終了させるわけにはいきません。Kubernetesの terminationGracePeriodSeconds を長く設定し、処理中の生成が終わるのを待つ必要があります。
しかし、これを適切に管理しないと、リクエストが来ていないにもかかわらず稼働し続ける高価なGPU Podが大量に残ることになります。これもまた、隠れたコスト要因となります。
技術的緩和策：KEDAとカスタムメトリクスによる制御
ここまではリスクについて解説してきましたが、これらを回避するための解決策が存在します。有効なアプローチとして挙げられるのは、Kubernetes標準のHPAではなく、KEDA (Kubernetes Event-driven Autoscaling) を活用した、よりインテリジェントな制御です。
「処理待ちリクエスト数」をトリガーにする優位性
CPU使用率が指標として不十分な場合、何を確認すべきでしょうか。答えは「Lag（ラグ）」、つまり「処理待ちのリクエスト数」です。
推論リクエストを一度、RedisやRabbitMQなどのメッセージキュー、あるいはAPIゲートウェイ経由で受け取ります。そして、「現在キューに何件のリクエストが溜まっているか」を監視します。
- キューにリクエストがある = GPUリソースが足りていない
- キューが空 = リソースは十分（あるいは過剰）
この指標は、CPU使用率よりもはるかに直接的で、ユーザーの体験（待ち時間）と相関します。
KEDA（Kubernetes Event-driven Autoscaling）の導入メリット
KEDAは、この「外部メトリクス（キューの長さなど）」に基づいてPodをオートスケールさせるためのCNCFプロジェクトです。
導入は非常にシンプルです。Helmチャートでインストールし、ScaledObject というカスタムリソースを定義するだけです。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: llm-inference-scaler
spec:
scaleTargetRef:
name: llm-inference-deployment
minReplicaCount: 1
maxReplicaCount: 10
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus-server
metricName: http_requests_pending
threshold: '5' # 未処理リクエストが5件を超えたらスケール
このように設定することで、「CPUが忙しいかどうか」ではなく「ユーザーが待たされているかどうか」で判断できるようになります。
Over-provisioning（予備リソース）の戦略的活用
それでも、コールドスタートの数分間はどうしてもゼロにはなりません。
ここで必要になるのが、エンジニアリング的な解決策ではなく、ビジネス判断としての「Over-provisioning（過剰配備）」です。
具体的には、常に「現在必要なリソース + 1台」の余力を保つように設定します。あるいは、優先度の低い低コストなPod（プレースホルダー）をあらかじめ起動しておき、本番のGPU Podが必要になったときに、そのプレースホルダーを退かして場所を譲る「Pod Priority & Preemption」というテクニックも有効です。
コストは掛かりますが、ユーザー体験を損なうリスクに対する保険料と考えれば、合理的な選択と言えます。
運用リスクへの備え：監視と緊急停止の設計
最後に、どんなに優れたオートスケーリング設定をしても、予期せぬ事態は起こり得ます。そのための安全対策を用意しておくことが重要です。
見るべきはGPU使用率ではなく「推論レイテンシ」
監視ダッシュボード（Grafanaなど）で最優先に表示すべきは、GPU使用率ではありません。
- P95 / P99 レイテンシ: 95%または99%のユーザーがどれくらいの時間で応答を受け取っているか。
- TTFT (Time To First Token): 最初の一文字が表示されるまでの時間。これがUXに最も影響します。
- スループット: 1秒あたりに生成されたトークン数。
これらが悪化した瞬間にアラートを通知する設定にしておくことが推奨されます。
コスト異常検知のアラート設定
クラウドベンダーの予算アラート機能は必ず設定してください。しかし、それだけでは事後対応になりがちです。
リアルタイムに近いコスト管理を行うなら、稼働中のGPUインスタンス数をPrometheusで監視し、「想定外にPod数が急増した場合」にSlackなどのチャットツールへ通知を送る仕組みを構築することが効果的です。
キルスイッチ（上限設定）の運用ルール
万が一、プログラムのバグやDDoS攻撃のようなアクセス集中で、オートスケーリングが過剰に機能しそうになった時、どのように制御するかが問われます。
物理的なスイッチはありませんが、運用ルールとしての「キルスイッチ」を定めておきます。
- HPA/KEDAのmaxReplicas制限: どんなに負荷が高くても、予算内で許容できる最大台数（例えば10台）をハードリミットとして設定しておく。
- API Gatewayでの流量制限（Rate Limiting）: バックエンドが処理限界を迎える前に、入り口で適切にリクエストを制限する仕組みを設ける。
システムを守るためには、時にリクエストを制限することも重要な設計の一部です。
まとめ
Kubernetesでの国産LLM運用は、技術的な挑戦であると同時に、コストと品質のバランスを問われるビジネス的な挑戦でもあります。
- 特性理解: LLMは従来のWebアプリとは違い、起動が遅く、リソース単価が高い。
- 遅延リスク: HPAの遅れとコールドスタート対策には、KEDAによるLagベースのスケーリングが有効。
- コストリスク: 無限にスケールさせないためのハードリミットと、異常検知の仕組みが必須。
「自動でスケールするから安心」ではなく、「どのようにスケールさせるかを適切に制御しているから安心」と言える状態を目指すことが重要です。
具体的なKEDAの設定ファイルや、Prometheusでの監視クエリの例については、公式の技術ドキュメントなどを参照することをお勧めします。また、国産LLMのモデル選定自体に迷っている場合は、モデル別のベンチマーク記事なども参考になります。
リスクを正しく評価し、適切な備えを行うことで、LLMプロジェクトを成功に導く基盤を構築できるでしょう。
コメント