Cloudflare가 공개한 KV Cache 요청 간 데이터 노출: SGLang은 왜 거부된 요청을 handoff로 보냈나?
Cloudflare는 2026년 10월 Workers AI의 GLM-5.3에서 요청 간 KV cache 노출 사고가 있었다고 공개했다. 보고서에 따르면 사고 기간은 8월 27일부터 9월 9일까지였으며, 155개의 응답이 영향을 받았고 관련 prompt는 모두 681,280 tokens를 초과했다. 같은 기간의 전체 요청 수는 공개되지 않았으므로 이 자료만으로 영향 비율을 계산할 수는 없다. Cloudflare 사고 보고서 · SGLang 공동 공개.
추론 클러스터를 운영하지 않는 독자를 위해 먼저 결론부터 말하자면, 이것은 모든 AI API에 해당하는 보편적인 위험은 아니다. Cloudflare는 다른 Workers AI 모델은 영향을 받지 않았고 GLM-5.3은 9월 9일 수정 후 서비스를 복구했다고 밝혔다. 공개 자료에서 명시한 영향 범위는 사고 기간 중 입력이 681,280 tokens를 초과한 GLM-5.3 요청이다. API를 호출하기만 한다면 자신의 사용이 이 조건에 해당하는지 먼저 확인하자. 자체 SGLang prefill/decode 분리 클러스터를 운영한다면 글 끝의 네 가지 검증 게이트를 보면 된다.
살펴볼 핵심은 “모델은 왜 유출을 일으키나?”라는 넓은 질문이 아니라 더 구체적인 상태 경계다. 계속 진행하면 안 된다고 판정된 요청이 왜 1 token짜리 placeholder 입력을 들고 prefill/decode handoff까지 들어갈 수 있었을까? 거부됐는데도 처리가 계속된다는 점이 가장 이상하다. 이 사고에는 두 문제가 겹쳐 있었다. 선언된 context 한도가 실제 KV pool이 수용할 수 있는 길이보다 컸고, 당시 분리 추론의 진입점에서 거부 상태가 요청을 충분히 일찍 종료시키지 못했다. 전자는 거부를 유발했고, 후자는 거부된 요청이 진행해서는 안 되는 경로를 계속 밟게 했다.
Cloudflare가 공개한 사고 당시의 7단계 경로(PR #36988은 9월 6일 병합됐지만, Cloudflare가 9월 9일 엔진 수정을 배포할 당시에는 프로덕션에 반영되지 않았다): ① Bootstrap: router가 원래 prompt 길이를 decode에 전달하고 decode가 해당 KV 페이지를 미리 예약한다. ② Prefill admission: admission은 **req.finished()**를 확인하지만 거부 이유가 finished_reason이 아니라 to_finish에 기록돼 있어 요청이 아직 끝나지 않은 것으로 판단되어 진입을 허용받을 수 있었다. ③ Prefill forward: prefill 입력이 1-token placeholder로 대체된다. ④ KV transfer: prefill은 placeholder에 해당하는 한 페이지의 KV만 보내면서 transfer-complete 신호를 낸다. ⑤ Decode admission: decode 쪽에서도 같은 종료 상태 검사가 handoff를 받아들인다. ⑥ Decode attention: decode는 예약 길이에 맞춰 모든 KV 페이지를 읽지만 현재 요청이 쓴 페이지는 첫 번째뿐이고 나머지에는 이전 요청의 데이터가 남아 있을 수 있다. ⑦ Response: Cloudflare는 클라이언트가 예상된 HTTP 400이 아닌 HTTP 200을 받았으며 응답에 다른 사용자의 세션 내용이 포함됐다고 보고했다. Cloudflare 사고 보고서가 이 경로를 단계별로 설명한다. SGLang issue #30233과 PR #38935에서도 관련 상태와 admission 수정을 교차 확인할 수 있다.
각 단계를 따로 보면 정상처럼 보일 수 있다. 하지만 합쳐 보면 거부 상태가 제때 적용되지 않았는데도 이후 단계가 요청을 정상 요청처럼 계속 처리했다는 사실이 드러난다.
681,280과 1,048,576은 서로 다른 용량이다
Cloudflare가 공개한 배포에서 모델 context 길이는 1,048,576 tokens로 설정돼 있었지만, 사고 당시 prefill GPU의 KV pool 용량은 681,280 tokens였다. 이후 Cloudflare는 pool 용량을 약 2.04 million tokens로 높이고 엔진 차원의 거부 안전장치를 추가했다. Cloudflare의 용량 설명과 수정 기록.
같은 보고서에 나오는 681,280이라는 숫자는 서로 다른 두 가지를 가리킨다. 하나는 영향을 받은 요청의 prompt 길이 임계값이고, 다른 하나는 당시 prefill GPU의 KV pool 용량이다. 숫자는 같지만 역할은 다르다. 앞의 값은 어떤 요청이 영향을 받았는지 설명하고, 뒤의 값은 런타임이 실제로 얼마나 수용할 수 있었는지 설명한다.
이 둘은 다른 문제를 다룬다. context length는 모델 설정상 요청이 도달할 수 있는 문맥의 상한이고, KV pool은 런타임에 token의 key/value 상태를 실제로 할당하고 보존할 수 있는 메모리 풀이다. context를 더 크게 설정한다고 KV pool도 자동으로 같은 크기로 확장되는 것은 아니다. 따라서 요청이 선언된 context 상한을 넘지 않았더라도 현재 worker가 실제로 보유할 수 있는 KV 상태의 용량을 초과할 수 있다.
pool 용량 부족은 원래 거부되어야 한다. 실제 문제는 거부 상태가 후속 handoff를 막지 못했다는 데 있다. Cloudflare의 공개 자료와 상위 소스 모두 분리 추론 경로에서 abort 상태가 제대로 전파되지 않은 점을 지목한다.
거부 이유가 기록됐다고 admission이 요청을 종료한 것은 아니다
관련 SGLang 경로에서 **Req.set_finish_with_abort()**는 거부 이유를 to_finish에 기록하는 동시에 입력 prompt를 1-token placeholder로 바꾼다. 하지만 당시 finished() 판단이 읽는 필드는 finished_reason이었다. 즉 거부 이유는 요청 객체에 기록됐지만, “요청이 끝났는가”를 판단하는 **finished()**는 여전히 정상적으로 스케줄링할 요청처럼 취급할 수 있었다. SGLang PR #38935의 근본 원인 설명.
이 상태 불일치는 소스 코드를 직접 보면 더 쉽게 검증할 수 있다. 아래는 고정 commit의 비연속 발췌이며 생략한 줄은 표시했다. 전체 문맥은 set_finish_with_abort() (L2053–2072), finished() (L1479–1481), update_finish_state() (L1842–1848)에서 확인할 수 있다.
# Req.set_finish_with_abort() — excerpt
self.origin_input_ids = array(
"q", [0]
) # set it to one token to skip the long prefill
# ... omitted ...
self.to_finish = FINISH_ABORT(error_msg, status_code, err_type)
# Req.finished()
return self.finished_reason is not None
# Req.update_finish_state()
if self.to_finish:
self.finished_reason = self.to_finish
self.to_finish = Noneto_finish가 영원히 적용되지 않는다는 뜻은 아니다. 이후 update_finish_state()가 이를 finished_reason으로 옮긴다. 문제는 그 상태 전환이 일어나기 전에 admission이 finished()를 확인한다는 점이다.
Cloudflare가 9월 9일 엔진 수정을 배포하기 전에는 이 상태 불일치가 분리된 prefill/decode 경로를 따라 전파될 수 있었다. admission은 요청이 진입할 수 있다고 판단했고 decode는 충분한 KV 페이지를 예약했지만, prefill은 1-token placeholder만 처리해 부족한 KV 상태만 생성하고 전송했다. 그 결과 decode가 현재 요청으로 덮어쓰지 않은 페이지를 읽을 수 있었다. Cloudflare는 실제 노출이 이전 요청이 남긴 KV 데이터에서 비롯됐다고 설명했다. Cloudflare 보고서 · 관련 상위 issue #30233.
여기서 세 종류의 “완료” 신호를 혼동하기 쉽다.
- HTTP 200은 클라이언트가 성공 HTTP 상태를 받았다는 뜻이다. 응답 의미가 올바르다거나 KV 페이지가 현재 요청 소유라는 점까지 증명하지는 않는다.
- prefill completion / transfer-complete는 어떤 처리 또는 handoff 단계가 완료 신호를 냈다는 뜻이다. 실제로 전송한 token 수가 decode가 예약한 모든 페이지를 덮는다는 보장은 아니다.
- decode가 완전하고 유효한 KV pages를 읽는 것이 실제 데이터 조건에 더 가까운 검사다. “흐름이 완료됐는가”만 확인하고 실제 쓰기 범위와 페이지 소유권을 확인하지 않으면 “전송 단계가 끝났다”를 “데이터가 완전하고 현재 요청 소유다”라고 잘못 판단할 수 있다.
흐름이 끝까지 진행됐다고 데이터까지 올바른 것은 아니다.
#36988, #38935, #38704는 하나의 수정이 아니다
상위 기록의 시간 순서와 역할을 분리해 읽는 것이 중요하다.
| 날짜 / 기록 | 상태 | 실제로 해결한 문제 |
|---|---|---|
| 2026-07-06, issue #30233 | 종료됨 | PD disaggregation에서 긴 prompt가 1 token만 전달되는 유사 문제의 초기 보고다. Cloudflare의 전체 프로덕션 사고를 독립 재현한 것은 아니다. |
| 2026-09-06, PR #36988 | 병합됨; Cloudflare는 v0.5.20 배포와 연결해 설명 | aborted prefill result의 종료 처리와 cleanup을 수정했다. 대기 중인 chunk 상태를 지우고, abort 결과를 미완료 큐에 다시 넣지 않으며, metadata/KV/HiCache/Mamba 등 자원을 해제하고, 이미 retire된 요청의 지연 결과를 무시한다. 정확성 결함을 다룬 수정이다. |
| 2026-09-16, PR #38935 | 병합됨; Cloudflare는 v0.5.21 배포와 연결해 설명 | 아직 진입하지 않은 거부 요청을 prefill과 decode admission 입구에서 더 일찍 종료해 불필요한 bootstrap, metadata buffer, sender/receiver 초기화, forward pass를 피한다. 작성자는 이것이 자원 낭비와 지연을 줄이는 수정이며 #36988 이후의 두 번째 독립 correctness 수정은 아니라고 명시했다. |
| 2026-09-09 생성, 2026-10-10 종료, PR #38704 | 종료, 미병합; 릴리스 없음 | Cloudflare가 제안한 다른 방어 방안이다. 상위 mainline에 포함된 수정으로 취급해서는 안 된다. |
#38935 설명은 중요한 시점도 제공한다. #36988이 포함된 수정 후 main에서는 decode가 부족한 handoff를 제출하지 않게 됐다. 상위 PR에는 1P1D(2×H200) 전후 동작 비교도 있다. #38935 병합 후 decode는 300초 대기 후 timeout되던 상태에서 즉시 400을 반환하는 상태로 바뀌었고, bootstrap/metadata buffer는 더 이상 생성되지 않았으며 stub batch는 1에서 0으로 줄었다. 이는 상위 PR에 제시된 비교이지 이 글에서 직접 실행한 성능 테스트가 아니다.
그래서 진입 가드를 “to_finish가 비어 있지 않으면 요청을 종료한다”로 단순화해서는 안 된다. #38935는 is_unadmitted_reject로 아직 진입하지 않았고 자원 소유권도 획득하지 않은 거부 요청을 식별한다. 재진입 또는 선점된 요청은 이미 KV나 metadata 같은 자원을 보유하고 있을 수 있으므로 abort 표시만으로 일찍 버리면 안 된다. decode 쪽도 재진입 경로를 고려해야 한다. 일부 자원 상태가 Req 객체에 남아 있지 않을 수 있기 때문이다. 너무 일찍 종료하면 정상 스케줄링 경로가 담당하는 cleanup, 예를 들어 streaming session의 active slot detach(세션이 활성 slot을 점유한 상태 해제)를 건너뛸 수 있다. SGLang PR #38935.
이후에도 관련은 있지만 서로 다른 방어가 추가됐다. PR #39500은 선택적 handoff KV checksum을 추가했다. Cloudflare는 잠재적 손상을 탐지하고 기록하는 KV canary와 read-time page tagging도 소개했다. 후자는 2026년 여름 테스트된 프로토타입으로 GLM-5.2에서 시도된 뒤 신뢰성 문제로 중단됐고, 특정 attention backend와 모델 아키텍처에 의존한다. 현재 일반적으로 배포된 보편적 방어가 아니다. Cloudflare는 checksum과 canary가 모든 모델 아키텍처를 지원하지 않았고 GLM-5.3 지원도 확대 중이라고 설명했다. handoff checksum은 prefill에서 decode로 가는 전송을 검증할 뿐, 이후 모든 decode 읽기를 검증하지는 않는다. PR #40645와 PR #41402는 drain acknowledgement 누락 또는 모든 decode peer를 포괄하지 못하는 문제를 함께 수정한다. PR #41404는 decode가 직접 시작한 abort 외의 transfer failure에도 deferred release를 확대해, 진행 중인 RDMA 쓰기가 페이지에 접근할 수 있는 동안 페이지가 해제되거나 재사용되는 것을 방지한다. 이 수정들은 KV page lifetime race를 다루며, 거부 요청이 결정적으로 부족한 handoff 경로로 진입하는 문제와는 다른 실패 경로다. Cloudflare의 방어와 버전 목록.
고정 버전 CPU 검증: 코드 경로를 확인했지, 테넌트 유출을 재현한 것은 아니다
이번 검증은 사고 보고서와 PR을 읽는 데서 끝나지 않았다. 다만 세 계층의 증거가 각각 뒷받침하는 범위는 다르다.
| 증거 | 관찰 결과 | 증거가 뒷받침하는 범위 |
|---|---|---|
| 자체 제작 Python 합성 상태 머신 | handoff 모델 6/6, admission / re-entry 모델 9/9 | 만든 상태 모델의 가드가 예상대로 동작한다는 뜻이다. SGLang 런타임 결과를 의미하지 않는다. |
| 고정 SGLang commit의 상위 CPU 단위 테스트(P1) | 두 테스트 파일 합계 19 passed; admission 테스트에는 별도로 12 subtests | 고정 버전의 실제 상위 mixin, queue, retire 코드를 실행했다. transport/cache/scheduler 협력 객체 일부는 Mock이며 실제 prefill/decode 클러스터는 실행하지 않았다. |
| 수정 전후 차분(P2) | #38935 admission 차분과 #36988 prefill cleanup 차분 모두 동작 변화 관찰 | 고정 입력이 두 버전에서 다른 코드 경로를 탔다는 뜻이다. CPU 코드와 프로브 동작에 한정된다. |
P1은 SGLang commit 8f3d6944b76c428d884582cb6c82a39db1465360에 고정했다(고정 소스). 실행한 상위 테스트는 test_prefill_abort_result_cleanup.py(11 passed)와 test_admission_abort_not_enqueued.py(8 passed, 추가로 12 subtests)로 총 19 passed다. 환경은 Linux CPU-only VM, Python 3.12.3, pytest 9.2.0, CPU용 torch였다. GPU, 모델 가중치, RDMA 또는 테넌트 데이터는 사용하지 않았다.
P2는 여러 수정을 한 비교에 섞지 않도록 각 PR의 이전/이후 버전을 따로 비교했다.
- 실험 A: #38935 admission 입구(base 17ba2c2e → head 8f3d6944). 수정 전에는 입구에서 거부된 요청이 큐에 들어가 sender/receiver 생성을 유발했다. 수정 후에는 입구에서 종료 처리되어 해당 handoff 객체가 생성되지 않았다. 유효한 요청과 metadata buffer를 가진 재진입 요청은 두 코드 트리 모두에서 유지됐고, 이들이 잘못 retire되는 현상은 관찰되지 않았다.
- 실험 B: #36988 prefill 결과 cleanup(base 9c254df8 → head 2ee5742a). 프로브는 수정 전 abort의 최종 결과가 미완료 캐시로 취급돼 inflight 큐에 다시 들어가고, 이미 retire된 요청의 지연 결과가 KV chunk 전송을 유발할 수 있음을 관찰했다. 수정 후에는 예상대로 cleanup이 완료되고 지연 결과가 이런 부작용을 더 이상 유발하지 않았다.
P2의 7/7과 P1의 11 passed는 서로 다른 버전에서 나온 결과다. P2는 #36988 head commit 2ee5742a 당시 존재했던 7개 테스트 케이스를 사용했다. P1의 고정 버전 8f3d6944에는 이후 sampling-mask 매개변수 테스트가 추가되어 해당 파일이 11개 항목으로 늘었다. 따라서 P2의 0/7 → 7/7은 같은 7개 케이스의 수정 전후 비교이며 P1의 11 passed와 합산해서는 안 된다. P2의 pre-fix 실패 7건 중 6건은 정상 transfer 경로로 빠졌을 때 발생한 AttributeError, 나머지 1건은 ValueError였다. 테스트 stub이 정상 경로를 모델링하지 않았기 때문에 생긴 예외이며, 업무 assertion 7개가 실패했다는 뜻은 아니다. 더 중요한 증거는 재큐잉, cleanup, 지연 전송 부작용의 관찰이다.
공개 검증 자료
차분 프로브 2개, 원본 JSON 출력 4개, P2 receipt, SHA-256 체크섬 목록을 공개 실험 자료 묶음에 공개했다. 두 base/head commit과 Mock 범위, CPU-only 한계를 기록했다. pre-fix 0/7은 stub fall-through(AttributeError 6건, ValueError 1건)이며 7개의 assertion 실패가 아니다. 이 자료가 보여주는 것은 고정 버전 간 코드 경로 차이이지 GPU/RDMA 또는 실제 테넌트 간 유출 재현이 아니다.
배포 환경에서 확인할 네 가지 게이트
다중 테넌트 추론 서비스를 운영하거나 SGLang prefill/decode 분리 아키텍처를 사용한다면 “v0.5.22로 올리고 긴 prompt 하나를 보내 HTTP 400이 나오면 끝”이라고 생각하기 쉽다. 하지만 운영 환경의 설정과 자원 수명 경로는 버전 번호만으로 검증할 수 없다. 검증은 네 가지 독립 게이트로 나누는 편이 낫다.
- Pool / context gate: 설정과 런타임 용량이 일치하는가. worker가 시작된 뒤 시작 로그에 실제 출력된 KV pool 용량을 context 설정과 비교한다. 선언된 context 상한과 런타임 실용량이 일치하는지 확인한다. 설정, GPU 분할, 동시성 정책이 바뀌면 시작 로그를 다시 확인한다. context 상한은 넘지 않았지만 현재 KV pool 용량을 초과하는 입력을 음성 사례로 만들고 handoff를 계속하지 않고 명시적으로 거부되는지 확인한다.
- Reject / admission gate: 거부 상태가 진입점에서 적용되는가. 거부된 요청이 bootstrap, queue admission, metadata buffer 할당, sender/receiver 초기화 전에 종료 처리되는지 확인한다. 새 요청뿐 아니라 유효한 요청, 재진입, 선점된 요청, KV/Mamba/metadata 자원을 여전히 보유한 요청도 테스트해야 한다. abort 상태가 있다는 이유만으로 모든 요청을 버리면 원래 요청의 자원 cleanup 책임을 깨뜨릴 수 있다.
- Transfer / read gate: 실제 전송 범위가 실제 읽기 범위를 덮는가. 예약된 token/page 수와 실제로 기록·전송된 유효 범위를 비교한다. HTTP 200이나 transfer-complete는 길이와 소유권 검증을 대신할 수 없다.
—disaggregation-enable-kv-checksum또는—kv-canary를 사용하려면 먼저 현재 모델과 backend의 지원 여부를 확인하고, 로그에서 요청이 실제로 검증을 거쳤는지 확인한다. Cloudflare 공개 당시 이 기능들은 GLM-5.3을 포함한 모든 아키텍처를 지원하지 않았다. 지원하지 않는 옵션을 유효한 방어로 계산해서는 안 되며 handoff checksum도 decode의 모든 읽기를 검증하지 않는다. - Lifetime / ownership gate: 실패 후 페이지를 언제 해제하거나 재사용할 수 있는가. abort, 지연 결과, 진행 중인 RDMA write에 대한 음성 테스트를 수행해 미완료 쓰기가 재할당된 페이지를 오염시키지 않는지, retire된 요청의 지연 결과가 chunk를 다시 보내지 않는지, 자원이 한 번만 해제되는지 확인한다. prefill과 decode 양쪽에서 deferred KV release가 활성화되어 있는지 확인한다. Mooncake에서는 transfer batch 상한과 release timeout이 맞는지도 확인해 timeout 후 진행 중인 쓰기가 지나치게 오래 남지 않게 한다. PR #41023을 포함한 버전은 지원 backend에서 deferred release를 기본 활성화했지만 실제 버전과 설정을 기준으로 확인해야 한다. #40645와 #41402는 drain acknowledgement 경로를, #41404는 다른 transfer failure의 지연 해제를 다룬다. 이 수명 주기 위험은 최초의 결정적인 handoff 결함과 별도로 검증해야 한다.
SGLang의 v0.5.22 release는 2026-10-19에 공개됐다. Cloudflare는 v0.5.22 이상으로 업그레이드하거나 필요에 따라 관련 수정을 backport할 것을 권고했다. 하지만 “버전을 올렸다”는 사실이 “배포가 격리 검증을 통과했다”는 뜻은 아니다. 실제 실행 중인 코드 버전, pool/context 설정, admission 음성 사례, 페이지 수명 주기를 확인해야 한다. checksum 같은 기능이 활성화되지 않았다면 작동 중인 방어로 계산해서는 안 된다.
이번 사고에서 기억할 점은 단순히 Boolean 하나가 잘못됐다는 것이 아니다. 거부 상태, 데이터 무결성, 자원 소유권은 서로 다른 경계다. 요청 객체에 거부 이유가 기록됐다고 admission이 반드시 이를 인식하는 것은 아니다. transfer가 끝났다고 decode가 읽는 모든 페이지를 현재 요청이 쓴 것도 아니다. abort가 발행됐다고 진행 중인 모든 쓰기가 끝난 것도 아니다. 각각의 경계를 따로 검증해야 성공처럼 보이는 요청 경로를 실제 데이터 격리의 증거로 착각하지 않는다.
테스트 일자: 2026년 10월 28일.
SGLang 사고 7단계 경로
거부된 요청이 admission, KV transfer, decode를 통과한 경로를 살펴봅니다. Cloudflare 공개 내용을 읽기 위한 UI이며 브라우저에서 SGLang을 실행하지 않습니다.
JavaScript가 없어도 7단계를 모두 읽을 수 있습니다.
- Cloudflare 사고 공개
1. Bootstrap: KV 페이지 예약
router가 원래 prompt 길이를 decode에 전달하고 decode는 KV 페이지를 예약합니다.
예약은 원래 prompt 기준이며 이후 전송이 전체 길이를 덮는다는 증거는 아닙니다.
- 고정 소스 CPU 차분
2. Prefill admission: 거부가 진입을 막지 못함
검사는 finished_reason을 읽지만 거부 사유는 to_finish에 있어 이전 경로는 미완료로 판단할 수 있었습니다.
고정 CPU 차분에서 수정 전 거부 요청은 큐에 들어가 sender를 만들었고 수정 버전은 admission 입구에서 retire했습니다.
고정 소스 · 8f3d6944b76c · L1479-L1481로컬 증거: probe-admission-pre-20261028.json로컬 증거: probe-admission-post-20261028.json
- Cloudflare 사고 공개
3. Prefill forward: 입력이 1 token으로 축소
긴 prefill을 건너뛰려고 입력을 1-token placeholder로 바꿨지만 원래 KV 상태가 완전하다는 뜻은 아닙니다.
placeholder는 제어 흐름 신호일 뿐 완전한 KV 내용의 증거가 아닙니다.
- Cloudflare 사고 공개
4. KV transfer: 한 페이지를 보내고 완료 신호
prefill은 placeholder에 해당하는 KV 페이지만 보내면서 완료를 알렸습니다. 신호 자체는 범위를 검증하지 않습니다.
이 단계는 Cloudflare 공개 내용이며 GPU/RDMA 전송을 독립 재현하지 않았습니다.
고정 소스 · 8f3d6944b76c · L2053-L2072로컬 증거: sglang-cpu-p2-receipt.json
- 고정 소스 CPU 차분
5. Decode admission: 같은 상태 검사로 다시 통과
decode도 handoff를 받아들였습니다. 고정 CPU 차분에서 이전 버전은 receiver를 만들고 수정 버전은 입구에서 retire했습니다.
고정 CPU 차분에서 이전 버전은 거부된 decode 요청에 receiver를 만들었고 수정 버전은 admission 입구에서 retire했습니다.
고정 소스 · 8f3d6944b76c · L1479-L1481로컬 증거: probe-admission-pre-20261028.json로컬 증거: probe-admission-post-20261028.json
- Cloudflare 사고 공개
6. Decode attention: 유효하게 쓴 범위를 넘어 읽음
decode는 예약 길이까지 읽었지만 공개 경로에서 현재 요청이 쓴 것은 첫 페이지뿐이었습니다.
공개된 사고 경로입니다. CPU 차분은 관련 abort/큐/정리 경로를 검사하지만 GPU attention을 재현하지 않습니다.
고정 소스 · 8f3d6944b76c · L1479-L1481로컬 증거: probe-prefill-pre-20261028.json로컬 증거: probe-prefill-post-20261028.json
- Cloudflare 사고 공개
7. Response: HTTP 200이 데이터 정확성을 뜻하지 않음
Cloudflare는 예상된 HTTP 400 대신 HTTP 200이 반환됐고 다른 사용자 세션 내용이 포함됐다고 보고했습니다.
이 결과는 공급업체 공개 내용이며 실제 테넌트 간 응답을 재현하지 않았습니다.
고정 소스 · 8f3d6944b76c · L1479-L1481로컬 증거: sglang-cpu-p2-receipt.json