안녕하세요 여러분,

최근 저는 긴 문맥의 에이전트 기반 코딩 (agentic coding)을 위해 M3 Ultra Mac Studio에서 DS4 Flash 대신 Qwen3.5-122B로 전환했습니다. 모델은 더 적합했지만, "따뜻한 (warm)" 문맥을 가지고 있음에도 불구하고 후속 메시지가 생성되기 시작할 때까지 3~5분이 걸리는 (cold fills) 문제에 직면했습니다.

알고 보니 문제는 모델이 아니라, 제가 사용하는 서빙 스택 (rapid-mlx의 qMLX 포크)에 있는 세 가지 특정 버그였습니다:

1. 프롬프트 불안정성 (Prompt Instability): 시스템 프롬프트의 고유한 메시지 ID가 바이트 단위로 정확한 KV 캐시 (KV cache) 매칭을 깨뜨려, 매 턴마다 전체 재계산 (re-compute)을 강제했습니다.
2. 중단 경로 (Interrupt Path): 생성이 중단되었을 때 스트리밍 답변이 유지되지 않아, 히스토리 불일치 (history divergence)를 유발했습니다.
3. 체크포인트 오염 (Checkpoint Poison): 백그라운드 라이터가 매칭할 수 없는 체크포인트를 생성하여 유효한 체크포인트를 밀어냈고, 이로 인해 공격적인 축출 (eviction)이 발생했습니다.

이 문제들을 수정한 후, 프리필 (prefill) 시간이 분 단위에서 초 미만으로 단축되었습니다 (예: 53k 토큰이 캐싱되어 있어 33개만 프리필됨).

저는 이 변경 사항들을 PR (Pull Request) 하기보다 포크 (fork) 하기로 결정했는데, 그 이유는 하이브리드 어텐션 (hybrid attention) 최적화가 Qwen에 매우 특화되어 있어 일반적인 업스트림 (upstream) 스택에서는 받아들이기 어려울 가능성이 높기 때문입니다. 이 아키텍처에 특화하여 최적화함에 따라 qMLX는 계속해서 분화될 것으로 예상됩니다.

저는 포크 버전과 프리필/디코드 (prefill/decode) 지표를 분리하는 벤치마크 스크립트 (bench_qmlx.py)를 오픈 소스로 공개했습니다. 다른 분들도 하이브리드 어텐션 캐싱에서 유사한 문제를 겪고 계시거나 추가 최적화에 대한 아이디어가 있다면 듣고 싶습니다.

상세 분석: https://mrzk.io/posts/qmlx-maximising-ai-psychosis-minmaxing-mac-studio/
GitHub (qMLX): https://github.com/marzukia/qMLX

수정 사항: 명확히 말씀드리자면, 복구 작업이 콜드 프리필 (cold-prefill) 절벽 현상은 해결하지만, 깊은 문맥의 턴 (deep context turns)을 완전히 무료(비용 없음)로 만들어주는 것은 아닙니다.

저의 딥 컨텍스트 (deep context) 세션 중 하나에서 가져온 예시입니다:

프롬프트 토큰 (Prompt tokens) | SSD에서 복구됨 (Restored from SSD) | 델타 프리필 (Delta prefilled) | 첫 번째 토큰 생성 시간 (Time to first token)

168,440 | 168,373 | 67 | 2.6s
167,859 | 167,727 | 132 | 2.6s
163,140 | 162,764 | 376 | 4.4s
168,332 | 167,912 | 420 | 4.8s
167,478 | 166,667 | 811 | 8.2s
164,400 | 163,206 | 1,194 | 11.6s
162,271 | 160,489 | 1,782 | 17.1s

제출자: /u/marzukia  

[link] [comments]