LanguageModel GPU 容量検証ポリシー

• ステータス: 実装済みポリシー（本番デプロイ検証は別作業）
• 最終更新: 2026年8月3日
• 対象: Mineral Exploration LanguageMode から起動する dense SpikingEvoTextLM 学習

目的

利用者が指定した LanguageModel 構成を Core がそのまま実行できることを維持しつつ、現在の GPU 空き VRAM で開始できない要求を、ジョブ作成前に明示的に拒否する。

このポリシーは構成を小さくする自動最適化ではない。batch_size、d_model、block 数、time_steps、seq_len を Mineral、SDK、Core のいずれも容量不足を理由に変更してはならない。

責務分担

層	責務	禁止事項
Mineral UI	入力変更後に現在の容量を表示し、既知の容量不足時は学習ボタンを無効化する	入力値を自動的に縮小しない
Mineral API	起動前に同じ容量検証を再実行し、不足時は HTTP 422 を返す	リクエストを変更してジョブを作成しない
Core / SDK	受け取った有効な学習構成をそのまま実行し、通常の CUDA 利用可否を検証する	GPU 種別や空き容量に応じて batch size を自動調整しない

したがって、容量不足を解消する操作は利用者が明示的に選択する。例として、batch size、モデル寸法、block 数、time_steps、または同時に GPU を使用している別プロセスを見直す。

UI と API の動作

非変更の容量照会

POST /api/language-mode/training-capacity は現在のフォーム構成を受け、モデル構成の基本妥当性を確認した後、容量見積もりだけを返す。状態の変更、ジョブ作成、構成の正規化以外の書換えは行わない。

LanguageMode UI は、architecture、d_model、head 数、block 数、time_steps、batch size、seq_len、Tokenizer、neuron type、learning rate の変更から 300 ms 後にこの API を呼び出す。結果が判定可能な場合、必要 VRAM と空き VRAM を表示する。

起動前検証

POST /api/language-mode/train と POST /api/language-mode/train/start は、ジョブ作成前に同じ検証を実行する。容量が既知で、必要量が空き量を超える場合は HTTP 422 を返す。

{
  "detail": {
    "message": "現在の GPU 空きメモリでは、指定された LanguageModel 構成を開始できません。構成は変更されていません。",
    "capacity": {
      "checked": true,
      "fits": false,
      "gpu_index": 0,
      "gpu_name": "CUDA GPU 名",
      "available_mb": 5923.0,
      "required_mb": 6144.0,
      "optimizer_mb": 0.0,
      "activation_mb": 0.0,
      "reserve_mb": 512.0,
      "effective_seq_len": 64
    }
  }
}

数値は構成と実行時の GPU 状態により変化する。422 を受けたクライアントは、元の入力値を保ったまま利用者に調整を求める。

見積もりの対象と選択 GPU

対象は dense_chronospike のみである。sparse_event_memory は別のメモリモデルを使用するため、容量照会は checked: false と理由を返す。GPU メトリクスを取得できない場合も同様に未判定として扱い、Core の通常の CUDA 利用可否検証へ委ねる。

Core は DEVICE=cuda で論理 CUDA device 0 を使用する。Mineral は同じ可視性設定を解釈し、CUDA_VISIBLE_DEVICES、未設定時は NVIDIA_VISIBLE_DEVICES の先頭に対応する物理 GPU を見積もる。指定が all または未設定なら、通常は GPU 0 を対象とする。

見積もりは Tokenizer 名から推定した語彙数、d_model、block 数、time_steps、batch size、シーケンス長、optimizer state、activation、予約領域を含む。dense モデルの概算パラメータ数は次を用いる。

\[P = 2Vd + V + d + 1 + B(12d^2 + 9d)\]

ここで \(V\) は語彙数、\(d\) は d_model、\(B\) は block 数である。optimizer 領域、activation 領域、5% の追加 headroom と、総 VRAM の 5% または 512 MiB の大きい方の予約領域を合算する。

Core は seq_len を含む提出構成を変更しない。そのため Mineral は要求された sequence length 自身を見積もりに使う。収束の既定値は seq_len=64、learning rate は \(10^{-4}\) だが、これらは UI/API の初期値であり、Core による隠れた上書きではない。

ハードウェア移植性

容量判定は RTX 2070 など特定 GPU の固定上限ではない。現在 Core が使用する可視 GPU の空き VRAM に対して毎回評価するため、十分な空きメモリを持つ H100 上では同じ構成を許可できる。

ただし現行の dense LanguageModel 学習は、複数 GPU の VRAM を合算したり自動 shard したりしない。H100 を 8 台公開していても、判定対象は可視リストの先頭 GPU である。特定 GPU で実行したい場合は、Mineral と Core で同じ CUDA_VISIBLE_DEVICES / NVIDIA_VISIBLE_DEVICES を設定する。分散学習・VRAM 集約は別機能として設計する。

運用上の制約

• 容量見積もりは起動時点の空き VRAM に基づく予防検査であり、保証ではない。照会後に別プロセスがメモリを確保する TOCTOU 競合や、CUDA/PyTorch の一時 workspace により実行時 OOM が起こる可能性は残る。
• 実行時 OOM が起きても、Core は構成を自動変更して再試行しない。失敗内容を記録し、利用者またはスケジューラが新しい明示的な構成で再実行する。
• この導入は実行中ジョブの request、artifact、batch size を変更しない。
• Docker 再起動を伴う本番反映と、実 GPU での継続運用検証は別作業である。

受入基準

1. 容量不足の dense 構成は、入力 batch_size を変更せずに不適合と判定される。
2. 容量見積もりと Core 実行は、同じ提出済み seq_len を使用する。
3. 容量不足の起動要求は、構造化した capacity 情報を含む HTTP 422 で拒否される。
4. 同じ構成は、十分な空き VRAM を持つ GPU では許可される。
5. UI は容量不足時に必要量と空き量を示し、学習ボタンを無効化する。

関連文書

• LanguageModel アーキテクチャ互換性・アーティファクト契約
• LLM Training System
• EvoSpikeNet ユーザーマニュアル
• 機能実装ステータス
• English version