<?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[在 魔改 3080 20G上，运行当下流行的ninfer-3090代码,峰值70t/s,ctx70k]]></title><description><![CDATA[<p dir="auto">对代码有一定的修改以适配RTX3080 <a href="https://github.com/yangkang5303/ninfer-3090" rel="nofollow ugc">代码仓库</a></p>
<p dir="auto">====================</p>
<h2>修复的 bug</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>文件</th>
<th>问题</th>
<th>修复</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>src/ops/gdn_gating_proj/bf16/bf16_gdn_gating_proj_plan.cpp</code></td>
<td>协作式 MMA 路由上界按 82 SM 硬编码,68 SM 上 prefill 宽 768 时 144 CTA 超出 136 驻留预算,模型加载即抛 <code>candidate is not legal for exact problem</code></td>
<td>路由上界改为按运行时 <code>device_sm_count()</code> 动态推导</td>
</tr>
<tr>
<td><code>src/ops/linear_swiglu/nvfp4/nvfp4_linear_swiglu_plan.cpp</code></td>
<td>A16 融合 swiglu 仅注册到 T≤16,prefill 宽 &gt;16 即抛异常</td>
<td>在 token 轴上按 32 分块调用小-T 核(镜像 FP8 A16 路线)</td>
</tr>
<tr>
<td><code>src/ops/linear_swiglu/nvfp4/nvfp4_linear_swiglu_small_t.cu</code></td>
<td>launcher 只注册 2..16</td>
<td>扩展到 2..32,与线性小-T 生产 schedule 一致</td>
</tr>
</tbody>
</table>
<h2>多角度优化结果</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>指标</th>
<th style="text-align:right">nvfp4 A16(原)</th>
<th style="text-align:right">groupwise-int(推荐)</th>
<th style="text-align:right">提升</th>
</tr>
</thead>
<tbody>
<tr>
<td>权重显存</td>
<td style="text-align:right">16.03 GiB</td>
<td style="text-align:right"><strong>15.25 GiB</strong></td>
<td style="text-align:right">−0.8 GiB</td>
</tr>
<tr>
<td>prefill(长 prompt)</td>
<td style="text-align:right">19.4 tok/s</td>
<td style="text-align:right"><strong>558–636 tok/s</strong></td>
<td style="text-align:right">~29×</td>
</tr>
<tr>
<td>decode(贪心)</td>
<td style="text-align:right">11.7 tok/s</td>
<td style="text-align:right"><strong>33.7 tok/s</strong></td>
<td style="text-align:right">2.9×</td>
</tr>
<tr>
<td>decode(MTP3)</td>
<td style="text-align:right">33.0 tok/s</td>
<td style="text-align:right"><strong>69.5 tok/s</strong></td>
<td style="text-align:right">2.1×</td>
</tr>
</tbody>
</table>
<p dir="auto">投机解码:MTP3 最优(87–91% 接受率);draft=5 反降至 67.6 tok/s(接受率 73%)。</p>
<h2>KV 量化</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>选项</th>
<th>payload(2048 tok)</th>
<th>可用性</th>
</tr>
</thead>
<tbody>
<tr>
<td>bf16</td>
<td>128 MiB</td>
<td>可用</td>
</tr>
<tr>
<td><strong>int8-group64</strong></td>
<td><strong>66 MiB</strong></td>
<td><strong>可用(推荐,显存最低)</strong></td>
</tr>
<tr>
<td>fp8</td>
<td>—</td>
<td>sm_86 拒绝(需 Blackwell mma.f8f6f4)</td>
</tr>
<tr>
<td>rk8v4(q4 V)</td>
<td>—</td>
<td>拒绝(未移植到 <code>kv_cache_append</code> Op)</td>
</tr>
</tbody>
</table>
<h2>70K 上下文长任务测试</h2>
<p dir="auto">配置:<code>groupwise-int</code> + <code>--kv-dtype int8</code> + <code>--spec mtp --draft-tokens 3</code>,prompt 69,770 token。</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>指标</th>
<th style="text-align:right">结果</th>
</tr>
</thead>
<tbody>
<tr>
<td>prompt tokens</td>
<td style="text-align:right">69,770</td>
</tr>
<tr>
<td>prefill</td>
<td style="text-align:right">636 tok/s(109.7 s)</td>
</tr>
<tr>
<td>decode(MTP3)</td>
<td style="text-align:right"><strong>62.97 tok/s</strong>(91% 接受率)</td>
</tr>
<tr>
<td>decode(贪心 baseline)</td>
<td style="text-align:right">28.66 tok/s</td>
</tr>
<tr>
<td>KV payload</td>
<td style="text-align:right">2.41 GiB</td>
</tr>
<tr>
<td>free after startup</td>
<td style="text-align:right">625 MiB</td>
</tr>
</tbody>
</table>
<p dir="auto">对比 20-token 上下文:MTP3 从 69.5 降到 62.97 tok/s,仅 ~9% 退化,注意力随上下文增长的成本被 int8 KV 有效控制。</p>
]]></description><link>https://lcz.me/topic/1715</link><generator>RSS for Node</generator><lastBuildDate>Mon, 21 Sep 2026 12:38:08 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/1715.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 15 Sep 2026 06:40:05 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 在 魔改 3080 20G上，运行当下流行的ninfer-3090代码,峰值70t/s,ctx70k on Tue, 15 Sep 2026 07:03:23 GMT]]></title><description><![CDATA[<p dir="auto">几个修复都对口，尤其 82 SM 硬编码那处——3090 是 GA102 82 SM，3080 20G 是 68 SM，路由上界改成 device_sm_count() 是正解，这类硬编码在移植时最容易踩。</p>
<p dir="auto">更关键的是量化路线的选择：sm_86 没有原生 FP4，nvfp4 在 Ampere 上基本是模拟/回退，所以 prefill 19.4 tok/s 不奇怪；换 groupwise-int 走 INT4 tensor core 才有 29× 这个量级。这条对想抄 3090 代码上 3080 的人最重要。</p>
<p dir="auto">问两个参数：groupwise-int 的 group size 用了多少（64 还是 128）？kernel 是 dequant 到 fp16 再算，还是真走 mma INT4？前者省显存但吃带宽，后者才能在 3080 的 760GB/s 上把 decode 拉起来。</p>
<p dir="auto">提醒一句：free after startup 只剩 625 MiB，ctx 再长或并发大于 1 很容易 OOM，建议先把 max-running-requests 锁 1，再逐步压 KV。MTP draft=5 掉到 67.6 符合预期，MTP3 在多数模型上就是甜点。</p>
<p dir="auto">3080 760GB/s 对 3090 936GB/s，decode 63 对 78 基本就是带宽比；配上 91% 接受率，这卡跑 70K 已经压得很干净了。</p>
]]></description><link>https://lcz.me/post/18309</link><guid isPermaLink="true">https://lcz.me/post/18309</guid><dc:creator><![CDATA[Xiaote]]></dc:creator><pubDate>Tue, 15 Sep 2026 07:03:23 GMT</pubDate></item></channel></rss>