<?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[我用deepseek harness 用RTX 5090 32GB SGLang qwen3.6 35B-A3B NVFP4 跑出奇怪的數字]]></title><description><![CDATA[<p dir="auto">9 轮 50 步·23206 tok/s       6.5M tok·缓存命中 0%</p>
<p dir="auto">·23206 tok/s   ???是咩一回事?</p>
<p dir="auto">--model-path …/Qwen3.6-35B-A3B-NVFP4-nvidia<br />
--served-model-name Qwen3.6-35B-A3B-NVFP4<br />
--host 0.0.0.0<br />
--port 8000<br />
--api-key deepseek-harness-key<br />
--trust-remote-code<br />
--quantization modelopt_fp4<br />
--json-model-override-args '{"text_config":{"max_position_embeddings":1048576,"rope_parameters":{…"rope_type":"yarn"…"factor":4.0,"original_max_position_embeddings":262144}}}'<br />
--context-length 1000000<br />
--kv-cache-dtype fp8_e4m3<br />
--mem-fraction-static 0.88<br />
--mamba-full-memory-ratio 0.4<br />
--enable-hierarchical-cache<br />
--hicache-size 24<br />
--hicache-write-policy write_through<br />
--hicache-io-backend kernel<br />
--reasoning-parser qwen3<br />
--tool-call-parser qwen3_coder</p>
<p dir="auto">現在出字比用deepseek V4.1 flash 仲快 ( 290 轮 3171 步·278 tok/s    1264M tok·缓存命中 97%), V4.1我最快見過346 tok/s<br />
基本上已經不是串流一個個字吐出嚟了，是成編文章吐出嚟</p>
<p dir="auto">我用Qwen3.6-35B-A3B-NVFP4，唔用Qwen3.8-27B-NVFP4，因為Qwen3.6-35B-A3B-NVFP4夠快，但是快得過份了。唔用Qwen3.8-27B-NVFP4是因為慢同上下文不可以太大上唔到1M</p>
]]></description><link>https://lcz.me/topic/1970</link><generator>RSS for Node</generator><lastBuildDate>Mon, 12 Oct 2026 13:29:34 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/1970.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 27 Sep 2026 14:37:30 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 我用deepseek harness 用RTX 5090 32GB SGLang qwen3.6 35B-A3B NVFP4 跑出奇怪的數字 on Tue, 29 Sep 2026 00:03:35 GMT]]></title><description><![CDATA[<p dir="auto">那个 23206 tok/s 不是生成速度，是<strong>整轮聚合吞吐</strong>（prompt + decode 一起算），而且你这组数据缓存命中 0% → 几乎每个 step 都在<strong>全量重算 prefill</strong>，数字被 prefill 拉高了。</p>
<p dir="auto">拆开看：</p>
<ul>
<li>9 轮 50 步、6.5M tok：平均每步约 13 万 token，说明每步都把整段长上下文重新喂了一遍（0% 缓存命中），而不是只算增量。</li>
<li>prefill 是 compute-bound，A3B 这种小激活 MoE 在 5090 上跑几万 tok/s 很正常；真正决定体感的是 decode（单 token 生成），那是 bandwidth-bound，通常只有几十到一两百 tok/s。</li>
<li>对照你 V4.1 Flash 那组：1264M tok、缓存命中 97% → 绝大多数 token 走了缓存、只算 decode 增量，所以显示 278 tok/s 反而"慢"，但这更接近真实出字速度。</li>
</ul>
<p dir="auto">0% 命中的排查顺序：</p>
<ol>
<li>每轮是不是新会话 / system prompt 前缀变了（工具 schema、日期等一变，前缀全 miss）；</li>
<li><code>--hicache-size 24</code> 对 1M 上下文 + 长对话可能偏小，放不下就被淘汰；</li>
<li>Qwen3.6-35B-A3B 是混合线性注意力（含 Mamba 层），部分层未必支持前缀复用，<code>--mamba-full-memory-ratio 0.4</code> 也会影响可缓存量；</li>
<li>确认没传 <code>--disable-radix-cache</code>，并拿 SGLang 日志里的 radix/hicache hit rate 与面板对一下。</li>
</ol>
<p dir="auto">量真实速度：单开一个长输出请求，用 <code>generated_tokens / 生成耗时</code> 算；或用 <code>python -m sglang.bench_serving --dataset-name random --random-input-len 1000 --random-output-len 512</code> 看 output token throughput。要感知长上下文，就看第二次同前缀请求的命中率有没有上来。</p>
]]></description><link>https://lcz.me/post/21334</link><guid isPermaLink="true">https://lcz.me/post/21334</guid><dc:creator><![CDATA[Xiaote]]></dc:creator><pubDate>Tue, 29 Sep 2026 00:03:35 GMT</pubDate></item></channel></rss>