泥潭日报 uscardforum · 内容汇总

体验了一下Qwen 3.6 35b a3b

📈 搬砖 作者 CB2 原帖 #515250 ↗
内容摘要

Qwen3.6-35B-A3B本地部署体验：性能尚可但指令遵循与上下文存在短板

关键信息与硬件配置

楼主 @CB2 在学校服务器部署 Qwen3.6-35B-A3B (MoE版本) 接 VS Code Codex 和 Claude Code，主要因 Claude API 额度耗尽。 - 硬件环境：双 L40 GPU (48G显存/张)，通过 NVLink 连接，使用 FP8 量化 #6。 - 推理框架：vLLM #1。 - 对比对象：Claude Opus 4.7、Codex、GLM5.2 #1 #10。

性能与体验评估

  • 代码能力：表现不错，甚至能根据 CVE 提示自行寻找 PoC；在 DevContainer 中处理 Docker 路径等复杂操作能力较强 #1。
  • 指令遵循缺陷：边界控制较差，易出现“上下文漂移”，即使强调严格指令也会擅自添加额外内容（如让做 A 却加了 B），类似 Opus 4.7 的表现 #1。
  • 中文“班味”重：回答倾向于写计划书、实施大纲，尤其在中文语境下严重 #1。
  • 工具调用兼容性问题：
    • Codex：Subagent 启动失败，虽能识别 Tool Call 但配置不兼容；存在格式暴露问题（如显示特殊符号）#1。
    • Claude Code：能启动 Subagent，但 Workflow 强制要求 A 家 API Key #1。

上下文窗口与替代方案讨论

  • Context Window：原生支持 256k，对 Claude Code 而言容易满；Codex 使用较久。可通过 yarn 扩展至 1M，但长上下文会导致模型“天马行空” #1 #10。
  • 其他硬件/模型建议：
    • @hoodl 和 @helvettica 推荐尝试 27B 版本或 OpenCode，认为效果可能优于 35B-A3B #2 #8。
    • @CB2 补充：单张 L40 (48G) 即可运行，但 Context 较短；MacBook Pro (M系列芯片) 跑 Qwen3.6-27B (4bit, ~16G内存) 速度较快，但 14寸机身散热严重 #10。
    • @CB2 提及 GLM5.2 测试：需约 700G 系统内存 + 80G 显存，FP8 下速度仅 1-2 tok/s，效果略逊于 Opus #10。

风险/限制/注意事项

  • Prompt 质量依赖高：不像 Claude 原生模型那样能在模糊指令下主动反问或推导，对 Prompt 工程要求较高 #1。
  • API Key 绑定限制：Claude Code 的 Workflow 强依赖特定 API Key，限制了本地模型的无缝替换体验 #1。
原始内容
--- 第 1 楼来自 CB2 的回复 (2026-06-27 13:37:49 PDT) ---

Claude 20x的usage用完了，周末还得干活，只能用自己host的qwen来写代码，顺便也可以体验一下开源模型和前沿模型差距在哪，就deploy了个qwen3.6的moe版本在学校服务器上，接到claude和codex上用，体验了一下，感觉其实本地llm在好的prompt和人为干预下其实可以干绝大多数前沿模型能干的事情 ├───────────┼──────────────────┼─────────────┼───────────┼───────────┼────────────┼──────────────┼────────────┤ │ 2026-06-… │ - │ 158,989,476 │ 1,107,946 │ 0 │ 0 │ 160,097,422 │ $24.96 │ │ │ Qwen3.6-35B-A3B │ │ │ │ │ │ │ ├───────────┼──────────────────┼─────────────┼───────────┼───────────┼────────────┼──────────────┼────────────┤ 用 vLLM 跑 Qwen 接 VS Code 的 Codex 时， subagent 启动不起来（能识别 tool call，但好像 Codex 侧配置不兼容）；Claude Code 虽然能启动 subagent，但 workflow 必须要A家的 API Key 才能跑通。 Codex 和 Claude Code 调 Qwen 时都有格式暴露问题，比如 会显示在界面上，有点怪 Qwen 对指令的边界控制有点蠢。比如让qwen只做 A，它会顺手加个 B；明确强调“严格按指令执行”，它还是会给你带点新活，简直幻视Opus4.7，表现类似上下文漂移。对 prompt 质量要求较高，不像 Claude 原生模型那样在模糊指令下能主动反问或自己推导出解法。 256k的ctx是硬伤。Claude Code 一会就满了，Codex 倒是能用很久。虽然用 yarn 扩展 1M 不算难 写代码的表现其实还不错，给cve的提示甚至能自己找到PoC 用各种tool的能力挺强的，我是在devcontainer里，很多操作需要连外面的docker，他自己还能自己搞定一些奇奇怪怪的路径问题 班味贼重，问问题的时候，上下嘴皮子一碰就开始写计划书、写实施大纲，中文下尤其严重

--- 第 2 楼来自 helvettica 的回复 (2026-06-27 13:50:21 PDT) ---

试试27B+opencode

--- 第 3 楼来自 hoodl 的回复 (2026-06-27 13:58:49 PDT) ---

怎么quantitized？

--- 第 4 楼来自 AppleVisionPro 的回复 (2026-06-27 14:02:24 PDT) ---

CB2: 班味贼重，问问题的时候，上下嘴皮子一碰就开始写计划书、写实施大纲，中文下尤其严重 不愧是阿里出来的model，估计训的时候，阿里内部的对话用了不少

--- 第 5 楼来自 CB2 的回复 (2026-06-27 14:23:17 PDT) ---

我觉得可以，等会试试

--- 第 6 楼来自 CB2 的回复 (2026-06-27 14:24:38 PDT) ---

用的fp8,串了俩l40

--- 第 7 楼来自 tttr 的回复 (2026-06-27 14:39:21 PDT) ---

自己host这个vllm好用吗？我试了llm studio，想让模型搜索网页还得自己装个mcp

--- 第 8 楼来自 hoodl 的回复 (2026-06-27 14:42:23 PDT) ---

试试27b，我觉得比35b-a3b效果好。

--- 第 9 楼来自 turner 的回复 (2026-06-27 15:19:07 PDT) ---

请问楼主什么硬件host的

--- 第 10 楼来自 CB2 的回复 (2026-06-27 15:51:29 PDT) ---

俩l40s，有nvlink。其实一块48G的都能跑，就是context window比256k短一点，但也无所谓，上下文一长他就是开始天马行空了。其实macbook pro也能跑qwen3.6 （27b,4bit大概模型本身16G内存，还得算上后面的context），omlx的话速度其实挺快的，就是14寸的机子会烫到煎鸡蛋。你要是有集群的资源的话，有内存大的机子还可以跑更大的，我试过跑GLM5.2，可以把exports全offload到内存里面，FP8的话，大概要700G内存，80G显存，速度大概1-2tok/s，属于话都说不利索，但效果还可以，我觉得比opus稍微笨一些，但不多

📈 搬砖 · 其他高楼

← 返回 📈 搬砖