💻🤖 Gemma4-12B v2 — 编码 + 智能体版 ✨

🐣 小巧体积，强大内核 — 面向所有人的本地编码与工具使用智能体

无论您使用何种 GPU，无论您拥有多少 RAM。 只要有 ~4.5 GB 的可用显存或统一内存，您现在就可以运行自己的 私有、离线编码智能体。🚀 v2 版本带来了重大的智能体升级 — 它能够阅读、推理、使用工具，并在执行前 完成多步骤技术任务。🧠🛠️ 完全本地运行，归属您个人所有，无需 API，无需云端。

📊 核心亮点 — 智能体功能表现（tau2-bench）

v2 专为编码 + 智能体工作而构建 — 编写代码、运行命令、使用工具、调试、多步骤技术任务。最清晰的信号来自 tau2-bench telecom，这是一个智能体工具使用基准测试，其诊断 → 修复 → 验证循环模拟了真实的终端/调试工作：

→ 在技术性智能体任务上，得分约为基础模型的3.5 倍。🎯 想了解完整情况 — 为何选择 telecom、两个模型的失败方式有何不同、 坦诚的局限性以及权衡取舍（包括通用知识）？下文将详细分解。👇

🚀 公告

📌 遇到问题？请先查看我的置顶讨论。 约 99% 的问题源于客户端/采样器配置，而非权重本身 — 并且在置顶讨论中 有快速解决方案。例如：输出混乱或重复出现 0000… 几乎总是意味着未设置重复惩罚（请设置 rep_pen 1.1，temp 1.0）； 而泄露 <|tool_call> / <|channel> 标记则表示您的前端未解析 Gemma 4 的原生工具格式（请使用 llama.cpp 的 --jinja 参数）。 如果您的问题未被涵盖，请随时开启讨论 — 我会阅读并尽快回复。💬

📦 本版本不提供 Q2_K 量化。 我已完成 Q2_K（imatrix）版本的构建，但在实际压力测试中表现不佳，因此决定暂缓发布 — 只有当我确信某个量化版本真正优质时，才会发布。 最小的可靠选项是 Q3_K_M；Q4_K_M 是推荐的平衡点。🙏

🔮 v3 版本已在开发中。 说实话？连我自己都没想到训练后模型性能的提升会如此显著 — 所以我会继续努力。v3 将 保持编码 + 智能体的核心 focus，并追求更高的目标。敬请期待！🎉

🐘 更强大的兄弟模型即将推出 — Qwen3.6-27B。 我也已开始使用相同的编码 + 智能体方案微调 Qwen3.6-27B， 面向那些拥有足够硬件空间并追求更强原始能力的用户。但我并未忘记本项目的初衷：27B 模型对部分用户的 GPU / RAM 而言可能过于沉重。 因此，它并非替代品 — 我会同时并行开发本 12B 系列的 v3 版本，并且它将变得更加强大。💪 无论您的硬件如何，都将有一个适合您的模型。 💚

💚 个人笔记 — 致谢与几句真心话（请阅读）

首先，由衷感谢大家分享的所有数据与帮助。 🙏 令人喜忧参半的是：没人预料到Fable 5 会被停用——而只有我自己的数据集保留了 Fable 5 真实、原创的思维链。 因此，对于社区贡献的每一个数据集，我都使用 Opus 4.8 (xhigh) 从零开始重建了缺失的推理过程。这可能与 Fable 5 最初的推理轨迹有所不同，但这是唯一可行的路径——而且改进效果实在是、实在是太显著了（几乎让我从椅子上跳起来 😄）。基准测试数据就在上方。👆

其次——我努力回复了每一条社区评论，也公开承认了 v1 版本在训练中存在的问题。真心感谢：正是你们的反馈让我得以改进。💚

由于 v1 登上了热门榜首，它也引来了一些负面言论/恶意攻击。我想温和但坚定地说：真正的批评在这里永远受欢迎——纯粹的侮辱则不然。 这是一个本地模型，让任何人都能在极小的 RAM/VRAM 上运行一个功能强大的 AI，零 API 成本且完全私密；我甚至开源了完整的 safetensors master 供大家研究和在此基础上进行开发。如果有任何问题，请就实际问题展开讨论——我真心希望听到并会采取行动。但那些纯粹是侮辱的评论对任何人都没有帮助，我会毫不犹豫地删除它们。🙏

请记住：我只是一个人——不是为了营销或日后 monetize 而发布“开源”模型的实验室。我不做广告。我是在自己的时间和金钱下为大家开发这个模型：合成数据、手工审查和清理数据、分割和重新分段（这一轮我甚至构建了一个动态上下文窗口处理过程，以保持智能体“先读后动”的步骤完整）、阅读最新论文，然后训练→评估→再训练→再评估。这耗尽了一整个 Claude Max 20× 套餐（我为自己的工作单独保留了一个 Pro 版本），而且仅 v2 就花费了 40 多个小时——即使用了 Opus 4.8，数据也不断抛出各种意外情况，我都必须亲自验证。真心感谢大家。🐾

🔬 基准测试详情（tau2-bench）

我在 tau2-bench（一个智能体工具使用基准测试）上对 v2 版本进行了评估。我没有运行整个测试套件——因为它非常耗时，所以我专注于最符合 v2 用途的单一领域。

为什么选择 tau2-bench 的 telecom 领域？ 电信故障排除要求智能体使用读取/检查工具进行诊断 → 精确定位问题 → 应用修复 → 验证修复——这与实际终端/调试工作的流程（检查状态 → 诊断 → 修复 → 确认）在结构上完全相同。这正是该模型旨在擅长的任务，因此它是衡量 v2 版本的合适标准（比购物/客户服务领域更合适）。

→ 在技术性智能体任务上，得分大约是基础模型的 3.5 倍。🎯

基于事实，而非虚构。 另外，一项独立的编码/终端虚构探测（故意诱使模型编造文件路径/函数签名/值的任务）发现，v2 版本与基础模型一样在行动前会先基于事实——它会先执行 grep/read/ls 等操作，并且不会编造内容（虚构率为 0%，与基础模型相当）。

有趣的部分——它们如何失败。 基础模型早早放弃：在此次测试中，它有 10 次 放弃并转交给人工处理（transfer_to_human），而不是完成修复。v2 版本则会坚持下去——它会留在循环中，像更大规模的模型那样解决问题，这正是它能解决更多任务的原因。不过它还不完美：有时仍会有些手忙脚乱（过度尝试、反复重试）。此外，一些未解决的任务实际上是基准测试自身 APN 工具的 bug（它会对本应正常处理的输入抛出错误），而非模型问题。需要明确的是：我不会为了提高分数而修补基准测试的工具或泄露测试问题——我更愿意报告真实的数字，并改进模型本身。v3 版本将进行更多训练。 🔧

关于 retail（客户服务购物）领域：在 tau2-bench 的 retail 领域，基础模型的得分略高于 v2 版本。这完全在预期之中，也是设计使然。 零售领域纯粹是客户服务（查询用户、处理订单）——并非本模型的用途。v2 版本专门针对编码 / 终端 / 技术性智能体工作，在这些领域（如电信）它的表现显著优于基础模型。需要客服机器人？这不是。需要本地编码/智能体模型？这就是。💚

坦诚看待规模问题。 当今的前沿模型——例如 mimo-v2.5-pro 或 Opus 4.8——在这个电信基准测试中都能达到 90% 以上的得分。它们的规模也非常庞大。对于一个 12B 参数的模型，我粗略估计 v3 版本的得分可能最高在 60–70% 左右（强调这只是估计——我甚至还没开始开发 v3 版本）。因此需要清醒地认识到：与前沿水平仍存在实际差距。但请记住模型规模——这是一个可以在你自己的机器上运行的 12B 参数模型，而在这个规模下尽可能缩小差距正是我们的全部目标。💪

权衡取舍——没有免费的午餐。 我还运行了一个通用知识基准测试（MMLU-Pro），v2 版本的得分略低于基础模型。对于有针对性的微调而言，这是完全正常且预期之中的：当你专注于提升编码和智能体能力时，会牺牲一小部分广泛知识的广度。需要通用模型？可以尝试我自己的通用型模型 Claude Opus 4.6/4.8 蒸馏版——或者原始的 google/gemma-4-12B-it 基础模型。需要本地编码/智能体工具？这就是 v2 版本的调优目标。

🔬 方法论说明，实事求是： 这些是本地、相同测试框架下的相对数值（所有模型均在 Q8_0 精度下测试，贪婪解码，模拟用户，20 个任务）。它们不能直接与已发布的 tau2-bench 排行榜数据相比（不同的用户模拟器、完整任务集、全精度）——本地自测的分数系统性地低于已发布的分数。请将它们理解为**“在相同条件下 v2 版本与基础模型的对比”**，这才是此处真正重要的比较。

📚 v2 版本（训练方面）有哪些新特性

v2 版本在 v1 版本编码能力的基础上，着重强化了智能体能力——这正是 v1 版本所欠缺的关键部分：

• 🛠️ 智能体/终端功能——支持真正的多步骤工具使用流程（读取→推理→执行→验证），并采用 Gemma 4 原生的工具协议。这一改进推动了 tau2-bench 电信领域测试成绩的显著提升，同时解决了 v1 版本“仅完成第一步就停止”的问题。
• 💻 编码能力——针对 Python 任务进行了经过验证的思维链优化（真实的思维链，通过测试用例验证），并加入了 Fable-5-redo 数据集以应对复杂场景。
• 📚 通用能力——精选了一部分推理/指令数据，以保持模型的广泛适用性。

所有推理过程均采用蒸馏思维链（详见上文个人说明中关于如何使用 Opus 4.8 重建 Fable 5 轨迹的内容）。

📦 选择合适的模型大小（GGUF 量化版本）

ℹ️ 本版本暂不提供 Q2_K 量化版本——该版本尚未通过压力测试（详见公告）。最小的可靠量化版本为 Q3_K_M。

🚀 如何运行模型

选项 A — 使用 llama.cpp（推荐） 🦙

⚠️ 需要最新版本的 llama.cpp（本模型基于 gemma4_unified 架构——旧版本无法加载）。

@echo off
cd /d C:\llama.cpp
llama-server.exe ^
  -m C:\models\gemma4-v2-Q4_K_M.gguf ^
  --ctx-size 16384 ^
  --n-gpu-layers 99 ^
  --no-mmap -fa on ^
  --jinja ^
  --temp 1.0 --top-p 0.95 --top-k 64 ^
  --host 0.0.0.0 --port 18080
pause

• 🛠️ 智能体使用： 通过 OpenAI 的 tools 字段传递工具（与 --jinja 兼容）。v2 版本会以 Gemma 4 的原生协议输出结构化工具调用，并且能很好地适应智能体循环（读取/搜索/编辑/运行，然后验证）。
• 🖱️ 一键应用： LM Studio / Jan / Ollama — 导入 GGUF 文件，选择一个量化版本，即可开始使用。

🧠 思考模式

v2 版本在回答前会通过 Gemma 的原生思考通道进行思考（请保持 enable_thinking=true，默认聊天模板已对此进行处理）。推荐采样参数：temp 1.0, top_p 0.95, top_k 64；对于编码任务，也可以使用贪婪采样（temp 0）。

⚠️ 注意事项

• 专为编码/终端/智能体场景优化。 通用知识事实/数字仍需仔细核对。
• 减少拒绝回答： 专注于任务的训练，未进行安全对齐 — 生产环境中请自行添加安全防护措施。请负责任地使用。🙏
• 以英语为中心。

📚 基础模型与许可

• 许可协议：Apache 2.0。 Gemma 4 由 Google 根据 Apache 2.0 协议发布（与旧版 Gemma 1/2/3 的条款不同），因此本微调版本同样遵循 Apache 2.0 协议 — 可免费使用、修改和再分发。🎉
• 基础模型： google/gemma-4-12B-it。
• 个人/业余项目 — 按原样分享，不提供任何担保。倾注时间、心血和大量咖啡打造而成。祝您使用愉快！🐾✨

⚡ 推测性解码（MTP 草稿）— 已验证构建

MTP/ 文件夹中提供了 Gemma 4 的多 token 预测草稿（unsloth 对 Google 官方 gemma-4-12B-it-assistant 的 GGUF 格式转换），用于推测性解码。Gemma 4 MTP 已集成到 llama.cpp 主线（PR #23398）— 无需使用分支 — 但目前 gemma4-assistant 加载器对构建版本较为敏感，因此请使用以下确切构建版本：

• ✅ 已验证可用：llama.cpp b9553（提交 9e3b928fd）。 我使用 gemma4-v2-Q8_0 和 MTP-Q8_0 草稿进行了测试：加载正常，并且生成速度有所提升（在简单的确定性提示下，约从 88 → 180 tok/s；在实际编码/思考场景中，预计提升约 1.2–1.3 倍）。无论是否使用，均无信息损失。
• ⚠️ 较新版本（例如 b9702 / b9717）目前在加载草稿时会崩溃，提示 invalid vector subscript。这是 gemma4-assistant 加载器路径中的上游回归问题，并非这些 GGUF 文件的问题 — 相同的文件在 b9553 版本上可以正常加载。在 upstream 修复此问题之前，请坚持使用 b9553 版本。

在 b9553 版本上的工作命令（注意使用旧版标志名称 — --model-draft，而非 --spec-draft-model）：

llama-server -m gemma4-v2-Q8_0.gguf ^
  --model-draft MTP\gemma-4-12B-it-MTP-Q8_0.gguf ^
  --spec-type draft-mtp --spec-draft-n-max 4 ^
  -ngl 99 -ngld 99 -fa on --jinja

ℹ️ “Gemma4Assistant requires ctx_other to be set (this is normal during memory fitting)”这一行提示并无影响。当前草稿模型为通用的Gemma 4助手（未针对v2版本重新训练），因此其接受率会略低于模型专用草稿的水平——但仍能实现100%无损效果。在显存较小的显卡上，Q8主模型+长上下文+草稿模型的组合可能会显得紧张；若遇到内存溢出（OOM）问题，请降至Q6_K/Q4_K_M量化级别或减小--ctx-size参数值。