継続学習は、静的なモデルから、すべてのインタラクションによって進化するモデルへのシフトを表しています。従来、モデルは四半期ごとにリリースされ、ユーザーは問題に遭遇してから改善を数ヶ月待つ必要がありました。BasetenとTrajectoryが協力して構築した推論パイプラインは、この状況を変革します。トレーニングが完了したばかりのLoRAアダプターを約1時間でA/Bテスト可能で完全なプロビナンス追跡付きのエンドポイントとしてデプロイします。
パイプラインは複数の重要な段階で構成されています。まず、トレーニングが完了したチェックポイントがストレージに到着します。次にマージ段階：アダプターがベースモデルにプルされ統合されます。最新のモデルアーキテクチャでは、この一見単純な行列乗算が複雑になります。融合プロジェクション（Q、K、Vプロジェクションが1つの行列を共有）、MXFP4量子化（ブロック単位のスケーリング係数を考慮する必要がある）、MoEモデル（各エキスパートのアダプターを個別にマージ）など、それぞれ異なる正確性の制約が課されます。パイプラインはすべてのマージ済みチェックポイントに対してアーキテクチャ認識の正確性チェックを実行し、サイレントに破損したモデルがトレーニングループを汚染するのを防ぎます。
マージされたモデルはBasetenのTrussフレームワークでパッケージ化され、依存関係、ランタイム仕様、サービング構成が自動処理されます。その後、Basetenカスタム推論ランタイムで検証が行われます。量子化を生存レイヤーに限定、RoPEスケーリングによる拡張コンテキスト、一致するドラフトモデルによる投機的復号など、各最適化には正確性の制約があります。継続学習のシナリオでは、新しいチェックポイントが毎時間到着するため、検証失敗はデプロイ前に自動的にキャッチされ、ユーザーが遭遇する前に修正されます。
デプロイ段階では、継続学習の重要な革新が現れます。新しいチェックポイントはバージョンアップではなく実験的バリアントとして扱われます。ルーティング層は旧バージョン（対照群）と新バージョン（実験群）の間でトラフィックを分割し、テレメトリを分離してリアルタイム比較を可能にし、データが優位性を示した場合のみロールアウトします。同じルーティング層はマルチテナント分離も処理し、各モデル、ルート、APIキーが特定の顧客にスコープされます。
エンドポイントが稼働すると、すべてのリクエストが完全なプロビナンス（応答したモデルバージョン、デプロイ日時、トレーニングラウンド）とともにログ記録されます。推論は継続学習モデルの最終状態ではなく、次のトレーニングラウンドのソースとなります。パイプライン全体のエンドツーエンド実行時間は約1時間で、トレーニングの有効性を維持するのに十分短く、チームはさらなる短縮に取り組んでいます。
将来の課題は2つあります。1つ目はマルチLoRAサービングです。現在は各アダプターをデプロイ時にマージしていますが、目標はベースモデル常駐型アーキテクチャでリクエストごとにアダプターを選択し、多数の顧客固有モデルのサービスコストを削減することです。2つ目は継続的にトレーニングされたドラフトモデルです。オフラインでトレーニングされたドラフトモデルはメインモデルの変化に追随できず、リフレッシュレートが上がるほど問題が悪化します。投機的復号を維持するには、各デプロイチェックポイントに対応するドラフトモデルを同時にトレーニングする必要があります。
継続学習が研究から製品へと移行する中、BasetenとTrajectoryはこのパラダイムを支えるプラットフォームインフラストラクチャを構築しています。これは始まりに過ぎず、今後はループを数分に短縮し、単一の製品で数百の異なるモデルをサービスする未来に向けて進化し続けます。