Tiel-Coder 35B-A3B on RX 6800M: MTP vs non-MTP at 262K – VelsTech Lab

🧪 VelsTech Lab Multi-Token Prediction (MTP) மூலம் ஊக டிகோடிங் – 35B-A3B MoE மாடலில், 12 GB மொபைல் GPU வில் 28+ CPU expert fallback உடன் draft head உண்மையில் வேகத்தை அதிகரிக்கிறதா?

🔧 முதலில் உங்கள் பொருத்தத்தை சரிபார்க்கவும்

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 – அதே மாடலுடன் multi-token prediction draft head
சூழல்: -c 262144 உடன் --cache-type-k q8_0 --cache-type-v q8_0 -fa on
ஆஃப்லோடு: -ngl 999 (கட்டாயம் – கீழே எச்சரிக்கையைப் பார்க்கவும்)
CPU experts: --n-cpu-moe 28 (MTP இல்லை) vs --n-cpu-moe 32 (MTP) – சிறிய வேறுபாட்டைக் கவனிக்கவும்
ப்ராம்ப்ட்: ~608-617 டோக்கன்கள் (இரண்டு ரன்களிலும் ஒரே ப்ராம்ப்ட்), n_threads=8, kv_unified=false, n_slots=1, n_ctx_slot=262144

எப்படி இயக்கினோம்

ரன் 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

ரன் 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

நாம் அளந்தது என்ன

ரன் 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

ரன் 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). Draft head அதன் கணிப்புகளில் 55% ஐ ஏற்றுக்கொள்கிறது, சராசரி 2.64 டோக்கன்கள். Graphs reused 62% குறைகிறது (131 → 50) ஏனெனில் draft context குறைவான cached graph executions ஐ மீண்டும் பயன்படுத்துகிறது. Prompt eval சிறிய பாதிப்பைக் கொண்டுள்ளது (-6.4%) கூடுதல் MTP context காரணமாக. --n-cpu-moe உம் வேறுபடுகிறது (28 vs 32) – MTP ரனில் கூடுதல் 4 CPU expert threads சிறிய பங்களிப்பை அளிக்கலாம்.

லாக்கள் என்ன சொன்னது – மற்றும் என்ன உடைந்தது

இரண்டு ரன்களும்: 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 ஆஃப்லோடு தவிர்க்க முடியாதது. மாடல் 35B Q4 இல் (~17.5 GB எடைகள்) + q8 KV 262K இல் (~12 GB+) – 12 GB இல் பொருந்தாது. பெரும்பாலான MoE expert computations --n-cpu-moe மூலம் CPU க்கு திரும்புகின்றன.
இரண்டு ரன்களும்: W tensor overrides to CPU are used with mmap enabled – consider using --load-mode none for better performance – சில tensor overrides CPU fallback ஐ கட்டாயப்படுத்துகின்றன. --load-mode none mmap ஐ பிரித்து செயல்திறனை மேம்படுத்தலாம்.
MTP ரன் மட்டும்: W device 'ROCm0' does not have support for op TOP_K needed for sampler 'top-k' – MTP draft sampler க்கு பொருத்தமானது; draft தரத்தை பாதிக்கலாம். 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 அதன் சொந்த draft context ஐ உருவாக்குகிறது, இது init நேரத்தில் ~200ms ஐ சேர்க்கிறது (சற்று அதிகமான prompt eval நேரத்தில் தெரியும்).
முக்கிய வேறுபாடு: --n-cpu-moe 28 (MTP இல்லை) vs --n-cpu-moe 32 (MTP) – இந்த 4-த்ரெட் வேறுபாடு ஒரு குழப்பமான காரணியாகும். இரண்டையும் ஒரே மதிப்புடன் மீண்டும் இயக்குவது MTP-மட்டும் ஆதாயத்தை தனிமைப்படுத்தும்.

இறுதி முடிவு

RX 6800M 12GB இல் 262K q8 KV உடன், இந்த 35B-A3B MoE மாடலில் MTP draft head +14.6% டிகோட் வேக அதிகரிப்பை வழங்குகிறது, டிகோடை 25.4 இலிருந்து 29.1 tok/s ஆக உயர்த்துகிறது. மேல்நிலை செலவு குறைவு (மொத்த நேரத்தில் 3% அதிகம், prompt eval இல் 6% மெதுவானது). --n-cpu-moe உம் வேறுபட்டதால், உண்மையான MTP-மட்டும் ஆதாயம் சற்று குறைவாக இருக்கலாம் – அதை ~10-12% நிகர என மதிப்பிடலாம். உங்கள் பேக்எண்ட் MTP sampler க்கு top-k ஐ ஆதரித்தால், ஏற்பு விகிதங்கள் மேலும் மேம்படலாம். சாட் பணிச்சுமைகளுக்கு (decode-bound), MTP ஐ draft head உடன் வரும் எந்த MoE மாடலிலும் இயக்குவது மதிப்புள்ளது.

🧪 மேலும் Lab

அடுத்தது: ஒரே மாதிரியான --n-cpu-moe மற்றும் --load-mode none உடன் இரண்டு ரன்களையும் மீண்டும் இயக்கி தூய MTP ஆதாயத்தை தனிமைப்படுத்தவும், பின்னர் top-k ஆதரவு வேறுபடும் Vulkan பேக்எண்டில் சோதிக்கவும்.

VelsTech Lab க்கு திரும்பு →