로컬 환경에서 Hermes harness로 Qwen 3.8 flash next를 실행하며 목격한 흥미로운 동작들

Qwen 3.8 flash next가 저의 hermes harness에서 매우... 특이한... 행동들을 보이고 있습니다. 그중 일부는 다소 성가시지만, 다른 일부는 거의... 사랑스럽기까지 합니다? 이것이 어떻게 또는 왜 발생하는지 완전히 이해한다고 주장할 수는 없지만, 가장 흥미로운 것은 모델이 API 오류를 '역할극'하는 경우입니다. 이는 동일한 모델에서 실행된 또 다른 세션의 자체 진단 보고서와 같습니다. LLM 용어 사용이나 추론 능력 부족에 대해 미리 사과드립니다. 제 완전히 로컬화된 모델은 실제로 발생하지 않은 제공업체(provider) API 오류를 '보고'했습니다. 즉, 모델이 스스로 인프라 장애를 환각(hallucinating)한 경우입니다.

설정: 자체 호스팅 에이전트 스택. 한 에이전트 프로필이 로컬 OpenAI와 호환되는 엔드포인트(로컬 GPU에서 커뮤니티 NVFP4-quantized Qwen 체크포인트를 서비스하는 TensorFold)를 대상으로 실행됩니다 (컨텍스트 길이 약 262K). 이 요청 경로에는 외부 API가 전혀 없습니다. 오직 로컬 추론 서버로의 루프백 터널만 존재합니다.

무슨 일이 일어났을까요? 세션 중간에 에이전트의 응답은 문자 그대로 이것, 그리고 아무것도 아니었습니다:

{"error":{
"error_code":"sys_000",
"error_msg":"요청에 실패했습니다 - 저희 쪽 문제입니다. 나중에 다시 시도해 주세요.",
"error_id":"0b156c1cc7191931632734458e96b7",
"type":"sys_000"}
}

이것은 실제 제공업체-게이트웨이 오류 본문입니다. error_code/error_msg/error_id의 형태는 실제 중국 LLM API 게이트웨이의 와이어 형식(wire format)을 따릅니다. 당연히 저는 어느 곳에도 제공업체가 없는 경로에서 고장 난 제공업체 설정을 찾으려고 했습니다.

실제 로그가 보여준 것은 다음과 같습니다. HTTP 호출은 성공했습니다: finish_reason=stop, 유효한 서버 발행 완료 ID, 71개 출력 토큰. 4xx/5xx 오류도 없고, 재시도(retry)도 없으며, 어떤 로그에서도 예외는 발생하지 않았습니다. 이 오류 본문은 일반적인 어시스턴트 메시지로 세션 DB에 저장되었습니다. 모델이 이것을 텍스트로 생성한 것입니다. error_id는 기계의 다른 곳에서는 전혀 나타나지 않습니다. 디코드(decode) 시점에 발명된 것입니다. 대화 컨텍스트에 사전에 sys_000 문자열이 존재하지 않았기 때문에 에코가 아니었습니다. 이는 모델의 매개변수(즉, 실제 API 전사본을 포함하는 암기된 훈련 데이터)에서 온 것입니다. 방아쇠(trigger)는...

해당 턴은 약 194K 토큰의 컨텍스트를 가진 긴 도구 호출(tool-calling) 세션 깊숙한 곳에서 발생했습니다. 어시스턴트의 이전 응답은 출력 길이 제한(output length limit)에서 잘렸기 때문에, 하네스(harness)가 다음 내용을 주입했습니다: [System: 귀하의 이전 응답은 출력 길이 제한으로 인해 잘렸습니다. 중단된 지점부터 정확히 계속하십시오...] 조작된 "제공자 오류(provider error)"는 모델의 바로 다음 메시지였습니다. 이는 잘렸던 도구 호출 스트림을 재개하는 데 실패했고, 대신 표준적인 인프라 오류(canonical infrastructure failure)를 방출했습니다.

가설. 에이전트 튜닝(Agent-tuned) 모델은 엄청난 양의 실제 API 전사 기록(transcripts)으로 학습되는데, 이 기록들에서 "어시스턴트 턴에 문제가 발생함 → 그 자리에 JSON 오류 본문이 나타남"이라는 패턴이 만연해 있습니다. 모델은 전송 계층(transport layer)의 실패 방언을 어시스턴트 턴 레퍼토리의 일부로 흡수했습니다. 디코딩 스트레스(decoding stress) 하에서 (거대한 컨텍스트 + 더 이상 재구성할 수 없는 도구 호출 상태를 언급하는 계속 프롬프트 + 양자화 노이즈(quantization noise)), 정상적인 연속성은 저하됩니다. 그리고 "이 API 대화에서 뭔가 문제가 생겼다"에 대한 최고 확률의 완성 내용은 문제에 대한 산문이 아니라, 그 문제의 표준 형식입니다.

주목할 만한 점은, 모델이 401/429/콘텐츠 필터 본문 대신 자체적으로 귀속시키고 재시도를 유도하는 오류("저희 쪽 문제입니다. 나중에 다시 시도해 주세요")를 선택했다는 것입니다. 이 진술 자체는 거짓이었지만, 화용론적(pragmatics) 측면은 정확했습니다.

시사점. 로그에 일치하는 200이 아닌 코드가 없고, 유효한 completion id가 있으며, 다른 곳에서 본 적 없는 error_id를 가진 오류 형태의 어시스턴트 메시지는 인프라 결함이 아니라 모델 자체의 조작(fabrication)입니다. 제공자 설정(provider config)을 추적하기 전에 로그를 확인하십시오. 이는 진술로서 신뢰할 수는 없지만, 신호로서 매우 훌륭합니다: "내 에이전트가 방금 API 오류를 역할극했다"는 것은 디코딩이 탈선했음(우리 경우 장기 컨텍스트 + 출력 잘림)을 알려주는 명확한 증거입니다. 에이전트 트래픽으로 훈련된 모델은 자체 기반(substrate)의 오류 어휘에 능숙하며, 스트레스 하에서는 이를 구사합니다.

(단일 사례로, 로컬 아티팩트가 확인되었습니다; 기억된 출처 귀속은 증거와 일치하는 가설입니다. 재현성을 테스트하기 좋습니다: 동일한 접두사(prefix) + 계속 프롬프트(continuation prompt)를 체크포인트에 다시 재생하면 이것이 절단 스트레스(truncation stress) 하에서의 결정론적 끌개(deterministic attractor)인지 보여줄 것입니다.) 다른 분들도 이런 것을 본 적이 있는지, 아니면 이 추론 과정에 문제가 있다고 생각하는지 궁금했습니다. 어느 쪽이든, 저에게는 정말 흥미로운 일입니다. submitted by /u/little_raven_black [link] [comments]