ローカルAIサービスがモデルを切り替えた後に、初回トークンのレイテンシーが急増する原因は何ですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Causes First-Token Latency Spikes After a Local AI Service Switches Models?

モデル切り替え後に初回トークンのレイテンシが急増するのは、通常、選択した新しいモデルがプロンプトを処理できるようになる前に、常駐状態を再構築する必要があるためです。

ホームAIサーバーは、ウォーム状態の1つのモデルには素早く応答できても、ビジョンモデルやコーディングモデルに切り替えると、初回トークンの前に一時停止することがあります。この遅延には、重みの読み込み、非量子化、デバイス転送、カーネルコンパイル、CUDAグラフのキャプチャ、キャッシュの割り当て、プロンプトのプリフィルなどが含まれます。どの段階が支配的になるかは、ストレージ、利用可能なアクセラレータメモリ、ランタイムポリシー、以前のモデルが完全に追い出されていたかどうかによって異なります。

コールドな重みの読み込みが最初の原因群

次のモデルがRAMまたはVRAMに存在しない場合、サーバーは1つ以上のチェックポイントシャードを読み込み、検証またはマッピングを行い、テンソルを構築して、使用可能な重みを実行デバイスへ転送する必要があります。ファイルが大きいほど、またNAS経路が遅いほど、推論を開始する前の一時停止が長くなります。

LLMのコールドスタートレイテンシの測定では、モデル状態がコールドな場合、起動時間がTTFTの大部分を占める可能性が示されています。この症状は、プロンプトのプリフィルカーネルが実行される前に、大量のストレージ読み込みとモデルローダー処理が発生する形で現れます。この違いは、その後の家庭環境でのテストでも確認できます。

両方のモデルが常駐している状態で2つのモデルを切り替えても同じ急増が発生するなら、重みの読み込みだけでは完全には説明できません。遅いリクエストに伴って読み込まれたバイト数と常駐モデルの状態が変化するかどうかが、判別のポイントです。

ランタイムの初期化が2つ目のコールドパスを生む

読み込み済みのモデルでも、運用上はコールドな場合があります。ランタイムは、アクティベーション後の最初のリクエストで、デバイスコンテキストの初期化、カーネルの選択、形状のコンパイル、グラフのキャプチャ、KVブロックの割り当て、トークナイザーやプロンプトテンプレートのキャッシュ構築を行うことがあります。

モデルストリーミングとウォームアップに関するエンジニアリング分析では、ストレージストリーミングと初期化・ウォームアップが分けて扱われています。段階の特徴は、チェックポイントI/Oが少量である一方、プロンプト処理の前にコンパイル、割り当て、またはアクセラレータのアクティビティが続くことです。自動化を進める前に、中間結果を確認できる状態にしておく必要があります。

モデルの形状、量子化バックエンド、コンテキスト上限、バッチプロファイル、ドライバーの状態によって、再利用できるアーティファクトが決まります。すぐに切り戻す場合はキャッシュが残っていれば高速ですが、メモリ圧迫によって追い出されると、同じ経路が再びコールドになります。

キュー待ちとプリフィルがモデル読み込みの遅延に見えることがある

切り替えリクエストは、モデルの停止、メモリ回収、別のユーザー、または長いプロンプトの後ろで待機することがあります。受け付けられると、プリフィルではデコード前にすべての入力トークンを処理するため、履歴が長いほどモデル読み込み時間を変えずにTTFTが増加します。この境界は、現実的な運用条件で個別に測定すべきです。

ページ化KVキャッシュの受け入れに関するサービング設計では、アクティブなシーケンスがページ化されたKVブロックを消費する仕組みと、利用可能なキャッシュ容量に応じて受け入れが決まる仕組みが説明されています。そのため、切り替えによってキャッシュ予約が変わると、チェックポイントのサイズとは無関係にキュー時間が変化する可能性があります。

障害の境界は、ウォーム状態で常駐し、初期化も安定しているモデルにおいて、プロンプトの長さまたは同時実行数に連動してレイテンシが急増するケースです。この場合、モデル切り替えは単なる相関であり、直接の原因はプリフィルまたはスケジューリングです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

TTFTを読み込み、ウォームアップ、キュー、プリフィルに分ける

固定したプロンプトを再生し、モデルの追い出し、チェックポイントのバイト数、ストレージスループット、ホストからデバイスへの転送、デバイスコンテキストの作成、カーネルコンパイル、グラフキャプチャ、KV割り当て、キュー待ち、プリフィル時間、最初のデコードステップを、1つの単調増加する時計で記録します。複数の要因が限られたコンテキストを奪い合う場合に、実際の影響が現れます。

メモリによるモデルルーティングとトレースを比較し、コールド切り替え、直後の切り戻し、常駐するデュアルモデルルーティング、短いプロンプト、長いプロンプトを個別にテストします。意図した状態だけが変わるように、サンプリング、クライアント、同時実行数を維持します。この依存関係は、最終的なインターフェースでも明示したままにしてください。

急増の原因を、最初に拡大した段階に割り当てます。読み込みが支配的なら重みを常駐させ、初期化が支配的なら互換性のあるアーティファクトを保持し、切り替え自体ではなくキューイングまたはプリフィルがTTFTを決めているなら、受け入れ条件またはコンテキストポリシーを変更します。