數位天堂 https://digiland.tw Nokia：科技始終來自於人性; 拜耳：如果文明不能使我們更相愛，那科技便失去意義！ 歡迎您的加入，讓我們一起討論科技與環保的整合應用... zh-TW https://www.rssboard.org/rss-specification CosyVoice 3 TTS 三卡實測：3060 12G / 3060 Ti 8G / 2080 Ti 22G in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23019#p23019 23019@https://digiland.tw 【補測】RTX 2060 6G 加入 CosyVoice 3 TTS 實測延續前文三卡實測，這次把 TTS 卡換成 RTX 2060 6G，用完全相同的腳本與條件再跑一次（bench_tts.sh 10，五句常用句各 10 輪 n=50，另加串流首包 n=10，排隊警告 0 筆）。四卡結果顯卡RTF串流首包TTS 顯存 RTX 3060 Ti 8G0.240約 1.27 秒4,753 MiB RTX 2080 Ti 22G0.2501.23–1.27 秒5,000 MiB RTX 3060 12G0.330約 1.72 秒5,957 MiB RTX 2060 6G0.3501.81 秒4,628 MiB 排名：3060 Ti ≈ 2080 Ti ＞ 3060 12G ≳ 2060 6G重點2060 與 3060 12G 幾乎一樣：RTF 只慢約 6%（0.35 對 0.33），首包慢約 0.09 秒，實際使用感覺不出差別。和 3060 Ti、2080 Ti 相比慢約 45%，但 RTF 0.35 代表合成速度仍是播放速度的近 3 倍，串流播放不會斷音。四路長句同時合成，連跑兩輪全部成功（每路約 7.8 秒）。連續四路並發 90 秒滿載：功耗中位 157 W、最高 163 W（已達 160 W 功耗上限）、溫度最高 69°C、時脈約 1,860 MHz、GPU 使用率約 99%，48 次合成零失敗。90 秒尚未達熱穩態，長時間滿載溫度會再高一些。滿載時顯存峰值 5,702 MiB，6 GB 只剩約 440 MiB，餘量偏緊。6 GB 的代價：語音辨識（ASR）要移到 CPU原本 ASR（SenseVoice）和 TTS 放在同一張卡上，約佔 1 GB。6 GB 放不下兩者：兩者同卡時，閒置看起來還剩 600 多 MiB，但一合成就出現 CUBLAS_STATUS_ALLOC_FAILED，並發請求全部失敗。若 ASR 先佔走 1 GB，TTS 開機時 vLLM 的試算階段就直接 OOM。把 ASR 改跑 CPU（Ryzen 7 5700G）後，2060 由 TTS 獨占，問題就解決了。ASR 在 CPU 上的速度：音訊長度CPUGPU 3 秒0.29 秒0.08 秒 5.8 秒0.58 秒0.08 秒 每句話大約多 0.2–0.4 秒，整體可以接受。換成 6 GB 卡要注意vLLM 的 gpu_memory_utilization 是「佔整張卡的比例」，換不同容量的卡一定要重算，不能沿用舊值。這次 2060 用 0.5（vLLM 約分到 3 GB）。驗收要看「合成當下」的顯存峰值，不能只看閒置數字。這次閒置時看起來有餘裕，實際合成才爆掉。量測條件：原生 Ubuntu，CosyVoice 3 fp16＋vLLM，最大並發 4；2060 上只跑 TTS。與前文的差異是 TTS 服務已加上台灣讀音修正與文字正規化，前端處理只多幾毫秒到幾十毫秒，對結果影響可忽略。 【補測】RTX 2060 6G 加入 CosyVoice 3 TTS 實測

延續前文三卡實測，這次把 TTS 卡換成 RTX 2060 6G，用完全相同的腳本與條件再跑一次（bench_tts.sh 10，五句常用句各 10 輪 n=50，另加串流首包 n=10，排隊警告 0 筆）。

四卡結果
顯卡RTF串流首包TTS 顯存
RTX 3060 Ti 8G0.240約 1.27 秒4,753 MiB
RTX 2080 Ti 22G0.2501.23–1.27 秒5,000 MiB
RTX 3060 12G0.330約 1.72 秒5,957 MiB
RTX 2060 6G0.3501.81 秒4,628 MiB
排名：3060 Ti ≈ 2080 Ti ＞ 3060 12G ≳ 2060 6G

重點

  • 2060 與 3060 12G 幾乎一樣：RTF 只慢約 6%（0.35 對 0.33），首包慢約 0.09 秒，實際使用感覺不出差別。
  • 和 3060 Ti、2080 Ti 相比慢約 45%，但 RTF 0.35 代表合成速度仍是播放速度的近 3 倍，串流播放不會斷音。
  • 四路長句同時合成，連跑兩輪全部成功（每路約 7.8 秒）。
  • 連續四路並發 90 秒滿載：功耗中位 157 W、最高 163 W（已達 160 W 功耗上限）、溫度最高 69°C、時脈約 1,860 MHz、GPU 使用率約 99%，48 次合成零失敗。90 秒尚未達熱穩態，長時間滿載溫度會再高一些。
  • 滿載時顯存峰值 5,702 MiB，6 GB 只剩約 440 MiB，餘量偏緊。


    • 6 GB 的代價：語音辨識（ASR）要移到 CPU

    原本 ASR（SenseVoice）和 TTS 放在同一張卡上，約佔 1 GB。6 GB 放不下兩者：

  • 兩者同卡時，閒置看起來還剩 600 多 MiB，但一合成就出現 CUBLAS_STATUS_ALLOC_FAILED，並發請求全部失敗。
  • 若 ASR 先佔走 1 GB，TTS 開機時 vLLM 的試算階段就直接 OOM。


    • 把 ASR 改跑 CPU（Ryzen 7 5700G）後，2060 由 TTS 獨占，問題就解決了。ASR 在 CPU 上的速度：
    音訊長度CPUGPU
    3 秒0.29 秒0.08 秒
    5.8 秒0.58 秒0.08 秒
    每句話大約多 0.2–0.4 秒，整體可以接受。

    換成 6 GB 卡要注意

  • vLLM 的 gpu_memory_utilization 是「佔整張卡的比例」，換不同容量的卡一定要重算，不能沿用舊值。這次 2060 用 0.5（vLLM 約分到 3 GB）。
  • 驗收要看「合成當下」的顯存峰值，不能只看閒置數字。這次閒置時看起來有餘裕，實際合成才爆掉。


    • 量測條件：原生 Ubuntu，CosyVoice 3 fp16＋vLLM，最大並發 4；2060 上只跑 TTS。與前文的差異是 TTS 服務已加上台灣讀音修正與文字正規化，前端處理只多幾毫秒到幾十毫秒，對結果影響可忽略。

    ]]>     Mon, 05 Oct 2026 00:54:11 +0800     CosyVoice 3 TTS 三卡實測：3060 12G / 3060 Ti 8G / 2080 Ti 22G in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23017#p23017 23017@https://digiland.tw CosyVoice 3 TTS 三張顯卡實測：RTX 3060 12G / 3060 Ti 8G / 2080 Ti 22G(改)前言前一篇完成 RTX 2080 Ti 22GB 魔改卡的燒機與顯存驗收後，這次把它正式拉進實際 AI 工作負載，看看這張「老世代＋大顯存」的顯卡，在語音合成這類與即時互動密切相關的任務上，到底能跑到什麼程度。這次沒有只測 2080 Ti，而是加入 RTX 3060 12GB 與 RTX 3060 Ti 8GB，使用相同的 CosyVoice 3 + vLLM 推理環境進行比較，並把測試重點放在 RTF、串流首包延遲、VRAM 使用量、顯存頻寬、溫度、並發能力，以及 vLLM、TensorRT、WSL2 等不同軟體條件所造成的差異。這次測試也刻意避開一個很容易出現的誤區：GPU 規格比較，不等於實際應用效能比較。2080 Ti 的理論顯存頻寬明顯高於 3060 Ti，22GB 顯存也遠大於 8GB；但在實際 TTS 工作負載中，頻寬、CUDA 核心數、kernel 啟動延遲、推理框架與資料傳輸方式，全部可能成為瓶頸。因此這篇文章不只想回答「哪張卡比較快」，更想找出一個實際問題：如果目標是架設一台長時間運作的本地 AI 語音服務，到底什麼才是真正影響使用體驗的瓶頸？以下測試全部以實際執行結果為主，並盡可能使用相同測試方法進行比較。數據適用於本次測試環境，不代表不同版本的 CUDA、PyTorch、vLLM、CosyVoice 或不同硬體平台一定會得到完全相同的結果。同一套 CosyVoice 3 + vLLM 加速管線，換三張不同世代、不同定位的卡實測 RTF、VRAM 用量與串流首包延遲。附燒機驗收數據、踩過的五個測量陷阱，以及每張卡實際可用的設定值。測試對象：RTX 3060 12G ／ RTX 3060 Ti 8G ／ RTX 2080 Ti 22G（改裝顯存）引擎：CosyVoice 3 + vLLM（自迴歸段加速）系統：原生 Ubuntu 26.04（非 WSL）──────────────────────────────■ 先講結論RTF 排名：3060 Ti（0.24）≈ 2080 Ti（0.25）＞ 3060 12G（0.33，慢 35%）。理論頻寬最高的 2080 Ti 並沒有明顯贏過便宜很多的 3060 Ti。CosyVoice 的自迴歸段是 kernel 啟動延遲瓶頸，不是頻寬瓶頸——所以軟體加速（vLLM）比換卡本身更有效：同一張卡光開 vLLM 就從 RTF 1.2~1.5 降到 0.3 附近，將近 4 倍。RTF 低不代表端到端快。實測本地 TTS 端到端首包中位數3.16 秒，比雲端 BytePlus 的1.63 秒還慢——因為本地是整段合成完才送出，架構差異蓋過了 RTF 的優勢。顯存分配用的是比例式參數（GPU fraction），換卡後沿用舊比例會爆量或浪費，必須每張卡重新校準（下文有三張卡各自的正確值）。──────────────────────────────◆ 01　硬體規格規格3060 12G3060 Ti 8G2080 Ti 22G(改) 架構Ampere GA106Ampere GA104Turing TU102-300A CUDA核心/SM數3584 / 284864 / 384352 / 68 VRAM/位寬12GB/192-bit8GB/256-bit22GB(改)/352-bit 理論頻寬360 GB/s448 GB/s616 GB/s（最高） FP32理論算力12.74 TFLOPS16.2 TFLOPS（最高）13.45 TFLOPS BF16支援✅✅❌ 實測功耗上限170W(功耗牆)200W(溫度牆)260W(功耗牆) 2080 Ti 是二手改裝顯存卡（原廠 11GB 改 22GB），Turing 世代沒有 BF16，vLLM 在它身上會自動降級（BF16→FP16、V1→V0 引擎、FlashAttention→XFormers），但 CUDA Graph 捕捉仍正常運作。──────────────────────────────◆ 02　TTS 服務層實測（重點數據）三張卡同一套設定（FP16 + ONNX 前端跑 CPU + vLLM），同一支腳本 bench_tts.sh 10、n=50，皆為原生 Ubuntu，日期分別為 2026-09-09 / 09-10 / 09-18，方法完全一致，可直接互相比較。GPURTF串流首包TTS VRAM 3060 12G0.330約 1.72s5,957 MiB 3060 Ti 8G0.24 ★約 1.27s4,753 MiB 2080 Ti 22G0.2501.23–1.27s5,000 MiB 3060 12G 慢的原因不是顯存或頻寬，是 SM 數量少（GA106 只有 28 組，3060 Ti 的 GA104 有 38 組）——CosyVoice 的計算量本來就不是被頻寬卡住，核心數量更關鍵。這也是 2080 Ti 頻寬贏 3060 Ti 近 38%、算力卻沒有明顯優勢的同一個原因：TTS 這個負載，SM 數量與排程效率比帳面頻寬更重要。⚠ VRAM fraction 是比例式，必須每卡重算vLLM 的顯存分配參數（COSY_VLLM_GPU_FRAC）是「佔總顯存的比例」，不是固定 MiB。沿用舊卡的比例在大顯存卡上會分配過量、在小顯存卡上會直接 OOM，且不影響速度只浪費顯存。三張卡各自校準後的正確值：設定3060 12G3060 Ti 8G2080 Ti 22G COSY_VLLM_GPU_FRAC0.270.400.15 實際 TTS VRAM5,957 MiB4,753 MiB5,000 MiB 踩過的雷：2080 Ti 沿用 3060 Ti 的 0.40 時，VRAM 直接灌到 10,472 MiB（遠超實際需求），改成 0.15 後降到 5,000 MiB，RTF 完全沒變（仍是 0.250）——多分配的顯存全部進了用不到的 KV cache。──────────────────────────────◆ 03　燒機驗收數據附上是因為「跑得動」跟「跑得快」是兩件事——尤其 2080 Ti 是後天改裝顯存的卡，容量造假或焊接不良通常第一輪燒機就會爆錯，不會等到半夜跑推論才吐亂碼。項目3060 12G3060 Ti 8G2080 Ti 22G VRAM全容量測試60min/62,686次/0 err30min/64,143次/0 err30min/22,357次/0 err 頻寬 寫入(達成率)316 GB/s (88%)390.5 GB/s (87%)467–472 GB/s (76%) 頻寬 讀取驗證318–320 GB/s393–394 GB/s495–505 GB/s 峰值溫度/熱餘裕77°C / 16°C85°C / 8°C81°C / 8°C 限制因素功耗牆溫度牆功耗牆 2080 Ti 這顆改裝卡通過了 22GB 全容量位元測試零錯誤，頻寬也達到理論值的 76%——改顆粒本身沒有問題，只是最終 TTS 速度沒有隨頻寬等比放大（見上一節的 SM 數量解釋）。──────────────────────────────◆ 04　軟體優化比硬體本身更有效▍vLLM：同一張卡，4 倍差距CosyVoice 的瓶頸出在自迴歸產生 token 的階段，這段 GPU 使用率只有 40–55%——是 kernel 啟動延遲卡住，不是算力卡住。vLLM 的 CUDA Graph 把大量小 kernel 呼叫打包成一次提交，正好打在這個痛點上。在 3060 Ti 上同一顆卡、同一份 FP16 設定做 A/B：測試句FP16(無vLLM)FP16+vLLM提升 打招呼RTF 1.49RTF 0.334.45× 跌倒確認句RTF 1.20RTF 0.323.79× 天氣問答RTF 1.19RTF 0.313.85× 對照組：同一張卡試過 TensorRT，數字上最快的 FP16+TRT 組合把 RTF 壓到 1.17（VRAM 降到 3,223 MiB），但實際聽起來聲音會顫抖、音質劣化，最終整條路線放棄。這裡的教訓是：優化要打在真正閒置的那個階段（自迴歸段使用率 40–55%），而不是已經接近滿載的階段（Flow+聲碼器已經 98–99% 使用率，TensorRT 打在這裡效果有限還傷音質）。▍作業系統一樣有 27% 差距同一張 3060 Ti，只換系統（WSL2 → 原生 Ubuntu 26.04），沒動硬體：指標WSL2原生 Ubuntu 26.04 TTS RTF(打招呼/跌倒句)0.33 / 0.320.24 / 0.24 (快27%) 端到端首聲3,159 ms2,112–2,206 ms 根因量到了：WSL2 的非同步 kernel 提交延遲 12.7µs、同步往返 37.1µs，原生 Linux 分別只要 3–6µs 和 8–15µs。GPU 本身的算力沒有差異（FP16 算力量測值等於理論值的 100%），純粹是虛擬化層加的延遲稅。──────────────────────────────◆ 05　RTF 低不代表體感快把本地 CosyVoice（RTF 0.24–0.32，vLLM 加速後）跟雲端 BytePlus TTS 直接量測端到端首包（WebSocket 收到第一個音訊 frame 的時間），15 次取中位數：TTS中位數最快最慢 雲端 BytePlus(雙向串流)1,630 ms ★1,1174,577 本地 CosyVoice(vLLM)3,159 ms2,20914,063 本地反而慢了近 1.9 倍——原因不是算力，是架構：本地是整段文字合成完才送出音訊（1–2 個 chunk），雲端是邊算邊串流送出。RTF 本身其實不差（單獨量測 TTS 段落是 0.38–0.74），差距全部出在「什麼時候開始送第一個音框」這件事上，換更快的顯卡救不了。 首包延遲 ≈ 630ms（固定架構成本）＋ 每秒音訊 × 160–210ms 對同一張卡（3060 Ti，原生 Ubuntu 生產環境）精確量測呼叫邊界後發現：延遲 = 一個固定成本 + 與音訊長度成正比的生成時間，而這個 ~630ms 固定成本是模型架構本身（flow-matching 的固定 ODE 步數 + 聲碼器），跟顯存頻寬無關，換卡砍不掉。實務上唯一免費的優化是讓第一句合成的文字盡量短，因為這個固定成本是「每次呼叫」付一次，不是「每個字」都要付。──────────────────────────────◆ 06　並發上限3060 Ti 上測試同時送多少請求會開始塌陷（拿掉不必要的全域鎖之後，模型本身是 thread-safe 的）：並發數最慢一筆平均/請求錯誤數 44.7s1,169 ms0 67.0s1,175 ms0 89.9s1,243 ms0 1012.3s1,233 ms0 1249.4s ⚠4,118 ms ⚠0 10 以內幾乎線性；跨過 12 直接劣化 3.3 倍，而且完全不報錯、不 OOM——沒有任何失敗訊號，只會變慢，必須自己設併發上限攔住，不能指望系統自己喊救命。在目前測試環境下，10 路並發仍能維持約 1.23 秒/請求的平均處理時間；提升到 12 路後延遲突然惡化，顯示約 10 路附近是本次設定下的實用並發上限。──────────────────────────────◆ 07　五個會讓你量到假數字的陷阱① Windows 顯卡驅動會偷偷把顯存溢到系統記憶體536+ 版驅動的「CUDA System Memory Fallback」在 VRAM 不足時不會報 OOM，而是靜默透過 PCIe 溢到系統 RAM（頻寬低一個數量級），完全沒有錯誤訊號。在一張 6GB 卡上實測：模型需求約 6.7GB，結果真的溢出，某句合成從 3.28s 暴增到 100s，一開始被誤判成「FP16 有問題」，後來才抓到是這個驅動行為。這個陷阱只在 Windows 上發生，是換到原生 Linux 的理由之一。② torch.cuda.max_memory_allocated() 量出來的 VRAM 是假的它不含 CUDA context、cuDNN/cuBLAS workspace，也不含 onnxruntime 自己的顯存池（CosyVoice 的語音 tokenizer 跟聲紋模型是用 ONNX Runtime 跑在 CUDA 上，完全在 PyTorch 的統計範圍之外）。用這個函式量，容易低估將近一半。一律改用 nvidia-smi 才是真實數字。③ GPU fraction 參數是比例式，換卡等於換算法同一個比例在不同顯存容量的卡上結果完全不同，可用資源變多反而可能因為分配過度而排擠掉別的服務，甚至 OOM。每次換卡都要重新校準，不能延用舊值。④ WSL2 的延遲稅算在「軟體」帳上，卻常被誤判成「硬體不夠力」同一張卡在 WSL2 跟原生 Linux 上，理論算力完全一樣（FP16 算力實測等於理論值），純粹是虛擬化層的 kernel 提交延遲拖慢啟動密集型負載。在下結論「這張卡不夠快」之前，先確認測試環境本身有沒有這一層稅。⑤ RTF 贏不代表數字沒有代價，一定要做真人聽感測試TensorRT 把 RTF 壓到全場最低（1.17），純看數字是勝利，但實際聽起來音質明顯劣化（顫抖）。任何「加速後數字變好看」的結果，上線前都應該實際聽一遍，不能只看 benchmark 輸出的數字。──────────────────────────────◆ 08　最終可用設定三張卡最後都收斂到同一套組合，差別只在 COSY_VLLM_GPU_FRAC： COSY_ONNX_CPU=1 # 語音 tokenizer 的 ONNX 前端丟 CPU 跑，省顯存 COSY_FP16=1 # 單這項對短句就有 ~1.6× 提升 COSY_TRT=0 # TensorRT 已驗證會傷音質，關閉 COSY_VLLM=1 # 4 倍提升的主要來源 COSY_VLLM_GPU_FRAC=0.40 # 依卡調整：3060Ti=0.40 / 3060 12G=0.27 / 2080Ti 22G=0.15 COSY_NO_LOCK=1 COSY_MAX_CONCURRENCY=4 # 實測數據支持拉到 10，12 開始塌陷 VLLM_NO_USAGE_STATS=1 DO_NOT_TRACK=1 # vLLM 預設會回傳使用統計，關掉三張卡的燒機、bench_tts.sh 對照與 vLLM/TensorRT 的 A/B 測試皆為原始資料整理，數字皆標註測試方法與日期；不同方法量出的數字不放進主表，避免誤導比較。總結這次三張 NVIDIA 顯卡的 CosyVoice 3 實測，得到一個相當有意思的結果：顯存最大的 2080 Ti 22GB，並沒有在 TTS 速度上明顯領先 3060 Ti 8GB。在本次測試環境中，3060 Ti 的 RTF 約 0.24，2080 Ti 約 0.25，兩者幾乎在同一個級距；反而是 3060 12GB 以約 0.33 落後。這說明對 CosyVoice 這類工作負載而言，單純增加顯存頻寬並不一定能等比例轉換成 TTS 效能，GPU 核心數量、kernel 啟動效率與推理框架的影響可能更大。但這並不代表 2080 Ti 22GB 沒有價值。它最大的優勢仍然是22GB 顯存容量。對需要較大模型、較大 batch、較大 KV cache，或希望同一張卡同時容納多個 AI 工作負載的使用者而言，8GB 與 22GB 所能做的事情仍然存在明顯差距。這次測試真正令人印象深刻的，反而是「軟體環境」的重要性。同一張 3060 Ti，在沒有 vLLM 與啟用 vLLM 的情況下，RTF 可以出現數倍差距；同一張 GPU 從 WSL2 改成原生 Ubuntu，也可以觀察到明顯的延遲改善。換句話說，當 GPU 本身已經不是主要瓶頸時，繼續換更貴的顯卡，未必比把推理架構整理好更有效。另外，這次測試也再次證明：RTF 是重要指標，但不是使用者體驗的全部。本地 CosyVoice 的 RTF 已經相當漂亮，但目前服務架構的端到端首包延遲仍然高於雲端串流服務。真正的問題不是單純「GPU 不夠快」，而是從文字輸入、模型生成、音訊封裝到第一個音訊 frame 傳送出去的整條 pipeline。因此，如果下一階段要繼續優化，我會把重點放在：進一步改善 CosyVoice 的真正串流輸出降低首句固定延遲重新檢查 vLLM 與 CosyVoice 的 batch / concurrency 策略針對多使用者情境尋找最佳並發上限比較原生 Ubuntu、Windows 與 WSL2 的實際服務成本評估 22GB 顯存是否能同時承載其他 LLM / AI 工作負載最有意思的地方是，這次測試並沒有得到一個簡單的「買哪張卡」答案。反而得到了一個更實用的結論：AI 工作負載的效能，往往不是由顯卡規格表上的某一個數字決定，而是由「模型 × GPU 架構 × 顯存 × 推理框架 × 作業系統 × 服務架構」共同決定。對想自己架設本地 AI 服務的人來說，真正值得測的，從來不只是 GPU-Z 上面的 TFLOPS 或顯存頻寬，而是把整套系統跑起來之後，使用者究竟多久能聽到第一個字、同時能服務多少人，以及長時間運作是否穩定。這也是這次三張卡實測最值得留下來的地方。 CosyVoice 3 TTS 三張顯卡實測：RTX 3060 12G / 3060 Ti 8G / 2080 Ti 22G(改)

    前言

    前一篇完成 RTX 2080 Ti 22GB 魔改卡的燒機與顯存驗收後，這次把它正式拉進實際 AI 工作負載，看看這張「老世代＋大顯存」的顯卡，在語音合成這類與即時互動密切相關的任務上，到底能跑到什麼程度。

    這次沒有只測 2080 Ti，而是加入 RTX 3060 12GB 與 RTX 3060 Ti 8GB，使用相同的 CosyVoice 3 + vLLM 推理環境進行比較，並把測試重點放在 RTF、串流首包延遲、VRAM 使用量、顯存頻寬、溫度、並發能力，以及 vLLM、TensorRT、WSL2 等不同軟體條件所造成的差異。

    這次測試也刻意避開一個很容易出現的誤區：

    GPU 規格比較，不等於實際應用效能比較。

    2080 Ti 的理論顯存頻寬明顯高於 3060 Ti，22GB 顯存也遠大於 8GB；但在實際 TTS 工作負載中，頻寬、CUDA 核心數、kernel 啟動延遲、推理框架與資料傳輸方式，全部可能成為瓶頸。

    因此這篇文章不只想回答「哪張卡比較快」，更想找出一個實際問題：

    如果目標是架設一台長時間運作的本地 AI 語音服務，到底什麼才是真正影響使用體驗的瓶頸？

    https://digiland.tw/uploads/3_20260930_002956_cosyvoicetts_benchmark.jpg

    以下測試全部以實際執行結果為主，並盡可能使用相同測試方法進行比較。數據適用於本次測試環境，不代表不同版本的 CUDA、PyTorch、vLLM、CosyVoice 或不同硬體平台一定會得到完全相同的結果。

    同一套 CosyVoice 3 + vLLM 加速管線，換三張不同世代、不同定位的卡實測 RTF、VRAM 用量與串流首包延遲。附燒機驗收數據、踩過的五個測量陷阱，以及每張卡實際可用的設定值。

    測試對象：RTX 3060 12G ／ RTX 3060 Ti 8G ／ RTX 2080 Ti 22G（改裝顯存）
    引擎：CosyVoice 3 + vLLM（自迴歸段加速）
    系統：原生 Ubuntu 26.04（非 WSL）

    ──────────────────────────────

    ■ 先講結論

  • RTF 排名：3060 Ti（0.24）≈ 2080 Ti（0.25）＞ 3060 12G（0.33，慢 35%）。理論頻寬最高的 2080 Ti 並沒有明顯贏過便宜很多的 3060 Ti。
  • CosyVoice 的自迴歸段是 kernel 啟動延遲瓶頸，不是頻寬瓶頸——所以軟體加速（vLLM）比換卡本身更有效：同一張卡光開 vLLM 就從 RTF 1.2~1.5 降到 0.3 附近，將近 4 倍。
  • RTF 低不代表端到端快。實測本地 TTS 端到端首包中位數3.16 秒，比雲端 BytePlus 的1.63 秒還慢——因為本地是整段合成完才送出，架構差異蓋過了 RTF 的優勢。
  • 顯存分配用的是比例式參數（GPU fraction），換卡後沿用舊比例會爆量或浪費，必須每張卡重新校準（下文有三張卡各自的正確值）。


    • ──────────────────────────────

    ◆ 01　硬體規格
    規格3060 12G3060 Ti 8G2080 Ti 22G(改)
    架構Ampere GA106Ampere GA104Turing TU102-300A
    CUDA核心/SM數3584 / 284864 / 384352 / 68
    VRAM/位寬12GB/192-bit8GB/256-bit22GB(改)/352-bit
    理論頻寬360 GB/s448 GB/s616 GB/s（最高）
    FP32理論算力12.74 TFLOPS16.2 TFLOPS（最高）13.45 TFLOPS
    BF16支援✅✅❌
    實測功耗上限170W(功耗牆)200W(溫度牆)260W(功耗牆)
    2080 Ti 是二手改裝顯存卡（原廠 11GB 改 22GB），Turing 世代沒有 BF16，vLLM 在它身上會自動降級（BF16→FP16、V1→V0 引擎、FlashAttention→XFormers），但 CUDA Graph 捕捉仍正常運作。

    ──────────────────────────────

    ◆ 02　TTS 服務層實測（重點數據）

    三張卡同一套設定（FP16 + ONNX 前端跑 CPU + vLLM），同一支腳本 bench_tts.sh 10、n=50，皆為原生 Ubuntu，日期分別為 2026-09-09 / 09-10 / 09-18，方法完全一致，可直接互相比較。
    GPURTF串流首包TTS VRAM
    3060 12G0.330約 1.72s5,957 MiB
    3060 Ti 8G0.24 ★約 1.27s4,753 MiB
    2080 Ti 22G0.2501.23–1.27s5,000 MiB
    3060 12G 慢的原因不是顯存或頻寬，是 SM 數量少（GA106 只有 28 組，3060 Ti 的 GA104 有 38 組）——CosyVoice 的計算量本來就不是被頻寬卡住，核心數量更關鍵。這也是 2080 Ti 頻寬贏 3060 Ti 近 38%、算力卻沒有明顯優勢的同一個原因：TTS 這個負載，SM 數量與排程效率比帳面頻寬更重要。

    ⚠ VRAM fraction 是比例式，必須每卡重算

    vLLM 的顯存分配參數（COSY_VLLM_GPU_FRAC）是「佔總顯存的比例」，不是固定 MiB。沿用舊卡的比例在大顯存卡上會分配過量、在小顯存卡上會直接 OOM，且不影響速度只浪費顯存。三張卡各自校準後的正確值：
    設定3060 12G3060 Ti 8G2080 Ti 22G
    COSY_VLLM_GPU_FRAC0.270.400.15
    實際 TTS VRAM5,957 MiB4,753 MiB5,000 MiB
    踩過的雷：2080 Ti 沿用 3060 Ti 的 0.40 時，VRAM 直接灌到 10,472 MiB（遠超實際需求），改成 0.15 後降到 5,000 MiB，RTF 完全沒變（仍是 0.250）——多分配的顯存全部進了用不到的 KV cache。

    ──────────────────────────────

    ◆ 03　燒機驗收數據

    附上是因為「跑得動」跟「跑得快」是兩件事——尤其 2080 Ti 是後天改裝顯存的卡，容量造假或焊接不良通常第一輪燒機就會爆錯，不會等到半夜跑推論才吐亂碼。
    項目3060 12G3060 Ti 8G2080 Ti 22G
    VRAM全容量測試60min/62,686次/0 err30min/64,143次/0 err30min/22,357次/0 err
    頻寬 寫入(達成率)316 GB/s (88%)390.5 GB/s (87%)467–472 GB/s (76%)
    頻寬 讀取驗證318–320 GB/s393–394 GB/s495–505 GB/s
    峰值溫度/熱餘裕77°C / 16°C85°C / 8°C81°C / 8°C
    限制因素功耗牆溫度牆功耗牆
    2080 Ti 這顆改裝卡通過了 22GB 全容量位元測試零錯誤，頻寬也達到理論值的 76%——改顆粒本身沒有問題，只是最終 TTS 速度沒有隨頻寬等比放大（見上一節的 SM 數量解釋）。

    ──────────────────────────────

    ◆ 04　軟體優化比硬體本身更有效

    ▍vLLM：同一張卡，4 倍差距

    CosyVoice 的瓶頸出在自迴歸產生 token 的階段，這段 GPU 使用率只有 40–55%——是 kernel 啟動延遲卡住，不是算力卡住。vLLM 的 CUDA Graph 把大量小 kernel 呼叫打包成一次提交，正好打在這個痛點上。在 3060 Ti 上同一顆卡、同一份 FP16 設定做 A/B：
    測試句FP16(無vLLM)FP16+vLLM提升
    打招呼RTF 1.49RTF 0.334.45×
    跌倒確認句RTF 1.20RTF 0.323.79×
    天氣問答RTF 1.19RTF 0.313.85×
    對照組：同一張卡試過 TensorRT，數字上最快的 FP16+TRT 組合把 RTF 壓到 1.17（VRAM 降到 3,223 MiB），但實際聽起來聲音會顫抖、音質劣化，最終整條路線放棄。這裡的教訓是：優化要打在真正閒置的那個階段（自迴歸段使用率 40–55%），而不是已經接近滿載的階段（Flow+聲碼器已經 98–99% 使用率，TensorRT 打在這裡效果有限還傷音質）。

    ▍作業系統一樣有 27% 差距

    同一張 3060 Ti，只換系統（WSL2 → 原生 Ubuntu 26.04），沒動硬體：
    指標WSL2原生 Ubuntu 26.04
    TTS RTF(打招呼/跌倒句)0.33 / 0.320.24 / 0.24 (快27%)
    端到端首聲3,159 ms2,112–2,206 ms
    根因量到了：WSL2 的非同步 kernel 提交延遲 12.7µs、同步往返 37.1µs，原生 Linux 分別只要 3–6µs 和 8–15µs。GPU 本身的算力沒有差異（FP16 算力量測值等於理論值的 100%），純粹是虛擬化層加的延遲稅。

    ──────────────────────────────

    ◆ 05　RTF 低不代表體感快

    把本地 CosyVoice（RTF 0.24–0.32，vLLM 加速後）跟雲端 BytePlus TTS 直接量測端到端首包（WebSocket 收到第一個音訊 frame 的時間），15 次取中位數：
    TTS中位數最快最慢
    雲端 BytePlus(雙向串流)1,630 ms ★1,1174,577
    本地 CosyVoice(vLLM)3,159 ms2,20914,063
    本地反而慢了近 1.9 倍——原因不是算力，是架構：本地是整段文字合成完才送出音訊（1–2 個 chunk），雲端是邊算邊串流送出。RTF 本身其實不差（單獨量測 TTS 段落是 0.38–0.74），差距全部出在「什麼時候開始送第一個音框」這件事上，換更快的顯卡救不了。

    首包延遲 ≈ 630ms（固定架構成本）＋ 每秒音訊 × 160–210ms

    對同一張卡（3060 Ti，原生 Ubuntu 生產環境）精確量測呼叫邊界後發現：延遲 = 一個固定成本 + 與音訊長度成正比的生成時間，而這個 ~630ms 固定成本是模型架構本身（flow-matching 的固定 ODE 步數 + 聲碼器），跟顯存頻寬無關，換卡砍不掉。實務上唯一免費的優化是讓第一句合成的文字盡量短，因為這個固定成本是「每次呼叫」付一次，不是「每個字」都要付。

    ──────────────────────────────

    ◆ 06　並發上限

    3060 Ti 上測試同時送多少請求會開始塌陷（拿掉不必要的全域鎖之後，模型本身是 thread-safe 的）：
    並發數最慢一筆平均/請求錯誤數
    44.7s1,169 ms0
    67.0s1,175 ms0
    89.9s1,243 ms0
    1012.3s1,233 ms0
    1249.4s ⚠4,118 ms ⚠0
    10 以內幾乎線性；跨過 12 直接劣化 3.3 倍，而且完全不報錯、不 OOM——沒有任何失敗訊號，只會變慢，必須自己設併發上限攔住，不能指望系統自己喊救命。在目前測試環境下，10 路並發仍能維持約 1.23 秒/請求的平均處理時間；提升到 12 路後延遲突然惡化，顯示約 10 路附近是本次設定下的實用並發上限。

    ──────────────────────────────

    ◆ 07　五個會讓你量到假數字的陷阱

    ① Windows 顯卡驅動會偷偷把顯存溢到系統記憶體
    536+ 版驅動的「CUDA System Memory Fallback」在 VRAM 不足時不會報 OOM，而是靜默透過 PCIe 溢到系統 RAM（頻寬低一個數量級），完全沒有錯誤訊號。在一張 6GB 卡上實測：模型需求約 6.7GB，結果真的溢出，某句合成從 3.28s 暴增到 100s，一開始被誤判成「FP16 有問題」，後來才抓到是這個驅動行為。這個陷阱只在 Windows 上發生，是換到原生 Linux 的理由之一。

    ② torch.cuda.max_memory_allocated() 量出來的 VRAM 是假的
    它不含 CUDA context、cuDNN/cuBLAS workspace，也不含 onnxruntime 自己的顯存池（CosyVoice 的語音 tokenizer 跟聲紋模型是用 ONNX Runtime 跑在 CUDA 上，完全在 PyTorch 的統計範圍之外）。用這個函式量，容易低估將近一半。一律改用 nvidia-smi 才是真實數字。

    ③ GPU fraction 參數是比例式，換卡等於換算法
    同一個比例在不同顯存容量的卡上結果完全不同，可用資源變多反而可能因為分配過度而排擠掉別的服務，甚至 OOM。每次換卡都要重新校準，不能延用舊值。

    ④ WSL2 的延遲稅算在「軟體」帳上，卻常被誤判成「硬體不夠力」
    同一張卡在 WSL2 跟原生 Linux 上，理論算力完全一樣（FP16 算力實測等於理論值），純粹是虛擬化層的 kernel 提交延遲拖慢啟動密集型負載。在下結論「這張卡不夠快」之前，先確認測試環境本身有沒有這一層稅。

    ⑤ RTF 贏不代表數字沒有代價，一定要做真人聽感測試
    TensorRT 把 RTF 壓到全場最低（1.17），純看數字是勝利，但實際聽起來音質明顯劣化（顫抖）。任何「加速後數字變好看」的結果，上線前都應該實際聽一遍，不能只看 benchmark 輸出的數字。

    ──────────────────────────────

    ◆ 08　最終可用設定

    三張卡最後都收斂到同一套組合，差別只在 COSY_VLLM_GPU_FRAC：

    COSY_ONNX_CPU=1 # 語音 tokenizer 的 ONNX 前端丟 CPU 跑，省顯存 COSY_FP16=1 # 單這項對短句就有 ~1.6× 提升 COSY_TRT=0 # TensorRT 已驗證會傷音質，關閉 COSY_VLLM=1 # 4 倍提升的主要來源 COSY_VLLM_GPU_FRAC=0.40 # 依卡調整：3060Ti=0.40 / 3060 12G=0.27 / 2080Ti 22G=0.15 COSY_NO_LOCK=1 COSY_MAX_CONCURRENCY=4 # 實測數據支持拉到 10，12 開始塌陷 VLLM_NO_USAGE_STATS=1 DO_NOT_TRACK=1 # vLLM 預設會回傳使用統計，關掉


    三張卡的燒機、bench_tts.sh 對照與 vLLM/TensorRT 的 A/B 測試皆為原始資料整理，數字皆標註測試方法與日期；不同方法量出的數字不放進主表，避免誤導比較。

    總結

    這次三張 NVIDIA 顯卡的 CosyVoice 3 實測，得到一個相當有意思的結果：

    顯存最大的 2080 Ti 22GB，並沒有在 TTS 速度上明顯領先 3060 Ti 8GB。

    在本次測試環境中，3060 Ti 的 RTF 約 0.24，2080 Ti 約 0.25，兩者幾乎在同一個級距；反而是 3060 12GB 以約 0.33 落後。這說明對 CosyVoice 這類工作負載而言，單純增加顯存頻寬並不一定能等比例轉換成 TTS 效能，GPU 核心數量、kernel 啟動效率與推理框架的影響可能更大。

    但這並不代表 2080 Ti 22GB 沒有價值。

    它最大的優勢仍然是22GB 顯存容量。對需要較大模型、較大 batch、較大 KV cache，或希望同一張卡同時容納多個 AI 工作負載的使用者而言，8GB 與 22GB 所能做的事情仍然存在明顯差距。

    這次測試真正令人印象深刻的，反而是「軟體環境」的重要性。

    同一張 3060 Ti，在沒有 vLLM 與啟用 vLLM 的情況下，RTF 可以出現數倍差距；同一張 GPU 從 WSL2 改成原生 Ubuntu，也可以觀察到明顯的延遲改善。換句話說，當 GPU 本身已經不是主要瓶頸時，繼續換更貴的顯卡，未必比把推理架構整理好更有效。

    另外，這次測試也再次證明：

    RTF 是重要指標，但不是使用者體驗的全部。

    本地 CosyVoice 的 RTF 已經相當漂亮，但目前服務架構的端到端首包延遲仍然高於雲端串流服務。真正的問題不是單純「GPU 不夠快」，而是從文字輸入、模型生成、音訊封裝到第一個音訊 frame 傳送出去的整條 pipeline。

    因此，如果下一階段要繼續優化，我會把重點放在：

  • 進一步改善 CosyVoice 的真正串流輸出
  • 降低首句固定延遲
  • 重新檢查 vLLM 與 CosyVoice 的 batch / concurrency 策略
  • 針對多使用者情境尋找最佳並發上限
  • 比較原生 Ubuntu、Windows 與 WSL2 的實際服務成本
  • 評估 22GB 顯存是否能同時承載其他 LLM / AI 工作負載


    • 最有意思的地方是，這次測試並沒有得到一個簡單的「買哪張卡」答案。

    反而得到了一個更實用的結論：

    AI 工作負載的效能，往往不是由顯卡規格表上的某一個數字決定，而是由「模型 × GPU 架構 × 顯存 × 推理框架 × 作業系統 × 服務架構」共同決定。

    對想自己架設本地 AI 服務的人來說，真正值得測的，從來不只是 GPU-Z 上面的 TFLOPS 或顯存頻寬，而是把整套系統跑起來之後，使用者究竟多久能聽到第一個字、同時能服務多少人，以及長時間運作是否穩定。

    這也是這次三張卡實測最值得留下來的地方。

    ]]>     Tue, 29 Sep 2026 23:04:09 +0800     RTX 2080 Ti 22GB 文生圖模型測試 in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23016#p23016 23016@https://digiland.tw 前言RTX 2080 Ti 22GB 魔改卡到手後，除了跑顯存驗證與運算正確性測試之外，另一個重要的應用場景就是文生圖（Text-to-Image）。這張卡 22GB 的顯存讓它足以承載多種主流生圖模型，包括 FLUX 系列、Z-Image Turbo 6B 以及 Qwen-Image-2.1。本文整理了八組測試場景，每組使用同一組提示詞（prompt），分別以 Z-Image Turbo 6B（以下簡稱 Z-Image）與 Qwen-Image-2.1 各跑一次，目的是直觀比較兩者在以下面向的表現：中文文字正確性與可讀性人物面部、手部等生物細節物理反射與光影一致性複雜場景中多物件的位置與透視關係整體寫實度與構圖品質每組測試均附上兩張輸出圖片，第一張為 Z-Image、第二張為 Qwen-Image。所有圖片均以 1024×1024 解析度輸出，未經後製修圖。1. 中文文字＋產品攝影＋複雜材質 一張高端消費電子產品廣告攝影，一台未來感的白色桌上型 AI 助理裝置放在深色胡桃木桌面中央，裝置正面有一塊小型螢幕，螢幕上清楚顯示繁體中文「居家守護助理」，下方顯示「讓家人安心，讓長輩有伴」，所有中文字必須正確、清晰、沒有錯字或亂碼。 背景是一間溫暖現代化的台灣住宅客廳，夕陽從右側落地窗照入，形成柔和金色光影。桌面上有一杯透明玻璃水杯、一本翻開的書、一副眼鏡、一支黑色鋼筆。玻璃杯產生真實折射與桌面陰影，金屬零件具有細膩反射，白色塑膠外殼具有微妙的霧面質感。 攝影棚級產品攝影，85mm lens，shallow depth of field，realistic global illumination，physically accurate reflections，high dynamic range，extremely detailed，photorealistic，4K commercial advertising photography。測試重點：中文文字、多材質、反射、景深、物件位置關係、中英文混合 prompt▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出2. 👴 老人＋手部＋人物互動 一位約75歲的台灣男性長者坐在客廳沙發上，穿著淺藍色襯衫和深灰色長褲，正在用右手操作桌上的智慧型手機，左手自然放在膝蓋上。他的女兒約40歲，坐在旁邊微笑看著父親，兩人正在自然交談。 要求人物具有真實亞洲人的臉部特徵、自然皮膚紋理、細微皺紋、真實頭髮與眼神。雙手必須具有正確的人體解剖結構，每隻手五根手指，手指自然彎曲，手機與手掌的接觸關係正確。 客廳有一盞落地燈、一張木質茶几、兩個陶瓷茶杯、一盆室內植物。午後自然光從窗戶進入，人物臉部受到柔和側光照射，背景具有自然景深。 documentary photography，natural candid moment，85mm portrait lens，realistic skin texture，subtle wrinkles，physically accurate hands，natural pose，cinematic but realistic lighting，photorealistic，high detail。這張很適合抓 AI 的破綻，尤其放大看：手指、手機、眼睛、嘴巴、人物彼此的肢體關係。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出3. 🪞 鏡子＋反射＋文字 一間極度寫實的現代台灣住宅玄關，一名穿著深藍色外套的中年男子站在大型落地鏡前整理衣領。 畫面必須同時呈現男子本人與鏡中的完整反射，而且鏡中人物的姿勢、衣服、手的位置、臉部方向必須與真實人物完全一致。鏡面反射必須符合物理光學，不能出現第二個不同的人。 鏡子旁牆面掛著一個小型金屬門牌，門牌上清楚寫著繁體中文「幸福之家」，中文字必須完全正確。 玄關地面為灰色拋光石材，可以看到人物和家具的微弱反射。右側有一盞暖黃色壁燈，產生自然的光暈與牆面陰影。 architectural photography，physically accurate mirror reflection，accurate perspective，global illumination，ray-traced appearance，realistic materials，photorealistic，high dynamic range，extremely detailed。這個是很好的物理一致性測試。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出4. 🚗 複雜街景＋大量中文招牌 一張極度寫實的台灣城市街景照片，傍晚六點左右，台北一條繁忙但真實的商業街。 街道兩側有便利商店、咖啡店、機車行、傳統麵店和水果店，招牌使用繁體中文。畫面中至少有十個不同大小的中文招牌，每個招牌的文字都應該具有清晰、可讀、合理的繁體中文字，不要使用簡體字、亂碼或虛構文字。 街道上有行人、汽車與大量機車，部分機車停在路旁。紅綠燈亮著紅燈，一位行人正在斑馬線等待。濕潤的柏油路面反射街燈與招牌霓虹燈。 要求所有車輛具有合理的四輪結構，機車具有正確的兩輪結構，人物具有自然比例，遠近透視正確。 realistic Taiwanese urban street photography，wet asphalt，neon reflections，accurate perspective，natural crowd，cinematic evening light，35mm lens，documentary photography，photorealistic，extremely detailed。這個非常狠 😂 因為同時測：文字＋多人＋車輛＋機車＋透視＋反射。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出5. 🌊 台灣風景＋小物件細節 從台灣東部海岸公路高處向下拍攝，一座蜿蜒的山海公路沿著陡峭山壁延伸，左側是深藍色太平洋，遠方可以看到一座孤立的小島。 前景是一台停在路旁的銀色小型 SUV，車頂安裝一台小型消費級空拍機，車旁放著一個黑色攝影背包、一瓶透明礦泉水和一頂棒球帽。 遠處有一艘白色大型郵輪正在海面航行，海面反射午後陽光。山壁上有茂密的台灣原生植物，公路護欄、路面標線、車輛比例與遠近透視必須正確。 晴朗午後，天空有少量積雲，遠山帶有自然的大氣透視。 professional landscape photography，Taiwan east coast，realistic atmospheric perspective，accurate scale，natural sunlight，physically accurate shadows，24mm wide-angle lens，HDR，photorealistic，ultra detailed。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出6. 🧠 Boss Level：工程師實驗室焊接這個我最推薦拿來測 Qwen-Image-2.1。 一張電影級、極度寫實的單張攝影畫面：凌晨四點，一名台灣男性工程師獨自在電子研發實驗室工作。 他坐在工作桌前，右手拿著精密鑷子，正在替一塊 ESP32-S3 開發板焊接一顆非常小的電子元件，左手扶著 PCB。桌面上有示波器、數位萬用電表、邏輯分析儀、烙鐵台、焊錫、電子零件盒、杜邦線、USB 線與幾塊不同版本的 PCB。 示波器螢幕上顯示清晰且合理的電子波形；旁邊的電腦螢幕顯示一段正在編譯的 C++ / Arduino 程式碼，程式碼必須具有合理的語法結構；PCB 上可以看到細小但合理的電子元件、IC、電阻電容、銅箔走線與絲印。 工程師戴著透明防護眼鏡，臉部受到桌燈照明，眼神專注。右手五根手指必須解剖結構正確，鑷子、焊接工具與手指的接觸關係必須完全合理。 桌面旁放著一杯已經喝了一半的咖啡，杯子表面有水氣；窗外是凌晨的城市夜景，可以看到遠方建築物的燈光。 整個場景必須遵守真實物理光學：金屬反射、玻璃反射、PCB 表面反光、螢幕發光、桌面陰影、人物投影與環境光必須互相一致。 cinematic documentary photography，professional electronics laboratory，physically accurate hands，accurate electronics，accurate perspective，realistic reflections，global illumination，ray-traced lighting，natural skin texture，35mm lens，shallow depth of field，photorealistic，extremely detailed，8K photographic realism。這張要檢查 10 個地方：手指是不是 5 根、鑷子有沒有穿過手、ESP32-S3 PCB 是否像真的 PCB、IC/電阻/電容是否合理、示波器波形是否像正常電子訊號、程式碼文字是否接近可讀、電腦螢幕上的字是否亂碼、咖啡杯/玻璃反射是否合理、光源方向是否一致、人/桌子/PCB/儀器的透視是否一致。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出7. 街頭人物隨拍 專業相機抓拍的超高清寫實街拍照片，以「上傳圖片」中的女性臉部特徵、髮型與整體外觀作為人物參考，保持與參考圖片高度一致的臉型、五官比例、髮型與髮色。一位 22 歲、具有自然東亞女性外貌的年輕女子，身材比例勻稱、曲線自然，穿著時尚而得體的日常休閒服裝。 她正自然地邁步走在天氣晴朗的城市街道上，一手拎著簡約時尚的購物袋，另一手拿著智慧型手機。她微微低著頭，視線自然地集中在手機螢幕上，呈現出專注查看手機訊息的自然瞬間。走路姿態自然流暢，雙腿與手臂的動作符合真實人體行走時的姿勢與重心變化，避免僵硬的擺拍感。 街道環境明亮乾淨，兩旁有現代商店、咖啡廳、街道樹木與行人，背景呈現真實城市生活氛圍。陽光從側前方照射，人物臉部與頭髮具有自然柔和的陽光與陰影，衣服的布料、頭髮絲、皮膚紋理與購物袋材質都清晰可見。 使用全片幅專業相機拍攝，50mm 鏡頭，淺景深，人物主體清晰銳利，背景具有自然柔和的散景。真實攝影光學、自然膚色、細膩皮膚紋理、真實頭髮細節、準確人體比例、自然手部與手指結構、正確的手機與手掌接觸關係、自然透視、真實陰影與反射。 high-end professional street photography, full-frame camera, 50mm lens, shallow depth of field, natural bokeh, realistic skin texture, detailed hair strands, accurate anatomy, natural walking motion, realistic hands and fingers, physically accurate lighting, realistic fabric texture, cinematic natural sunlight, HDR, photorealistic, ultra detailed, 8K photographic quality。如果你是要專門測試「參考臉＋動態姿勢＋手部＋手機」能力，這版其實比單純強調「美女」更有效，因為一次會測到好幾個容易出錯的地方。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出8. 車內視角自拍 一張自然寫實、帶有溫暖黃昏氛圍的年輕成年東亞女子車內近距離人像攝影，4:5 直式構圖，呈現自然手機隨拍與高質感 Lifestyle Photography 風格。 一位年輕成年東亞女子坐在現代轎車的前排座位上，身體自然朝向鏡頭，安全帶從肩膀斜跨身前。她擁有精緻自然的東亞五官、柔和小巧的臉型、明亮深色眼睛、自然眉形與淡雅乾淨的妝容。肌膚細膩通透，同時保留真實皮膚紋理，不過度磨皮；雙頰帶有夕陽映照形成的自然暖色紅潤，嘴唇呈柔和自然的淡粉色。 她留著深棕色長直髮，中間自然分線，長髮蓬鬆柔順地披落在雙肩與身前，細緻髮絲被夕陽勾勒出暖金色光澤。 女子安靜地直視攝影機，神情平靜、自然、略帶柔和自信感，不刻意微笑。一隻手自然抬起靠近肩膀與長髮位置，手掌微微收起，像是準備整理頭髮；手指姿態自然、五指結構正確。手上佩戴簡約細戒指與金屬手環，頸部佩戴纖細金色項鍊與小巧黑色星形造型吊墜，搭配簡約黑色細肩帶上衣。 畫面最重要的光線來自車窗外的低角度黃昏夕陽，溫暖金色陽光從側前方斜射進車內，直接照亮女子半邊臉部、眼睛、鼻樑、嘴唇、頭髮與手臂，形成漂亮而自然的 Golden Hour 光影；另一側保持柔和陰影，使臉部具有自然立體感。陽光明亮但不過曝，皮膚色調自然，不產生塑膠感。 背景保留真實的深色汽車內裝、皮革座椅、頭枕、後排座位與車窗結構，車窗外可以看見清澈明亮的藍色天空。背景稍微柔化，但仍能辨識是真實汽車內部，避免棚拍感與合成感。 相機採用近距離半身構圖，約從腰部/上半身至頭頂完整入鏡，50–70mm 自然人像透視，視角接近人物眼睛高度。焦點精準落在雙眼與臉部，眼睛清晰銳利，細緻髮絲與真實肌膚紋理清楚可見；自然 HDR、真實動態範圍、電影級暖色調、高清細節。 photorealistic、natural skin texture、golden hour sunlight、realistic car interior、sharp focus、high detail、8K。避免：臉部過度磨皮、AI 塑膠肌、五官變形、手部畸形、多手指或少手指、安全帶位置錯誤、頭髮黏成一片、過曝夕陽、過強濾鏡、假 HDR、背景合成感、模糊臉部。▎Z-Image Turbo 6B 輸出▎Qwen-Image-2.1 輸出總結 Benchmark 建議如果你的目的是比較 Qwen-Image-2.1、Z-Image、FLUX.1/FLUX.2 的能力，我最推薦直接用第 1、2、3、6 四組做固定 benchmark：同解析度、同 seed（如果模型允許）、同採樣設定，各跑一次，再比較文字、手、反射、複雜場景和物件一致性。初步心得與觀察以下為本次測試的幾點主觀心得，供有興趣的網友參考：關於中文字目前這兩套工具在繁體中文字的正確性上，表現都不及格。Z-Image 在測試 1 中「居家守護助理」的「護」字出現明顯筆畫錯誤，而街景招牌的中文字更是完全錯亂——這在需要產出含文字圖片的應用場景中，是很大的硬傷。Z-Image Turbo 6B優點：生成速度非常快，每張約 12 秒即可完成，適合需要快速迭代或大量試錯的場景。缺點：圖片的合理性有待加強。例如台灣東海岸風景測試中，空拍機的外型與比例不太自然，郵輪船頭的方向也與 prompt 描述的透視不一致。整體而言，畫面細節的邏輯連貫性還有進步空間。Qwen-Image-2.1優點：生圖品質相較之下略勝一籌，構圖邏輯與物件相對位置的合理性較好，場景的整體感也更接近 prompt 的描述。缺點：生成速度明顯偏慢，每張約需 90 秒。若需要大量產圖，時間成本會是主要的考量因素。討論以上為個人的初步測試心得，兩套工具各有擅場與短板。不知道大家比較喜歡哪一張圖片、或是偏好哪一套生圖工具呢？歡迎在底下留言一起討論！ 前言

    RTX 2080 Ti 22GB 魔改卡到手後，除了跑顯存驗證與運算正確性測試之外，另一個重要的應用場景就是文生圖（Text-to-Image）。這張卡 22GB 的顯存讓它足以承載多種主流生圖模型，包括 FLUX 系列、Z-Image Turbo 6B 以及 Qwen-Image-2.1。

    本文整理了八組測試場景，每組使用同一組提示詞（prompt），分別以 Z-Image Turbo 6B（以下簡稱 Z-Image）與 Qwen-Image-2.1 各跑一次，目的是直觀比較兩者在以下面向的表現：

  • 中文文字正確性與可讀性
  • 人物面部、手部等生物細節
  • 物理反射與光影一致性
  • 複雜場景中多物件的位置與透視關係
  • 整體寫實度與構圖品質


    • 每組測試均附上兩張輸出圖片，第一張為 Z-Image、第二張為 Qwen-Image。所有圖片均以 1024×1024 解析度輸出，未經後製修圖。

    1. 中文文字＋產品攝影＋複雜材質

    一張高端消費電子產品廣告攝影，一台未來感的白色桌上型 AI 助理裝置放在深色胡桃木桌面中央，裝置正面有一塊小型螢幕，螢幕上清楚顯示繁體中文「居家守護助理」，下方顯示「讓家人安心，讓長輩有伴」，所有中文字必須正確、清晰、沒有錯字或亂碼。 背景是一間溫暖現代化的台灣住宅客廳，夕陽從右側落地窗照入，形成柔和金色光影。桌面上有一杯透明玻璃水杯、一本翻開的書、一副眼鏡、一支黑色鋼筆。玻璃杯產生真實折射與桌面陰影，金屬零件具有細膩反射，白色塑膠外殼具有微妙的霧面質感。 攝影棚級產品攝影，85mm lens，shallow depth of field，realistic global illumination，physically accurate reflections，high dynamic range，extremely detailed，photorealistic，4K commercial advertising photography。


    測試重點：中文文字、多材質、反射、景深、物件位置關係、中英文混合 prompt

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165340_z-image01.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165358_qwen-image01.jpg

    2. 👴 老人＋手部＋人物互動

    一位約75歲的台灣男性長者坐在客廳沙發上，穿著淺藍色襯衫和深灰色長褲，正在用右手操作桌上的智慧型手機，左手自然放在膝蓋上。他的女兒約40歲，坐在旁邊微笑看著父親，兩人正在自然交談。 要求人物具有真實亞洲人的臉部特徵、自然皮膚紋理、細微皺紋、真實頭髮與眼神。雙手必須具有正確的人體解剖結構，每隻手五根手指，手指自然彎曲，手機與手掌的接觸關係正確。 客廳有一盞落地燈、一張木質茶几、兩個陶瓷茶杯、一盆室內植物。午後自然光從窗戶進入，人物臉部受到柔和側光照射，背景具有自然景深。 documentary photography，natural candid moment，85mm portrait lens，realistic skin texture，subtle wrinkles，physically accurate hands，natural pose，cinematic but realistic lighting，photorealistic，high detail。


    這張很適合抓 AI 的破綻，尤其放大看：手指、手機、眼睛、嘴巴、人物彼此的肢體關係。

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165514_z-image02.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165525_qwen-image02.jpg

    3. 🪞 鏡子＋反射＋文字

    一間極度寫實的現代台灣住宅玄關，一名穿著深藍色外套的中年男子站在大型落地鏡前整理衣領。 畫面必須同時呈現男子本人與鏡中的完整反射，而且鏡中人物的姿勢、衣服、手的位置、臉部方向必須與真實人物完全一致。鏡面反射必須符合物理光學，不能出現第二個不同的人。 鏡子旁牆面掛著一個小型金屬門牌，門牌上清楚寫著繁體中文「幸福之家」，中文字必須完全正確。 玄關地面為灰色拋光石材，可以看到人物和家具的微弱反射。右側有一盞暖黃色壁燈，產生自然的光暈與牆面陰影。 architectural photography，physically accurate mirror reflection，accurate perspective，global illumination，ray-traced appearance，realistic materials，photorealistic，high dynamic range，extremely detailed。


    這個是很好的物理一致性測試。

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165540_z-image03.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165549_qwen-image03.jpg

    4. 🚗 複雜街景＋大量中文招牌

    一張極度寫實的台灣城市街景照片，傍晚六點左右，台北一條繁忙但真實的商業街。 街道兩側有便利商店、咖啡店、機車行、傳統麵店和水果店，招牌使用繁體中文。畫面中至少有十個不同大小的中文招牌，每個招牌的文字都應該具有清晰、可讀、合理的繁體中文字，不要使用簡體字、亂碼或虛構文字。 街道上有行人、汽車與大量機車，部分機車停在路旁。紅綠燈亮著紅燈，一位行人正在斑馬線等待。濕潤的柏油路面反射街燈與招牌霓虹燈。 要求所有車輛具有合理的四輪結構，機車具有正確的兩輪結構，人物具有自然比例，遠近透視正確。 realistic Taiwanese urban street photography，wet asphalt，neon reflections，accurate perspective，natural crowd，cinematic evening light，35mm lens，documentary photography，photorealistic，extremely detailed。


    這個非常狠 😂 因為同時測：文字＋多人＋車輛＋機車＋透視＋反射。

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165613_z-image04.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_190821_qwen-image04.jpg

    5. 🌊 台灣風景＋小物件細節

    從台灣東部海岸公路高處向下拍攝，一座蜿蜒的山海公路沿著陡峭山壁延伸，左側是深藍色太平洋，遠方可以看到一座孤立的小島。 前景是一台停在路旁的銀色小型 SUV，車頂安裝一台小型消費級空拍機，車旁放著一個黑色攝影背包、一瓶透明礦泉水和一頂棒球帽。 遠處有一艘白色大型郵輪正在海面航行，海面反射午後陽光。山壁上有茂密的台灣原生植物，公路護欄、路面標線、車輛比例與遠近透視必須正確。 晴朗午後，天空有少量積雲，遠山帶有自然的大氣透視。 professional landscape photography，Taiwan east coast，realistic atmospheric perspective，accurate scale，natural sunlight，physically accurate shadows，24mm wide-angle lens，HDR，photorealistic，ultra detailed。


    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165644_z-image05.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165653_qwen-image05.jpg

    6. 🧠 Boss Level：工程師實驗室焊接

    這個我最推薦拿來測 Qwen-Image-2.1。

    一張電影級、極度寫實的單張攝影畫面：凌晨四點，一名台灣男性工程師獨自在電子研發實驗室工作。 他坐在工作桌前，右手拿著精密鑷子，正在替一塊 ESP32-S3 開發板焊接一顆非常小的電子元件，左手扶著 PCB。桌面上有示波器、數位萬用電表、邏輯分析儀、烙鐵台、焊錫、電子零件盒、杜邦線、USB 線與幾塊不同版本的 PCB。 示波器螢幕上顯示清晰且合理的電子波形；旁邊的電腦螢幕顯示一段正在編譯的 C++ / Arduino 程式碼，程式碼必須具有合理的語法結構；PCB 上可以看到細小但合理的電子元件、IC、電阻電容、銅箔走線與絲印。 工程師戴著透明防護眼鏡，臉部受到桌燈照明，眼神專注。右手五根手指必須解剖結構正確，鑷子、焊接工具與手指的接觸關係必須完全合理。 桌面旁放著一杯已經喝了一半的咖啡，杯子表面有水氣；窗外是凌晨的城市夜景，可以看到遠方建築物的燈光。 整個場景必須遵守真實物理光學：金屬反射、玻璃反射、PCB 表面反光、螢幕發光、桌面陰影、人物投影與環境光必須互相一致。 cinematic documentary photography，professional electronics laboratory，physically accurate hands，accurate electronics，accurate perspective，realistic reflections，global illumination，ray-traced lighting，natural skin texture，35mm lens，shallow depth of field，photorealistic，extremely detailed，8K photographic realism。


    這張要檢查 10 個地方：
    手指是不是 5 根、鑷子有沒有穿過手、ESP32-S3 PCB 是否像真的 PCB、IC/電阻/電容是否合理、示波器波形是否像正常電子訊號、程式碼文字是否接近可讀、電腦螢幕上的字是否亂碼、咖啡杯/玻璃反射是否合理、光源方向是否一致、人/桌子/PCB/儀器的透視是否一致。

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165718_z-image06.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165734_qwen-image06.jpg

    7. 街頭人物隨拍

    專業相機抓拍的超高清寫實街拍照片，以「上傳圖片」中的女性臉部特徵、髮型與整體外觀作為人物參考，保持與參考圖片高度一致的臉型、五官比例、髮型與髮色。一位 22 歲、具有自然東亞女性外貌的年輕女子，身材比例勻稱、曲線自然，穿著時尚而得體的日常休閒服裝。 她正自然地邁步走在天氣晴朗的城市街道上，一手拎著簡約時尚的購物袋，另一手拿著智慧型手機。她微微低著頭，視線自然地集中在手機螢幕上，呈現出專注查看手機訊息的自然瞬間。走路姿態自然流暢，雙腿與手臂的動作符合真實人體行走時的姿勢與重心變化，避免僵硬的擺拍感。 街道環境明亮乾淨，兩旁有現代商店、咖啡廳、街道樹木與行人，背景呈現真實城市生活氛圍。陽光從側前方照射，人物臉部與頭髮具有自然柔和的陽光與陰影，衣服的布料、頭髮絲、皮膚紋理與購物袋材質都清晰可見。 使用全片幅專業相機拍攝，50mm 鏡頭，淺景深，人物主體清晰銳利，背景具有自然柔和的散景。真實攝影光學、自然膚色、細膩皮膚紋理、真實頭髮細節、準確人體比例、自然手部與手指結構、正確的手機與手掌接觸關係、自然透視、真實陰影與反射。 high-end professional street photography, full-frame camera, 50mm lens, shallow depth of field, natural bokeh, realistic skin texture, detailed hair strands, accurate anatomy, natural walking motion, realistic hands and fingers, physically accurate lighting, realistic fabric texture, cinematic natural sunlight, HDR, photorealistic, ultra detailed, 8K photographic quality。


    如果你是要專門測試「參考臉＋動態姿勢＋手部＋手機」能力，這版其實比單純強調「美女」更有效，因為一次會測到好幾個容易出錯的地方。

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165756_z-image07.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165814_qwen-image07.jpg

    8. 車內視角自拍

    一張自然寫實、帶有溫暖黃昏氛圍的年輕成年東亞女子車內近距離人像攝影，4:5 直式構圖，呈現自然手機隨拍與高質感 Lifestyle Photography 風格。 一位年輕成年東亞女子坐在現代轎車的前排座位上，身體自然朝向鏡頭，安全帶從肩膀斜跨身前。她擁有精緻自然的東亞五官、柔和小巧的臉型、明亮深色眼睛、自然眉形與淡雅乾淨的妝容。肌膚細膩通透，同時保留真實皮膚紋理，不過度磨皮；雙頰帶有夕陽映照形成的自然暖色紅潤，嘴唇呈柔和自然的淡粉色。 她留著深棕色長直髮，中間自然分線，長髮蓬鬆柔順地披落在雙肩與身前，細緻髮絲被夕陽勾勒出暖金色光澤。 女子安靜地直視攝影機，神情平靜、自然、略帶柔和自信感，不刻意微笑。一隻手自然抬起靠近肩膀與長髮位置，手掌微微收起，像是準備整理頭髮；手指姿態自然、五指結構正確。手上佩戴簡約細戒指與金屬手環，頸部佩戴纖細金色項鍊與小巧黑色星形造型吊墜，搭配簡約黑色細肩帶上衣。 畫面最重要的光線來自車窗外的低角度黃昏夕陽，溫暖金色陽光從側前方斜射進車內，直接照亮女子半邊臉部、眼睛、鼻樑、嘴唇、頭髮與手臂，形成漂亮而自然的 Golden Hour 光影；另一側保持柔和陰影，使臉部具有自然立體感。陽光明亮但不過曝，皮膚色調自然，不產生塑膠感。 背景保留真實的深色汽車內裝、皮革座椅、頭枕、後排座位與車窗結構，車窗外可以看見清澈明亮的藍色天空。背景稍微柔化，但仍能辨識是真實汽車內部，避免棚拍感與合成感。 相機採用近距離半身構圖，約從腰部/上半身至頭頂完整入鏡，50–70mm 自然人像透視，視角接近人物眼睛高度。焦點精準落在雙眼與臉部，眼睛清晰銳利，細緻髮絲與真實肌膚紋理清楚可見；自然 HDR、真實動態範圍、電影級暖色調、高清細節。 photorealistic、natural skin texture、golden hour sunlight、realistic car interior、sharp focus、high detail、8K。


    避免：臉部過度磨皮、AI 塑膠肌、五官變形、手部畸形、多手指或少手指、安全帶位置錯誤、頭髮黏成一片、過曝夕陽、過強濾鏡、假 HDR、背景合成感、模糊臉部。

    ▎Z-Image Turbo 6B 輸出
    https://digiland.tw/uploads/3_20260924_165827_z-image08.jpg
    ▎Qwen-Image-2.1 輸出
    https://digiland.tw/uploads/3_20260924_165838_qwen-image08.jpg

    總結 Benchmark 建議

    如果你的目的是比較 Qwen-Image-2.1、Z-Image、FLUX.1/FLUX.2 的能力，我最推薦直接用第 1、2、3、6 四組做固定 benchmark：同解析度、同 seed（如果模型允許）、同採樣設定，各跑一次，再比較文字、手、反射、複雜場景和物件一致性。

    初步心得與觀察

    以下為本次測試的幾點主觀心得，供有興趣的網友參考：

    關於中文字

    目前這兩套工具在繁體中文字的正確性上，表現都不及格。Z-Image 在測試 1 中「居家守護助理」的「護」字出現明顯筆畫錯誤，而街景招牌的中文字更是完全錯亂——這在需要產出含文字圖片的應用場景中，是很大的硬傷。

    Z-Image Turbo 6B

    優點：生成速度非常快，每張約 12 秒即可完成，適合需要快速迭代或大量試錯的場景。

    缺點：圖片的合理性有待加強。例如台灣東海岸風景測試中，空拍機的外型與比例不太自然，郵輪船頭的方向也與 prompt 描述的透視不一致。整體而言，畫面細節的邏輯連貫性還有進步空間。

    Qwen-Image-2.1

    優點：生圖品質相較之下略勝一籌，構圖邏輯與物件相對位置的合理性較好，場景的整體感也更接近 prompt 的描述。

    缺點：生成速度明顯偏慢，每張約需 90 秒。若需要大量產圖，時間成本會是主要的考量因素。

    討論

    以上為個人的初步測試心得，兩套工具各有擅場與短板。不知道大家比較喜歡哪一張圖片、或是偏好哪一套生圖工具呢？歡迎在底下留言一起討論！

    ]]>     Thu, 24 Sep 2026 23:31:45 +0800     RTX 2080 Ti 22GB 魔改卡到貨：燒機驗收與實測心得 in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23009#p23009 23009@https://digiland.tw 前言最近幫測試主機（Ryzen 7 5700G / Ubuntu）換上一張廠商標示為「全新訂製」的 RTX 2080 Ti 22GB 魔改卡，取代原本的 RTX 3060 Ti 8GB。這類訂製卡是供應商以 2080 Ti 晶片重新焊上更高容量的顯存顆粒而成，出廠版本與批次品質各有差異，所以到貨後不能只是「跑個甜甜圈就收工」——顯存顆粒焊接與品質是最大的變數，而 GeForce 沒有 ECC，算錯不會當機，只會讓 TTS 出雜音、LLM 吐怪字，很容易被誤判成「模型爛掉」。這次照著先前建立的五關驗收流程走，重點放在顯存正確性與運算正確性這兩個「甜甜圈碰不到、卻能一票否決」的項目。第 1 關：身分驗證nvidia-smi 與 lspci 讀到的資訊如下，重點在確認這不是「刷 BIOS 的假卡」或「被切過匯流排的減料卡」：檢查項目讀到的值判定 Device ID0x1E07（TU102-300A，A 晶片）✅ 與 2080 Ti 官方一致 SM 數量68（torch 讀出）✅ 4,352 CUDA cores 未縮水 VRAM22,001 MiB 可用（原廠 11GB 改裝 22GB）✅ Power Limit260 W（上限 320 W）✅ 可正常解鎖 VBIOS90.02.42.00.0C✅ 可查到 Max Operating Temp89°C（Slowdown 91°C / Shutdown 94°C）⚠ 比 Ampere 卡低 4°C，餘裕以此為準 這台機器有兩個「看似異常其實正常」的現象：PCIe 顯示 Gen3 是對的（5700G 是 Cezanne APU，不支援 PCIe 4.0，這是 CPU 限制）；閒置時 gen.current 會掉到 1（ASPM 省電）。別誤判成故障。第 2 關：顯存正確性（30 分鐘）用 memtest_vulkan 跑 30 分鐘、22,357 輪，結果：錯誤 0，佔用 21,657 MiB（整張 22GB 覆蓋）。項目實測備註 錯誤數0一票否決項目，PASS 寫入頻寬466.5–471.9 GB/s（理論 616 的 76%）見下方說明 讀取驗證頻寬494.6–505.4 GB/s（81%） 顯存時脈7000 MHz 滿速Vulkan 走 P0 頻寬達成率 76% 比先前兩張 Ampere 卡（87–88%）低，但同為 Turing 架構的 2080 SUPER 在 memtest_vulkan 也只有寫入 73–79%（單一外部資料點），應屬架構差異，而非卡有問題。防偽判準（減料卡只能跑出約一半）遠遠通過。比較值得注意的是頻寬曲線：前 12 分鐘從 471.9 降到約 467（-1%），之後持平在 466.4–468.0，這段時間正好與升溫 37→80°C 重疊；溫度停、頻寬也停，判定為溫度效應而非持續劣化。但這波動是先前 3060 Ti（全距 0.05%）的 20 倍——GDDR6 有 EDC 重傳機制，訊號邊緣化時會先表現為頻寬下降而非錯誤。對手工換焊的改裝卡，這值得長期追蹤：日後重測時若熱機頻寬持續走低，就是劣化徵兆。第 3 關：運算正確性 + 熱穩定（10 分鐘）本機沒有 nvcc，改用 pytorch 容器做「先算參考答案、重複同運算位元比對」的方式，6,281 輪位元比對、錯誤 0。瞬時約 313–314 輪/30s ≈ 11,500 GFLOP/s（fp32，達理論 13.45 TFLOPS 的 86%，先前 3060 是 71%）。訊號實測判定 位元比對6,281 輪 / 錯誤 0✅ GPU 峰值溫度81°C（距 Max Operating 8°C）⚠ 通過但餘裕偏緊 功耗峰值 259 W（貼齊 260 W 牆）✅ 沒被改 BIOS SW Power Capping累積 >3600 s✅ 正常，就是吃滿牆 SW/HW Thermal Slowdown0✅ 風扇61%✅ 遠未到上限 散熱餘裕 8°C 是在九月、機殼開著的條件下量的，夏天關殼積灰後會更快吃完。訂製卡不論測試結果如何，換散熱膏與顯存墊都建議直接做——這是保養不是修理。意外發現：GPU 滿載會把 CPU 烤到 86°CGPU 滿載期間 CPU Tctl 85–86°C，而 CPU 幾乎閒置（load 1.4）。5700G Tjmax 95°C，只剩約 9°C 餘裕。原因：2080 Ti 是開放式下吹散熱設計，250W 的熱風直接灌進位在上方的 CPU 散熱器（現場確認風向）。影響有二：一是 GPU 忙碌時 CPU 端的工作（例如 SenseVoice ASR 跑在 CPU）可能撞 95°C 降頻，語音辨識延遲上升；二是若走「一台雙卡」方案會更糟（兩張卡約 450W 的熱都往 CPU 吹），這是評估「一台雙卡 vs 兩台分工」時的扣分項。待辦：確認機殼風道（CPU 散熱器出風是否對準後排風扇）、BIOS 調高機殼風扇曲線。服務層實測（換上 2080 Ti 22GB 後）服務3060 Ti 8G（舊）2080 Ti 22G（新） TTS RTF（n=50）0.240.25（幾乎持平，差異 TTS 串流首包1.27 s1.23–1.27 s TTS 顯存（frac 0.15）4,753 MiB5,000 MiB 文生圖 klein / schnell13.6 s / 28.9 s（2026-09-05 記錄）5.6 s / 12.8 s 本地 LLM 27B（qwen38）放不下46.7 tok/s（8K ctx、GPU 獨佔） 文生圖快了約 2.3 倍。最大的買點是：本地 LLM 27B 終於放得下，GPU 獨佔下 46.7 tok/s。對照雲端模型 TTFT 中位數約 428ms——本地合規率較高但延遲慢約 5 倍，適合批次任務，即時語音場景仍建議雲端。num_ctx 對生成速度測試（GPU 獨佔，Qwen3.8-27B，2026-09-17）num_ctx生成速度建議 8,19239.7 tok/s✅ 最快 16,38437.5 tok/s✅ 建議值 32,76830.3 tok/s✅ 仍可用 65,53618.9 tok/s⚠️ 掉 40% 131,0727.9 tok/s🔴 掉 79% 262,1446.0 tok/s🔴 掉 84% 規律：超過 32K 後大約每翻倍就砍半。整體效能（2026-09-16）生成速度範圍27.8–39.7 tok/s 首 token（/no_think）約 2.4 s 首 token（思考開啟）約 4.8 s 另外記錄兩點：2080 Ti（Turing, SM 7.5）上 vLLM 0.9.0 會自動降級（bf16→fp16、V1→V0、FlashAttention→XFormers），CUDA Graph 照常擷取，速度與 3060 Ti 相當；唯一硬限制是 TTS 容器的 vLLM 不可升級到已移除 V0 的版本，否則 Turing 無路可退。TTS 佔用 5,000 MiB 是 COSY_VLLM_GPU_FRAC=0.40 比例式配置的結果，不是模型變小。結論這張卡目前判定留用：顯存全數可用、零錯誤、運算正確，功耗牆與溫度牆都正常。要盯的是改裝卡特有的「熱機頻寬 -1% 後持平」現象——日後重測若持續走低即為劣化徵兆。散熱餘裕 8°C 偏緊，建議換膏保養，並留意 GPU 滿載時 CPU 會被烤到 86°C 的風道問題。訂製卡的本質是「用出廠品質的變異換 CP 值」：省下的錢買的是需要自己驗證、自己追蹤的健康度。驗收關卡（尤其顯存正確性）不能省，頻寬曲線與溫度餘裕留個紀錄，三個月後重測一次做對照，就能看出這張卡值不值得長期服役。 前言

    最近幫測試主機（Ryzen 7 5700G / Ubuntu）換上一張廠商標示為「全新訂製」的 RTX 2080 Ti 22GB 魔改卡，取代原本的 RTX 3060 Ti 8GB。這類訂製卡是供應商以 2080 Ti 晶片重新焊上更高容量的顯存顆粒而成，出廠版本與批次品質各有差異，所以到貨後不能只是「跑個甜甜圈就收工」——顯存顆粒焊接與品質是最大的變數，而 GeForce 沒有 ECC，算錯不會當機，只會讓 TTS 出雜音、LLM 吐怪字，很容易被誤判成「模型爛掉」。這次照著先前建立的五關驗收流程走，重點放在顯存正確性與運算正確性這兩個「甜甜圈碰不到、卻能一票否決」的項目。

    https://digiland.tw/uploads/3_20260919_175026_rtx2080ti22gb_report.jpg

    第 1 關：身分驗證

    nvidia-smi 與 lspci 讀到的資訊如下，重點在確認這不是「刷 BIOS 的假卡」或「被切過匯流排的減料卡」：
    檢查項目讀到的值判定
    Device ID0x1E07（TU102-300A，A 晶片）✅ 與 2080 Ti 官方一致
    SM 數量68（torch 讀出）✅ 4,352 CUDA cores 未縮水
    VRAM22,001 MiB 可用（原廠 11GB 改裝 22GB）✅
    Power Limit260 W（上限 320 W）✅ 可正常解鎖
    VBIOS90.02.42.00.0C✅ 可查到
    Max Operating Temp89°C（Slowdown 91°C / Shutdown 94°C）⚠ 比 Ampere 卡低 4°C，餘裕以此為準
    這台機器有兩個「看似異常其實正常」的現象：PCIe 顯示 Gen3 是對的（5700G 是 Cezanne APU，不支援 PCIe 4.0，這是 CPU 限制）；閒置時 gen.current 會掉到 1（ASPM 省電）。別誤判成故障。

    第 2 關：顯存正確性（30 分鐘）

    用 memtest_vulkan 跑 30 分鐘、22,357 輪，結果：錯誤 0，佔用 21,657 MiB（整張 22GB 覆蓋）。
    項目實測備註
    錯誤數0一票否決項目，PASS
    寫入頻寬466.5–471.9 GB/s（理論 616 的 76%）見下方說明
    讀取驗證頻寬494.6–505.4 GB/s（81%）
    顯存時脈7000 MHz 滿速Vulkan 走 P0
    頻寬達成率 76% 比先前兩張 Ampere 卡（87–88%）低，但同為 Turing 架構的 2080 SUPER 在 memtest_vulkan 也只有寫入 73–79%（單一外部資料點），應屬架構差異，而非卡有問題。防偽判準（減料卡只能跑出約一半）遠遠通過。

    比較值得注意的是頻寬曲線：前 12 分鐘從 471.9 降到約 467（-1%），之後持平在 466.4–468.0，這段時間正好與升溫 37→80°C 重疊；溫度停、頻寬也停，判定為溫度效應而非持續劣化。但這波動是先前 3060 Ti（全距 0.05%）的 20 倍——GDDR6 有 EDC 重傳機制，訊號邊緣化時會先表現為頻寬下降而非錯誤。對手工換焊的改裝卡，這值得長期追蹤：日後重測時若熱機頻寬持續走低，就是劣化徵兆。

    第 3 關：運算正確性 + 熱穩定（10 分鐘）

    本機沒有 nvcc，改用 pytorch 容器做「先算參考答案、重複同運算位元比對」的方式，6,281 輪位元比對、錯誤 0。瞬時約 313–314 輪/30s ≈ 11,500 GFLOP/s（fp32，達理論 13.45 TFLOPS 的 86%，先前 3060 是 71%）。
    訊號實測判定
    位元比對6,281 輪 / 錯誤 0✅
    GPU 峰值溫度81°C（距 Max Operating 8°C）⚠ 通過但餘裕偏緊
    功耗峰值 259 W（貼齊 260 W 牆）✅ 沒被改 BIOS
    SW Power Capping累積 >3600 s✅ 正常，就是吃滿牆
    SW/HW Thermal Slowdown0✅
    風扇61%✅ 遠未到上限
    散熱餘裕 8°C 是在九月、機殼開著的條件下量的，夏天關殼積灰後會更快吃完。訂製卡不論測試結果如何，換散熱膏與顯存墊都建議直接做——這是保養不是修理。

    意外發現：GPU 滿載會把 CPU 烤到 86°C

    GPU 滿載期間 CPU Tctl 85–86°C，而 CPU 幾乎閒置（load 1.4）。5700G Tjmax 95°C，只剩約 9°C 餘裕。原因：2080 Ti 是開放式下吹散熱設計，250W 的熱風直接灌進位在上方的 CPU 散熱器（現場確認風向）。

    影響有二：一是 GPU 忙碌時 CPU 端的工作（例如 SenseVoice ASR 跑在 CPU）可能撞 95°C 降頻，語音辨識延遲上升；二是若走「一台雙卡」方案會更糟（兩張卡約 450W 的熱都往 CPU 吹），這是評估「一台雙卡 vs 兩台分工」時的扣分項。

    待辦：確認機殼風道（CPU 散熱器出風是否對準後排風扇）、BIOS 調高機殼風扇曲線。

    服務層實測（換上 2080 Ti 22GB 後）
    服務3060 Ti 8G（舊）2080 Ti 22G（新）
    TTS RTF（n=50）0.240.25（幾乎持平，差異 <5%）
    TTS 串流首包1.27 s1.23–1.27 s
    TTS 顯存（frac 0.15）4,753 MiB5,000 MiB
    文生圖 klein / schnell13.6 s / 28.9 s（2026-09-05 記錄）5.6 s / 12.8 s
    本地 LLM 27B（qwen38）放不下46.7 tok/s（8K ctx、GPU 獨佔）
    文生圖快了約 2.3 倍。最大的買點是：本地 LLM 27B 終於放得下，GPU 獨佔下 46.7 tok/s。對照雲端模型 TTFT 中位數約 428ms——本地合規率較高但延遲慢約 5 倍，適合批次任務，即時語音場景仍建議雲端。

    num_ctx 對生成速度測試（GPU 獨佔，Qwen3.8-27B，2026-09-17）
    num_ctx生成速度建議
    8,19239.7 tok/s✅ 最快
    16,38437.5 tok/s✅ 建議值
    32,76830.3 tok/s✅ 仍可用
    65,53618.9 tok/s⚠️ 掉 40%
    131,0727.9 tok/s🔴 掉 79%
    262,1446.0 tok/s🔴 掉 84%
    規律：超過 32K 後大約每翻倍就砍半。

    整體效能（2026-09-16）
    生成速度範圍27.8–39.7 tok/s
    首 token（/no_think）約 2.4 s
    首 token（思考開啟）約 4.8 s
    另外記錄兩點：2080 Ti（Turing, SM 7.5）上 vLLM 0.9.0 會自動降級（bf16→fp16、V1→V0、FlashAttention→XFormers），CUDA Graph 照常擷取，速度與 3060 Ti 相當；唯一硬限制是 TTS 容器的 vLLM 不可升級到已移除 V0 的版本，否則 Turing 無路可退。TTS 佔用 5,000 MiB 是 COSY_VLLM_GPU_FRAC=0.40 比例式配置的結果，不是模型變小。

    結論

    這張卡目前判定留用：顯存全數可用、零錯誤、運算正確，功耗牆與溫度牆都正常。要盯的是改裝卡特有的「熱機頻寬 -1% 後持平」現象——日後重測若持續走低即為劣化徵兆。散熱餘裕 8°C 偏緊，建議換膏保養，並留意 GPU 滿載時 CPU 會被烤到 86°C 的風道問題。

    訂製卡的本質是「用出廠品質的變異換 CP 值」：省下的錢買的是需要自己驗證、自己追蹤的健康度。驗收關卡（尤其顯存正確性）不能省，頻寬曲線與溫度餘裕留個紀錄，三個月後重測一次做對照，就能看出這張卡值不值得長期服役。

    ]]>     Fri, 18 Sep 2026 16:09:23 +0800     Qwen3.8-27B 本地測試計畫 in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23006#p23006 23006@https://digiland.tw 前言本文整理 RTX 2080 Ti 22GB（改裝版）本地運行 Qwen3.8-27B 的測試計畫，包含環境配置、效能優化與進階加速（DFlash2 / 推測解碼）說明。文中亦補充筆者查證的模型背景與部署建議，供有興趣在消費級硬體上運行 27B 級模型的讀者參考。聲明：本文撰寫時，筆者訂購的 2080 Ti 22GB 魔改卡仍在運送途中，所有效能數字皆為理論估算與既有社群回報，尚未經筆者本機實測。待到貨完成壓力測試後，將另行補充實測結果。---一、模型與硬體摘要Qwen3.8-27B（官方資料，2026-08-14 開源）27B 稠密模型，Apache 2.0 開源授權。原生 262K 上下文窗口（可擴展至 1M），相較前代大幅提升。原生視覺能力（影像與影片理解），具備多模態潛力。預設啟用思考模式，支援 reasoning_effort 三檔（xhigh / medium / low）。官方標示 16GB+ 顯存即可本地運行（量化後）。測試硬體：RTX 2080 Ti 22GB（改裝版）TU102 核心、4352 CUDA、352-bit 匯流排（~616GB/s 記憶體頻寬）。顯存自原廠 11GB 改裝為 22GB（11 顆 2GB 顆粒）。模型權重（IQ4_XS）約 14.6GB，可 100% 載入 GPU VRAM，剩餘約 7.4GB 供 KV Cache 使用。二、基準數據參考（官方與第三方測評）| 指標 | Qwen3.8-27B | 前代 Qwen3.6-27B || DeepSWE 1.1 | 42.2 | 13.3 || Terminal Bench 2.1 | 73.0 | 63.4 |代理能力（Agentic）較前代大幅躍進，第三方測評於 SWE-bench Pro、OSWorld、AndroidWorld 等亦有亮眼表現。意涵：27B 規模足以承擔「工具呼叫」型工作負載，適合用於本機自動化任務。三、環境配置與啟動參數建議使用 llama-server 建立獨立推論服務，並啟用 Flash Attention 與 KV Cache 4-bit 量化： llama-server \ -m qwen3.8-27b-iq4_xs.gguf \ --n-gpu-layers 99 \ --ctx-size 32768 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --flash-attn四、效能優化設定預設配置下估算吐字速度為 12~18+ t/s；極限調優有機會推升至 22~28+ t/s。四個優化維度：1. 鎖定 Pinned Memory（--mlock）預設 llama.cpp 以 mmap 讀取模型，可能觸發分頁調度開銷。加上 --mlock 可將模型鎖定於實體記憶體，避免被換出至 Swap，維持 GPU 顯存補給穩定。2. 精準搭配 FlashAttention 與 CUDA KernelsTuring 架構（CC 7.5）處理非對稱量化開銷較大，指定 --flash-attn；KV Cache 量化建議選用原生 CUDA 加速格式（q4_0 / q8_0 / f16），避免非原生格式拖慢運算。3. 開啟推測解碼（Speculative Decoding / MTP）Qwen3.8 原生支援 Multi-Token Prediction（MTP）。掛載小 Draft 模型或啟用 --spec-draft-n-max 2，由小模型預測 2~3 個 token、主模型一次驗證，可將生成速度提升 25%~40%。4. 針對任務調整 Context 與 Thinking將 Context 自極限 64K 下調至實用的 16K~32K，能釋放 3~4GB VRAM 給 CUDA 動態批次；程式碼等專一任務可收斂思考預算（Reasoning Budget），改善長文本「前快後慢」現象。極限效能啟動範例（挑戰 20+ t/s） llama-server \ -m qwen3.8-27b-iq4_xs.gguf \ --n-gpu-layers 99 \ --ctx-size 32768 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --flash-attn \ --mlock \ --spec-draft-n-max 2五、進階加速：DFlash2 / 推測解碼核心邏輯：以極低計算開銷預測 token，減少主模型讀取顯存權重的次數。未啟用：GPU 每生成 1 token 需將 14.6GB 權重完整搬入核心一次（頻寬瓶頸）。啟用後：猜中 3 個 tokens 時，讀取一次權重即可同時輸出 3 個 tokens，顯存頻寬利用效率實質提升 2~3 倍。速度預估對比：模式/設定預估速度說明 原生 llama.cpp / MLX（無推測）12 ~ 18 t/s標準解碼，每次輸出 1 token 掛載 DFlash2 / MTP（2 Draft）25 ~ 38+ t/s猜中率約 60%~75%，速度翻倍 極致順暢（High Acceptance）40+ t/s結構化程式碼等高猜中率情境逼近極限 部署注意事項Draft 模型僅佔 0.5~1.5GB VRAM，22GB 下完全不構成壓力。Mac 環境以 MLX 框架整合；NVIDIA（Linux/Windows）透過 llama.cpp --spec-draft、或 vLLM / TensorRT-LLM / SGLang 啟動。六、筆者補充建議（上線前）魔改卡到貨先測再上線：建議先以 GPU-Z 確認 22528MB 顯存辨識正確，再跑 24 小時 VRAM 壓力測試，確認散熱與穩定性後，才正式投入推論服務。雙卡分工（若同時有第二張卡）：可讓 2080 Ti 22GB 專責 LLM 推論，將語音（TTS/ASR）等輕量任務導向另一張低功耗卡，避免互相干擾，整體服務更穩定。任務分流選用模型：本機 27B 模型適合例行性、固定流程的巡檢維運任務；重視正確性與文采的任務（如財經數據整理、對外文章）仍建議交由雲端較大模型處理，以兼顧成本與品質。七、總結在 RTX 2080 Ti 22GB 上啟用推測解碼，有機會在保有 100% 無損精確度的前提下，享受 30+ tokens/sec 的本機推論速度。對想以有限預算踏入本地 LLM 的讀者而言，此組合具備相當高的成本效益。本文為整理與規劃性質；實際硬體表現可能因賣家批次與韌體而異，歡迎讀者補充實測數據。 前言
    本文整理 RTX 2080 Ti 22GB（改裝版）本地運行 Qwen3.8-27B 的測試計畫，包含環境配置、效能優化與進階加速（DFlash2 / 推測解碼）說明。文中亦補充筆者查證的模型背景與部署建議，供有興趣在消費級硬體上運行 27B 級模型的讀者參考。

    https://digiland.tw/uploads/3_20260913_151532_rtx2080ti.jpg

    聲明：本文撰寫時，筆者訂購的 2080 Ti 22GB 魔改卡仍在運送途中，所有效能數字皆為理論估算與既有社群回報，尚未經筆者本機實測。待到貨完成壓力測試後，將另行補充實測結果。

    ---

    一、模型與硬體摘要

    Qwen3.8-27B（官方資料，2026-08-14 開源）
  • 27B 稠密模型，Apache 2.0 開源授權。
  • 原生 262K 上下文窗口（可擴展至 1M），相較前代大幅提升。
  • 原生視覺能力（影像與影片理解），具備多模態潛力。
  • 預設啟用思考模式，支援 reasoning_effort 三檔（xhigh / medium / low）。
  • 官方標示 16GB+ 顯存即可本地運行（量化後）。


    • 測試硬體：RTX 2080 Ti 22GB（改裝版）
  • TU102 核心、4352 CUDA、352-bit 匯流排（~616GB/s 記憶體頻寬）。
  • 顯存自原廠 11GB 改裝為 22GB（11 顆 2GB 顆粒）。
  • 模型權重（IQ4_XS）約 14.6GB，可 100% 載入 GPU VRAM，剩餘約 7.4GB 供 KV Cache 使用。


    • 二、基準數據參考（官方與第三方測評）

    | 指標 | Qwen3.8-27B | 前代 Qwen3.6-27B |
    | DeepSWE 1.1 | 42.2 | 13.3 |
    | Terminal Bench 2.1 | 73.0 | 63.4 |

  • 代理能力（Agentic）較前代大幅躍進，第三方測評於 SWE-bench Pro、OSWorld、AndroidWorld 等亦有亮眼表現。
  • 意涵：27B 規模足以承擔「工具呼叫」型工作負載，適合用於本機自動化任務。


    • 三、環境配置與啟動參數

    建議使用 llama-server 建立獨立推論服務，並啟用 Flash Attention 與 KV Cache 4-bit 量化：

    llama-server \ -m qwen3.8-27b-iq4_xs.gguf \ --n-gpu-layers 99 \ --ctx-size 32768 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --flash-attn


    四、效能優化設定

    預設配置下估算吐字速度為 12~18+ t/s；極限調優有機會推升至 22~28+ t/s。四個優化維度：

    1. 鎖定 Pinned Memory（--mlock）
    預設 llama.cpp 以 mmap 讀取模型，可能觸發分頁調度開銷。加上 --mlock 可將模型鎖定於實體記憶體，避免被換出至 Swap，維持 GPU 顯存補給穩定。

    2. 精準搭配 FlashAttention 與 CUDA Kernels
    Turing 架構（CC 7.5）處理非對稱量化開銷較大，指定 --flash-attn；KV Cache 量化建議選用原生 CUDA 加速格式（q4_0 / q8_0 / f16），避免非原生格式拖慢運算。

    3. 開啟推測解碼（Speculative Decoding / MTP）
    Qwen3.8 原生支援 Multi-Token Prediction（MTP）。掛載小 Draft 模型或啟用 --spec-draft-n-max 2，由小模型預測 2~3 個 token、主模型一次驗證，可將生成速度提升 25%~40%。

    4. 針對任務調整 Context 與 Thinking
    將 Context 自極限 64K 下調至實用的 16K~32K，能釋放 3~4GB VRAM 給 CUDA 動態批次；程式碼等專一任務可收斂思考預算（Reasoning Budget），改善長文本「前快後慢」現象。

    極限效能啟動範例（挑戰 20+ t/s）

    llama-server \ -m qwen3.8-27b-iq4_xs.gguf \ --n-gpu-layers 99 \ --ctx-size 32768 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --flash-attn \ --mlock \ --spec-draft-n-max 2


    五、進階加速：DFlash2 / 推測解碼

    核心邏輯：以極低計算開銷預測 token，減少主模型讀取顯存權重的次數。

  • 未啟用：GPU 每生成 1 token 需將 14.6GB 權重完整搬入核心一次（頻寬瓶頸）。
  • 啟用後：猜中 3 個 tokens 時，讀取一次權重即可同時輸出 3 個 tokens，顯存頻寬利用效率實質提升 2~3 倍。


    • 速度預估對比：
    模式/設定預估速度說明
    原生 llama.cpp / MLX（無推測）12 ~ 18 t/s標準解碼，每次輸出 1 token
    掛載 DFlash2 / MTP（2 Draft）25 ~ 38+ t/s猜中率約 60%~75%，速度翻倍
    極致順暢（High Acceptance）40+ t/s結構化程式碼等高猜中率情境逼近極限
    部署注意事項
  • Draft 模型僅佔 0.5~1.5GB VRAM，22GB 下完全不構成壓力。
  • Mac 環境以 MLX 框架整合；NVIDIA（Linux/Windows）透過 llama.cpp --spec-draft、或 vLLM / TensorRT-LLM / SGLang 啟動。


    • 六、筆者補充建議（上線前）

  • 魔改卡到貨先測再上線：建議先以 GPU-Z 確認 22528MB 顯存辨識正確，再跑 24 小時 VRAM 壓力測試，確認散熱與穩定性後，才正式投入推論服務。
  • 雙卡分工（若同時有第二張卡）：可讓 2080 Ti 22GB 專責 LLM 推論，將語音（TTS/ASR）等輕量任務導向另一張低功耗卡，避免互相干擾，整體服務更穩定。
  • 任務分流選用模型：本機 27B 模型適合例行性、固定流程的巡檢維運任務；重視正確性與文采的任務（如財經數據整理、對外文章）仍建議交由雲端較大模型處理，以兼顧成本與品質。

    • https://digiland.tw/uploads/3_20260913_150929_qwen_38_27b_.jpg
    七、總結
    在 RTX 2080 Ti 22GB 上啟用推測解碼，有機會在保有 100% 無損精確度的前提下，享受 30+ tokens/sec 的本機推論速度。對想以有限預算踏入本地 LLM 的讀者而言，此組合具備相當高的成本效益。

    本文為整理與規劃性質；實際硬體表現可能因賣家批次與韌體而異，歡迎讀者補充實測數據。

    ]]>     Tue, 15 Sep 2026 21:06:41 +0800     淘寶 2080 Ti「22GB 魔改卡」採購指南 in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23005#p23005 23005@https://digiland.tw 前言近年台灣技術圈對「淘寶上的 RTX 2080 Ti 22GB 魔改卡」討論度上升，主因是本地 AI 需求（LLM 推理、Stable Diffusion / Flux 生圖）對 VRAM 的胃口愈來愈大，而消費級新卡的顯存規格普遍停滯而且價格因 AI 熱度也跟著水漲船高。本文整理採購前應先搞懂的關鍵事實，供有意入手的讀者參考。注意：本文撰寫時，筆者訂購的 2080 Ti 22GB 魔改卡仍在運送途中，文中所有性能與溫度數據皆引用社群既有回報，尚未經筆者本機實測驗證；待顯示卡到貨並完成壓力測試後，將另行補充實測章節。一、魔改卡的本質：顯存翻倍，而非效能升級RTX 2080 Ti 原廠規格為 11GB（TU102-300A 核心、4352 CUDA 核心、352-bit 匯流排、11 顆 1GB GDDR6）。所謂魔改，是將 11 顆 1GB 顆粒更換為 11 顆 2GB 顆粒，使總顯存達 22GB。此作業需進行 BGA 拆焊、植球，並刷寫對應的 VBIOS。關鍵在於：記憶體匯流排寬度維持不變（352-bit，約 616GB/s）。因此，這張卡的定位是「裝得下較大的模型」，而非「運算更快」。以量化推理為例：第三方社群回報使用者以 LM Studio 執行 Qwen3.6 27B Q4，約 18~22 token/s、GPU 溫度約 70°C（此數據尚未經筆者實測，待到手後補充第一手結果）。二、保固與品質：二手改裝品，風險自負魔改卡以二手拆機的 2080 Ti 為基礎改裝，沒有原廠保固，多由賣家提供店保一年，退換條件差異極大。建議選購要點：優先選擇三風扇版本（渦輪版散熱較差，實測常達 85~90°C 且噪音明顯）。要求賣家提供 GPU-Z 截圖，確認系統辨識為 22528MB 顯存。確認供電規格（「滿供電」款較穩定）、VBIOS 版本。到貨後務必先進行 24 小時 VRAM 壓力測試，再投入正式使用。三、22GB 的 VRAM 恰好對應常見 AI 工作負載任務約需 VRAM 7B Q4 對話~5GB 13B Q4~8GB 27B Q4（Qwen3.6 等）~15.7GB 32B Q2~Q4~16-18GB Flux dev 生圖（20 步）~16-18GB 由表可見，22GB 可涵蓋 27B Q4 本地推理與 Flux dev 生圖兩大常見需求。消費級新卡在 16~24GB 區間幾乎無選項（該區段多由工作站卡佔據），魔改卡因此填補了價格與容量之間的空隙。四、風險清單散熱：渦輪版高溫高噪，需三風扇或良好機殼通風。VBIOS：若未正確刷寫，可能無法辨識完整顯存，甚至無法開機。顆粒品質：二手顆粒之長期壽命無保證。供電：建議確認賣家供電規格，避免不穩。保固：僅店保，需自行確認條件。結論若目標是「在約一萬五千元台幣預算內，於本機運行 27B LLM 推理與 Flux 生圖」，則 RTX 2080 Ti 22GB 魔改卡是目前 CP 值較高的選項之一——同等 VRAM 的 NVIDIA 專業卡價格高出數倍。選擇三風扇、滿供電之版本，到貨後完成壓力測試再上線，即可投入日常使用。本文為資料整理性質，實際硬體表現可能因賣家批次而異，歡迎讀者補充實測數據。 前言
    近年台灣技術圈對「淘寶上的 RTX 2080 Ti 22GB 魔改卡」討論度上升，主因是本地 AI 需求（LLM 推理、Stable Diffusion / Flux 生圖）對 VRAM 的胃口愈來愈大，而消費級新卡的顯存規格普遍停滯而且價格因 AI 熱度也跟著水漲船高。本文整理採購前應先搞懂的關鍵事實，供有意入手的讀者參考。

    https://digiland.tw/uploads/3_20260919_174710_taobao_rtx2080ti22gb_servey.jpg

    注意：本文撰寫時，筆者訂購的 2080 Ti 22GB 魔改卡仍在運送途中，文中所有性能與溫度數據皆引用社群既有回報，尚未經筆者本機實測驗證；待顯示卡到貨並完成壓力測試後，將另行補充實測章節。

    一、魔改卡的本質：顯存翻倍，而非效能升級

    RTX 2080 Ti 原廠規格為 11GB（TU102-300A 核心、4352 CUDA 核心、352-bit 匯流排、11 顆 1GB GDDR6）。所謂魔改，是將 11 顆 1GB 顆粒更換為 11 顆 2GB 顆粒，使總顯存達 22GB。此作業需進行 BGA 拆焊、植球，並刷寫對應的 VBIOS。
    關鍵在於：記憶體匯流排寬度維持不變（352-bit，約 616GB/s）。因此，這張卡的定位是「裝得下較大的模型」，而非「運算更快」。
    以量化推理為例：第三方社群回報使用者以 LM Studio 執行 Qwen3.6 27B Q4，約 18~22 token/s、GPU 溫度約 70°C（此數據尚未經筆者實測，待到手後補充第一手結果）。

    二、保固與品質：二手改裝品，風險自負

    魔改卡以二手拆機的 2080 Ti 為基礎改裝，沒有原廠保固，多由賣家提供店保一年，退換條件差異極大。
    建議選購要點：
  • 優先選擇三風扇版本（渦輪版散熱較差，實測常達 85~90°C 且噪音明顯）。
  • 要求賣家提供 GPU-Z 截圖，確認系統辨識為 22528MB 顯存。
  • 確認供電規格（「滿供電」款較穩定）、VBIOS 版本。
  • 到貨後務必先進行 24 小時 VRAM 壓力測試，再投入正式使用。


    • 三、22GB 的 VRAM 恰好對應常見 AI 工作負載
    任務約需 VRAM
    7B Q4 對話~5GB
    13B Q4~8GB
    27B Q4（Qwen3.6 等）~15.7GB
    32B Q2~Q4~16-18GB
    Flux dev 生圖（20 步）~16-18GB
    由表可見，22GB 可涵蓋 27B Q4 本地推理與 Flux dev 生圖兩大常見需求。消費級新卡在 16~24GB 區間幾乎無選項（該區段多由工作站卡佔據），魔改卡因此填補了價格與容量之間的空隙。

    四、風險清單

  • 散熱：渦輪版高溫高噪，需三風扇或良好機殼通風。
  • VBIOS：若未正確刷寫，可能無法辨識完整顯存，甚至無法開機。
  • 顆粒品質：二手顆粒之長期壽命無保證。
  • 供電：建議確認賣家供電規格，避免不穩。
  • 保固：僅店保，需自行確認條件。


    • 結論

    若目標是「在約一萬五千元台幣預算內，於本機運行 27B LLM 推理與 Flux 生圖」，則 RTX 2080 Ti 22GB 魔改卡是目前 CP 值較高的選項之一——同等 VRAM 的 NVIDIA 專業卡價格高出數倍。選擇三風扇、滿供電之版本，到貨後完成壓力測試再上線，即可投入日常使用。

    本文為資料整理性質，實際硬體表現可能因賣家批次而異，歡迎讀者補充實測數據。

    ]]>     Sun, 13 Sep 2026 00:22:08 +0800     小米配蕃茄!? 小米路由器 R1D 首刷中文 Tomato in 數位天堂 : Tomato firmware 討論區 https://digiland.tw/viewtopic.php?pid=23004#p23004 23004@https://digiland.tw 感謝中文化，值得收藏，謝謝分享! 感謝中文化，值得收藏，謝謝分享!thankgod

    ]]>     Tue, 04 Aug 2026 06:19:00 +0800     某知名路由器暗藏後門？請自行檢查驗證 in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=23003#p23003 23003@https://digiland.tw

    ]]>     Mon, 20 Jul 2026 21:28:36 +0800     AMB82 Mini 版本小智 Demo in 創客天堂 : DIY創客專區 https://digiland.tw/viewtopic.php?pid=23001#p23001 23001@https://digiland.tw 沒有語音喚醒音量也太小還需要音源放大還有許多問題尚待解決，完整度約 87%但是使用國產 MCU 就是爽!!#realtek #amb82mini #xiaozhi #xiaozhi-esp32 沒有語音喚醒
    音量也太小還需要音源放大
    還有許多問題尚待解決，完整度約 87%

    但是使用國產 MCU 就是爽!!
    #realtek #amb82mini #xiaozhi #xiaozhi-esp32

    ]]>     Sun, 26 Apr 2026 15:28:42 +0800     大改謎謎蝦🦐（MimiClaw） in 創客天堂 : DIY創客專區 https://digiland.tw/viewtopic.php?pid=23000#p23000 23000@https://digiland.tw 大改謎謎蝦🦐（MimiClaw）基於 ESP32-S3 的本地 AI 助理，主要新增修改：支援 OpenRouter 多模型路由（Claude、Gemini、MiniMax...隨時切換）狀態列顯示目前使用 Model、Provider、IP 等資訊新增 320×480 TFT LCD 支援，WeChat 風格即時對話泡泡支援中文、日文顯示（思源黑體 CJK 字型）維持原有功能：Telegram 對話、排程提醒、Web 搜尋、GPIO 控制開源在 GitHub，歡迎試試看或給個 ⭐https://github.com/twtomato/mimiclaw-lcd#MimiClaw 大改謎謎蝦🦐（MimiClaw）

    基於 ESP32-S3 的本地 AI 助理，主要新增修改：
  • 支援 OpenRouter 多模型路由（Claude、Gemini、MiniMax...隨時切換）
  • 狀態列顯示目前使用 Model、Provider、IP 等資訊
  • 新增 320×480 TFT LCD 支援，WeChat 風格即時對話泡泡
  • 支援中文、日文顯示（思源黑體 CJK 字型）
  • 維持原有功能：Telegram 對話、排程提醒、Web 搜尋、GPIO 控制

    • https://digiland.tw/uploads/3_mimiclaw.jpg

    開源在 GitHub，歡迎試試看或給個 ⭐
    https://github.com/twtomato/mimiclaw-lcd

    #MimiClaw

    ]]>     Tue, 31 Mar 2026 11:55:02 +0800     ESP32 ESP-NOW SyncDraw 同步繪圖 in 創客天堂 : DIY創客專區 https://digiland.tw/viewtopic.php?pid=22995#p22995 22995@https://digiland.tw 這是兩年前做的專案，當時沉迷於 ESP-NOW 技術，所以常常腦動大開，想一些奇奇怪怪的應用，這是其中之一種應用。利用 ESP-NOW 傳輸技術，能夠同時在多個裝置上顯示手寫或繪製內容的系統。A system that synchronizes handwritten or drawn content across multiple devices using ESP-NOW.Github連結: https://github.com/twtomato/SyncDraw其他應用: ESP32 ESP-NOW 搖桿 這是兩年前做的專案，當時沉迷於 ESP-NOW 技術，所以常常腦動大開，想一些奇奇怪怪的應用，這是其中之一種應用。

    利用 ESP-NOW 傳輸技術，能夠同時在多個裝置上顯示手寫或繪製內容的系統。

    A system that synchronizes handwritten or drawn content across multiple devices using ESP-NOW.

    Github連結: https://github.com/twtomato/SyncDraw
    其他應用: ESP32 ESP-NOW 搖桿

    ]]>     Thu, 12 Mar 2026 16:43:33 +0800     手搓春嬌AI機器人 in 創客天堂 : DIY創客專區 https://digiland.tw/viewtopic.php?pid=22993#p22993 22993@https://digiland.tw 玩了一陣子的小智AI機器人，一直想替換喚醒詞，查了網上資料才知道是有難度的，山不轉路轉，只好自己手搓語音辨識喚醒她 做法: 我加了一組SU-03T語音辨識模組，自行加入想要的喚醒詞，當SU-03T辨識到喚醒詞時，會觸發指定的引腳送低電壓信號給ESP32 GPIO0，這時我的"春嬌"機器人就會醒來 以下是 Demo 影片影片連結: https://www.youtube.com/shorts/8OnAcNeKXoE 玩了一陣子的小智AI機器人，一直想替換喚醒詞，查了網上資料才知道是有難度的，山不轉路轉，只好自己手搓語音辨識喚醒她 milk

    做法: 我加了一組SU-03T語音辨識模組，自行加入想要的喚醒詞，當SU-03T辨識到喚醒詞時，會觸發指定的引腳送低電壓信號給ESP32 GPIO0，這時我的"春嬌"機器人就會醒來 YA

    以下是 Demo 影片

    影片連結: https://www.youtube.com/shorts/8OnAcNeKXoE

    ]]>     Sat, 05 Jul 2025 00:24:43 +0800     [測試] RT-N16 100M NAT 效能大考驗 in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=22992#p22992 22992@https://digiland.tw 最近N16不穩定，先拿N18頂先，應該會很有感才對。 最近N16不穩定，先拿N18頂先，應該會很有感才對。

    ]]>     Thu, 24 Apr 2025 18:56:58 +0800     RT-N16 官方新版韌體 ASUSWRT RT-N16_3.0.0.x in 創客天堂 : 硬體及網路技術綜合討論區 https://digiland.tw/viewtopic.php?pid=22991#p22991 22991@https://digiland.tw 可以試試看先刷Tomato，讓舊機有機會再重生了。 可以試試看先刷Tomato，讓舊機有機會再重生了。

    ]]>     Thu, 24 Apr 2025 18:42:57 +0800     Tomato 後續延伸版本 FreshTomato in 數位天堂 : Tomato firmware 討論區 https://digiland.tw/viewtopic.php?pid=22990#p22990 22990@https://digiland.tw 試問 有Ac66u 可用中文話軟件嗎？！ 我試過都無法使用。 試問 有Ac66u 可用中文話軟件嗎？！ 我試過都無法使用。

    ]]>     Thu, 24 Apr 2025 12:16:30 +0800