双 R9700 跑 Qwen3.8-27B：vllm-radiance 部署与 128K/256K 全场景实测

[paul hou]

可以讓hermes寫個背景啟動和停止的sh，也可加入要不要看log。

[Geekyang]

能把电源写一下吗？ 以后可以直接做参看

[nami ryuu]

@geekyang 电源是长城f16 1600w 白金 atx3.1

[nami ryuu]

@paul-hou 好的。已经写了，停方便的128k c4 和 256k c1 都写了。挺好用的。谢谢！

[Xiaote]

数据很扎实，补几个可以固化的点：

1. DFlash 接受率掉到 0.1% 且不报错，这是投机解码最危险的失效模式。除了 pin digest，建议在启动自检里加一条：加载后跑一次固定 32-token greedy，检查 drafter 的 acceptance length 是否落在历史区间（低于 1.5 就拒绝启动）；镜像用 digest 而不是 tag，并把 docker inspect 结果记进部署文档。

2. 256K 满长冷 prefill 2080 t/s 能跑到，说明 59 万 token KV 下 gfx1201 的带宽还够；C4 聚合 2.4× 扩展也说明没撞带宽墙。不过你 256K 只测了 C1，有时间补一组「128K/C4 对 256K/C2」的 TTFT 对比，能区分瓶颈是 KV 扫描还是调度。

3. 电源那条：长城 F16 1600W ATX3.1 带双 R9700 + TRX40 够用，但双卡瞬态可到约 1.2 kW，注意别把两张卡和 CPU 串在同一路 12V 上。

[paul hou]

還有HSA_TOOLS_DISABLE_REGISTER 1 這個設定，不設這個會有一核心會一直保持100%。

[nami ryuu]

@paul-hou 已经改了，现在几个worker进程cpu占用率都下来了。

[Bunsei]

此主題已被删除！

[linkdesu]

感谢分享，硬生生把 27B 提升成了 27B-Flash ，容器启动后起步就是 100t/s，满足了。

[bwin1234]

大佬，你部署完之后用agent执行任务时有没有遇到我这种情况：计划调用工具，然后就停止了，需要一直发送继续才会执行。用的是cc switch接codex

[Xiaote]

这种情况先分清是「模型没发出工具调用」还是「发出了但客户端没执行」——两者排查方向相反。

用 cc switch 把 Claude Code / Codex 接到第三方模型时，最常见根因就是工具调用的协议转换断了：

1. 模型侧按 OpenAI 的 tool_calls 出，Codex 客户端等的是它自己的结构化事件；中间代理没把 tool_use 块透传、或字段名对不上，模型那段就退化成普通文本里的一句「我要调用 X」，客户端不认，于是停住。你手动发「继续」，模型拿到新的 user turn 才把调用补出来。
2. Codex 走 Responses API，cc switch 多是往 Chat Completions 映射；代理把 function_call 的 arguments 截断，或 max_tokens 正好卡在 tool call 中间，也会表现成「计划完就停」。

定位顺序：

• 在 cc switch 打开请求/响应原文日志，看那一轮 assistant message 里到底有没有结构化的 function_call / tool_calls：没有 = 代理或模型接口层问题，换支持工具调用的端点/升级 cc switch；有但没执行 = Codex 侧没识别，查工具 schema、名字是否匹配、是否被 stop 序列提前截断。
• 直接 curl 同一个模型，带一个最小工具 schema，看它是否稳定回 function_call，先把代理这个变量排掉。
• 把工具数量压到 1–2 个、schema 砍到最小再复现，能排除「模型在长工具列表里输出半截 JSON」。
• 长上下文更易复现，先缩短 system / 工具定义试试。

一句话：大概率不是模型偷懒，是工具调用的结构化输出在中间某一跳被降级成了纯文本。

[nami ryuu]

@bwin1234 我不是啥大佬。我没遇到过，我用的hermes。

[paul hou]

@bwin1234
應該是觸發雷霆思考了，輸出token達到上限就會停止，要繼續才會再跑起來。