一直没找到在DGX上能完全满意的一套模型配置
-
说个可能被忽略的角度:你换了一圈模型还在翻车,问题可能一半不在模型,而在长程任务的组织方式。Kanban 跑长程任务时"幻觉、偷懒、自己找台阶"这三种症状,最常见的原因是这几点:
-
任务粒度太大。一张卡片里塞"完成整个功能",模型跑到后面连最初目标都忘了,只能开始编。正确做法是把大任务拆成一张卡一个可验证的小步骤,每张卡有明确的完成定义(比如"输出某文件、满足某条件"),做完立刻归档。
-
上下文越滚越长,模型会"找台阶"。长任务跑到后面,历史对话占满上下文,模型为了收尾会假装完成。解决:每完成一个阶段就把该阶段的结论压缩成一段摘要(用 handoff 或让它更新项目笔记),把原始过程归档,保持工作上下文精简。
-
温度太高是幻觉放大器。长任务建议把 temperature 调到 0.1-0.3,工具调用和代码输出会稳定很多——不少"幻觉"其实就是采样太随机。
-
模型分工比单模型硬扛更有效。规划决策用你手上最强的模型(哪怕慢一点),执行简单步骤用快的模型。你提到 qwen3.6 27B 早期 toolcall 截断,那个问题在近几个版本的 SGLang/vLLM 上基本修掉了,值得配 MTP 再试一次,顺便 --kv-cache-dtype fp8 能省不少显存。
单台 DGX 跑不了大模型确实是硬件天花板,但 kanban 长任务的稳定性更多是编排问题,不是模型大小问题——小模型+好的任务拆解,往往比大模型硬跑一个超长任务更可靠。先把编排理顺,再决定要不要上更大的模型,可能更省心。
-
-
qwen3.6 27B是有會因為tool call問題而中斷任務的可能, 事實上deepseek也是有toolcall leak 造成coding agent中途停下的問題.
我的解決方法有兩個:- 使用claude code或codex cli的goal工具. 設定了/goal 之後, coding agent會督促模型沒有完成不能停下來. 兩者實現的方式不同, 各有一定效用. 其他如kimi code也是有這個命令,只是我沒用過.
- 我掛了一層proxy上去, 在模型跟code/claude code之間,專門去攔截有問題的訊息,把message修復, 讓整個工作可以繼續下去. 目前我在qwen 3.6 27B, deepseek v4 flash, glm 5.2都有遇到類似但不同的問題, 都是靠proxy修復. 我用的proxy有兩個, 一個是純proxy, https://github.com/ladiossoop5star/opencode_compat_proxy , 一個是因為後來我用litellm做模型的routing, 所以另外做了litellm的hook https://github.com/ladiossoop5star/litellm_coding_agent_hook . 可以參考看看.
-
個人淺見, 如果是複雜冗長的任務, 可能還是用coding agent去跑會比較容易掌握, 可以讓hermes跟coding agent(codex cli/pi agent/claude code/kimi code..等等)協同作戰, 由hermes監控coding agent並由user手動或自動送命令過去.
早期我沒解決會停下來的問題之前, 我是讓openclaw 定期去巡視工作中的tmux sessions, 有誰停下來了, 看起來又還沒完成工作的, 自動送出繼續+enter, 他就會繼續跑了. 也可以讓openclaw/hermes定期或手動讓他回報目前進度跟輸入指令.Deepseek單機我是沒跑過, 我是用雙機跑原版的. 原版權重160G, IQ2SS 應該也差不多80G. 我看論壇上心得是沒有太大損失, kv也足以支撐512K x 3 或 256K x 5. 不過他沒圖像, 剩餘的ram應該也不太夠去架多模態, 如果需要處理圖像可能就無法考慮了.
體感上我覺得deepseek v4 flash比qwen 3.6 27B Q8強一點, 但是差距沒有到很大. qwen 3.6 27B我之所以跑Q8, 是因為這已經是我能接受的速度的極限了, 不然全精度還是放得下的. 後來有出了有含MTP頭的模型我就沒試過BF16了, 或許BF16的qwen 3.6 27B速度有所提升也不一定.
不過, deepseek v4 flash正式版即將推出,或許一切都會讓人改觀.

-
個人淺見, 如果是複雜冗長的任務, 可能還是用coding agent去跑會比較容易掌握, 可以讓hermes跟coding agent(codex cli/pi agent/claude code/kimi code..等等)協同作戰, 由hermes監控coding agent並由user手動或自動送命令過去.
早期我沒解決會停下來的問題之前, 我是讓openclaw 定期去巡視工作中的tmux sessions, 有誰停下來了, 看起來又還沒完成工作的, 自動送出繼續+enter, 他就會繼續跑了. 也可以讓openclaw/hermes定期或手動讓他回報目前進度跟輸入指令.Deepseek單機我是沒跑過, 我是用雙機跑原版的. 原版權重160G, IQ2SS 應該也差不多80G. 我看論壇上心得是沒有太大損失, kv也足以支撐512K x 3 或 256K x 5. 不過他沒圖像, 剩餘的ram應該也不太夠去架多模態, 如果需要處理圖像可能就無法考慮了.
體感上我覺得deepseek v4 flash比qwen 3.6 27B Q8強一點, 但是差距沒有到很大. qwen 3.6 27B我之所以跑Q8, 是因為這已經是我能接受的速度的極限了, 不然全精度還是放得下的. 後來有出了有含MTP頭的模型我就沒試過BF16了, 或許BF16的qwen 3.6 27B速度有所提升也不一定.
不過, deepseek v4 flash正式版即將推出,或許一切都會讓人改觀.

@soop-ladios 昨天装个 codex,然后和他讨论一番。决定在 codex 复制我在 Hermes 上的工作流。需求端保留在 Hermes。全文档交换系统。Hermes 用codex-run 方式启动。然后 简单cron扫描交换区进行双向通讯。阻塞性事件微信通知人肉处理。跑了一个自动抓雪球 文章的并整理评级的小项目效果很好。对多 agent看板工作流控制比我在 Hermes 手工攒起来强多了。后台用的 DeepSeek false 还没接 DGX,可能也是特别顺的原因之一。下次转到本地模型的再试
-
@soop-ladios 昨天装个 codex,然后和他讨论一番。决定在 codex 复制我在 Hermes 上的工作流。需求端保留在 Hermes。全文档交换系统。Hermes 用codex-run 方式启动。然后 简单cron扫描交换区进行双向通讯。阻塞性事件微信通知人肉处理。跑了一个自动抓雪球 文章的并整理评级的小项目效果很好。对多 agent看板工作流控制比我在 Hermes 手工攒起来强多了。后台用的 DeepSeek false 还没接 DGX,可能也是特别顺的原因之一。下次转到本地模型的再试
-
這個模型我有用一陣子, 蠻不錯的, 不過有一些過度思考跟loop輸出的問題, 而且他們好像還在tune, 可能再等一陣子吧.
-
GDX 部署好了 SGLang+27B 了。Mamba size 要自己显式设定等于你的并发数*5,否者 SGLang 会限制你的并发数。SGLang 在部署27B 的时候竟然认不全所有共享内存。我把--mem-fraction-static 1.4 才把看 kVcache撑起来。这个具体数值可能要自己根据情况看。 Hermes 出了 0.20.0 版,a2a和框架通讯都获益,不需要 cron,不需要 codex cli。Hermes 调用CC switch 配置27B的 codex 做点个人小项目泡一晚上都很稳。@soop-ladios
-
@包磊 不錯喔,不過如果你之前沒試過,或許可以試試hermes直接接deepseek 看看,可能之前就是模型的問題而已
這兩天DGX論壇上也把單台dgx spark裝deepseek flash 0731搞到看起來還不錯,可以試試. 若一台覺得精度不夠,可能要看用量決定是再買一台來張量並行,還是直接用線上的.
兩台速度快很多,prefill 2000初 t/s, decode 40-60 tok/s, 精度也夠,看怎麼取捨了.@soop-ladios 更进一步 2 台 DGX Spark 可以实现 1+1 > 2 的效果,看到没人提就分享一下,成本很高大家量力而行吧。仓库链接: https://github.com/MiaAI-Lab/DeepSeek-v4-Flash-DSpark-2x-DGX-Spark
-
@soop-ladios 更进一步 2 台 DGX Spark 可以实现 1+1 > 2 的效果,看到没人提就分享一下,成本很高大家量力而行吧。仓库链接: https://github.com/MiaAI-Lab/DeepSeek-v4-Flash-DSpark-2x-DGX-Spark

