一直在通过3批评判器流程运行Qwen3.6-27B。这个流程的重要性远超我的想象。
摘要
报告了通过3批评判器编码流程运行Qwen3.6-27B(8位)的情况,发现该流程能有效捕捉错误,使最终输出质量与前沿模型相当,并提出了一种工作流:前沿模型负责规划,Qwen负责执行。
我已经通过我的编码流程运行Qwen3.6-27B(8位)几天了,同时还运行了GLM5.2。该流程使用3个评判器——代码审查、测试审查、Playwright端到端测试——每个评判器在接受输出前都会使用新的上下文。Qwen3.6作为27B稠密模型是名副其实的。基准测试没有骗人。它能处理仓库级别的推理,生成不错的代码。但确实,它比前沿模型犯更多错误。意料之中。我没想到的是,我为前沿模型构建的3批评判器流水线在这里竟然非常适用。评判器捕捉了额外的错误。流程处理了重试开销,没有打乱节奏。经过评判器处理后的输出质量足够好,以至于我看不出与前沿模型运行在最终质量上的区别。只是过程更嘈杂。不过有一点,这次运行的执行计划是由GLM5.2编写的,而不是Qwen3.6。我的猜测是,最佳分工是前沿模型负责规划,Qwen3.6负责执行。在推理至关重要的地方使用强模型,在高容量实现中使用廉价模型,由流程捕捉错误。
相似文章
构建 Qwen 3.6 - Codex 桥梁:进一步进展与现实现状检查
作者更新了自定义的适配器和 UI 桥接工具,以便通过 llama.cpp 在本地 RTX 5090 上运行 Qwen 3.6 模型,从而在 GitHub Copilot Codex 中使用。本文详细介绍了已实现的功能、修复的 Bug 以及在实现与原生 OpenAI 模型等效性方面仍存在的局限性。
我无法让Qwen3.6 27B超越Qwen-Coder-Next,不确定原因
用户报告称,Qwen-Coder-Next 在实际测试和合成基准测试中均优于 Qwen3.6 27B,尽管其他人称赞 27B,用户寻求关于可能设置问题的建议。
在github-copilot、pi、claude-code和opencode中使用Qwen3.6 27B完成相同任务
作者使用相同的 Qwen3.6 27B 模型测试了多个编码代理框架(GitHub Copilot、Pi、Claude Code、OpenCode),发现框架设计对性能影响显著,其中 OpenCode 在网络搜索和 Web 开发方面表现出色,而 GitHub Copilot 在文件编辑工具方面表现不佳。
引用 Georgi Gerganov
Georgi Gerganov 证实 Qwen3.6-27B 是一个非常强大的本地编程模型,他日常在 M2 Ultra 或 RTX 5090 上使用一个轻量级框架来运行它。
本地运行 Qwen3.6-35B-A3B 作为编码 Agent:我的完整部署与可用配置
一份详尽指南,教你如何在 Apple Silicon 上通过 llama.cpp 本地运行 350 亿参数 Qwen3.6 模型,并驱动 pi 编码 Agent,附带优化后的启动参数与采样配置。