많은 기대에도 불구하고 Gemma 4 12b QAT는 제 사용 사례에서 퇴보한 결과입니다.. 제 주력 모델은 아닙니다

지난 며칠 동안 새로운 Gemma 4 12b QAT 모델에서 일관된 도구 호출 (tool calling)을 구현하려고 시도했지만 결국 포기해야 했습니다. 모델이 실제로 작동할 때는 아주 잘 작동하지만, 저의 특정 사용 사례와 워크플로(workflows)에는 맞지 않습니다. 문제없이 작동했던 표준 Q5_K_L 버전과 비교하면 심각한 퇴보(regression)입니다. 일반적으로 Qwen은 코딩용이고 Gemma는 창작용이라는 것이 중론이라는 것을 알고 있습니다. 하지만 저는 일반 Q5_K_L 버전을 사용했을 때 코딩을 매우 잘할 수 있다는 점을 사실로서 말씀드릴 수 있습니다. 프롬프트 구조, 수정 사항, 특정 프로그래밍 언어를 고려했을 때, 저는 한 프로젝트에서 2,300줄의 견고한 코드(완전히 디버깅되었고, 구조적으로 건전하며, 테스트를 마친 상태)를 생성할 수 있었습니다. 또한, 사무라이에 관한 일반적인 프롬프트로 10,000줄의 이야기 작성을 할 수 있었습니다. 속도가 전부는 아닙니다. 이 QAT 모델의 주요 문제는 생성 중에 끊임없이 스스로를 의심한다는 점입니다. 저는 커스텀 VS Code 확장 프로그램에서의 코딩, 이야기 쓰기, 그리고 실제 사용 사례에 사용해 보았지만, 초당 60 토큰(tokens)이라는 안정적인 속도를 기록함에도 불구하고 결과는 완전히 일관성이 없었습니다. 핵심적인 실패 지점은 서버 시작 로그에서 바로 나타납니다: W load: control-looking token: 50 '<|tool_response|>' was not control-type; this is probably a bug in the model. its type will be overridden. 모델이 프로세싱을 시작하기도 전에 스스로의 도구 응답(tool response) 태그를 잘못 구성하고 덮어쓰기 때문에, 구조화된 함수 실행(structured function execution)이 깨집니다. 만약 에이전트 워크플로(agent workflows)나 개발자 확장 프로그램에 의존한다면, 시간을 아끼기 위해 일반 양자화(quants) 버전을 계속 사용하세요. 지난 며칠 동안 새로운 Gemma 4 12b QAT 모델에서 일관된 도구 호출을 구현하려고 시도했지만 결국 포기해야 했습니다. 모델이 실제로 작동할 때는 아주 잘 작동하지만, 저의 특정 사용 사례와 워크플로에는 맞지 않습니다. 문제없이 작동했던 표준 Q5_K_L 버전과 비교하면 심각한 퇴보입니다. 일반적으로 Qwen은 코딩용이고 Gemma는 창작용이라는 것이 중론이라는 것을 알고 있습니다.

하지만 저는 일반적인 Q5_K_L 버전으로 코딩을 매우 잘할 수 있다는 점을 사실로서 말씀드릴 수 있습니다. 프롬프트 구조 (prompt structure), 수정 사항, 그리고 특정 프로그래밍 언어들을 고려했을 때, 저는 한 프로젝트에서 2,300줄의 견고한 코드를 생성할 수 있었습니다. 또한, 사무라이에 관한 일반적인 프롬프트로 10,000줄의 이야기 작성을 수행할 수 있었습니다. 속도가 전부가 아닙니다. 이 QAT 모델의 주요 문제는 생성 (generation) 중에 끊임없이 스스로를 의심한다는 점입니다. 저는 제가 만든 커스텀 VS Code 확장 프로그램에서의 코딩, 이야기 쓰기, 그리고 실제 사용 사례 (use cases)에 사용해 보았지만, 초당 60 토큰 (tokens)이라는 견고한 속도를 기록함에도 불구하고 결과가 완전히 일관되지 않았습니다. 백엔드 (backend)나 하드웨어 설정 오류를 배제하기 위해, 정확한 GPU 감지, 스레드 할당 (thread assignment), 컨텍스트 할당 (context allocation), 그리고 네이티브 템플릿 자동 매칭 (native template auto-match)을 보여주는 제 서버 로그의 연속적인 시작 블록을 아래에 첨부합니다: 0.00.074.191 I - CUDA0 : NVIDIA GeForce RTX 4080 SUPER (16375 MiB, 15061 MiB free) 0.00.074.205 I - CPU : 12th Gen Intel(R) Core(TM) i7-12700KF (98097 MiB, 86472 MiB free) 0.00.074.254 I system_info: n_threads = 12 (n_threads_batch = 12) / 20 | CUDA : ARCHS = 890 | USE_GRAPHS = 1 | PEER_MAX_BATCH_SIZE = 128 | CPU : SSE3 = 1 | SSSE3 = 1 | AVX = 1 | AVX2 = 1 | F16C = 1 | FMA = 1 | LLAMAFILE = 1 | OPENMP = 1 | REPACK = 1 | 0.00.074.293 I srv init: using 19 threads for HTTP server 0.00.080.574 I srv load_model: loading model 'E:\models\gemma-4-12B-it-qat-UD-Q4_K_XL.gguf' 0.01.205.117 W load: control-looking token: 50 ' ' was not control-type; this is probably a bug in the model. its type will be overridden 0.01.205.496 W load: control-looking token: 212 '</s>' was not control-type; this is probably a bug in the model.

its type will be overridden 0.01.242.092 W load: special_eog_ids contains '<|tool_response|>', removing '</s>' token from EOG list 0.03.279.202 W llama_context: n_ctx_seq (32768) < n_ctx_train (262144) -- the full capacity of the model will not be utilized 0.03.370.810 I slot load_model: id 0 | task -1 | new slot, n_ctx = 32768 0.03.370.887 I srv load_model: prompt cache is enabled, size limit: 8192 MiB 4.07.196.023 I srv params_from_: Chat format: peg-gemma4 하드웨어 라인은 4080 Super가 깨끗하게 활용되었고 스레드 실행이 i7-12700KF 토폴로지에 정확히 일치함을 증명합니다. 서버는 성공적으로 32768 컨텍스트 크기를 초기화했으며, 모델 메타데이터에서 적절한 네이티브 peg-gemma4 채팅 레이아웃을 스스로 자동 감지했습니다. 이는 깨진 도구 호출(tool calling) 문제를 경고에 표시된 토큰 버그로 완전히 격리합니다. 모델은 처리를 시작하기도 전에 자체적인 도구 응답 태그를 잘못 구성하고 덮어쓰면서 구조화된 함수 실행을 망가뜨립니다. 에이전트 워크플로우나 개발자 확장에 의존한다면, 시간을 절약하기 위해 일반 양자화(regular quants) 버전을 사용하세요. submitted by /u/Wrong_Mushroom_7350 [link] [comments]