SubquadraticのSnap、384kトークンウィンドウで長文脈の意思決定に対応

サンフランシスコに拠点を置くスタートアップSubquadraticは、1回のリクエストで最大384,000トークンを処理できる新しい意思決定モデル「SubQ Snap」を立ち上げました。今回のリリースは、最近の競合他社と比較してコンテキスト容量の大幅な拡大を示しており、チャンク分割なしで大規模なコードベースやドキュメントセットにわたる複雑な推論タスクを処理することを目指しています。

何が起きたか

この発表は、オープンエンドなテキストを生成するのではなく、事前定義された回答から選択を行うAIシステムの特殊なクラスである「意思決定モデル」への関心の高まりを受けて行われました。9月中旬に32,000トークンの制限付きでリリースされたTypeSafeのJevモデルがこのトレンドを引き起こし、OpenAI、Microsoft、Amazonなどの主要テクノロジー企業が参入するきっかけとなりました。SubquadraticはSnapをこの概念の直接的な進化形として位置づけ、Jevの12倍のコンテキストを処理できると主張しています。

SubquadraticのCEOであるAlex Whedon氏は、JevがSnapのインスピレーション源となったものの、新しいモデルは高価なフロンティア大規模言語モデル（LLM）から substantial な作業負荷を軽減するために構築されたと述べています。AIエージェントのワークフローにおけるすべてのステップで巨大な汎用モデルを使用する代わりに、Snapは管理上の重労働を担当します。これにはツールの選択、関連ファイルの特定、テスト結果の評価などが含まれます。同社は、必要な情報が小さなコンテキストウィンドウを超えると現在の意思決定モデルが苦戦し、開発者が潜在的に重要なデータを破棄せざるを得なくなると論じています。

Snapは現在パブリックプレビューで利用可能です。同社はサービスを入力トークン100万あたり$0.05で提供しており、出力については課金していません。Whedon氏は、モデルが入力を読み取り、許可された回答に対する確率スコアのみを返すため、計算コストはテキスト生成よりもコンテキスト処理に大きく偏っていると説明しています。フルの384,000トークンリクエストのコストは約2セントです。

仕組み

Snapは、同社が5月に導入したアーキテクチャであるSubquadratic Sparse Attention (SSA) に依存しています。従来のトランスフォーマーモデルは注意機構（アテンション）を二次的に計算するため、入力長が増加すると計算負荷が劇的に増加します。SSAはこの関係を、コンテキスト長に対して注意機構の要件が線形に増加するように変更します。これにより、標準的なアーキテクチャで見られる指数関数的なコスト急増なしに、数十万トークンを効率的に処理できます。

このモデルは、積極的な要約や細粒度のチャンク分割といった脆弱な前処理ステップを排除するように設計されています。AIエージェントがバグを修正する必要がある場合、モジュール全体、ログ、ドキュメントを一度にSnapに投入できます。モデルは全コンテキストを分析し、編集すべきファイルや次に呼び出すツールなどの意思決定を行います。384,000トークンを超えるコーパスには依然として検索システムが必要ですが、Whedon氏は、より大きなウィンドウにより粗い検索が可能になり、慎重にトリミングされたスニペットではなくドキュメント全体を取得できるようになると指摘しています。

主要な詳細

• Snapはテキストと画像に対して最大384,000トークンのコンテキストウィンドウをサポートしていますが、社内では100万トークンでのテストも実施済みです。
• モデルは100,000トークンを処理し、約1秒で意思決定を返します。
• 複数ドキュメントにわたる推論をテストするDecision LCRベンチマークにおいて、SnapはJevの48.0に対し74.0のスコアを記録しました。
• Subquadraticによると、Snapはエンタープライズ向けベンチマーク16項目中13項目でJevを上回り、平均スコアは67.6対61.6でした。
• パブリックプレビューの384,000トークン制限は、現在のコンピューティング能力によるものであり、100万トークンを公開サポートするには2.6倍の計算資源が必要です。
• Snapは最新のDecision Indexリーダーボードにはまだ掲載されていません。これは現行バージョンがオープンウェイトモデルに焦点を当てており、非公開テストが含まれているためです。

なぜ重要なのか

AIエージェントを構築するエンジニアにとって、主な利点は複雑性とコストの削減です。現在、コンテキスト管理には検索拡張生成（RAG）、要約、チャンク分割の複雑なパイプラインが含まれます。これらのステップは、微妙だが重要な詳細を省略することでエラーを導入することがよくあります。エージェントが生データの大規模な部分を専門的な意思決定モデルに直接渡すことを可能にすることで、開発者はアーキテクチャを簡素化できます。これにより、前処理中に重要なコンテキストを失うリスクが低減されます。

コスト効率もまた重要な要素です。フロンティアLLMを実行ループ内のすべての些細な意思決定で使用するのは高額です。これらの頻繁かつ低レベルな選択肢を、Snapのような安価で高速なモデルにオフロードすることで、運用経費を大幅に削減できます。Snapが大規模コンテキストを処理しながら高い精度を維持できれば、エージェントはトークン制限や予算上限に達することなく、より大きなデータセット上で自律的に動作できるようになります。

ただし、これらの主張は主に内部ベンチマークに基づいています。Subquadraticは適応させた長文脈評価用のコードを公開しましたが、独立した検証はまだ待たれています。開発者は、パフォーマンス上の優位性を有望ではあるが、外部データがさらに入手可能になるまで第三者環境では未実証であると捉えるべきです。

できること

• 現在のエージェントワークフローに、より大きなウィンドウによって簡素化できる頻繁なコンテキスト切り詰めや複雑なチャンクロジックが含まれているかどうかを評価してください。
• コードベースナビゲーションやマルチドキュメント分類など特定のタスクでSnapのパブリックプレビューをテストし、現在のスタックと比較してレイテンシと精度を確認してください。
• 意思決定ステップにフロンティアLLMを使用する場合と、Snapに入力トークン100万あたり$0.05を支払う場合のコスト差を計算してください。
• 公開された評価コードを検討し、Subquadraticが長文脈保持をどのように測定しているかを理解し、それらの指標があなたのユースケースに合致するか判断してください。
• Decision Indexリーダーボードの今後の更新を監視し、Snapが将来の独立ランキングに掲載されるかどうかを確認してください。
• Snapが広範なコンテキスト分析を担当し、より小さく高速なモデルが即時かつローカルな意思決定を担当するハイブリッドアプローチを検討してください。