AIキャッシュの性能は、信頼境界の内側で測る

Cloudflareは2026年10月26日、同社のGLM-5.3環境で8月27日から9月9日にかけてリクエスト間のデータ露出が発生したと公表した。他のWorkers AIモデルへの影響はなかったとしている。同社報告。

これは特定の事故であり、共有型の推論サービスすべてが情報を漏らすという証拠ではない。ただし調達に際して、より広い問いを投げかける。推論が高速化したという測定で、どの境界が維持されていたのか。顧客が許可した仕事をサービスが引き続き行ってこそ、速度には価値がある。

顧客間の分離もワークロードに含める

二つの会社が使う、架空の文書アシスタントを考えてみよう。どちらも契約書の要約を依頼し、同じ公開指示を使う。しかし非公開の文書は異なる。これらを処理しやすい一つの集団にまとめた性能試験は、魅力的な結果を示しても、顧客が実際に求める機密性を表していないかもしれない。

本稿の分析上の提案は、共有を許される集団をワークロードの定義に入れることだ。試験中の仕事は一人、一チーム、一組織、それとも互いに無関係な組織に属するのか。これらは同じ条件ではない。同じ企業の中でも、法務調査と通常の顧客対応では異なるアクセス境界が必要な場合がある。

すると比較表の読み方も変わる。一方の試験が広範な再利用を認め、もう一方が部門ごとに分離しているとしよう。前者の遅延が小さいだけでは、実装が優れているとは言えない。提供するサービスの条件が違う可能性がある。まず許される共有範囲を合わせ、その内側で性能を比べるべきだ。

共有そのものを否定しているわけではない。全員が閲覧できる公開指示の再利用は合理的な設計になり得る。問題は、便利な技術上の分類が、十分に検討されない権限の決定へと変わることだ。同じモデルや請求アカウントを使うこと、質問の表現が似ていることだけで、どの仕事が派生状態を共有すべきかは決まらない。

顧客が購入するのは一回の回答だけでもない。混雑時、仕事の終了後、利用方法の変更後も、同じ境界が維持されることを期待する。分離条件は性能報告の片隅の注記ではなく、タスクの種類、入力規模、受入基準とともに結果を解釈する前提になる。

回答が返ることだけでは受入試験にならない

SGLangの10月26日の公表は、拒否されたリクエストが分離処理の引き渡しへ進み、そのリクエスト用に埋められていないキャッシュページを読む問題を説明する。寿命管理の対策は別途論じている。保守者の報告。

本稿の分析で重要なのは、意図的な計算の再利用と、別のリクエストの状態への意図しない接触は異なる問題だという点だ。前者を管理する規則が後者も防ぐとは限らない。調達側は、許可する構成に加えて、仕事が正常に進まないときも実装がその条件を守るという証拠を必要とする。

実際の顧客資料ではなく、架空の文書を使う管理された受入演習を考えられる。一つの試験群に固有のプロジェクト名を与え、別の群にはその閲覧権限を与えない。評価者は、誤った群の情報が回答へ入らないかを調べると同時に、正当な要約が有用かも確認する。これは許可された試験の設計案であり、特定サービスの本番障害率を推定するものではない。

拒否、中断、再試行も、顧客が経験するサービスの一部として試験に含めるべきだ。形式が正しく、最後まで順調に完了する仕事だけでは、公表結果と運用上の問いの間に空白が残る。一方、試験への合格も、あらゆる漏洩可能性が消えた証明ではない。指定した構成、場面、観察期間についての証拠である。

したがって、有用な報告は三つの結果を分ける。許可され有用な回答、明示的な拒否または失敗、そして現存する権限では生成されるべきでなかった回答だ。返った内容をすべて一つの成功率に平均すれば、最も重要な違いが見えなくなる。出所を誤った流暢な回答より、理由の明確な失敗が顧客の利益にかなう場合もある。

この区別は最適化チームの動機にも関わる。エラー削減だけを目標にすれば、より多くの仕事に内容を返す方向へ傾き得る。許可された有効な結果を目標にすれば、一部の仕事を終了させることが正しい場合もある。これは受入目標の設定に関する議論であり、特定の供給者の動機を非難するものではない。

境界を固定してから効率を比較する

別の設計例として、vLLMの文書は任意のリクエスト用ソルトにより、同じソルトを持つリクエスト間にプレフィックスキャッシュの再利用を制限する方法を示す。すべての寿命管理上の欠陥への対策ではない。vLLM文書。

調達上の示唆は、その実装を義務付けることではない。購入側が説明でき、運用側が検証できる共有規則を求めることだ。アプリケーション責任者は、同じプロジェクト内の再利用を認めつつ無関係な顧客を分けるかもしれない。別の責任者は、共有されるリクエスト由来の状態を減らすため、多少遅いサービスを選ぶかもしれない。秒間トークン数だけでは両者を評価できない。

合理的な反論もある。分離を細かくするほど共通基盤の経済的な利点が減り、複雑な試験は導入を遅らせる可能性がある。その取引条件は隠さず明示すべきだ。比較すべきなのは同じ分離要件を満たす設計の遅延、容量、運用負担である。分離されたサービスと、同じ制約のない測定を同等の製品として比べることではない。

後にチームがアクセスモデルを変えるときにも同じ原則が当てはまる。二つのワークスペースの統合は新しい共有機会を生み、参加者の削除は範囲を狭めるかもしれない。本稿が提案する管理では、ユーザー一覧の編集だけでなく、性能上の前提の見直しも必要になる。高速な設定に価値があるのは、権限が現在の仕事に適している間だけだ。

これらの公表は、あらゆる顧客に最良の構成を決めるものではない。むしろ評価者に、必要な分離を明示して検証した後に、どれだけ有用な処理能力が残るかを問わせる。信頼境界から切り離された速度の数字より、それが推論サービスを選ぶ意味のある基準となる。