Tiel-Coder 35B-A3B RX 6800M पर: MTP बनाम non-MTP 262K पर – VelsTech Lab

🧪 VelsTech Lab 35B-A3B MoE मॉडल पर मल्टी-टोकन प्रेडिक्शन (MTP) के माध्यम से स्पेक्युलेटिव डिकोडिंग – क्या ड्राफ्ट हेड 12 GB मोबाइल GPU पर 28+ CPU एक्सपर्ट फ़ॉलबैक के साथ वास्तव में गति बढ़ाता है?

🔧 पहले अपनी फ़िट जाँचें

LLM VRAM कैलकुलेटर – क्या 35B Q4 + 262K आपके VRAM में फ़िट बैठता है? · GPU AI परफ़ॉर्मेंस कैलकुलेटर – चलाने से पहले किस tok/s की उम्मीद करें।

कैलकुलेटर खोलें →

दो बिल्ड का परीक्षण

मशीन: R9 5900HX (8C/16T) · AMD RX 6800M 12GB (RDNA2, मोबाइल) · 32 GB RAM · Ubuntu 26.04 · ROCm 10.0 · llama.cpp (वर्तमान बिल्ड)
मॉडल (बिना MTP): Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf – कुल 35B, 3B सक्रिय MoE, Q4_K_XL क्वांट
मॉडल (MTP): Tiel-Coder-35B-A3B-MTP-UD-Q4_K_XL.gguf – वही मॉडल मल्टी-टोकन प्रेडिक्शन ड्राफ्ट हेड के साथ
कॉन्टेक्स्ट: -c 262144 और --cache-type-k q8_0 --cache-type-v q8_0 -fa on
ऑफ़लोड: -ngl 999 (फ़ोर्स्ड – नीचे चेतावनी देखें)
CPU एक्सपर्ट: --n-cpu-moe 28 (बिना MTP) बनाम --n-cpu-moe 32 (MTP) – मामूली अंतर पर ध्यान दें
प्रॉम्प्ट: ~608-617 टोकन (दोनों रन में एक ही प्रॉम्प्ट), n_threads=8, kv_unified=false, n_slots=1, n_ctx_slot=262144

हमने इसे कैसे चलाया

Run 1 – बिना MTP

export LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH
llama-server \
 -m /home/user-name/models/Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf \
 -ngl 999 \
 --n-cpu-moe 28 \
 --cache-type-k q8_0 \
 --cache-type-v q8_0 \
 -c 262144 -fa on \
 --jinja --parallel 1

Run 2 – MTP स्पेक्युलेटिव डिकोडिंग

export LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH
llama-server \
 -m /home/user-name/models/Tiel-Coder-35B-A3B-MTP-UD-Q4_K_XL.gguf \
 --spec-type draft-mtp \
 -ngl 999 \
 --n-cpu-moe 32 \
 --cache-type-k q8_0 \
 --cache-type-v q8_0 \
 -c 262144 -fa on \
 --jinja --reasoning-preserve --parallel 1

हमने क्या मापा

Run 1 – बिना MTP (--n-cpu-moe 28)

prompt eval:   5220.06 ms / 621 tokens (  8.41 ms/tok,  118.96 tok/s)
eval (decode): 5155.86 ms / 132 tokens ( 39.36 ms/tok,   25.41 tok/s)
generate:      100 tokens @ 25.39 tok/s (tg), 25.65 tok/s (tg_3s)
total:         10375.93 ms / 753 tokens
graphs reused: 131

Run 2 – MTP (--spec-type draft-mtp, --n-cpu-moe 32)

prompt eval:   5574.58 ms / 621 tokens (  8.98 ms/tok,  111.40 tok/s)
eval (decode): 5105.25 ms / 131 tokens ( 39.27 ms/tok,   25.46 tok/s)
generate:      100 tokens @ 29.09 tok/s (tg), 29.38 tok/s (tg_3s)
draft:         acceptance = 0.54667 (82 accepted / 150 generated), mean len = 2.64
total:         10679.83 ms / 752 tokens
graphs reused: 50

आमने-सामने तुलना

Metric               No MTP              MTP           Delta
─────────────────────────────────────────────────────────────
Prompt eval          118.96 tok/s       111.40 tok/s    -6.4%
Decode (slot)        25.41 tok/s         25.46 tok/s    +0.2%
Generate (tg)        25.39 tok/s         29.09 tok/s   +14.6%
Generate (tg_3s)     25.65 tok/s         29.38 tok/s   +14.5%
Total time           10.38 s             10.68 s        +3.0%
Graphs reused         131                  50            -62%
Draft acceptance      –                    54.7%          –
Mean len              –                     2.64          –

निष्कर्ष: MTP स्पेक्युलेटिव डिकोडिंग 35B-A3B MoE मॉडल पर +14.6% डिकोड स्पीडअप (25.39 → 29.09 tok/s) देता है। ड्राफ्ट हेड अपनी 55% भविष्यवाणियों को 2.64 टोकन की औसत लंबाई के साथ स्वीकार करता है। Graphs reused 62% घट जाते हैं (131 → 50) क्योंकि ड्राफ्ट कॉन्टेक्स्ट कम कैश्ड ग्राफ़ एक्सीक्यूशन का पुनः उपयोग करता है। प्रॉम्प्ट eval में मामूली कमी (-6.4%) आती है, जो अतिरिक्त MTP कॉन्टेक्स्ट के कारण है। ध्यान दें कि --n-cpu-moe भी भिन्न है (28 बनाम 32) – MTP रन में 4 अतिरिक्त CPU एक्सपर्ट थ्रेड्स का लाभ के एक छोटे हिस्से में योगदान हो सकता है।

लॉग्स ने क्या कहा – और क्या टूटा

दोनों रन: W common_fit_params: failed to fit params to free device memory: n_gpu_layers already set by user to 999, abort – आपने 12 GB कार्ड पर -ngl 999 फ़ोर्स किया, इसलिए आंशिक CPU ऑफ़लोड अपरिहार्य है। मॉडल Q4 में 35B (~17.5 GB वज़न) + q8 KV 262K (~12 GB+) है – 12 GB में फ़िट होना असंभव है। अधिकांश MoE एक्सपर्ट गणनाएँ --n-cpu-moe के माध्यम से CPU पर फ़ॉलबैक करती हैं।
दोनों रन: W tensor overrides to CPU are used with mmap enabled – consider using --load-mode none for better performance – कुछ टेंसर ओवरराइड्स CPU फ़ॉलबैक फ़ोर्स करते हैं। --load-mode none mmap को अलग करके प्रदर्शन में सुधार कर सकता है।
केवल MTP रन: W device 'ROCm0' does not have support for op TOP_K needed for sampler 'top-k' – MTP ड्राफ्ट सैम्पलर के लिए प्रासंगिक; ड्राफ्ट गुणवत्ता को प्रभावित कर सकता है। 54.7% स्वीकृति दर ऐसे बैकएंड से बेहतर हो सकती है जो top-k मूलतः सपोर्ट करता है।
केवल MTP रन: I common_speculative_init_result: creating MTP draft context against the target model '...MTP-UD-Q4_K_XL.gguf' – MTP अपना स्वयं का ड्राफ्ट कॉन्टेक्स्ट बनाता है, जो इनिशियलाइज़ेशन समय में ~200ms जोड़ता है (प्रॉम्प्ट eval समय में थोड़ी वृद्धि में दिखाई देता है)।
मुख्य अंतर: --n-cpu-moe 28 (बिना MTP) बनाम --n-cpu-moe 32 (MTP) – यह 4-थ्रेड का अंतर एक कन्फ़ाउंड है। दोनों को समान मान के साथ पुनः चलाने से केवल MTP लाभ को अलग किया जा सकेगा।

निचली पंक्ति

RX 6800M 12GB पर 262K q8 KV पर, इस 35B-A3B MoE मॉडल के लिए MTP ड्राफ्ट हेड +14.6% का सार्थक डिकोड स्पीडअप प्रदान करता है, जो डिकोड को 25.4 से 29.1 tok/s तक बढ़ा देता है। ओवरहेड न्यूनतम है (कुल समय में 3% अधिक, प्रॉम्प्ट eval में 6% धीमा)। चूँकि --n-cpu-moe भी भिन्न था, वास्तविक MTP-मात्र लाभ संभवतः थोड़ा कम है – इसे ~10-12% शुद्ध कह सकते हैं। यदि आपका बैकएंड MTP सैम्पलर के लिए top-k समर्थन करता है, तो स्वीकृति दरें और बेहतर हो सकती हैं। चैट वर्कलोड (डिकोड-बाउंड) के लिए, MTP उन सभी MoE मॉडलों पर सक्षम करने लायक है जो ड्राफ्ट हेड के साथ आते हैं।

🧪 और अधिक Lab

अगला: दोनों को समान --n-cpu-moe और --load-mode none के साथ पुनः चलाकर शुद्ध MTP लाभ को अलग करें, फिर Vulkan बैकएंड पर परीक्षण करें जहाँ top-k समर्थन भिन्न है।

VelsTech Lab पर वापस जाएँ →