내 답글에 대한 정정(추측이 아니라 측정한 것): gguf 리더로 다섯 파일을 전부 감사한 결과 라우터(ffn_gate_inp)는 스톡 Q4_K_M과 Q6_K를 포함해 어디에서나 F32 28/28이었다. 내가 쓴 F16이 아니며, 스톡은 이들을 다운퀀트하지도 않는다. 우리 레시피가 이들을 예산 큐 밖으로 빼두는 것은 사실이지만, 바이너리에는 F32로 기록되어 있다 — 1D 법칙과 같은 부류의 동작이다. 카드는 'pinned F16'에서 'pinned out-of-budget(파일 내 F32)'로 수정될 예정이다. 질문에 이것이 주는 의미: 스텁 고집은 분명히 라우터 탓이 아니다 — 다섯 파일 모두에서 바이트 단위로 동일하다. 베이스 고유 특성 + 압착된 thinking...

1070 적합성에 대한 훌륭한 데이터 포인트 — 7500이 만들어진 목표 자리 그대로다. 고집 문제에 대해: 대부분 베이스 고유 특성이며, 네 진단이 맞다. Mellum은 thinking이 잘리면 이르게 확정해 버린다 — JetBrains 스스로 'truncated reasoning is a failed response'라고 쓰고 있다. 여유를 주면(더 긴 컨텍스트, thinking 예산) 이른 확정 후 밀어붙이는 현상은 대부분 사라진다. 라우터: 우리 빌드에서는 원인일 수 없다 — ffn_gate_inp는 28개 레이어 전부 F16으로 고정되어 있고, 이것이 레시피에서 유일한 타협 불가 항목이다. 플랫 스톡 퀀트(Q4_K_M 포함)에서는 라우터가 실제로 다운퀀트되므로, 같은 크기의 스톡과 비교한다면...

10000 퀀트가 0.7GB를 깎으면서 실제로 +15 태스크를 내는 건 정말 야무지다. 1070에서 7500을 만져 봤는데 스톡 q4km이 긴 컨텍스트에서 OOM이 나는 바로 그 지점에 딱 맞아들어간다. he+ 지표가 더 안정적인 것도 납득된다 — 동일 설정에서 he가 3-4점씩 출렁였다가 he+는 그대로 안정을 유지하는 실행을 겪은 적이 있다. Mellum에서 눈치챈 한 가지는 thinking 토큰에 숨 쉴 틈을 조금 안 주면 함수 스텁을 끝맺는 데 이상하게 고집스러워진다는 점이다, 마치 잘못된 구조에 일찍 확정한 뒤 더 밀어붙이는 것 같다. 혹시 라우터 포화가 그...