サーバーがアイドル状態になった後、ローカルLLMの初回トークン遅延が増加するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Local LLM First-Token Latency Rise After the Server Sits Idle? - Zima Store Online

初回トークンのレイテンシは、アイドル状態の後に上昇することがよくあります。これは、次のリクエストで、ウォーム状態のリクエストが再利用するモデル、メモリ、アクセラレータ、電力状態を再構築する必要があるためです。

家庭用AIサーバーは、繰り返し送るプロンプトには素早く応答できても、翌朝に最初のリクエストを送ると遅く感じることがあります。モデル自体はディスク上に残っていても、そのページ、GPU割り当て、カーネル、実行コンテキストがウォーム状態でなくなっている可能性があります。どの程度の遅延が再発するかは、ストレージ速度、メモリ負荷、ランタイムによる追い出し、デバイスの電源管理、プロンプトの長さによって決まります。

アイドル時間によって、複数の異なるウォーム状態が失われる

ウォーム状態のリクエストでは、RAMやVRAMにすでに常駐している重み、OSが保持しているファイルシステムのページ、初期化済みのアクセラレータライブラリ、コンパイル済みカーネル、メモリプール、稼働中のモデルワーカーを再利用できます。アイドル時のクリーンアップでは、1つの層だけが削除される場合もあれば、プロセス全体が終了する場合もあります。

マルチティアのチェックポイント読み込みは、チェックポイントをアクセラレータの近くに保持し、複数のストレージ層を介して読み込み、モデルの状態がすでにローカルにある場所でリクエストをスケジューリングすることで、サーバーレスモデルの起動を高速化します。この設計は、コールド時のレイテンシが単一のディスク読み込み時間ではなく、転送と初期化の一連の工程であることを示しています。

実際に観測される遅延は、どの層がコールド状態になったかによって異なります。プロセスが稼働し続けていた場合はデバイスのクロック上昇だけで済むことがありますが、追い出されたモデルでは、重みの読み込み、デバイスメモリの割り当て、ランタイム構造の再構築を行い、その後でプロンプトを処理してからでなければトークンを出力できません。

モデルの読み込みとプレフィルによって、トークンが表示される前に遅延が積み重なる

初回トークンまでの時間には、キュー待ち、重みの利用可能化、ランタイムの初期化、トークン化、入力全体に対するプレフィルが含まれます。プレフィルによって最初のデコード状態が生成されるまで出力トークンは存在しないため、デコード速度が速くても、これらの工程を隠すことはできません。

GPUメモリの再利用は、未使用のGPUメモリにパラメーターを保持し、アフィニティを考慮したスケジューリングを用いて、転送の繰り返しを減らします。報告されたコールドスタートの改善結果は、サービスがすべてのモデルを完全にロードしたままにできない場合でも、部分的な常駐状態を維持することが重要になり得る理由を示しています。

そのため、重みがウォーム状態でも長いシステムプロンプトでは遅いままになることがあり、短いプロンプトでもコールド状態のモデル読み込みで停止することがあります。読み込み時間、初期化、プレフィル、初回デコードを分けて計測することで、平均化された1つのTTFT値によって実際のコールド要因が隠れるのを防げます。

電力節約は通常、より小さいものの測定可能な要因

CPU、GPU、NVMeデバイス、PCIeリンクは、非アクティブ時に低電力状態へ移行することがあります。最初のバースト処理では、クロックを上げてアクティブな経路を復元する必要があるため、継続的な計算が始まる前に短い立ち上がり時間が加わります。ホストのスリープ設定が積極的な場合は、サービスやディスクが一時停止して、さらに大きな遅延が発生することがあります。

コールドスタート工程のオーバーラップは、エッジLLMのコールドスタートにおいて、モデルの読み込み、通信、計算を重ねて実行します。この研究は、1つの起動工程を隠すには他の工程との調整が必要であり、特に重みと計算処理が制約のある複数のデバイスに分散している場合に重要であることを示しています。

問題となるのは、最初の応答が遅い原因をすべて電力状態のせいにすることです。遅延が何秒にも及ぶ場合は、ミリ秒単位のクロック遷移よりも、モデルの追い出し、ストレージ読み込み、コンテナの起動、プロンプトのプレフィルが主な原因であることがほとんどです。デフォルトですべての省電力機能を無効にするのではなく、タイムラインを計測して原因を特定してください。

Featured

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

ZimaCube2

コールドスタートとコールドプロンプトのコストを分ける

固定した短いプロンプトを、アイドル時間が0分、1分、10分、60分、480分の状態でそれぞれ1回送信します。各間隔について、プロセスの稼働時間、モデルの常駐状態、RAMとVRAMの使用量、読み込みバイト数、デバイスクロック、キュー時間、トークン化、プレフィル、初回デコード、合計TTFTを記録します。

モデルのコールドスタート用ストレージでストレージ層を比較し、次にワーカーを固定する、ファイルシステムキャッシュだけをウォームアップする、ホストRAMだけをウォーム状態に保つ、プロンプトの長さを変える、といった条件で再度テストします。各実行では、すべての最適化を組み合わせるのではなく、1つの状態層だけを変更してください。

他のサービスを圧迫することなく、繰り返し発生するアイドル時間の後でも必要なTTFTを維持できる場合にのみ、サーバーをウォーム状態とみなしてください。モデルを固定することでメモリ負荷が高まったり、優先度の高いワークロードが妨げられたりする場合は、トレードオフを隠すのではなく、許容範囲を定めたコールドスタートを受け入れ、その状態を明示してください。