peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF · Hugging Face

来源：https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF
TielCoder — 基于 Ornith-1.5 35B-A3B，经过锐化优化与动态量化处理

SWE-bench-Live：Tiel 在 25 个问题中解决 12 个，与 Opus 4.6 持平，并超越 KAT-Coder、Nail、原版 Qwen3.6-35B-A3B 和 Ornith

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#straight-to-the-point直入主题

Tiel 是工具库中的快速编码器。在 4-bit 量化下仅需 22 GB 显存，它就能以与 Opus 4.6 中等规模相当的效率（及速度，配合合适 GPU）修复实际代码库问题，同时保持我们测试过的所有本地模型中最佳的多轮对话质量。它也恰好不擅长琐碎问答。

工作选用它，考试选别的。

这是 Ornith-1.5-35B-A3B (https://huggingface.co/ornith-ai/Ornith-1.5-35B-A3B) 采用自定义重要性矩阵动态重量化，并内嵌 Sharp 对话模板 (https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-Templates) 的 GGUF 版本。
含多 token 预测头的 TielCoder MTP GGUF 版本请见此处 (https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF-MTP)。

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#the-numbers性能数据

与其他本地构建版本对比：
SWE-bench-Live：Qwen3.8-27B 在 25 个问题中解决 16 个（平均 50.2 分钟/问题），Dirk 解决 15 个（20.1 分钟），TielCoder 解决 12 个（8.6 分钟），原版 Qwen3.6-35B-A3B 解决 8 个（5.5 分钟）
多轮对话：Claw-Eval 多轮测试中，Tiel 综合得分 67.2，优于 Ornith 的 65.3 和 Nail 的 60.5（各基于 114 段评分对话）
推理与知识：MMLU-Pro 测试中，Tiel 得分 73.7，Nail 得分 84.0（均为 4-bit 量化，对照组单独验证模板影响）

性能定位
在 25 个 SWE-bench-Live 问题中，Tiel 解决了 12 个——与 Opus 4.6（中等规模）持平，比 Ornith-1.5 本身多 4 个，比 Nail 多 3 个，比 Sonnet 5（中等规模）多 4 个。在同量级模型中位居前列；领先者均为稠密 27B 模型与 Opus 5。其耗时稳定性也优于 Nail：中位数 8.6 分钟（Nail 为 7.2），但平均值 8.6 分钟（Nail 为 15.7），因其避免了 Nail 的高耗时尾部问题。

对话表现
在 Claw-Eval 多轮任务中，Tiel 得分 67.2，优于 Nail 的 60.5 及其基础模型 Ornith 的 65.3。其优势在于回答质量而非提问数量：相比基础模型，回答质量高 3.8 分，澄清性提问少 5.1 分。由于评分权重对答案的侧重是提问的四倍，这种权衡值得——但若需要模型在行动前对模糊请求进行追问，则基础模型表现更好。

知识损耗
MMLU-Pro 得分 73.7（Nail 为 84.0），均为 4-bit 量化。差异主要源于基础模型特性：Ornith-1.5 原始得分 78.0，而原版 Qwen3.6-35B-A3B 为 85.3。我们的量化处理并非主因——采用 Ornith 原生模板的同量化版本得分完全一致。剩余 4.3 分差异源于 Sharp 模板促使答案更简洁，这正是本构建版本追求的权衡。

如何选择

• 智能体编码或需保持长期对话实用性 → Tiel
• 考试型知识与高难度推理 → Nail（MMLU-Pro 高 10.3 分，但对话能力低 6.7 分）
• 忽略显存追求单问题最高修复量 → Dirk（稠密 27B 模型，同批问题中解决 15 个，较原版 Qwen3.8-27B 仅差 1 个，但速度快 2.5 倍）

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#run-it运行方法

显存适配说明：最后一列显示可同时容纳权重及运行所需显存的最小显卡规格。实际上下文开销低于文件大小暗示——这是混合 SSM/注意力架构，仅含 2 个 KV 头，因此缓存增长量远小于同规模稠密模型。

# 下载并运行基础文本模型
hf download peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF \
  Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf --local-dir Tiel
llama-server -m Tiel/Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf -ngl 99 --jinja

# 采样参数建议：temperature 1.0, top_p 0.95, top_k 20（智能体编码时可用 temperature 0.6）

视觉能力
Tiel-Coder 继承 Ornith-1.5 的视觉模块——可直接输入测试失败截图、堆栈跟踪或设计稿。投影器为 mmproj-BF16.gguf（单文件 903MB，各量化级别共享），完全保留 Ornith 原始组件。我们仅修改对话模板而非权重，因此底层投影器保持原样。

# 下载含视觉组件的版本
hf download peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF \
  Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir Tiel
# 运行视觉推理示例
llama-mtmd-cli -m Tiel/Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf --mmproj Tiel/mmproj-BF16.gguf \
  -ngl 99 --image screenshot.png -p "Why is this test failing?"

视觉模块未受量化影响：所有量化级别均使用原始 BF16 精度的投影器，因此 2-bit 文本模型与 8-bit 模型的视觉能力完全一致。

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#no-multi-token-prediction-head无多 token 预测头

Ornith-1.5 发行版包含 MTP（nextn）模块，但本仓库各量化版本未携带——原因现已过时，以下为完整始末。

构建这些量化版本时，该模块尚未训练。所有矩阵标准差均为 0.020，峰度 3.00，最大值为 5 倍标准差（典型随机初始化特征），而同文件所有已训练层的峰度介于 4-39 之间，离群值超过 14。随机权重草稿的接受概率如同随机猜测，因此该模块占文件体积的 2.4% 却未发挥作用，移除后无任何输出变化。

Ornith 于 2026-08-23 修复此问题，重新上传了含训练完毕模块的单分片。我们实测了替换件：峰度 25.1，离群值达 98 倍标准差，nextn 投影层值为 825——无论如何解读都非随机初始化状态。该头现已生效，并包含在 Tiel-Coder-35B-A3B-GGUF-MTP 中。

本仓库量化版本为最新构建但未重建。重新上传仅涉及 MTP 张量——lm_head 在修复前后完全一致，第 39 层专家值的集合也相同——因此其他组件未变动。若运行时支持多 token 推测解码，请选用 MTP 版本；否则可节省该头占用的 0.9 GB 显存。

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#how-the-imatrix-was-made重要性矩阵的生成方式

每个量化级别均基于我们自建的重要性矩阵，而非借用矩阵。校准语料来自 eaddario/imatrix-calibration（MIT 协议）的 4900 万字符，约四分之三为 code_medium，四分之一为 combined_all_large，二者交替混合而非分区存放。此设计有意为之——Tiel 定位编码场景，故语料侧重代码；混合切片则保留数学、工具调用与非英语文本，确保这些路径不会在量化中被粗劣处理。

该矩阵在原始 BF16 权重的 Q8_0 量化版上测算，通过 3000 个 512 token 分块（约 150 万 token），足以让每个专家被充分激活——本模型为 256 专家混合架构，每个 token 路由 8 个专家，过短的语料会导致部分专家未被充分训练。最终量化版本基于 BF16 源文件配合此矩阵生成。

该矩阵本身提供下载，即 Tiel-Coder-35B-A3B.imatrix.gguf（183 MiB，510 个张量）——无需耗时自行测算，一条命令即可生成未发布的量化版本：

hf download peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF Tiel-Coder-35B-A3B.imatrix.gguf --local-dir .
llama-quantize --imatrix Tiel-Coder-35B-A3B.imatrix.gguf Ornith-1.5-35B-BF16.gguf out.gguf IQ4_XS

请注意该命令的局限性：上表中的量化版本采用逐张量动态配方叠加于此矩阵，并搭载 Sharp 模板。直接使用上游 BF16 文件执行 llama-quantize 无法复现任一效果。

eaddario 的代码切片本身构建于 Open-Critic-GPT、opc-sft-stage2、Magicoder-Evol-Instruct-110K 和 McEval-Instruct。

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#limitations局限性

• 考试成绩是其弱项：若以 MMLU-Pro 为标准，Nail 高 10.3 分
• 澄清性提问比基础模型少 5.1 分：简洁未必总是优势，模糊请求可能直接应答而非追问
• 基准测试中 SWE-bench-Live 每题仅单次运行，MMLU-Pro 使用三个随机种子，细微差异视为噪声
• 仅支持中英双语（继承自基础模型）

https://huggingface.co/peculiar-ragdoll/Tiel-Coder-35B-A3B-GGUF#credits致谢

• ornith-ai：Ornith-1.5-35B-A3B 权重（MIT 协议）
• Unsloth：动态 GGUF 量化方法的原始实现
• froggeric：Sharp 模板的源流模板
• eaddario：重要性矩阵校准语料（MIT 协议）
• llama.cpp：llama-quantize/llama-imatrix/llama-server 工具链

基于 MIT 协议，继承 Ornith-1.5 的许可证条款。