<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[双卡别无脑刷同款模型：双 RX 7900 XTX 跑 Qwen3.8-27B 的异构分工与 MTP 实战调优]]></title><description><![CDATA[<p dir="auto">在上一篇评测中，我们实测了消费级硬件跑百 B 级大模型的边界，得出的核心结论是：<strong>日常高频生产力依然是满血 27B 最具性价比</strong>。</p>
<p dir="auto">而在多卡服务器上部署 27B 时，很多人的第一反应是：<strong>两张一模一样的显卡，直接刷同一套量化权重和参数，负载均衡轮询就好了。</strong></p>
<p dir="auto">过去两周，我们在 192.168.0.241 这台双路服务器上，针对两张 RX 7900 XTX 24GB（端口 11435 与 11436），对开源社区知名作者 <strong>huihui-ai</strong> 发布的 <a href="https://huggingface.co/huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF" rel="nofollow ugc">Huihui-Qwen3.8-27B-abliterated-GGUF</a>（无审查 / 去除拒答偏见版本）系列模型做了深度的基准评测和单变量 A/B 测试。</p>
<p dir="auto">最终得出的核心结论只有一句话：</p>
<blockquote>
<p dir="auto"><strong>不要把两张卡物理上统一成同款模型！保留异构部署（一快一稳），让 11436 当质量门卫、11435 当高速跑道，系统的真实吞吐和容错率反而最高。</strong></p>
</blockquote>
<p dir="auto">这里把完整的测试数据、踩坑细节、模型命名规范和中央路由设计逻辑整理出来，供折腾多卡本地部署的同学参考。</p>
<hr />
<h2>01. 两个端口的同口径对决数据</h2>
<p dir="auto">我们先看一下两张卡当前生产配置的硬碰硬数据（统一采用包含长短指令、代码沙箱执行、8K 检索的 20 题基准）：</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>评测维度</th>
<th>11435 端口（高速路由）</th>
<th>11436 端口（质量路由）</th>
<th>实测差异与解读</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>具体模型文件</strong></td>
<td><code>Huihui-Qwen3.8-27B-abliterated-Q5_K.gguf</code></td>
<td><code>Huihui-Qwen3.8-27B-abliterated-UD-Q4_K_XL.gguf</code></td>
<td>来自 huihui-ai 无审查开源仓库</td>
</tr>
<tr>
<td><strong>量化方式</strong></td>
<td>标准 llama.cpp Q5_K GGUF</td>
<td>Unsloth Dynamic 量化 (UD-Q4_K_XL)</td>
<td>UD 量化动态平衡层权重</td>
</tr>
<tr>
<td><strong>推测解码参数</strong></td>
<td>原生 MTP D4</td>
<td>原生 MTP D3</td>
<td>D3 质量更稳，D4 短测更快</td>
</tr>
<tr>
<td><strong>20 题加权解码速度</strong></td>
<td><strong>62.11 tok/s</strong></td>
<td><strong>48.12 tok/s</strong></td>
<td><strong>11435 快 29.1%</strong></td>
</tr>
<tr>
<td><strong>平均首 Token 延迟 (TTFT)</strong></td>
<td><strong>6.47 秒</strong></td>
<td><strong>7.37 秒</strong></td>
<td>11435 快 13.9%</td>
</tr>
<tr>
<td><strong>20 题整组墙钟耗时</strong></td>
<td><strong>597.2 秒 (~10.0m)</strong></td>
<td><strong>729.4 秒 (~12.2m)</strong></td>
<td>11436 慢 22.1%</td>
</tr>
<tr>
<td><strong>人工质量得分（严格口径）</strong></td>
<td><strong>92.0 分</strong>（静态审计 93.0）</td>
<td><strong>96.5 分</strong></td>
<td>11436 领先 4.5 分</td>
</tr>
<tr>
<td><strong>代码边界实际通过率</strong></td>
<td><strong>2 / 6</strong></td>
<td><strong>3 / 6</strong></td>
<td>复杂边界都不能跳过测试</td>
</tr>
<tr>
<td><strong>长文本 Needle in Haystack</strong></td>
<td>未单独测</td>
<td><strong>10K / 40K / 80K 全部 3/3 命中</strong></td>
<td>80K 命中但 TTFT 约 212s</td>
</tr>
</tbody>
</table>
<p dir="auto">从数据可以清晰看出：<strong>11435（Q5_K）在纯吐字速度和首字响应上全面领先（快了近 30%），但在严格代码边界和复杂逻辑上，11436（UD-Q4_K_XL）的胜率明显更高。</strong></p>
<hr />
<h2>02. 为什么看似矛盾的跑分里藏着“评分陷阱”？</h2>
<p dir="auto">大家可能会注意到：11435 之前历史记录过 97.0 分，为什么这里又写 92.0 分？是不是 Q5_K 反而不如 Q4 了？</p>
<p dir="auto">这里有一个非常典型的<strong>评估标准演进陷阱</strong>：</p>
<ol>
<li><strong>旧 97.0 分是宽松口径</strong>：当时两道 Python 代码题只要输出了看似完整的逻辑就给了满分，没有用严格的沙箱去跑极端边界用例。</li>
<li><strong>新口径加入了严苛边界断言</strong>：比如 <code>code-01</code> 混用了带时区与不带时区的 ISO 时间戳、乱序输入下的 owners 首次出现去重；<code>code-02</code> 传入了 <code>Decimal('NaN')</code>。</li>
<li>把历史 11435 的输出放到现在的沙箱里跑，通过率同样只有 2/6。因此 11435 的真实严格得分其实是 92.0 分，而不是它本身变笨了。</li>
</ol>
<p dir="auto">这也证明了一点：<strong>不要凭单次测试的几个点估计，就神化某一个量化版本。</strong> 11436 的 UD-Q4_K_XL 确实在当前测试集上更稳（96.5 分），但它还没有在所有场景下压倒性超越 Q5_K。</p>
<hr />
<h2>03. 为什么“统一两张卡配置”其实是个坏主意？</h2>
<p dir="auto">如果把两张卡全部刷成 11436 的 UD-Q4_K_XL，看似运维变简单了，但实际上你会失去很多：</p>
<h3>1. 白白损失 22.5% 的系统总吞吐</h3>
<p dir="auto">两张卡全切 11436 后，持续解码速度从 62 tok/s 掉到 48 tok/s，20 题耗时直接多出 22%。对于本地多 Agent 或高频调用管道来说，这种减速是肉眼可见的。</p>
<h3>2. 引入致命的“同质化失败（Correlated Failures）”</h3>
<p dir="auto">如果两张卡是完全相同的模型、量化和参数，那么某一种特定的提示词缺陷、格式偏见或代码盲区会在两个端口上 100% 共同复现。一旦主服务翻车，备用服务也大概率跟着翻车。</p>
<h3>3. 大量“低风险脏活”根本不需要支付质量延迟</h3>
<p dir="auto">在完整的开发工作流里，有很多任务本质上是<strong>可以被自动化验证的</strong>（比如根据已有函数写单测、改写一段 Markdown、提炼日志、生成样板代码）。这些任务交给 11435 跑出 62 tok/s，测试通过就直接用；通不过再交由 11436 兜底修复，整体效率远高于所有任务都慢吞吞走 11436。</p>
<hr />
<h2>04. 落地实践：中央模型异构路由规则</h2>
<p dir="auto">我们目前在调度层使用的任务分发策略不是简单的按“代码 / 非代码”二分，而是按 <strong>“失败是否易于机器验证”</strong> 以及 <strong>“重做成本高低”</strong> 来判断：</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>任务类型</th>
<th>首选端口</th>
<th>升级 / 降级策略</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>核心代码实现、跨文件重构</strong></td>
<td><strong>11436 (UD-Q4_K_XL)</strong></td>
<td>排队或超时时降级到 11435 生成初稿，但必须由测试与中央审查兜底</td>
</tr>
<tr>
<td><strong>Bug 定位、代码安全审查</strong></td>
<td><strong>11436 (UD-Q4_K_XL)</strong></td>
<td>纯日志归纳与简单告警可走 11435</td>
</tr>
<tr>
<td><strong>严格 JSON、工具调用 DAG 规划</strong></td>
<td><strong>11436 (UD-Q4_K_XL)</strong></td>
<td>Schema 校验失败禁止直接执行，转重试</td>
</tr>
<tr>
<td><strong>文章初稿、改写、翻译、摘要</strong></td>
<td><strong>11435 (Q5_K)</strong></td>
<td>格式校验失败时自动转 11436</td>
</tr>
<tr>
<td><strong>单元测试编写、脚手架、数据清洗</strong></td>
<td><strong>11435 (Q5_K)</strong></td>
<td>跑测试不通过或连续两次修复失败时，升级给 11436</td>
</tr>
<tr>
<td><strong>40K / 80K 长上下文精准定位</strong></td>
<td><strong>11436 (UD-Q4_K_XL)</strong></td>
<td>命中准确度极高，但 80K 需注意预热 prompt cache</td>
</tr>
<tr>
<td><strong>交互式低延迟、要求秒回的任务</strong></td>
<td><strong>11435 (Q5_K)</strong></td>
<td>高风险或要求一次成功时改走 11436</td>
</tr>
</tbody>
</table>
<hr />
<h2>05. 核心调优与避坑参数</h2>
<h3>1. MTP 推测解码：D3 是 11436 的最佳甜点位</h3>
<ul>
<li><strong>MTP Off</strong>：速度只有 33.0 tok/s；</li>
<li><strong>MTP D3</strong>：速度拉升到 <strong>62.9 tok/s</strong>（6 题筛选），20 题全量质量分 <strong>96.5</strong>，接受率达 81.4%；</li>
<li><strong>MTP D4</strong>：短测速度虽然涨到 66.5 tok/s，但 20 题全量质量跌落到 94.5（出现了逻辑漂移）。因此果断放弃 D4，生产坚守 D3。</li>
<li><strong>DFlash2 表现</strong>：相比原生无推测确实快了 47%，但依然比原生 MTP D4 慢约 26%，不建议在 Vulkan/ROCm 生产环境硬上。</li>
</ul>
<h3>2. 7900 XTX 真实散热与热点（Hotspot）</h3>
<p dir="auto">我们在高负载下进行了逐秒硬件遥测：</p>
<ul>
<li><strong>热点（Junction/Hotspot）最高 85–86°C</strong>（远低于 110°C 临界）；</li>
<li><strong>核心 Edge 表面最高 69°C</strong>，显存最高 82°C；</li>
<li>SCLK 核心频率全程平稳无降频，<strong>确认没有出现任何热降频（Thermal Throttling）</strong>。</li>
<li>GPU 电源策略保持 <strong>auto</strong> 即可，长期锁 high 并不会在全量 20 题中带来净收益。</li>
</ul>
<hr />
<h2>总结与开源致谢</h2>
<p dir="auto">在双 7900 XTX 环境下，让 11436（UD-Q4_K_XL）守住 96.5 分的质量底线，让 11435（Q5_K）跑出 62 tok/s 的吞吐上限，配合中央路由的自动升降级，是在有限算力下榨出最高能效的最优解。</p>
<p dir="auto">感谢开源社区 <strong>huihui-ai</strong> 团队提供的优质无审查量化模型，模型主页：<br />
<img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f517.png?v=301515bb865" class="not-responsive emoji emoji-android emoji--link" style="height:23px;width:auto;vertical-align:middle" title="🔗" alt="🔗" /> <a href="https://huggingface.co/huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF" rel="nofollow ugc">https://huggingface.co/huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF</a></p>
<p dir="auto">大家手头有多卡部署时，也不妨尝试这种一快一稳的异构打法，欢迎在评论区交流讨论！</p>
]]></description><link>https://lcz.me/topic/1300</link><generator>RSS for Node</generator><lastBuildDate>Wed, 09 Sep 2026 23:52:17 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/1300.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 25 Aug 2026 02:01:58 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 双卡别无脑刷同款模型：双 RX 7900 XTX 跑 Qwen3.8-27B 的异构分工与 MTP 实战调优 on Wed, 26 Aug 2026 14:54:18 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/stxpnet" aria-label="Profile: stxpnet">@<bdi>stxpnet</bdi></a> 确实，这样分配也是很不错的一个概念，等3.8的moe出来后，我也试试混搭玩玩！</p>
]]></description><link>https://lcz.me/post/14158</link><guid isPermaLink="true">https://lcz.me/post/14158</guid><dc:creator><![CDATA[abaalei]]></dc:creator><pubDate>Wed, 26 Aug 2026 14:54:18 GMT</pubDate></item><item><title><![CDATA[Reply to 双卡别无脑刷同款模型：双 RX 7900 XTX 跑 Qwen3.8-27B 的异构分工与 MTP 实战调优 on Wed, 26 Aug 2026 06:24:46 GMT]]></title><description><![CDATA[<p dir="auto">和我的想法不同，我想的是左脑 理科生 ，稠密模型，慢工出细活。 右脑文科生，MOE模型，想象力丰富，关于编排，做领导。 合二为一，威力无穷。</p>
]]></description><link>https://lcz.me/post/14048</link><guid isPermaLink="true">https://lcz.me/post/14048</guid><dc:creator><![CDATA[stxpnet]]></dc:creator><pubDate>Wed, 26 Aug 2026 06:24:46 GMT</pubDate></item><item><title><![CDATA[Reply to 双卡别无脑刷同款模型：双 RX 7900 XTX 跑 Qwen3.8-27B 的异构分工与 MTP 实战调优 on Tue, 25 Aug 2026 02:20:24 GMT]]></title><description><![CDATA[<p dir="auto">观摩学习，数据非常详细。去对齐版本大家都懂。</p>
]]></description><link>https://lcz.me/post/13765</link><guid isPermaLink="true">https://lcz.me/post/13765</guid><dc:creator><![CDATA[terry]]></dc:creator><pubDate>Tue, 25 Aug 2026 02:20:24 GMT</pubDate></item></channel></rss>