詳しい解説 · 読了目安 7 分
CloudflareがGLM-5.3のキャッシュ分離事故を説明、応答成功だけでは確認できない境界
10月26日の公表は8〜9月の事故に関するもの。設定とエンジンの修正、未完成の整合性対策を区別する。
- 当サイトの公開日
- 原典の公開日
- 出典確認日
Cloudflareは10月26日、Workers AI上のGLM-5.3でリクエストをまたぐデータ露出が起きた経緯を公表した。容量の不一致とSGLangの拒否処理の不具合が重なったという。9月9日に修正・復旧した事故の報告であり、新たな障害や、すべてのGLM導入に共通すると確認された問題ではない。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- 同社によると8月27日〜9月9日に155件の応答が影響を受け、すべて681,280 tokensを超えるプロンプトだった。155は顧客数ではない。
- 設定上のコンテキストは1,048,576 tokensだったが、prefillのキャッシュ容量は681,280。修正後は約204万tokensとなり、拒否処理も修正された。
- 分離型運用者にはSGLang v0.5.22以降を推奨。検知の対応範囲はアーキテクチャに依存し、将来の整合性対策は完成済みの万能な保証ではない。
公表日と事故の期間を分ける
Cloudflareは、Workers AIでの提供開始である8月27日から9月9日までを露出期間としている。KnosticのGadi Evron氏が9月8日に報告した。翌9日は13:22 UTCに事故を宣言し、14:00にモデルを非公開化、変更と検証を経て19:40に公開提供を再開した。10月26日は関係者との調整後の公表日である。
同社は、同じモデルへの他の顧客の直前のリクエスト内容を含む155件の応答を特定した。自社と研究者のテストを除くと時刻と量は通常の長文利用と整合し、意図的悪用の証拠は見つからなかったとしている。これは悪用が一切なかった証明ではない。他のWorkers AIモデルは影響を受けていないとも説明する。
公称コンテキストが実際のプールを上回った
この構成ではprefill GPUがプロンプトを処理し、鍵・値キャッシュをMooncakeとRDMAでdecode GPUへ渡す。SGLangはモデルの重みを読み込んだ後に残ったメモリーからプール容量を決め、コンテキスト上限は別に設定する。その結果、1,048,576 tokensの窓に対して681,280 tokens分しかない状態が生じた。
Cloudflareは提供開始前に差を認識していたが、長文テストが成功したため、過大な入力は安全に拒否されると想定したと認める。HTTP状態と性能を確認する一方、出力の検証が不十分だったという。報告が説明するのは設定と推論エンジンの相互作用であり、モデルの重みにバックドアがあるという証拠ではない。
拒否待ちでも処理中と判定された
スケジューラーは過大なリクエストを拒否対象にし、入力を1 tokenの仮データへ置き換えた。しかし分離構成の受け入れ判定は、拒否されたかではなく処理が終了したかを見ていた。保留中のエラーは終了判定を成立させず、prefillとdecodeの両側が本来エラーで終えるべきリクエストを通してしまった。
原図では8ページを確保し、新しい要求が1ページだけを書き、decodeが残る7ページの古い内容も読む状況を示す。このページ数は説明用で、事故の測定値ではない。HTTP 200、もっともらしいtoken計数、自然な文章が返っても、以前の要求内容が混ざり得た。応答の成功は分離の正しさを保証しない。
即時修復は設定とエンジンの二層
Cloudflareによると設定変更後のprefillプールは約204万tokensとなり、1,048,576 tokensの上限を上回った。同時に保留中の拒否を受け入れ段階で終了させ、割り当てやキャッシュ転送より前に止めるよう修正した。両方を検証してから再開したとしている。容量増加だけでは将来のメモリー設定に依存してしまう。
原文の表はv0.5.20の初期修正、v0.5.21のより早い拒否、v0.5.22までの追加対策を区別する。分離型運用者にはv0.5.22以降、または適切な修正のバックポートを推奨する。これは当該提供方式と修正群に関する助言であり、性能比較や、バージョン更新だけで全構成が安全になるという証明ではない。
転送中の書き込みが寿命管理を複雑にする
関連する別の問題として、要求を中止しても送信済みのRDMA書き込みは取り戻せない。宛先ページを早く再利用すると、遅れた書き込みが別の要求を壊す可能性がある。こうした時刻依存の競合とは異なり、本件の拒否された要求は決まった誤経路を進んだ。いずれも関係する処理の終了まで所有関係を維持する必要がある。
同社は両側での解放延期、Mooncakeの転送バッチ制限、ロードバランサーの切断処理変更、導入時確認を説明する。重み、量子化、並列化を変えた後は両側の実容量を測るよう勧める。ChecksumとKV Canaryはすべてのアーキテクチャに対応しておらず、設定を有効にしただけで全要求が検証されると考えてはいけない。
長期の整合性保証はまだ完成していない
ページタグの試作品は8月にGLM-5.2で試された。同社はスループットとテールレイテンシーの負担が1%未満だったとするが、信頼性の問題から直後に無効化した。この値は限定的な実験であり、現在稼働する保護や一般的な負担の測定ではない。解放時にページをゼロ化する案も草案段階とされる。
転送のchecksumは引き渡しを検証し、ページ所有権の確認は後の読み取りまで検証を広げる。Cloudflareは分散転送プロトコルの形式的モデル化も計画するが、証明の限界を認める。AISubHubの分析：分離、拒否、寿命管理をそれぞれ検証し、導入済み対策と試作、将来の保証を明確に区別する必要がある。
注目する理由
AISubHubの分析：テナント分離には独立した受け入れ基準が必要だ。HTTP状態、token計数、速度が正常でも、メモリーの所有関係が間違うことはある。設定確認と異常経路のテストは、性能ベンチマークとは別の問いを扱う。
制約と提供状況
影響範囲、修復、意図的悪用の証拠が見つからなかったとの説明はCloudflareによる。AISubHubはサービスやパッチを独立監査していない。すべてのGLM導入が影響を受けたとも、あらゆるSGLang構成でキャッシュの寿命管理ミスがなくなったとも確認できない。
出典と根拠
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。