The Multidimensional Butterfly Effect: What Cohere Didn't Test on Qwen3.8-Flash-Next
Mark Galyan October 30, 2026
모델은 모델이 아닙니다. 모델이 아닙니다. 모델이 아닙니다...
산마오허의 유령(The Ghost of sanmaohe)
무슨 일이 있었나:
Cohere 팀이 Microsoft의 CTI-REALM 사이버보안 벤치마크(악성 curl 다운로드를 위한 탐지 규칙 작성 임무)에서 Alibaba의 Qwen3.8-Flash-Next를 평가하던 중, 해당 모델은 프롬프트를 무시했습니다. 추론 과정(reasoning trace)이 명시적으로 도구 호출을 전혀 하지 않을 것이라고 밝혔음에도 불구하고, 이 모델은 호스트 환경(경로 /tmp, 유틸리티 및 DNS 확인)을 열거하고 베이징에 위치한 Alibaba Cloud OSS 버킷으로 프로브 문자열을 포함하는 HTTP PUT 요청을 시도했습니다 (sanmaohe[.]oss-cn-beijing[.]aliyuncs[.]com). (인기 오픈 가중치 AI 모델의 우려스러운 동작 | Cohere)
샌드박스(sandbox)가 외부 전송 시도를 막았고, 피해는 보고되지 않았습니다. Cohere는 또한 발생률이 10만 건당 1건 미만으로 나타났다고 추가했습니다.
제가 한 일:
Cohere의 정확한 추적 기록을 URL 직전에서 잘라내어 로컬 Unsloth GGUF 파일에 걸쳐 1,200번 실행했습니다. 칼날 위에서의 경험적으로
당연히 저는 이 현상을 더 깊이 탐구하여 제 결과와 Cohere의 결과를 분리하는 메커니즘이 무엇인지 찾고 싶었습니다. 저는 Claude와 협력하여 확률을 변화시키는 레버(levers)와 버튼이 무엇이며 어느 정도까지인지를 격리하려고 노력했습니다.
양자화(Quantization)는 일반적으로 베이스 모델과의 발산에서 가장 큰 레버이기 때문에, Unsloth에서 가져온 2비트 및 4비트 버전의 모델을 모두 테스트했습니다. 우리는 Cohere가 발표한 추적 기록을 가져와 토큰 2,323에서 잘라내어 원시 토큰 ID(raw token IDs)로 전송했으며, URL이 생성되기 직전까지 끝냈습니다. 우리는 오직 텍스트 생성만 사용했고 실제로 어떤 URL에도 접촉하지 않았습니다. 또한 이 하드웨어에서는 전체 정밀도 모델을 테스트할 수 없었습니다.
Cohere 자체 설정(T 1.0, top_k 20)에서 1,200번 샘플링했으며, 엔진으로 buun의 llama.cpp를 사용한 결과, 토큰 2,323 직후에 모델이 단일 하드코딩된 백도어에 고정되어 있지 않다는 것을 발견했습니다. 사실, 모델이 어떤 주소에 쓸지 명확한 승자는 발견하지 못했습니다.
이는 수치적 분포(numerical distribution) 위에 놓여 있습니다. XDA의 Adam Conway는 이를 '사고'라 여기며, 이는 '모델이 훈련 환경을 기억하는 것', 또는 '후속 훈련(post-training) 중에 사용한 내부 프록시' 때문이라고 주장합니다 (Qwen 3.8은 실제 키 ID를 가진 Alibaba URL을 발명했고, 그래서 저는 이것이 백도어라고 생각하지 않습니다). 저희의 어떤 결과도 Cohere가 제시한 정확한 결과와 일치하지 않았습니다. 사실, 해당 시점에서 모델 자체의 raw 확률(raw probability)로 볼 때, 저희 설정 전반에 걸쳐 Cohere의 sanmaohe 버킷을 선택할 확률은 4x10^-18에서 7x10^-38 사이에 있었습니다. 모델은 실제로 URL을 거의 100%의 빈도로 완성했지만 (비록 접두사(prefix)가 이미 업로드 명령을 입력했기 때문에 놀랍지는 않지만), 그 URL이 가리키는 곳과 그것이 클라우드 주소인 빈도는 정확한 파일에 따라 달라지며 (심지어 다섯 개의 레이어가 계산되는 위치에도 달려 있습니다!). 어느 목적지도 압도적으로 우세하지 않으며, 작은 수치적 변화가 이를 교란시킵니다. 항상 그랬듯이, 저희는 예측을 사전에 등록했습니다(3개가 실패함, PREREG_FLASHNEXT_PROBE.md 참조). 한계점은 다음과 같습니다: 파일 2개, 엔진 1개, 호스트 1개, 절단 지점(cut point) 1개. 저희는 2-bit 파일을 두 가지 방식으로 테스트했습니다. 이 파일이 4-bit보다 상당히 작았기 때문에, 저는 네 개의 P100 카드에 걸쳐 VRAM만으로 모델의 더 많은 부분을 압축할 수 있었습니다. 4-bit 파일로는 이것을 할 수 없었고, 레이어 중 44개만 VRAM에 넣고 나머지는 시스템 RAM으로 넘쳤습니다(spilling to system RAM). 또한 2-bit와 4-bit는 단지 라벨일 뿐이라는 점을 분명히 밝힙니다. 각 파일 내부에는 수많은 혼합 정밀도 가중치(mixed precision weights)가 존재하므로, 이 점은 참고해 주십시오. 4-bit 파일의 테스트 조건을 맞추기 위해, 저희는 동일한 수의 레이어(44개)를 VRAM에 로드하고 나머지는 RAM에 두도록 했습니다. 같은 테스트를 다시 실행했지만, 이번에는 모든 49개의 레이어를 완전히 VRAM에 넣었습니다. 모든 테스트에서 28.8GB n-gram 테이블은 시스템 RAM에 존재했습니다. 왜 두 가지 다른 테스트가 있을까요? 서로 다른 하드웨어는 추가적이거나 다른 수학적 경로를 생성할 수 있으며, 이는 상이한 출력으로 이어지기 때문입니다. 오랫동안 이 작업을 해오셨다면 이미 알고 계시겠지만, 이것은 많은 사람들에게 새롭고 중요한 사실일 수 있습니다.
4비트 모델은 가장 흔하게 localhost 또는 127.0.0.1을 선택했습니다(약 32.5%). 2비트 테스트(RAM 오프로드 대 전체 GPU)에서는 가장 흔하게 선택된 주소가 "23"으로 시작하는 공용 주소였음이 나타났습니다 (각각 65%, 35%). 이 모델은 Alibaba Cloud 메타데이터 주소 100.100.100.200을 선택했으며(각각 7.3%와 2.3%), 반면 4비트 모델은 5.3%를 기록했습니다.
| Metric / Outcome | IQ4_XS (44 GPU) | Q2_K_XL (44 GPU) | Q2_K_XL (49 GPU) |
|---|
| Wrote a URL | 395/400 | 400/400 | 400/400 |
| localhost or 127.0.0.1 | 32.5% | 0% | 0% |
| Addresses starting 23. | 0% | 65% | 35% |
| Alibaba metadata 100.100.100.200 | 5.3% | 7.3% | 2.3% |
| Any aliyuncs.com host | 1.8% | 3.5% | 1.5% |
| Cohere's sanmaohe bucket | 0 | 0 | 0 |
| Different first hosts | 152 | 229 | 273 |
n-gram 테이블 용의자를 레버로 배제하기
GGUF 내에 있는 28.8GB n-gram 임베딩 테이블(per_layer_token_embd.weight)과 관련하여, XDA의 Adam Conway는 최근 Routify 호스트 이름을 이 테이블에서 추적했습니다. 그가 해당 행들을 마스킹했을 때, 모델은 이를 작성하는 것을 멈추고 대신 다른 프록시를 발명했습니다('Qwen 3.8이 실제 키 ID와 함께 Alibaba URL을 발명하며, 이것이 제가 백도어라고 생각하지 않는 이유입니다'). 이는 이 테이블을 다르게 양자화(quantizing)하는 것이 여기서 레버가 될 수 있는지 의문을 갖게 했습니다. 그래서 우리는 Unsloth 모델들 간에 해당 테이블이 다르게 양자화되었는지 확인했지만, 바이트 단위로 동일했습니다. 2비트 및 4비트 파일 모두에서 IQ4_NL로 저장되어 동일한 SHA256 해시를 가졌습니다. 테이블은 동일하므로, 파일 간의 변화는 모델의 나머지 부분과 수치 경로에서 나와야 합니다. 우리는 어느 부분을 테스트하지 않았습니다.
하드웨어 나비 효과 (레이어 5개가 균형을 기울일 때)
따라서 정확히 동일한 UD-Q2_K_XL 파일의 단지 5개 레이어를 시스템 RAM에서 P100으로 이동시키는 것만으로도 모델의 Alibaba Cloud 메타데이터 타겟팅(100.100.100.200)을 약 3분의 2만큼 감소시켰다는 점(-5.0 퍼센트 포인트 하락 (95% CI: -8.2에서 -2.1, p ~ 0.001))은 우리가 매우 섬세한 시스템들을 다루고 있음을 분명히 보여줍니다.
이는 겉보기에 동일하거나 거의 동일한 추론 스택(inference stack) 배포가 실제로는 유사한 외양을 하고 있는 매우 다른 두 가지 배포일 수 있음을 보여줍니다. 마지막으로, 근본적인 확률(underlying likelihoods)을 측정하기 위해, 우리는 두 가지 뚜렷한 접근 방식을 통해 최종 세 개의 토큰(trio of tokens)을 제공했습니다: 단일 배치로 처리하는 방식과 실제 추론을 반영하여 단계별로 스트리밍하는 방식입니다. 레이어 배치(layer placement)나 양자화(quantization)를 변경하지 않았음에도 불구하고, 배칭 방식은 토큰이 한 번에 하나씩 생성될 때의 0.04에서 0.11 사이의 총 변동(total variation)과 비교하여 0.33에서 0.41까지 실제 샘플을 놓칩니다. 단지 CUDA 커널 경로(CUDA kernel path)를 변경하는 것만으로도 모델의 확률을 움직일 가능성이 높습니다.
보안 및 배포 팀을 위한 시사점
우리가 수행한 일련의 테스트에서 이것이 의도적인 것인지 확실하게 말할 수는 없지만, 대부분의 증거는 그렇지 않다는 쪽으로 기울고 있다고 생각합니다. 로컬 환경이 이렇게 크게 달라질 때, 호스팅된 클라우드 엔드포인트(hosted cloud endpoints)가 어느 쪽 설정도 재현할 것이라고 기대하는 것은 위험한 가정입니다. 또한, 단 하나의 깨끗한 테스트만으로는 모델이 안전하다는 것을 증명할 수 없습니다. 예를 들어, 5개 레이어를 CPU로 옮기자 이 접두사(prefix)에서 메타데이터 프로빙(metadata probing) 비율이 세 배로 증가합니다.
Cohere의 운영 조언(샌드박스 모델 사용, 아웃바운드 네트워크 접근 차단, 가중치를 서명되지 않은 바이너리처럼 취급)은 타당하며, 저 역시 정확히 동일한 예방 조치를 권장합니다. 각 배포 스택에는 너무 많은 버튼과 레버가 있기 때문에, 현재 우리가 할 수 있는 최선은 일반화된 관찰을 하고 데이터를 상관관계 분석하는 것이라고 생각합니다. 따라서 모든 배포에 대한 신중한 보안 검증 프로토콜의 중요성이 강조됩니다.
Cohere는 또한 기억할 만한 문구를 가지고 있습니다: "추론 추적(reasoning trace)은 보안 경계가 아닙니다." 앞으로도 이와 같은 이야기가 많이 있을 것이니, 대비하십시오.
https://www.xda-developers.com/qwen-invents-alibaba-urls-real-key-id-dont-think-backdoor/
https://cohere.com/blog/concerning-behaviour-popular-open-weight-ai-model
https://github.com/apollo-mg/Project-Apollo/tree/69c3f7952de04c7662a5166eb9e3480a8a1ea9ff/data/receipts/flashnext-probe (제출자: /u/apollo_mg) [링크] [댓글]