Workers AI、長い入力で他人の会話が混ざる不具合　155件

米Cloudflareは米国時間の10月26日（日本時間27日朝）、AIの推論の場「Workers AI」で動かすモデル「GLM 5.3」で、ほかの利用者の会話の中身が返事に混ざる不具合があったとXの公式アカウントで知らせた。同じ日の報告によると、8月27日から9月9日までに155件の返事が当たり、どれも68万1280トークンを超える長い入力への返事だった（会社の申告）。

長い入力で、前の人の計算結果を読んだ

GLM 5.3は中国Z.aiのモデルで、エージェントでのコーディング向けに作られている。Cloudflareは、文脈の長さを104万8576トークンとして出していた。ところが、入力を先に読み込むGPUの側で、計算の途中の結果（KVキャッシュ）をためる場所は68万1280トークン分しか無かった。

Cloudflareは公開の前からこの食い違いを知っていた。入りきらない入力にはエンジンが誤りを返すと考え、長い入力の試験でも成功の応答が返っていたので、問題ないと見ていたという。試験では応答のコードと速さだけを見て、返事の中身までは確かめていなかったと認めている。

もう1つは、使っていたオープンソースの推論エンジン「SGLang」の不具合だ。入りきらない入力は中で「断る」印が付き、1トークンだけの仮の入力に置き換わる。1台で動かす時はこれで誤りが返る。しかし、入力を読む機械と返事を作る機械を分ける構成では、断った依頼がそのまま先へ流れた。返事を作る側は、前の依頼が残したキャッシュをそのまま読んで返事を作り、ほかの利用者の入力や途中の返事が混ざった。利用者にはエラーでなく、正常の応答が返っていた。

報告から1日で止めて直した

見つけたのは、Knosticの研究者Gadi Evron氏だ。9月8日に、HackerOneにあるCloudflareの報告の窓口へ知らせた。Cloudflareは翌日に再現を確かめ、問題の扱いを始めてから40分ほどでモデルを止めた。その日のうちに設定と修正したエンジンを入れて、公開に戻した。報告の時刻はすべて協定世界時で、日本時間では9月9日の夜に止め、10日の午前4時40分ごろに戻したことになる。

Cloudflareは翌10日に、SGLangを手がけるRadixArkの開発者と会い、本体での直し方を決めた。同じ不具合は、7月6日に別の利用者がSGLangに報告していたことも、調べる中で分かったという。今回の公表は、研究者とRadixArkと日を合わせたものだ。

報告によると、自社と研究者の試験を除いた依頼は、普通に長い文脈を使った時の時刻と量に合い、わざと狙われた跡は見つかっていない。Workers AIのほかのモデルは当たらなかったという（いずれも会社の申告）。

設定は、キャッシュの場所を約204万トークン分に広げ、文脈の長さに収まる入力なら必ず入るようにした。エンジンには、断った依頼を受け渡しの前に止める直しを入れ、SGLangの本体にも同じ考えの変更が入った。返事を作る側が、受け取ったトークンの数と予約した数が合うかを確かめる案も出している。

Cloudflareによると、これはキャッシュの場所を「もう使い終わった」と見なして別の依頼に渡してしまう種類の不具合の1つで、数か月前から直してきた。9月11日から19日にかけて、SGLangで動かす全部のモデルに追加の対策を入れた。受け渡しの途中で接続が切れても依頼を途中で止めないようにし、配る前にキャッシュの大きさと文脈の長さを比べる検査も必ず通すようにした。

SGLangの運用者は0.5.22以降に

Cloudflareは、SGLangを入力と返事で機械を分けて動かしているほかの運用者に、v0.5.22以降に上げるよう勧めている。あわせて、重みや量子化、並列の数を変えるたびに、起動のログでキャッシュの大きさと文脈の長さを比べるよう書いた。小さければ文脈の長さを下げる。中継の仕組みが長さを止めてくれる、エンジンが入りきらない入力を断ってくれる、とは考えないようにと書いた。受け渡したキャッシュの検算の機能（--disaggregation-enable-kv-checksum）も、対応するモデルでは使うよう勧めている。ただし、まだ全部のモデルには対応していない。

編集部の見方

Workers AIのAPIを呼ぶだけの人は、自分で何かを直す必要はない。それでも、長い資料やリポジトリを丸ごと渡す使い方では、他人のデータが混ざる道が実際にあったことは覚えておきたい。手元や自社のGPUでSGLangを動かしてエージェントを回している人は、版とキャッシュの大きさをまず確かめたい。「エラーが出ないから大丈夫」と応答のコードだけで試験を済ませない、という教訓は、小さなチームの運用にもそのまま当てはまる。