いやはや、これが現実だ。それっぽいAIエージェントを開発している人間なら、その苦しみは身に染みて分かっているはずだ。単一のクエリで燃え尽きるトークン代だけでなく、その後の延々と続く会話のコストが、まさに「無限ループ」のように積み重なっていく。これまでの常識は、「毎回、会話全体を再生する」という、実に単純明快、そして致命的な発想だった。結果、コストは二次関数的に増大する。API料金、諸君、これはもう制御不能なレベルにまで膨れ上がっていたのだ。クロード・オーパスのようなモデルで、たった一日の作業が月間予算を吹き飛ばす、そんな状況すらあり得た。まさに、壁にぶつかり、強打されたようなものだ。
そこで登場するのが、このBurnlessだ。まるで数行のPythonコードで世界飢餓を解決してきたかのような、そんな颯爽とした登場である。これはオープンプロトコルであり、オーケストレーションレイヤーでもある。そして何より重要なのは、あの忌まわしいO(N²)のコスト曲線を見事に、甘美なO(N)へと反転させる点だ。その計算は魔法ではない、ただ賢いだけだ。彼らの主張によれば、実際のAPI利用量を16倍削減したとのこと。つまり、90%オフ。これは、じっくり噛みしめるべき数字だろう。
悪夢の二次関数コスト
では、現在のマルチターンエージェントループのパラダイムはどうか？これはコスト面での大惨事だ。新しいターンが発生するたびに、それまでの会話履歴全体を再送信する必要がある。もしNターン目のコストがNトークンに比例するなら、Nターン全体での総コストは実にΘ(N²)にまで膨れ上がる。これは、新しい一文だけでなく、これまでに発した全ての言葉に料金を払っているようなものだ。些細なチャットを超えて、まともな利用は不可能と言っていい。
Burnless：O(N)の救世主
Burnlessは、ベンダーに依存しないオーケストレーションレイヤーとして自身を位置づけている。そのアイデアは、まず「Maestro」モデル（クロード、GPT、Gemini、あるいはローカルのLlamaでも良い）を選び、全てをオーケストレーションさせる。そして、「Workers」を特定のタスクに割り当てる。これはベンダー固有の階層ではない。品質とコストのバンド、すなわち「gold」「silver」「bronze」といった具合だ。これらを、手持ちのコマンドラインインターフェースにマッピングする。単純なタスクなら、コストゼロでローカルOllamaモデルを利用する、なんてことも可能だ。プロバイダーを好きに組み合わせる？もちろん、それもOKだ。
しかし、この二次関数的なコストを圧縮する真の決め手は、その仕組みにある。ここでは、二つの主要なメカニズムが働いている。第一に、「Shared Prefix Cache」。あの巨大なシステムプロンプト、場合によっては20,000トークンを超えるものだが、これがキャッシュされる。もし同じプロバイダーを使い続けるなら、セッション中にモデルを変更しても、プリフィックスが同一であれば無効にはならない。第二に、「Capsule History」。エージェントのメモリに生のトランスクリプトを保存する代わりに、Maestroモデルは、以前のターンを圧縮した、わずか約80文字の「カプセル」だけを保持する。これにより、二次関数の履歴項は、小さな一次関数へと収縮する。巨大なシステムプロンプトは、キャッシュ読み込み価格で課金される。これは、賢明な進むべき道だ。
結果として、二次関数の履歴項は小さな一次関数へと収縮し、巨大なシステムプロンプトはキャッシュ読み込み価格で課金される（これはAnthropicでは、新規入力に比べて約10倍安価だ）。
彼らは、Anthropic SDKを使用した再現可能なベンチマークも提供している。Claude 3 Opusを用いた10ターンセッションの場合：
- 単体（キャッシュなし）：4.66ドル
- 単体（キャッシュあり）：0.65ドル
- Burnless Maestro： 0.45ドル（-90.3%）
彼らの主張によれば、この計算は、プロンプトキャッシュを提供し、入力トークンごとに課金するあらゆるプロバイダーに適用できる。これは、普遍的な問題に対する普遍的な解決策だ。そして、そのセットアップは…まあ、Pip installして設定するだけ。簡単だ。これは単なるラッパーではない、LLMアプリケーションの構築方法における、根本的なアーキテクチャのシフトなのだ。
ベンダーアグノスティシズムこそ王道
コスト削減という利点に加え、このプロジェクトの美点は、ベンダーアグノスティックであるというコミットメントだ。config.yamlの例を見れば明らかだ。既存のCLIコマンドを文字通りドロップインできる。安価なタスクにはローカルモデルを使いたい？ それでOKだ。重い処理には特定のプロバイダーを使いたい？ それもOKだ。これらの機能を自由に組み合わせられる能力は、最適化のために極めて重要だ。これにより、開発者は単一ベンダーのエコシステムに縛られることから解放される。これは、AI分野で私たちが推進すべきモジュール性そのものだ。イノベーションを可能にし、ベンダーロックインを防ぐものだ。
これがAIエージェントの未来か？
これは、必要不可欠な進化のように思える。O(N²)というコスト構造は、複数のターンにわたってコンテキストを維持する必要があるエージェントにとって、明らかに詰まった道だった。Burnlessは、現実的な解決策を提示している。既存の技術――キャッシング、要約技術――に基づいているが、LLMエージェントの問題にエレガントに応用されている。MITライセンスにより、誰でも自由に使用・貢献できる。これは単に数ドルを節約するだけでなく、予算を破綻させることなく、より複雑で高性能なAIエージェントを構築可能にするということだ。研究、中小企業、そして個々の開発者にとって、その意味するところは大きい。
🧬 関連インサイト
よくある質問
Burnlessは具体的に何をするのですか？ Burnlessは、マルチターンLLMエージェントの会話を最適化し、APIコストを劇的に削減するオープンソースのオーケストレーションレイヤーです。システムプロンプトのキャッシュと会話履歴の圧縮により、二次関数的コストO(N²)を線形O(N)に変換します。
これは現在のLLM API呼び出しに取って代わるものですか？ Burnlessは、LLM API呼び出しを直接置き換えるものではありません。むしろ、API呼び出しを管理・最適化します。選択したLLMプロバイダーは引き続き使用しますが、Burnlessがそのやり取りをオーケストレーションし、トークン使用量とコストを最小限に抑えます。
Burnlessは無料で使用できますか？ Burnlessソフトウェア自体はオープンソースであり、MITライセンスの下で無料で使用できます。ただし、Burnlessで使用するLLM APIプロバイダーから発生するコストは引き続き発生しますが、これらのコストは大幅に削減されます。
