Temporalの履歴リプレイを捨て、継続をチェックポイントする新しい耐久実行モデル
Durable execution without history replay

耐久実行システムは通常、失敗後に履歴をリプレイして現在位置を再構築する。しかし長時間動くAIエージェントでは、蓄積された履歴が回復経路の負担になる。筆者は、コンパイラとランタイムがライブ継続を直接チェックポイントするTCC(Transparent Continuation Checkpointing)を提案。予備評価では、ライブ状態を約4KBに固定しつつ境界深度を10から1,000へ増やしたとき、TCCの回復は約0.6〜0.9ミリ秒でほぼ一定だったのに対し、Temporalのリプレイ再構築は約61ミリ秒から1.7秒に増加した。ただしこれは特定条件下での回復スケーリングの違いを示すもので、一般的な高速化を主張するものではない。
履歴リプレイは現在位置を再構築する。TCCはコミットされた継続をロードして実行状態を復元し、再開する。
HNでの議論
11- weitendorf
良いモデルだ。実際にモデルを訓練したり、エージェントシステムを設計したりすることに興味がある人は、これをやるべきだ。
私の会社はこの問題に取り組むことから始まった。なぜなら、これがプログラミングモデルの訓練方法や、LLMを特定のタスクで確実にデプロイする方法の基盤だからだ。これのおかげで、LLMに対するはるかに優れたメンタルモデルを築くことができた。なぜなら、「チャット」の中では一貫したペルソナや一貫した知識・能力を持っているように感じられるが、その外ではLLMが実際にはどれほど奇妙に気まぐれで、一貫性がなく、好みがうるさいかを目の当たりにしたからだ。
当初は、特定のタスクを完了する能力を引き出すためのプロンプトの探索だと考えていたが、今では速度・信頼性・運用面(例えば、性能を落とさずにモデルを切り替えられるか?)のメリットの方が、ほとんどのユーザーにとってさらに大きいと思う。
ちょっとした「秘密」を言うと、ラボがこの方法でモデルを使うことさえ難しくしているし、これがもっと広く理解されることが重要だ。分布を考慮したリプレイ/再サンプリングは、LLMのポストトレーニングにおける重要なテクニックだ。しかし、これはタスクの一部のサブセットに対して最適なモデルを自動的に特定できるようにするものでもあり、多くのコストを節約できる。
- orbital-decay
Durable executionは全般的に少しバズワードのように見える。もし状態が実行グラフ内で定義されているなら、それは既存のアルゴリズムやパターンのグループを指す単なる傘用語にすぎない。もし定義されていないなら、何に再開するというのか?クラッシュ直前のスナップショットはおそらく再び未定義の状態につながり、その場合、クラッシュを永続的に自動化していることになる(あるいはさらに悪いことに、捕捉されない不正な動作を)。
- alex_hirner
プログラムのスナップショットは、https://github.com/pydantic/monty が可能にし、目指していることでもある。
参考までに、AI対応のインタプリタが増えていくと思う。ある意味、それが伝統的なマイクロサービスアーキテクチャに挑戦するのは面白いと思う。