<?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[2 x Tesla V100 32G, llama.cpp-v100, Qwen3.8-27B-Q8_0.gguf , decode 破百, prefill 16xx~19xx tok/s, 部署,調優與TP修補與解決循環問題]]></title><description><![CDATA[<p dir="auto">手上空著兩張V100, 其他模型都有機器跑了, 就想回頭搞搞Qwen 3.8 27B, 順便為Qwen 4.0暖暖身. 基於工作需求, Q8是必須的, 之前跑過大概decode 3,40 tok/s , prefill 7,800 tok/s, 就差強人意. 這次網上找找看有沒有什麼更強的部署, 還真的找到.<br />
用著用著無限循環的老問題再度發生, 就讓GPT 6.1 sol去修復一下, 修好之後就沒有再發生了. 少了循環問題後, 3.8 27B還是挺能打的, 跑了幾個長鏈任務, 不比其他模型差, 就256K上下文少了點, 時不時就compact. 以下為安裝紀錄:</p>
<h1>Qwen3.8-27B 部署摘要</h1>
<h2>目前模型與服務</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>項目</th>
<th>正式設定</th>
</tr>
</thead>
<tbody>
<tr>
<td>API 模型名稱</td>
<td><code>qwen-3.8-27b</code></td>
</tr>
<tr>
<td>Target</td>
<td><code>models/Qwen3.8-27B-Q8_0.gguf</code>，Q8_0 GGUF，約 29.05 GB</td>
</tr>
<tr>
<td>Draft</td>
<td><code>models/Qwen3.8-27B-DFlash2-F16.gguf</code>，約 3.86 GB；來源 BF16 已轉 F16，未直接使用 BF16 運算</td>
</tr>
<tr>
<td>推論引擎</td>
<td><code>1115714829/llama.cpp-v100</code> v100-2.0.1.1，基準 commit <code>f17d925</code>，另有本機 TP 修補；執行檔 <code>build-tp/bin/llama-server</code></td>
</tr>
<tr>
<td>硬體</td>
<td>2 × Tesla V100-SXM2-32GB，NVLink；每卡功耗上限 225 W</td>
</tr>
<tr>
<td>GPU 切分</td>
<td>Tensor parallel，<code>--split-mode tensor --tensor-split 1,1</code>，全層 GPU offload</td>
</tr>
<tr>
<td>max seq num / 最大併發</td>
<td><strong>2</strong>，<code>--parallel 2</code>；兩路同時處理與生成均已實測</td>
</tr>
<tr>
<td>每路實際可用 context</td>
<td><strong>262144 tokens（256K，輸入＋輸出）</strong></td>
</tr>
<tr>
<td><code>--ctx-size</code></td>
<td><strong>524800 tokens（總配置）</strong>；獨立 KV，<code>--no-kv-unified</code></td>
</tr>
<tr>
<td>每路 KV token 容量</td>
<td>262400 tokens，為 256 對齊配置；524800 ÷ 2</td>
</tr>
<tr>
<td>Slot 上限</td>
<td>262152，含 8 個內部保留位置；<code>SLOT_CTX=262152</code>、<code>--kv-unified-per-slot 262152</code></td>
</tr>
<tr>
<td>主模型 KV cache</td>
<td>K/V 均為 <strong>q8_0</strong>；payload 合計 <strong>17425 MiB ≈ 17.02 GiB</strong>，每卡對齊配置 <strong>8712.77 MiB</strong></td>
</tr>
<tr>
<td>Draft KV / recurrent state</td>
<td>Draft KV 約 80 MiB／卡；target recurrent state 約 1197 MiB／卡，與主模型 KV 分開計算</td>
</tr>
<tr>
<td>Batch / ubatch</td>
<td>logical batch <strong>2048</strong>、physical ubatch <strong>2048</strong></td>
</tr>
<tr>
<td>投機解碼</td>
<td><code>draft-dflash</code>，最多 <strong>7</strong> 個 draft tokens／輪</td>
</tr>
<tr>
<td>其他快取</td>
<td><code>--cache-ram 2048</code>：<strong>主機 RAM</strong> 前綴快取上限 2048 MiB；<code>--ctx-checkpoints 4</code>，不是 GPU KV 容量</td>
</tr>
<tr>
<td>採樣預設</td>
<td><strong>temperature 1.0、frequency_penalty 0.3</strong>、top_p 0.95、top_k 20、min_p 0</td>
</tr>
<tr>
<td>Thinking 預設</td>
<td><strong>開啟、xhigh</strong>；請求可用 <code>reasoning_effort</code> 覆寫；<code>none</code> 關閉，<code>high</code> 映射至 <code>xhigh</code></td>
</tr>
<tr>
<td>記憶體保護</td>
<td>systemd <code>MemoryMax=54G</code>、<code>MemorySwapMax=0</code></td>
</tr>
</tbody>
</table>
<p dir="auto">實際容量以兩路各 <strong>261632 輸入＋512 輸出＝262144 tokens</strong> 驗證，並非把總 256K 除以兩路。額外 slot 位置用於投機解碼內部空間；runtime metadata 覆寫為 262152，未修改 GGUF、未啟用 YaRN／RoPE 縮放，也不宣稱原生 256K 以上的品質。</p>
<h2>最近採樣參數變更</h2>
<p dir="auto">依使用者指示，將服務預設 <strong>temperature 從 0.4 改為 1.0、frequency_penalty 從 0 改為 0.3</strong>，</p>
<p dir="auto"><strong>改動原因</strong>：Coding agent使用本模型時，出現大段推理文字循環，以及成功取得工具結果後仍反覆發出相同工具呼叫。使用者停止該次執行，之後指定這兩項採樣調整，以減少重複循環。temperature 改回 1.0 的用意是增加採樣多樣性，frequency_penalty 0.3 則對重複出現的 token 加入頻率懲罰；後者不是對相同工具名稱或參數的直接去重機制。temperature 0.4 是否為原問題根因尚未經對照測試確認。</p>
<p dir="auto"><strong>後續測試結果</strong>：新參數 temperature 1.0／frequency_penalty 0.3 經多輪測試，原先的重複推理／工具呼叫循環問題未再復現。此處記錄使用者回報的測試結果，</p>
<h2>驗證與測試數據</h2>
<p dir="auto">單位為 tokens/s；屬指定測試內容的觀測值。Native 冷測 temperature=0；warm／並行 chat 為 temperature=1，chat 測試明確關閉 thinking。<strong>目前 temperature=1.0、frequency_penalty=0.3 已重啟並驗證短 API，且使用者回報後續多輪測試未再復現原循環問題；下列歷史效能測試的 frequency_penalty=0，尚未按新採樣設定重跑整套效能基準。</strong></p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>測項</th>
<th>輸入／輸出與結果</th>
<th style="text-align:right">Prefill</th>
<th style="text-align:right">Decode</th>
</tr>
</thead>
<tbody>
<tr>
<td>正式服務單路 16K 冷測</td>
<td>16384＋128，cache_n=0，通過</td>
<td style="text-align:right"><strong>1949.28</strong></td>
<td style="text-align:right"><strong>180.53</strong></td>
</tr>
<tr>
<td>兩路各 32K 冷測</td>
<td>各 32768＋128，全通過；整組 38.17 秒</td>
<td style="text-align:right">—</td>
<td style="text-align:right">—</td>
</tr>
<tr>
<td>兩路各 128K 冷測</td>
<td>各 131072＋128，全通過；整組 211.30 秒</td>
<td style="text-align:right">—</td>
<td style="text-align:right">—</td>
</tr>
<tr>
<td>兩路完整 256K 冷測</td>
<td>各 261632＋512，cache_n=0，全部無截短；整組 <strong>603.08 秒（10.05 分鐘）</strong></td>
<td style="text-align:right">第一路 <strong>879.71</strong></td>
<td style="text-align:right">每路 <strong>106.08–107.32</strong></td>
</tr>
<tr>
<td>滿長前綴兩路同時生成</td>
<td>各 261632＋512，無截短；各重用 261628 個 prompt tokens、重算 4 個；整組 <strong>8.41 秒</strong></td>
<td style="text-align:right">不作冷 prefill 比較</td>
<td style="text-align:right">每路 <strong>63.92–75.52</strong></td>
</tr>
<tr>
<td>連續重用滿長前綴</td>
<td>再次兩路各輸出 512、無截短；整組 <strong>8.23 秒</strong>，再次觀察同時生成 2 路</td>
<td style="text-align:right">—</td>
<td style="text-align:right">每路 <strong>65.30–76.17</strong></td>
</tr>
<tr>
<td>重啟後兩路 OpenAI chat</td>
<td>各完整輸出 512，HTTP 200，同時生成 2 路</td>
<td style="text-align:right">—</td>
<td style="text-align:right">每路約 <strong>157.45–157.48</strong></td>
</tr>
</tbody>
</table>
<p dir="auto">冷長輸入有排程等待：上述 256K 冷測同時 processing=2、generating=1；另以 warm 測試確認滿長下 generating=2。第二路冷測 prompt timing 含等待，不當作獨立 prefill 基準；warm 數字也不等於冷輸入速度。</p>
<p dir="auto">其他驗證：</p>
<ul>
<li><strong>正確性抽查</strong>：6 組 greedy 答案與原 layer 模式參考逐字一致；不是完整品質基準。</li>
<li><strong>TP 修補</strong>：修正 mirrored 非連續 tensor 的 async 傳輸限制；CPU／雙 GPU Meta 與 scheduler CTest 共 3/3 通過，兩張卡 CONT 算子各 78/78 通過；本機 patch 尚未上游合併。</li>
<li><strong>邊界修正</strong>：原本只留 2 個位置，7 步投機的 warm 測試曾只輸出 511；改留 8 個位置後，完整冷測與連續兩輪 warm 皆輸出 512，失敗結果保留。</li>
<li><strong>服務驗證</strong>：health、模型名稱、兩個 slot、metrics、實際 TP 函式庫、重啟與開機啟動皆通過。temperature／frequency_penalty 新預設、thinking 預設及各 reasoning level 均已有實際 API 驗證。</li>
</ul>
<h2>資源與未採用方案</h2>
<ul>
<li>最終滿長冷／熱／連續 warm 測試：每卡 VRAM 峰值 <strong>28500 MiB</strong>，實際 <code>memory.free</code> 最低 <strong>3995 MiB</strong>；驅動另保留約 274 MiB，不能直接把 total−used 全算成可用。</li>
<li>同三輪測試：host 最低 available <strong>51.04 GiB</strong>、服務 RSS 最高約 <strong>3.75 GiB</strong>，服務 swap 始終 <strong>0</strong>。其他測項已有 RAM 快取時 RSS 可較高；主機原有 swap 約 0.84 GiB，不代表主機 swap 為 0。</li>
<li><strong>三路共用約 600K＋F16＋ubatch 2048 未採用</strong>：曾在 draft 載入時 OOM。額外 KV 本身只多約 1.22 GiB／卡，但共享路徑使用 dense mask，主模型計算緩衝曾升至約 7.30 GiB／卡；不是單純多 88K KV 放不下。使用者已決定維持兩路 256K，未降低 KV 精度。</li>
</ul>
<h2>Llama bency 實測數據</h2>
<p dir="auto"><img src="https://upload.lcz.me/uploads/e2f1f091-6ce4-40c7-9b96-ac36b52438b5.png" alt="螢幕擷取畫面 2026-11-02 175153.png" class="img-markdown  img-fluid" /></p>
]]></description><link>https://lcz.me/topic/2792</link><generator>RSS for Node</generator><lastBuildDate>Tue, 10 Nov 2026 00:19:47 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/2792.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 02 Nov 2026 10:10:00 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 2 x Tesla V100 32G, llama.cpp-v100, Qwen3.8-27B-Q8_0.gguf , decode 破百, prefill 16xx~19xx tok/s, 部署,調優與TP修補與解決循環問題 on Wed, 04 Nov 2026 14:47:33 GMT]]></title><description><![CDATA[<p dir="auto">V100-32G的本地大模型的效果超过了7900XTX 24G，不错啊</p>
]]></description><link>https://lcz.me/post/31058</link><guid isPermaLink="true">https://lcz.me/post/31058</guid><dc:creator><![CDATA[PhilipShi2026]]></dc:creator><pubDate>Wed, 04 Nov 2026 14:47:33 GMT</pubDate></item></channel></rss>