抡锤者

abaalei

@Queen-Laura a6000 哈哈等大佬出结果啦

abaalei

@terry https://www.bilibili.com/video/BV1dVhW6zEoH/ 我只是一个把服务器放在床上抱着睡的折腾男罢了就跟老特你说的一样，现在有hermes 有deepseek，人类只需要负责物理操作，剩下的，动动嘴皮子喊ai去搞就是了，我这几天都没怎么动过啥，就是看到有好的项目就扔给ai分析是否适合自己用，适合就跑调优，不适合就放着

服务器 3500
处理器 450
内存 3508
显卡 10004
8fdc0aa6-1a26-40cc-91a7-37f73190586e-aee0dba1c5ca95984eb8c35ccf248e3.jpg
da80ff40-e838-43ff-be11-9ee90797957e-55cb642690dbd94595b946b2eb4c99b.jpg

目前我都在想卖一张7900xtx，再买4张T10了
不管是comfyui，还是LLM，4张T10都能跟2张7900xtx打55开

abaalei

@Misakiyu-Xmilk G292 Z20 技嘉的服务器

abaalei

硬件环境：
• 采样节点（Node-292）：4× NVIDIA Tesla T10 16GB (Turing/sm75), PCIe P2P, 无 NVLink, ComfyUI 0.30.0, PyTorch 2.13.0+cu130, Ray 2.58.0, xfuser 0.4.4, Raylight (Ulysses=4, Ring=1, FSDP=true)
• 解码节点（Node-241）：NVIDIA GeForce RTX 3080 Ti 12GB (独立 ComfyUI 0.34.0, CUDA_VISIBLE_DEVICES=0 物理隔离)
• 网络链路：千兆/2.5G 局域网（实测带宽约 2.35Gbps）

业务场景：MiniMax H3 视频生成模型 REF2VA 工作流（416×736 分辨率、124 帧、24fps、Turbo LoRA 6 步去噪）。

0. 核心结论与实测收益

在多卡高负载视频生成场景中，瓶颈往往不在于单卡算力，而在于重载扩散采样与高开销 VAE 视频/音频解码串行争抢资源。

通过构建“双机阶段级异步流水线”（4×T10 专职纯扩散去噪，RTX 3080 Ti 专职 INT8 视频 VAE + 音频 VAE + MP4 封装），实测数据如下：

指标维度	传统单机全部串行	双机阶段流水线	收益变动
4×T10 采样+保存 Latent	~140.45 秒	~140.45 秒	专注去噪，无上下文打断
跨机 Latent 传输 (4.3MB)	0 秒 (本地)	1.0~1.2 秒	局域网开销极低
3080 Ti INT8 VAE + 封装	串行计入关键路径	完全隐藏于下一任务	边际耗时被掩盖
连续 2 条视频 Makespan	305.32 秒	292.17 秒	总耗时降低 4.31%
长队列稳态吞吐	23.58 条/小时	25.61 条/小时	吞吐量提升 +8.59%

时间轴 ─────────────────────────────────────────────────────────────>

Node-292 (4×T10)   [ 第 1 条采样 140s ][ 第 2 条采样 140s ][ 第 3 条采样 140s ]
Node-241 (3080 Ti)                    [ 第 1 条 VAE 11s ][ 第 2 条 VAE 11s ]

1. 为什么不是“把 3080 Ti 强行并入五卡 Tensor Parallel”？

很多机友第一反应是“能不能跨机器把五张卡拉成一个集群”？在实操中这是典型的反模式：

计算架构异构：Tesla T10 是 Turing 架构 (sm75)，3080 Ti 是 Ampere 架构 (sm86)，底层 CUDA Kernel 与算力特性不一致；
跨机通讯开销致命：跨机器做模型并行（TP/USP）需要极高频的 AllReduce 同步，没有专用 100Gb+ RoCE/InfiniBand 网络必定引起严重通信死锁与性能断崖；
阶段解耦更高效：MiniMax H3 的输出是包含视频与音频的 NestedTensor。416×736 分辨率的 latent 仅仅约 4.3MB。传输 4.3MB 只需要 1 秒，而跑一次 VAE 解码需要 10~13 秒。用阶段级流水线剥离 VAE，可以让昂贵的 4 卡采样集群 100% 跑满，彻底释放吞吐潜力。

2. 核心架构设计与工程落地

① 双流 Latent 结构化导出与原子落盘

MiniMax H3 同时包含视频与音频两组 Latent。自定义落地节点负责：

校验并导出视频 Latent（shape: (1, 24, ...)）与音频 Latent（shape: (1, 32, 2, ...)）；
严格进行 NaN/Inf 数值自检；
先写 .part 临时文件，校验成功后原子重命名为 .h3latent，并同步生成 .sha256 校验指纹文件。

采样工作流尾部改写为：

XFuserSamplerCustomAdvanced 
    └── Save MiniMax H3 AV Latent (输出 4.3MB 双流文件，剥离原生解码)

② 解码机（Node-241）隔离 API 服务

解码端通过独立 Python 虚拟环境拉起专用 ComfyUI 实例，严格实施物理设备隔离：

# 启动解码专用实例（监听指定端口，白名单加载 handoff 节点）
CUDA_VISIBLE_DEVICES=0 ./venv/bin/python main.py \
  --listen 0.0.0.0 --port 8192 \
  --disable-all-custom-nodes \
  --whitelist-custom-nodes h3_latent_handoff \
  --dont-print-server

检查 /proc/$pid/environ 确认环境干净，杜绝与其他计算卡产生资源争抢。

③ 视频 VAE 精度选型：INT8 ConvRot vs FP16

在 3080 Ti 上针对官方 VAE 进行了严格的 A/B 对比：

VAE 选型	尾段纯解码耗时	PSNR 峰值信噪比	均方误差 (MAE)	综合判定
FP16 官方标准 VAE	13.57 秒	41.95 dB	1.39	基准质量，耗时略长
INT8 ConvRot 官方 VAE	10.37 秒	41.50 dB	1.52	速度快 23.6%，画质完全无肉眼可辨损失

INT8 ConvRot 在 124 帧全流程抽检中有限值表现稳定，未出现历史社区反馈过的黑屏或溢出异常，被选定为生产基线。

④ 自动化监控流水线（Watcher Daemon）

后台监控守护脚本监听采样目录，一旦捕获到 .h3latent 与 .sha256 同步就绪：

自动计算本地 Hash，发起跨机安全传输；
远端重验 SHA-256 无误后原子落盘；
远程触发 8192 端口 API 执行解码与音视频合成；
产出结构化审计回执 *.pipeline.json。

3. 深入对比：4 步 Turbo LoRA 是否具备生产可用性？

社区中 Turbo LoRA 标称支持 4 步去噪，我们保持同 Seed、同提示词进行了严谨步数 A/B：

采样步数	4×T10 采样保存	含远端完整耗时	画质与时序表现
6 步（基准）	140.92 秒	154.38 秒	服装细节高度一致，动作自然平滑，生产默认首选
4 步（激进）	95.13 秒	106.22 秒	速度提升 32.5%，但抽帧发现角色服装发生明显漂移（如红色裙装漂移为背带裤）

结论：4 步仅适合前期快速挑分镜、低精度批量预览；生产交付仍坚决锁死 6 步。

4. 失败探索与避坑反模式

反模式一：盲目启用 SAGE_FP16：
在 Turing 架构上强制指定 SAGE_FP16，首个 denoiser 步即抛出 AttributeError: module 'sageattention' has no attribute 'sageattn_qk_int8_pv_fp16_cuda'。Turing (sm75) 并不支持该 kernel，切忌盲从高版本特性。
反模式二：执念于升级万兆网络（10GbE）：
实测 4.3MB 的 Latent 走普通千兆局域网只需要 1 秒。相对于 140 秒的扩散采样，将网络从 1 秒压到 0.2 秒对总体吞吐影响甚至不足 0.5%，切勿在非关键路径上浪费工程精力。

abaalei

@坤坤是的,起码卡回来了

abaalei

@johnnybegood 确实,后路都已经各种找好了,诉讼状也基本写好了

abaalei

@williamlouis 是的,买的时候就预料到的,只是那吊毛不拍胸口我自负盈亏还没啥,那吊毛说了又不做这才是最气的

abaalei

硬件环境：双 AMD Radeon RX 7900 XTX 24GB (XFX 凤凰涅槃 + Sapphire Pulse) + NVIDIA RTX 3080 Ti 12GB，Xeon E5-2682 v4 (x996plus / 241 节点)，Ubuntu 22.04 LTS (Kernel 7.0.0-30-generic)，ROCm 7.2 / amdgpu。

核心场景：本地部署 Qwen3.8-27B 离线大模型推理 & ComfyUI 生图管线。

文档性质：根据系统 syslog/dmesg 底层日志、闲鱼交易记录、微信沟通记录与实物工单取证还原，事实数据完全可核对。

0. 导读与省流摘要

买二手硬件，大家都有“二手出柜、自负盈亏”的心理底线。但这块 7900 XTX 的经历把二手生态的人性反差与厂商保修潜规则展现得淋漓尽致：

原卖家画饼：闲鱼 4700 元购入，交易前买家担心拒保，卖家拍胸脯语音立誓：“有问题找我，我帮你去售后，我就不信了！”
硬件暴毙：上机运行多卡推理与生图，遭遇深层次 AMD SMU（电源管理单元）通信死锁，最终跨平台永久卡死 VGA 故障灯，POST 自检循环重启。
卖家现形 & 官方秒拒：真出故障后，原卖家光速变脸要推给私人作坊高价维修；官方 400 系统因卡出厂在 2025 年 1 月 1 日前，个人送保看都没看直接秒拒。
绝处逢生：挂闲鱼 3000 元准备当尸体料板止损时，遇上好心买家指点迷津——绕过个人送保，走官方授权区域代理商代送修（仅收几十元代送费，不查一手凭证）。
换新下车：寄出后顺利返厂，厂商直接以换代修换回一张良品卡，满血复活！

【原卖家 4700 拍胸脯画饼】
       │
       ▼ (运行 Qwen3.8 / ComfyUI)
【SMU 0xFFFFFFFF 死锁 → 永久卡 VGA 灯暴毙】
       │
       ▼
【找卖家被推诿加钱 ➔ 官方个保因 2025 前老卡秒拒】
       │
       ▼
【闲鱼 3000 标尸体甩卖】
       │
       ▼ (闲鱼老哥指点迷津)
【走官方 400 查 SN ➔ 对接区域代理商 ➔ 50元代送费】
       │
       ▼
【官方售后以换代修 ➔ 换回良品卡满血复活！】

1. 祸根初埋：4700 元拍胸口画饼的闲鱼卖家

2026 年，为了扩展 241 算力节点的本地推理能力，我在闲鱼“智创电脑配件小卖铺”看中了一张 XFX 讯景 RX 7900 XTX 凤凰涅槃。

买卡前，我知道讯景历史批次的保修对二手极不友好，因此特意在下单前沟通确认：

[买家] 老板早上好，我刚打电话问过讯景那边，他们说没有原始记录会产生拒保。
       那您这边看看能不能优惠一点，或者找原始卖家拿回购买资料之类？确定还在保对吗？
[卖家] 确定！
[卖家（语音 5秒）] 你就放心好了有问题你找我我帮你去售后去我就不信了举报！
[卖家（语音 10秒）] 那你就这么跟他说，所有的厂商都可以个人支持个人送保……
                  如果确定不支持，那以后谁还买讯景的产品呢？
[买家] 那可以，可以小刀再包个顺丰吗？
[卖家] 4700。（发起专拍链接）

血泪教训：很多卖家为了把高价二手硬件脱手，会毫无心理负担地向买家做任何“口头售后保证”。二手交易中，凡是没有发票白纸黑字过户的“拍胸口保修”，99.9% 都是交易诱饵。

2. 物证时间线：SMU 死锁与显卡物理暴毙的技术溯源

卡插上 241 节点后，满载温控确实不错（满载核心 60~70℃，热点 80℃）。但高负载运转几天后，这颗 Navi 31 核心的隐藏暗病彻底爆发。

故障演化时间线

日期 / 时间	运行场景	系统底层现象 / 日志证据	状态判定
2026-08-30 19:12	运行 Qwen3.8-27B 连续推理	`dmesg` 报 `SMU: response:0xFFFFFFFF`，风扇读不到 PWM 满转拉啸，音频总线掉线	初次发作：接口版本不匹配导致 SMU 假死
2026-08-30 20:01	内核升至 7.0.0-30 验收	`smu driver if version = 0x3d` vs `smu fw if version = 0x40`	常驻隐患：驱动层接口与芯片固件脱节
2026-08-30 21:40	拆卡接入 Win 主机延长线	经历一次亮红灯后，在单卡平台下成功复位并点亮系统	侥幸暂活：卡内保护机制短暂解除
2026-09-02 13:45	运行 ComfyUI 批量跑图	核心无计算 hang，但 dmesg 连续刷出 449 条 `SMU no response`，rocm-smi 读不出功耗温度	二次恶化：电源管理单元再次彻底死锁
2026-09-02 14:44	尝试将 linux-firmware 降至 .26	成功降级并锁定包版本，跑满 60 秒 300W 压测看似稳定	假象恢复：以为是驱动固件 bug
2026-09-02 15:30	重启系统验证	彻底暴毙：机器无法通过 POST 自检，VGA 故障灯常亮，风扇转数秒即停，主板断电重启循环	硬件级阵亡：跨主板、切双 BIOS 均无法点亮

核心报错日志切片（取自 /var/log/syslog 与 journalctl）

[ 5641.102941] amdgpu 0000:83:00.0: SMU: response:0xFFFFFFFF message: TransferTableSmu2Dram (44) arg: 0x00000000
[ 5646.103012] amdgpu 0000:83:00.0: Failed to export SMU metrics table!
[ 5651.103088] amdgpu 0000:83:00.0: Failed to get fan speed(PWM)!
[ 5656.103154] snd_hda_intel 0000:83:00.1: Refused to change power state from D3hot to D0
[ 5661.103210] snd_hda_intel 0000:83:00.1: CORB reset timeout#1, disabling-interface

为什么会彻底死掉？
SMU 是 GPU 的大脑神经元，负责各供电相位的动态调压调频（P-State）、温度监控与上电时序。在长期版本失配与重度计算压迫下，该卡的片上电源控制状态机或核心供电 MOSFET/PWM 芯片发生不可逆击穿，导致主板开机给 PCIe 上电时握手失败，触发主板自我保护切断供电。

3. 人性修罗场：卖家推诿扯皮与官方秒拒

卡彻底无法点亮后，我先按照常规路径维权，迎来了连续两记闷棍：

第一棍：官方系统“看都不看直接秒拒”

致电 XFX 官方 400，并提交个人送保申请。官方给出的答复十分残酷：

“该显卡出厂日期在 2025 年 1 月 1 日之前。按照公司规定，旧批次显卡不支持个人送保业务，必须提供第一手原始购买凭据或由经销商出具证明，否则一律拒保。”

售后系统甚至没有让我寄过去检测，直接在后台退回了个人申请单。

第二棍：买前拍胸脯的卖家露出真面目

抱着最后一丝希望，我找到当初信誓旦旦的闲鱼卖家，好声好气商量：

[买家] 找老板你这边送修可以吗，修成功的话给回 350 你们😂😂
[买家] 明白，那可以帮忙看看怎么交给讯景维修吗？现在问题是他们卡都没有看，
       就说我这个卡不能个人送保，要找经销商送才行。
[卖家（语音 8秒）] 这边儿，那就得检查了，那就不是说个人修修了，
                  就得找那个这种维修的，专门儿维修的给修修。
[卖家（语音 2秒）] 那就不是 350。

当初买卡时那句**“有问题你找我我帮你去售后”的豪言壮语，在短短几天内变成了“找专门私人维修修、350块不够”**的杀猪盘。

面对这种无赖嘴脸，多说一句都是浪费口舌。我心灰意冷，把卡拍照，以 3000 元料板/尸体价 挂上了闲鱼，准备自己咽下 1700 元的血亏。

4. 闲鱼遇贵人：老哥拆解“代理商送修”潜规则

事情的惊天反转发生在挂出尸体贴的当晚 22:39。

一位 ID 为 不会飞de云 的闲鱼机友主动发来消息：

[不会飞de云] 兄弟，你这个可以质保的。
[不会飞de云] 只要是真无拆无修的，包可以质保的。
[不会飞de云] 联系代理商就行了，代理商一般要收取几十到一百的送修费，我的刚送去！

随后老哥发来长段语音和实物对比图，为我拆解了二手硬件售后的核心底层逻辑：

厂商个保一刀切背后的漏洞：
厂商卡死 2025 年前的个人送保，是为了卡掉大批矿卡和二手散户直接冲击工厂产能。但这不意味着显卡本身脱保！
真正的绿色通道：区域代理商（总代）：
硬件厂商与一级/二级代理商之间有稳定的返厂维修合同配额。代理商送修走的是经销商 B2B 维修通道，工厂根本不查终端消费者的购买发票！
破局操作 SOP：
- 拨打 400 客服电话，只报序列号（SN 码），确认该卡是否在厂家保修期内；
- 确认在保后，向客服要求获取你所在区域（或全国范围内）的授权代理商/送修经销商联系方式；
- 联系代理商，说明显卡在保，支付 50~100 元的人工代送/物流服务费；
- 代理商查验外观无私拆、无物理磕碰后，直接统一打包发回工厂！

听到这番分析，我茅塞顿开。为了感谢老哥的无私分享，我立刻在闲鱼给对方转了 6.66 元 奶茶钱。在二手鱼龙混杂的泥潭里，这种纯粹的机友互助真的让人心头一暖。

5. 换新落地：以换代修满血复活

周一上班后，我迅速执行了这套代理商送修流程：

400 查保：客服输入 SN 码，系统确认显卡在保（质保期覆盖到 2026 年底）；
对接代理：顺利拿到代理商送修地址；
顺丰寄出：支付 50 元代送服务费，顺丰标快寄出显卡。代理商收到后仅核验了螺丝防拆贴与外观，二话没说直接进返厂系统。

返厂一周后，代理商发来回执：显卡核心供电故障，无法局部维修，厂家判定直接更换良品！

几天后顺丰快递到家，开箱验收：

换回了一张成色极新的官方良品卡，背板出厂贴纸完好；
硅脂垫边缘有少许微量的渗油痕迹（返厂仓储良品的祖传特征，完全不影响电气性能）；
装机上架 241 节点，一键点亮，顺利通过压力测试，满载核心 60℃、热点 80℃，SMU 通信完全正常！

6. 二手高端硬件售后避坑 SOP（总结指南）

如果你也是常年折腾二手显卡、算力卡的玩家，遇到故障被拒保时，请把这套经过实战检验的 SOP 焊在脑子里：

步骤	关键动作	核心禁忌 / 注意事项
Step 1: 验在保状态	拨打品牌官方 400 客服电话，直接报 SN 序列号查询剩余保修天数。	切勿主动在电话里说“我是闲鱼二手的”、“我没有发票”，只问“请帮我查下这个 SN 码的保修截止日期”。
Step 2: 索取渠道信息	若官方称“旧批次不能个人送保”，顺理成章要求：“请提供离我最近的官方授权代理商或经销商送修联系方式”。	只要卡在保，官方客服有义务提供经销渠道送修路径。
Step 3: 走代理商代保	联系代理商，主动提出支付 50~100 元代保服务费/往返运费。	保证显卡无私拆、无严重物理磕碰、防拆贴完整。代理商不关心一手发票，只看在保和无外观损伤。
Step 4: 破除卖家幻想	闲鱼买卡前，把卖家的“保修承诺”一律当放屁。	能给一手京东/原厂电子发票的才算真在保；没有凭证的，按“脱保或走代理”做好预期折价。

（本文全流程数据、硬件型号、沟通截图及系统日志已归档备查，欢迎硬件社区与折腾玩家交流探讨。）

abaalei

这篇是给《零代码接单一个月后，我为什么选择止损：一次手术课件 Vibe Coding 项目复盘》补的一段记录。

那篇复盘是Codex侧（GPT5.6SOL）写的，我在开头留了一句话："此文由 GPT5.6SOL 撰写，它缺少了一开始我使用本地 Agent 迭代时候的上下文"。

缺的正是最重要的那一段——项目最开始，把甲方给的云端方案往一张 12GB 显卡上落的那 47 小时。那一段的代码、交付包、视频产物、文件时间戳和会话账目都还在机器上，所以下面不是回忆，是可核对的记录。

一、那两天到底要解决什么

甲方给的是一个已经在云端跑通的方案。落到本地只有两个硬约束：

一张 3080Ti，12GB 显存（不是 24G，不是 A100），要跑 LTX-2.3 22B 图生视频模型；
交付物很具体：一个能在 ComfyUI 里跑通的纯官方节点工作流 JSON，加一段手机录制的一键生产过程视频。

没有设计文档，没有验收清单，没有"效果达到什么程度算过"。

最后这一条，是整件事真正的病根，后面还会回来要账。

二、47 小时里发生了什么

工作窗口是 7/15 13:10 → 7/17 12:34，10 个会话。其中出交付包、出成片的密集迭代，是 7/15 22:58 → 7/16 14:18 那 15.5 小时。

07-15 13:10 起 — 拆解甲方那份带私有节点依赖的工作流，确定它在 12GB 卡上的可行边界。
07-15 22:58 — 第一版可跑通的 JSON（27KB）。
07-15 23:04 — 试了那个"最优雅"的方案：用 ComfyUI 的 List 隐式循环，一条工作流跑完 6 个场景再合并。当天就被实测否掉了（原因见第四节第一条）。
07-15 23:27 — V2：改架构。 放弃"在画布内部做统一管线"，改成「外部 Python 调度器 + 单场景模板」。
07-16 00:23 / 00:51 — V3（显存优化）、V4（首次完整无 OOM 跑通），三个交付包（v2/v3/v4）在 90 分钟内连发。
07-16 02:44 — V3 实测。这一次会话跑了 916 条消息、455 次工具调用。
07-16 10:00–11:13 — V4 实测：首次产出完整合成片（1.05MB / 36.5 秒）。
07-16 12:05–14:18 — V5：加"四级裁图链"，出移交文档，成片 1.16MB。
07-17 00:25 — 补超分链（384×288 → 高清）。
07-17 12:34 — 甲方真正在意的那个要求第一次露头："识别缝线范围"。

交出的是：一份能跑的产线 + 一段合成好的课件动画。

三、那几天换了多少模型？账目在这里

复盘里记得"换了好几个模型"。会话库把这件事记成了数字。

整个 7 月到 8 月，本地 Agent 侧真实调用过的模型共 13 条记录（跨 provider，9 个模型族）：gemini-pro-agent、gemini-3-flash-agent、gemini-3.6-flash(-high)、claude-sonnet-4-6、deepseek-v4-pro、deepseek-v4-flash、glm-5.2（两个 provider）、grok-4.3、grok-3-mini-fast。

而这一支（7/15–7/17，10 个会话）实际落在 3 个模型上：

gemini-pro-agent — 1,178 次调用 / 938.8 万 token
gemini-3-flash-agent — 429 次调用 / 472.8 万 token
deepseek-v4-pro — 49 次调用 / 9.8 万 token

合计：2,684 条消息，1,656 次 API 调用，1,421 万 token，记录的现金成本 0 元。

这段账目最有价值的地方，不是数字，是它证明了一件事：

换了这么多模型，没有换掉任何一条失败原因。

第四节那 7 条坑，逐条追溯，没有一条跟"模型不够聪明"有关：

List 隐式循环失效，是 ComfyUI 的节点语义问题；
6 张图被拍扁成一个 batch，是工作流的拓扑问题；
VLM 返回坐标格式漂移，用云端模型还是本地模型都一样，缺的是容错代码；
384×288 / 12fps，是 12GB 显存算出来的上限；
验收标准没定义，那是流程，不是模型。

换模型是当时最容易做、也最没用的一件事。 那 47 小时里真正起作用的那次动作（V2 改架构），跟模型毫无关系。

四、技术上有用的部分

1. ComfyUI 的 List 隐式循环，在定制节点上会失效。

理论上往下游塞一个 List 会触发隐式循环，但工作流里的缩放/视频节点内部把 List 拍扁成了 batch=6。表现是耗时 167 秒（正好等于一次生成的时间），而且 6 张图被强行杂糅——模型开始脑补：第一次生出一个戴着白色眼罩的女人，把医学线稿图像海盗眼罩一样糊在眼睛上；改掉提示词重跑，它又脑补出一个穿白 T 恤的男人。

模型看到的不是"六张图"，是"一帧"。 要把一张线稿动起来，就得一张一张喂——"批量"这个动作必须由画布外面的调度器来做。

这也是 V2 那次架构掉头的直接原因，而这次掉头是那 47 小时里唯一被后续验证为正确的判断：画布上永远只有一个场景的模板，复杂度全部关在 Python 里。结果是 6 个场景在 12GB 卡上连续跑完、零 OOM。

2. VLM 给的坐标不可信，但可用。

实际跑通的是"VLM 出坐标 + 程序做后处理"：VLM 会把 1 写成 "Scene 1"，bbox 字段名会漂（ymin / top），偶尔还嵌套数组；加了 8% 边距扩展之后又出现负值越界，导致 OpenCV 保存空图直接崩。

把它当"不稳定的专家建议"，不要当结构化 API。

3. 裁图最终是四级兜底链：CV 自适应（5 档阈值 + NMS 合并）→ VLM 统一检测 + 场景映射 → VLM 传统裁图 → 硬编码坐标。低对比度扫描件上 CV 会整体失效，所以必须能一键降级到人工坐标。

4. 甲方的工作流带私有节点依赖（329:xxx 形式的引用、XB 系列、ROCm 补丁、sageattention）。最后决定全剔除，只留官方节点 + GGUF 加载器——牺牲一点画质，换"能在任何一台干净机器上装起来"。

5. wait_for_completion 只检查 gifs/ 目录，而视频产物落在 videos/ 里，脚本永远等不到结果。

6. 帧数没有注入 EmptyLTXVLatentVideo，出来的视频长度和场景对不上。

7. 高频重试会让 /free 返回 500，显存疑似没完全释放——12GB 跑 22B 时的常态，只能靠控制并发躲开。

五、结束时留下的硬数据

代码：6 个 Python 文件 / 1,186 行（编排 131 + 裁图 311 + VLM 检测 473 + 提交 136 + 解析 118 + 合并 17）
工作流模板：19 个节点，纯官方节点 + GGUF 加载器
渲染参数：配置 384×256（实际输出 384×288，LTX 按 32 对齐）/ 20 steps / 12 fps / VAE 分块 128 / UNet 换出 96 块 / NAG 8.0
最终成片：384×288 / 12fps / 36.5 秒 / 438 帧 / h264
交付包：4 个（最小的 5.6KB）；工作区总占用 约 7.5MB

对照原文里的后期数据（工作区 62GB / 269 个文件 / 115,875 行 / 101 个审计目录 / V17 约 50GB）：

阶段零用 1,186 行、7.5MB 工作区，把片子做出来了；后期用 115,875 行、62GB 工作区，过不了验收。

这不是模型变笨了，是流程变了。

六、没解决的四个问题（照实列）

裁图坐标仍偏紧（8% 边距不够，应提到 12–15%）；
CV 投影法兜底没实现，当时只存在于讨论里；
VLM 会把页脚误检成第 6 个子图；
384×288 / 12fps 是这张卡的上限——不是审美选择，是显存算出来的。要 1920×1080 / 30fps，只能换卡或多卡。

七、这段记录唯一的新增结论

那 47 小时交出去的东西是**"能跑通"**：产线跑得动、片子出得来、工作流能在别人的机器上装起来。

交不出去的东西，是甲方真正要的**"手术逻辑正确性"——它在 7/17 才第一次以"识别缝线范围"的形式出现，而且从头到尾没有被写成一条可判定的验收条件**。当时的对话里，没有一句话是"什么样的画面算通过"。

开工前我没有把验收条件钉死，这是我的责任。后果就是复盘里那一段：需求只能以"我觉得不对"的形式反复出现；而它每出现一次，当下唯一能做的事就是——再加一道检查。检查越来越严，产出越来越远。

如果这个项目重来一次，先写下这五行，再动第一行代码：

验收条件（化整为零，逐条可判）：
1. 输入：一张扫描件 + 一份 Markdown → 输出 6 段场景视频 + 1 段合成片
2. 尺寸 / 帧率：___（阶段零实测：384×288 / 12fps 是 12GB 卡的上限）
3. 每帧必须与对应子图"同构"：无新增解剖结构、无新增文字、无人物出现
4. 关键步骤顺序：与 Markdown 的 6 个场景一一对应（顺序错 = 不通过）
5. 修改轮次：___ 轮以内；超出即重新评估范围或终止

第 3 条就是"手术逻辑正确性"的可判定版本——它不需要人去"感觉对不对"，只要拿原图逐帧点一遍。如果第一天就有这五条，"感觉不对"最多只能推翻一次。

顺带一句：那套后来一路加到 v4 的质检门，不是被设计进来的。7/17 的对话里它已经被明确拒绝过一次——"我们不需要 qa 系统，只需要把视觉模型提供接口出来给外部调用就行"。它是在没人写下验收条件的情况下，被"每次觉得不对就加一道检查"的惯性，一次一道，慢慢长出来的。

结语

那 47 小时里，我在做的事情是"把东西跑通"，那是该做的部分。

真正让这个项目亏钱的，不是模型（换了 13 个都没用）、不是 12GB 显存、也不是谁写的提示词，而是从头到尾没有一个人把"通过"这个词定义成一句可以判定的话。

所以，补上那段被漏掉的记录之后，我想说的其实只有一句：

动手写第一行代码之前，先写下"什么叫做完"。那是最便宜的保险。

本文是《零代码接单一个月后，我为什么选择止损》的补记。所有数字来自本地产物时间戳、ffprobe 实测与会话账目。

abaalei

@kos-or 我用水冷 360 好像280rmb 工包的九州风神还是酷冷至尊改扣具改出来的，不过做工啥的很一般，只能说能用就行

abaalei

@kos-or ununtu的通病 SMU报错+llama还是啥一直在唤醒，导致smu卡死，具体等返修回来会发个贴说说

abaalei

@拐子001 epyc一代，二代的u已经很便宜了，但是主板最近被炒起来了，动则2000起，就连华南金牌也涨到3500～4000，实属离谱

abaalei

哈哈 x99我很久之前就发帖提过不支持p2p，用sglang是难点。不过现在新的是咋样就没了解了，刚换了epyc平台卡就坏了，哎

abaalei

@David-Chen 我电脑常驻的就是我另一篇帖子说的https://lcz.me/topic/1300/双卡别无脑刷同款模型-双-rx-7900-xtx-跑-qwen3.8-27b-的异构分工与-mtp-实战调优，huihui Q5km 以及UD4，本次对比的qwen用的是ud4版本

abaalei

@stxpnet 确实，这样分配也是很不错的一个概念，等3.8的moe出来后，我也试试混搭玩玩！

abaalei

01. 写在前面

这并不是一次跑分榜单上的纸面打分，而是一次基于真实项目逆向工程的硬碰硬对比。

最近大模型圈子里最吸睛的话题，当Opencode中的免费模型，代号 Ox Alpha（也就是大家常说的“牛来”匿名模型）。很多人觉得，像逆向工程、内核驱动分析、底层音频协议拆解这种脏活累活，只有动辄千亿甚至万亿参数的云端前沿模型才能搞定，本地跑个 27B 顶多帮着写写胶水代码。

前两天刚好要逆向某款主流的车载伴侣通信 APK（涉及车载通信模块语音交互、QPCMV 数字 PCM 音频流与 USB UAC 桥接），我们用同一份粗粒度的分析 Prompt，分别交给了：

单卡本地量化运行的 Qwen3.8-27B；
最近很火的神秘云端模型 Ox Alpha（牛来匿名模型）。

两份输出最终都写了 184 行，切入点却大相径庭：Qwen 把火力集中在 Java 反编译调用栈、PCM 格式与音频路由泵；Ox Alpha 则大力出奇迹，解密出了 APK 内部潜藏的内核模块、用户态守护进程与初始化链路。

如果把这两份报告放到工程团队面前，究竟谁更适合直接作为开发指导基线？

02. 先说结论：Qwen 报告更适合当主基准，Ox Alpha 挖到了隐藏拼图

如果让我选一份直接交给驱动和协议开发同学去落地复核，我会选 Qwen3.8-27B 的版本作为主报告。

原因很简单：它的每一条结论都能顺着类名、方法名和代码行号回查，把“代码实证”与“架构推断”区隔得极其清晰。

而 Ox Alpha 扮演了一名优秀的“广度侦察兵”：它挖出了 Qwen 完全没注意到的加密内核模块（.ko）和自实现 ADB 协议，线索密度极高，但由于全文几乎没有提供证据来源代码位置与工具输出，无法直接免检并入设计基线。

八个维度的工程评审打分如下：

考核维度	Qwen3.8-27B (本地量化)	Ox Alpha 牛来 (匿名模型)	关键胜负手分析
证据可追溯性	9.0	6.0	Qwen 全文标清反编译类名、方法与行号；Ox 缺乏取证命令
事实与推断的区隔	9.0	5.5	Qwen 明确标注未决项；Ox 多处把推测写成绝对事实
PCM 音频链路还原细度	9.0	6.5	Qwen 完整理清四腿音频泵逻辑；Ox 上下行方向混淆了坐标
APK 隐藏资产与二进制广度	7.0	9.0 ★	Ox Alpha 惊艳解密出 3 个内嵌驱动/二进制与 ADB 协议
技术自洽性与逻辑闭环	7.5	6.5	Qwen 有一处 80ms 算错；Ox 存在 USB bulk 与 ACM 描述冲突
可复现性与审计友好度	8.5	7.0	第三方可随时按 Qwen 索引复核反编译代码
工程可执行度	8.5	8.0	Qwen 产物可直接指导抓包验证与驱动对接
风险与未知项处理	9.0	6.5	Qwen 诚实列出未解参数枚举；Ox 结论下得过满
综合评审得分	8.4 / 10	7.0 / 10	裁决：以 Qwen 为主干，吸纳 Ox 的二进制线索

03. 两份报告具体都分析出了什么？

Qwen3.8：顺着反编译调用链，精准恢复 PCM 数据流

Qwen3.8 的报告在开头就声明了反编译工具链、核心包名与分析规范。它还原的核心技术细节包括：

AT 控制命令面：理清了 AT+QPCMV=1,2、AT+QPCMV=1,0 与复位模式的关系，以及 !qp、!qp0、!clcc 等诊断指令；
基准 PCM 音频参数：明确锁定为 8000 Hz、16-bit、Mono 单声道、20 ms 帧长、标准帧大小恰好 320 字节（160 个采样）；
宿主四腿音频泵逻辑：
- 模块下行泵：USB 音频设备输入 ➔ AudioRecord.read() ➔ 车载扬声器 AudioTrack.write()；
- 本地上行泵：车内麦克风采集 ➔ 经过系统 AEC/NS/AGC 滤波 ➔ USB 音频设备 AudioTrack.write() ➔ 送入模块。
诚实标明未决项：明确指出 QPCMV 裸桥是否带额外帧头、8k 与 16k 间是否存在重采样仍需真机抓包确认。

Ox Alpha（牛来）：沿着 APK 资产，挖出隐藏的内核启动链

Ox Alpha 的广度则非常惊人，它发现并解密了 APK 内嵌的 3 个底层文件：

aprv3.ko：模块侧 APRv3 驱动，负责与高通 DSP 通信；
voice.ko：语音前端驱动，负责建立底层 ALSA PCM 节点；
vhold：用户态守护进程，常驻后台防止 Voice Session 被释放，并负责推送 UCM 与 ACDB 校验；
自实现 ADB 客户端：识别出该 App 不需要宿主系统具备 adb 工具，直接在 USB bulk 管道上自建协议向模块端 insmod 推驱动。

这组线索解释了为什么很多第三方固件单发 AT 命令无法建立语音——因为必须先在模块侧加载内核驱动完成 DSP 握手！

04. 为什么 Qwen 报告更适合作为工程主基线？

1. 把结论牢牢钉在证据上

Qwen 在给出每一个参数时，都附带了反编译代码位置。比如得出“20ms 帧长”，它直接给出了缓冲区计算代码，算出了 160 采样与 320 字节。团队成员即使怀疑结论，也能在 10 秒钟内跳到代码行去复核。而 Ox Alpha 虽然结论惊艳，但缺少代码定位，无法直接审计。

2. 对上下行坐标没有混淆

Ox Alpha 简单地把音频流写成：

下行：AudioTrack -> UAC bulk out
上行：AudioRecord -> UAC bulk in

这种描述模糊了相对坐标（是相对 Android Host 还是相对 USB 模块？），极易导致底层驱动把上下行通路接反。而 Qwen 明确分清了两条独立的采集与播放泵线程。

05. 两份报告各自的小瑕疵

两份报告都不是 100% 完美的：

Qwen 的小失误：在计算 1280 字节缓冲时长时，误写成了 160ms（对于 8kHz 16-bit 单声道，1280 / (8000 * 2) = 0.08s，正确结果应为 80ms）。
Ox Alpha 的薄弱点：“不依赖 root 即可工作”表述不够严谨——Host 端实现 ADB 协议确实不需 Host Root，但模块端执行 insmod 和写 /usr/bin 依然需要底层提权。

06. 总结：工程落地如何合流？

最实用的做法绝不是选一份扔一份，而是：

以 Qwen3.8 的 PCM 链路与方法级索引作为主架构骨架；
把 Ox Alpha 挖出来的 3 个隐藏二进制作为关键线索补齐 SHA-256 哈希与反编译点；
修正 80ms 缓冲计算，并在真机上验证 AT 握手。

这次实测彻底推翻了“小参数模型做不了复杂系统逆向”的偏见。在受约束的硬核技术分析中，给足上下文与清晰目标的 Qwen3.8-27B，凭借严密的证据纪律，完全具备硬刚甚至胜出当红云端神秘模型（如 Ox Alpha 牛来）的实战能力！

abaalei

UD4 跟 Q5 倒是有https://lcz.me/topic/1300/双卡别无脑刷同款模型-双-rx-7900-xtx-跑-qwen3.8-27b-的异构分工与-mtp-实战调优

abaalei

晚了，我上两三个月入坑的时候，ddr4 2133 regecc 从280 以每周20左右缓慢跌到220，昨晚看了下，回去350了，离谱

abaalei

在上一篇评测中，我们实测了消费级硬件跑百 B 级大模型的边界，得出的核心结论是：日常高频生产力依然是满血 27B 最具性价比。

而在多卡服务器上部署 27B 时，很多人的第一反应是：两张一模一样的显卡，直接刷同一套量化权重和参数，负载均衡轮询就好了。

过去两周，我们在 192.168.0.241 这台双路服务器上，针对两张 RX 7900 XTX 24GB（端口 11435 与 11436），对开源社区知名作者 huihui-ai 发布的 Huihui-Qwen3.8-27B-abliterated-GGUF（无审查 / 去除拒答偏见版本）系列模型做了深度的基准评测和单变量 A/B 测试。

最终得出的核心结论只有一句话：

不要把两张卡物理上统一成同款模型！保留异构部署（一快一稳），让 11436 当质量门卫、11435 当高速跑道，系统的真实吞吐和容错率反而最高。

这里把完整的测试数据、踩坑细节、模型命名规范和中央路由设计逻辑整理出来，供折腾多卡本地部署的同学参考。

01. 两个端口的同口径对决数据

我们先看一下两张卡当前生产配置的硬碰硬数据（统一采用包含长短指令、代码沙箱执行、8K 检索的 20 题基准）：

评测维度	11435 端口（高速路由）	11436 端口（质量路由）	实测差异与解读
具体模型文件	`Huihui-Qwen3.8-27B-abliterated-Q5_K.gguf`	`Huihui-Qwen3.8-27B-abliterated-UD-Q4_K_XL.gguf`	来自 huihui-ai 无审查开源仓库
量化方式	标准 llama.cpp Q5_K GGUF	Unsloth Dynamic 量化 (UD-Q4_K_XL)	UD 量化动态平衡层权重
推测解码参数	原生 MTP D4	原生 MTP D3	D3 质量更稳，D4 短测更快
20 题加权解码速度	62.11 tok/s	48.12 tok/s	11435 快 29.1%
平均首 Token 延迟 (TTFT)	6.47 秒	7.37 秒	11435 快 13.9%
20 题整组墙钟耗时	597.2 秒 (~10.0m)	729.4 秒 (~12.2m)	11436 慢 22.1%
人工质量得分（严格口径）	92.0 分（静态审计 93.0）	96.5 分	11436 领先 4.5 分
代码边界实际通过率	2 / 6	3 / 6	复杂边界都不能跳过测试
长文本 Needle in Haystack	未单独测	10K / 40K / 80K 全部 3/3 命中	80K 命中但 TTFT 约 212s

从数据可以清晰看出：11435（Q5_K）在纯吐字速度和首字响应上全面领先（快了近 30%），但在严格代码边界和复杂逻辑上，11436（UD-Q4_K_XL）的胜率明显更高。

02. 为什么看似矛盾的跑分里藏着“评分陷阱”？

大家可能会注意到：11435 之前历史记录过 97.0 分，为什么这里又写 92.0 分？是不是 Q5_K 反而不如 Q4 了？

这里有一个非常典型的评估标准演进陷阱：

旧 97.0 分是宽松口径：当时两道 Python 代码题只要输出了看似完整的逻辑就给了满分，没有用严格的沙箱去跑极端边界用例。
新口径加入了严苛边界断言：比如 code-01 混用了带时区与不带时区的 ISO 时间戳、乱序输入下的 owners 首次出现去重；code-02 传入了 Decimal('NaN')。
把历史 11435 的输出放到现在的沙箱里跑，通过率同样只有 2/6。因此 11435 的真实严格得分其实是 92.0 分，而不是它本身变笨了。

这也证明了一点：不要凭单次测试的几个点估计，就神化某一个量化版本。 11436 的 UD-Q4_K_XL 确实在当前测试集上更稳（96.5 分），但它还没有在所有场景下压倒性超越 Q5_K。

03. 为什么“统一两张卡配置”其实是个坏主意？

如果把两张卡全部刷成 11436 的 UD-Q4_K_XL，看似运维变简单了，但实际上你会失去很多：

1. 白白损失 22.5% 的系统总吞吐

两张卡全切 11436 后，持续解码速度从 62 tok/s 掉到 48 tok/s，20 题耗时直接多出 22%。对于本地多 Agent 或高频调用管道来说，这种减速是肉眼可见的。

2. 引入致命的“同质化失败（Correlated Failures）”

如果两张卡是完全相同的模型、量化和参数，那么某一种特定的提示词缺陷、格式偏见或代码盲区会在两个端口上 100% 共同复现。一旦主服务翻车，备用服务也大概率跟着翻车。

3. 大量“低风险脏活”根本不需要支付质量延迟

在完整的开发工作流里，有很多任务本质上是可以被自动化验证的（比如根据已有函数写单测、改写一段 Markdown、提炼日志、生成样板代码）。这些任务交给 11435 跑出 62 tok/s，测试通过就直接用；通不过再交由 11436 兜底修复，整体效率远高于所有任务都慢吞吞走 11436。

04. 落地实践：中央模型异构路由规则

我们目前在调度层使用的任务分发策略不是简单的按“代码 / 非代码”二分，而是按 “失败是否易于机器验证” 以及 “重做成本高低” 来判断：

任务类型	首选端口	升级 / 降级策略
核心代码实现、跨文件重构	11436 (UD-Q4_K_XL)	排队或超时时降级到 11435 生成初稿，但必须由测试与中央审查兜底
Bug 定位、代码安全审查	11436 (UD-Q4_K_XL)	纯日志归纳与简单告警可走 11435
严格 JSON、工具调用 DAG 规划	11436 (UD-Q4_K_XL)	Schema 校验失败禁止直接执行，转重试
文章初稿、改写、翻译、摘要	11435 (Q5_K)	格式校验失败时自动转 11436
单元测试编写、脚手架、数据清洗	11435 (Q5_K)	跑测试不通过或连续两次修复失败时，升级给 11436
40K / 80K 长上下文精准定位	11436 (UD-Q4_K_XL)	命中准确度极高，但 80K 需注意预热 prompt cache
交互式低延迟、要求秒回的任务	11435 (Q5_K)	高风险或要求一次成功时改走 11436

05. 核心调优与避坑参数

1. MTP 推测解码：D3 是 11436 的最佳甜点位

MTP Off：速度只有 33.0 tok/s；
MTP D3：速度拉升到 62.9 tok/s（6 题筛选），20 题全量质量分 96.5，接受率达 81.4%；
MTP D4：短测速度虽然涨到 66.5 tok/s，但 20 题全量质量跌落到 94.5（出现了逻辑漂移）。因此果断放弃 D4，生产坚守 D3。
DFlash2 表现：相比原生无推测确实快了 47%，但依然比原生 MTP D4 慢约 26%，不建议在 Vulkan/ROCm 生产环境硬上。

2. 7900 XTX 真实散热与热点（Hotspot）

我们在高负载下进行了逐秒硬件遥测：

热点（Junction/Hotspot）最高 85–86°C（远低于 110°C 临界）；
核心 Edge 表面最高 69°C，显存最高 82°C；
SCLK 核心频率全程平稳无降频，确认没有出现任何热降频（Thermal Throttling）。
GPU 电源策略保持 auto 即可，长期锁 high 并不会在全量 20 题中带来净收益。

总结与开源致谢

在双 7900 XTX 环境下，让 11436（UD-Q4_K_XL）守住 96.5 分的质量底线，让 11435（Q5_K）跑出 62 tok/s 的吞吐上限，配合中央路由的自动升降级，是在有限算力下榨出最高能效的最优解。

感谢开源社区 huihui-ai 团队提供的优质无审查量化模型，模型主页：
https://huggingface.co/huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF

大家手头有多卡部署时，也不妨尝试这种一快一稳的异构打法，欢迎在评论区交流讨论！

abaalei

@kos-or 不客气，就是闲的蛋疼喜欢瞎折腾，看到有新玩具就赶紧冲上去玩玩而已

抡锤者

abaalei

帖子