Gemma 4 12b QAT 对于我的用例来说是一种倒退，尽管热议纷纷.. 不是我的主要推荐

我花了最后几天时间试图从新的 Gemma 4 12b QAT 模型中获得一致的工具调用，但不得不放弃。当模型确实工作时，它表现很好，但针对我的特定用例和工作流，它不适合我。与标准 Q5\\_K\\_L 版本相比，这是一个重大倒退，该版本运行无误。我知道普遍共识是 Qwen 用于编码，Gemma 用于创意。但我可以明确告诉你，我使用常规的 Q5\\_K\\_L 版本编码非常出色。考虑到提示结构、编辑和特定编程语言，我在一个项目上生成了 2,300 行可靠的代码（完全调试、架构健全且经过测试）。此外，我还能在一个关于武士的通用提示上生成 10,000 行故事写作。速度不是一切。这个 QAT 模型的主要问题是它在生成过程中不断自我质疑。我尝试在自定义 VS Code 扩展中使用它进行编码、写故事以及实际用例，但结果完全不一致，尽管达到了稳定的每秒 60 个 token。核心故障点直接出现在服务器启动日志中：`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` 因为模型在处理开始前就错误配置并覆盖了自己的工具响应标签，结构化函数执行被破坏。如果你依赖代理工作流或开发者扩展，省点时间，坚持使用常规量化版本。 我花了最后几天时间试图从新的 Gemma 4 12b QAT 模型中获得一致的工具调用，但不得不放弃。当模型确实工作时，它表现很好，但针对我的特定用例和工作流，它不适合我。与标准 Q5\\_K\\_L 版本相比，这是一个重大倒退，该版本运行无误。我知道普遍共识是 Qwen 用于编码，Gemma 用于创意。但我可以明确告诉你，我使用常规的 Q5\\_K\\_L 版本编码非常出色。考虑到提示结构、编辑和特定编程语言，我在一个项目上生成了 2,300 行可靠的代码。此外，我还能在一个关于武士的通用提示上生成 10,000 行故事写作。速度不是一切。这个 QAT 模型的主要问题是它在生成过程中不断自我质疑。我尝试在自定义 VS Code 扩展中使用它进行编码、写故事以及实际用例，但结果完全不一致，尽管达到了稳定的每秒 60 个 token。 为了排除任何后端或硬件配置错误，下面是我服务器日志中的连续启动块，显示了精确的 GPU 检测、线程分配、上下文分配和原生模板自动匹配： 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 '<|tool_response>' 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 聊天布局。这完全将工具调用失败隔离到警告中显示的分词器 bug。模型在处理开始前就错误配置并覆盖了自己的工具响应标签，破坏了结构化函数执行。如果你依赖代理工作流或开发者扩展，省点时间，坚持使用常规量化版本。