Basetenのエンジニアリングチームは、デルタ重み同期システムの最新の進歩を公開した。約770GBのGLM-5.3チェックポイントの同期は、平均約36秒から15秒に短縮され、リクエストの一時停止は6秒から0.8秒になった。スループットは最大3.2倍向上し、CPUメモリの制約で以前は実行できなかったKimi K3の強化学習ロールアウトも可能になった。
従来のデルタ重み同期では、CPU上のコピーをデコードの基盤として保持する必要があった。トレーナーは完全なチェックポイントとスパースなデルタをオブジェクトストレージに公開し、各デルタテンソルは親バイトと新バイトのXORをzstdで圧縮したものだった。ロールアウトクラスタはBaseten Delivery Network経由でオブジェクトを取得し、新しいポリシーを再構築してGPUをインプレースで更新する。しかし旧設計では、XORバイトを新しい値に変換するために、各レプリカが完全な親チェックポイントをホストメモリに保持し、更新のたびにCPUコピーを修正する必要があった。
このCPUコピーは三つのコストをもたらした。第一にメモリ。GLM-5.3の完全な親は約770GBで、8基のB300を搭載したノードでは1.1TBのホストKVキャッシュと共存できず、キャッシュを275GBに縮小せざるを得なかった。第二に時間。CPUコピーを新しいポリシーに昇格させるのに更新ごとに約45秒かかり、次のデルタをブロックしていた。第三に二重の真実の源。各更新はGPUとCPUコピーの両方に反映されなければならず、さもなければ次のデルタが誤った親に対してデコードされてしまう。
新しい設計の核心は、GPUがポリシーNの全バイトをすでに保持しているという事実にある。必要なのは、変化する少数のバイトを読み取る方法だけだった。起動時にモデルをローカルディスクからロードし、エンジンの実際のGPUレイアウトに従って各サービングテンソルを検証し、テンソルごとのAdler-32チェックサムを記録してから、ローカルコピーを削除する。以後、GPUメモリが唯一の親となる。
デルタが到着すると、ネイティブデコーダはzstdのコマンドを直接走査し、非ゼロのXORバイトのみを保持する。各変更要素について、その位置とXORマスクを記録する。密なXORテンソルを具現化することはなく、モデルの重みも読まない。古いポリシーがサービスを続ける中、各GPUワーカーは変更位置の古い値のみを収集し、XORマスクを適用して絶対的な新しい値を得て、トレーナーのチェックサムで検証し、エンジン固有のテンソルレイアウトの書き込み計画にその値を封入する。
チェックサム検証も専用の最適化が施された。トレーナーは変更された各テンソルの新バイトのAdler-32を公開する。素朴に検証するとテンソル全体を再ハッシュすることになり非効率だ。Adler-32では各バイトの寄与が位置と値のみに依存するため、変更バイトの影響は定数時間で計算できる。起動時に記録したチェックサムから始め、変更バイトごとに補正を一度加え、トレーナーの値と比較する。変更されていないバイトは決して読まれない。この最適化により更新全体が最大2.3倍高速化され、例えばKimi K3の30GBデルタでは約230秒から約100秒に短縮された。同時に、破損したダウンロードや誤った親はGPU書き込み前に拒否される。
広範な事前準備により一時停止の目的は、停止中に行う操作を最小化することにある。現在の停止は三つのステップのみだ。アドミッションを閉じて実行中のリクエストをその場で一時停止する。新しい値をインプレースで書き込み、派生重みを更新する。新しいポリシーバージョンを公開し、アドミッションを再開する。GLM-5.3では停止時間は0.8秒で、以前は6秒だった。45秒のCPU昇格もなくなったため、次のデルタは到着次第すぐに適用できる。
さらなる最適化は、更新処理がサービスとGPUやCPUを共有する問題に対処する。並列性を意識したデルタデコーダは、テンソル並列とエキスパート並列の下で各変更を所有するGPUに分割し、各GPUは変更を自身のパック済みレイアウトのアドレスに直接マッピングする。swizzled FP8やFP4のスケールファクタにも対応する。SGLangのスケジューラがPythonイベントループであるため、プロセス内のCPU負荷の高い処理はGILを巡って競合しバッチスケジューリングを停止させる。そこで更新計画はCUDAを使わない別のヘルパープロセスで実行し、共有ピンドメモリを介してGPUワーカーとバルクデータを交換する。ダウンロードとデコードはパイプライン化され、各シャードは到着次第デコードされる。デコーダはサービング用に16コアを残すようサイズ設定された、永続的な低優先度のネイティブスレッド上で動作する。
Kimi K3のケースは特に重要だ。サービング時のMXFP4レイアウトで1.7TBのサイズを持つ。CPUチェックポイントを保持する場合、各GB300ノードは重みの半分だけで約838GBのホストメモリを必要とし、サービングコンテナのメモリ制限をほぼ使い切ってしまう。GB300はハードウェアが事前設定されているため、これは厳しい制約だ。現在、Kimi K3は各4基のGPUを搭載した2台のGB300ノードで動作する。各ノードは自身が所有するテンソルのみをデコード、検証、ステージングし、他方のノードの重みを保持することはない。両方のノードが正常に書き込みを完了して初めて、新しいポリシーが公開されリクエストが再開される。8.4GBのデルタでは、Kimi K3は同期リクエストから重みの反映まで75秒、停止時間4.1秒で完了する。
解放されたホストメモリはKVキャッシュのオフロードに再利用される。退避されたGPU KVページは破棄されるのではなくホストメモリに書き戻され、同じプレフィックスを持つ後続のリクエストはprefillを再実行する代わりに再ロードする。RLロールアウトのマルチターンで長い共有プレフィックスを持つ場合、退避された150kトークンのプレフィックスをCPUメモリから再ロードするのに0.48秒かかり、新規prefillの4.9秒と比べて大幅に短い。AgentXベンチマークでは、並行数16ではKVキャッシュがGPUに収まるため両方式に差はない。並行数48ではエージェントのプレフィックスがGPUメモリに収まらずホストメモリには収まるため、オフロードによりミスがヒットに変わり、ヒット率は2%から92%に跳ね上がり、GPUあたりの出力スループットは3.2倍向上した。
すべての結果は単一レプリカ、トレーナー形状の固定デルタで測定され、トレーナーのデルタ同期リクエストからレプリカが新しいポリシーを提供するまでの時間、すなわちS3マーカーから最初の新しい応答までの時間で計測されている。チームは、このソリューションをトレーニングスタックに導入したいユーザーはRLロールアウトのドキュメントを参照するかチームに連絡するよう呼びかけている。