# MoE vs Dense on RX 6800M: 3B Active vs 27B at 16K/262K – VelsTech Lab

> Same RX 6800M 12GB – Ornith 35B MoE (3B active, 262K) vs Qwen 27B dense (27B, 16K) at q8 KV, ROCm vs Vulkan head-to-head.

*Source: https://velstech.net/moe-vs-dense-rx6800m-16k-vs-262k.hi (Hindi translation of https://velstech.net/moe-vs-dense-rx6800m-16k-vs-262k) · Updated: 2026-08-27*

*Markdown version. [Read the interactive guide](https://velstech.net/moe-vs-dense-rx6800m-16k-vs-262k.hi). English Markdown: https://velstech.net/moe-vs-dense-rx6800m-16k-vs-262k.md.*

---

🧪 VelsTech Lab एक ही card, एक ही engine, scale करने के दो विपरीत तरीके: Qwen 27B dense 16K पर बनाम Ornith 35B-A3B MoE (3B active) 262K पर, दोनों q8 KV पर 12GB RX 6800M पर। कौन जीतेगा यह इस पर निर्भर करता है कि आप क्या पूछते हैं बनाम आप कितना generate करते हैं।

🔧 अपने model के लिए गणित दोहराएँ

MoE: *active* params (35B नहीं, 3B) + custom KV दर्ज करें। Dense: पूरे params दर्ज करें। `q8_0` vs `f16` को ईमानदारी से रखें।

[LLM VRAM Calculator →](https://velstech.net/llm-vram-calculator) [GPU Performance →](https://velstech.net/gpu-ai-calculator)

## दोनों runs आमने-सामने

एक ही GPU **RX 6800M 12GB** (~384 GB/s), एक ही `q8_0` KV, एक ही `n_threads=8`, एक ही 335-373 prompt tokens। केवल model + context + MoE offload अलग हैं।

```
Model               Params   Context  KV type  Offload          Build   Prompt eval          Decode tg          Total
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Qwen 27B Ridge       27B dense  16K   q8_0     -ngl 999 (+fit abort)  ROCm    1713 ms /373 = 217.6 tok/s   18.12 tok/s   14.23s /601 tok
3.7bpw Ridge                                                Vulkan  2493 ms /373 = 149.6 tok/s   21.84 tok/s   13.57s /616 tok

Ornith 35B-A3B MoE   35B/3B*    262K  q8_0     --n-cpu-moe 28        ROCm    3995 ms /335 = 83.8 tok/s    25.62 tok/s   14.65s /609 tok
Q5_K/Q4_K mix               kv_unified=false              Vulkan  4029 ms /335 = 83.1 tok/s    19.66 tok/s   19.59s /642 tok
* 35B total, 3B active – MoE decodes 3B, not 35B.
```

पहली दो पंक्तियाँ: [Qwen 27B 16K full report](https://velstech.net/qwen-27b-ridge-rocm-vs-vulkan); आखिरी दो: [Ornith 35B 262K full report](https://velstech.net/ornith-35b-moe-262k-rocm-vs-vulkan)। सभी `-c` reserved KV, `fa on`, 373/335 prompt tokens, ~600 gen tokens पर।

## वास्तव में क्या हुआ

- Decode scale पर MoE की जीत है, लेकिन हर जगह नहीं। 16K dense पर Vulkan +20% जीतता है (21.84 बनाम 18.12)। 262K MoE पर ROCm +30% जीतता है (25.62 बनाम 19.66)। एक ही card, विपरीत engine विजेता – bottleneck pure VRAM BW (dense 27B) से CPU-MoE + PCIe (262K पर CPU पर 28 experts) में flip हो जाता है।

- Prompt eval prompt size से नहीं, context reservation से गिरता है। Qwen 16K prompt 217 tok/s बनाम Ornith 262K prompt 83 tok/s – वही 335 tokens, लेकिन Ornith 262K KV pool (kv_unified=false, n_slots=1) reserve करता है जो prefill bookkeeping का खर्च जोड़ता है। आप -c के लिए भुगतान करते हैं, भले ही prompt छोटा हो।

- MoE प्रति token कहीं कम bytes decode करता है। Dense प्रति token 27B weights decode करता है; MoE ~3B active decode करता है। इसलिए Ornith 262K पर भी 12GB पर 25.6 tok/s कर सकता है जबकि Qwen 16K पर 18-21 करता है – active मायने रखता है, total नहीं। हमारा GPU calculator bound decode ≈ BW×0.8 / bytes_per_token resident होने पर ~30 tok/s predict करता है; 25.6 तक का अंतर CPU MoE + offload का है।

- दोनों ने -ngl 999 मजबूर किया → failed to fit params... abort। --fit on ignore हो गया था। अगला Lab -ngl हटाएगा और fitted layers को log करेगा, साथ ही MoE के लिए --load-mode none जोड़ेगा (जो tensor overrides to CPU with mmap को ठीक करता है)।

## VRAM गणित – 12GB अब भी क्यों चलता है

Qwen 27B 3.7bpw: `27B ×0.4625 ≈12.5 GB` weights + q8 KV 16K ≈2.2 GB + 6% overhead → ~15.6 GB ([VRAM Calculator](https://velstech.net/llm-vram-calculator) से) – 12GB से काफी अधिक, इसलिए partial offload 18-21 tok/s बनाम 30 tok/s bound को समझाता है।

Ornith 35B MoE 3B active: 35B mix Q5/Q4 अगर 35B के रूप में गिना जाए तो ≈13-14 GB, लेकिन KV प्रति token *active* 3B के साथ scale करता है, इसलिए 262K q8 naively dense के रूप में गिनने पर ~262K×0.5KB ≈131 GB होगा। इसलिए हम 28 experts को CPU पर force करते हैं – आप resident नहीं हैं, आप sparse हैं। calculator में 35B नहीं, `3B active` + custom `layers 48 / kv 4 / hd 128` दर्ज करें, या `Custom model…` को toggle करें।

हम कैसे calculate करते हैं – संख्याओं के पीछे के formulas

#### VRAM

```
weights = params × bytes_per_weight / GiB
kv_per_token = 2 × layers × kv_heads × head_dim × bytes
kv_cache = kv_per_token × context × batch / GiB
total = weights + kv_cache + (weights+kv)×0.06+0.25
```

MoE के लिए KV के लिए *active* params का उपयोग करें, total नहीं। [LLM VRAM Calculator](https://velstech.net/llm-vram-calculator) → Custom model देखें।

#### Speed bound

```
decode_tok/s ≈ (memory_BW ×0.8) / bytes_per_token (weights + KV per token)
```

MoE bytes_per_token ≈ active 3B, dense ≈27B – इसलिए Ornith कुल बड़ा होने के बावजूद Qwen से तेज़ हो सकता है।

## तो 12GB card पर कौन सा चुनें?

- छोटे prompts + लंबे उत्तर (chat, 16K window): Qwen 27B dense Vulkan पर (21.8 tok/s) बेहतर chat feel देता है।

- विशाल context + MoE (262K window, 28 CPU experts): Ornith 35B MoE ROCm पर (25.6 tok/s) window के बावजूद decode जीतता है, लेकिन इसे --load-mode none चाहिए और पहले prompt पर धैर्य (83 tok/s)।

- अगला optimization: दोनों को -ngl 999 की आवश्यकता नहीं, fitted layers को log करें, और हर context पर q8 vs f16 KV test करें। वह Lab #4 है।

🧪 Raw runs में गहराई से देखें

पूरे logs, commands और warnings दोनों source Labs में हैं – Qwen 16K से शुरू करें, फिर Ornith 262K, फिर यहाँ compare करें।

[Qwen 27B 16K →](https://velstech.net/qwen-27b-ridge-rocm-vs-vulkan) [Ornith 35B 262K →](https://velstech.net/ornith-35b-moe-262k-rocm-vs-vulkan)

---

*VelsTech – https://velstech.net/moe-vs-dense-rx6800m-16k-vs-262k.hi.md*