- inference की मांग supply से आगे निकल रही है और NVIDIA GPU व token लागत बढ़ रही है, ऐसे में AMD MI355X B300 की तुलना में प्रति GPU औसतन लगभग 2.75 गुना सस्ता होकर कम-लागत inference विकल्प के रूप में उभर रहा है
- AMD Instinct MI350 सीरीज़ सिलिकॉन स्तर पर Blackwell से टक्कर लेती है, लेकिन NVIDIA की software बढ़त और day-0 support वास्तविक serving speed और adoption की कठिनाई तय करते हैं
- Wafer ने GLM-5.2 को MI355X पर optimize करके 20k input/1k output, 60% cache hit rate workload में 2626 tok/s/node और 2.4 rps हासिल किए, जो B200 के मापे गए performance का 80% स्तर है
- single-stream आधार पर 10k input token/1.5k output token में 213 tok/s दर्ज किए गए, और भले ही यह leaderboard के शीर्ष पर न हो, cost-per-performance में इसे बढ़त माना गया
- यह नतीजा custom kernel के बिना framework bug fixes, quantization, speculative decode, और MoE kernel selection tuning से आया, इसलिए AMD की चुनौती अब धीरे-धीरे software से ज़्यादा support समस्या के करीब पहुंच रही है
AMD inference लागत और NVIDIA software gap
- inference की मांग तेज़ी से बढ़ रही है और supply से आगे निकल रही है, जबकि Claude Fable, GLM-5.2, Minimax M3 जैसे frontier models लगभग हर दो हफ्ते में आ रहे हैं, जिससे token demand भी बढ़ रही है
- Blackwell supply पर्याप्त न होने से NVIDIA GPU कीमतें और token लागत साथ-साथ महंगी हो रही हैं
- AMD MI355X B300 की तुलना में प्रति GPU औसतन लगभग 2.75 गुना सस्ता है, और hardware specs भी तुलनीय स्तर के हैं
- AMD Instinct MI350 परिवार सिलिकॉन स्तर पर Blackwell से प्रतिस्पर्धा करता है, लेकिन NVIDIA अपने day-0 support और software ecosystem की वजह से नए models की inference serving ज़्यादा तेज़ी और कम friction के साथ कर पाता है
- MI355X और ROCm stack पर नए frontier models का SOTA performance अक्सर default रूप में नहीं मिलता, और कभी-कभी runnable image ढूंढना भी मुश्किल हो सकता है
- day-0 support न होने पर नए model को build और optimize करने में कई हफ्तों की engineering और compute लग सकती है, और तब तक उससे भी नया model आ जाता है, जिससे AMD लगातार catch-up मोड में रहता है
MI355X पर GLM-5.2 performance
- Wafer का मानना है कि agent kernel और model optimization में सुधार के साथ AMD और NVIDIA के बीच का वास्तविक production gap घट रहा है
- 20k input/1k output, 60% cache hit rate workload में 2626 tok/s/node हासिल किए गए
- sustained RPS: 2.4 rps
- परिभाषित knee: TTFT 5 सेकंड या उससे कम
- B200 पर मापे गए performance का 80% स्तर
- MI355X की कीमत 2 गुना से अधिक कम है
| sustained RPS | aggregate tok/s/node | TTFT p50 / p95 | success rate |
|---|---|---|---|
| 0.5 | 449 | 0.59s / 0.60s | 100% |
| 1.0 | 974 | 0.60s / 0.81s | 100% |
| 1.5 | 1913 | 0.62s / 1.03s | 100% |
| 2.0 | 1944 | 0.62s / 1.05s | 100% |
| 2.25 | 2089 | 0.63s / 1.23s | 100% |
| 2.4 saturation | 2626 | 0.81s / 2.22s | 100% |
- Artificial Analysis के मानक के अनुसार GLM-5.2 single-stream में 10k input token/1.5k output token पर 213 tok/s हासिल किए गए
- यह संख्या Artificial Analysis leaderboard के शीर्ष स्तर पर नहीं है, लेकिन cost-per-performance में इसे बेहतर माना गया
- टेस्ट TensorWave की AMD MI355X capacity पर serve किए गए
quantization और inference framework का चयन
- पहला चरण quantization और framework चयन था, और Wafer ने bf16-आधारित GLM-5.2 को AMD Quark से MXFP4 में quantize किया
- z-ai की आधिकारिक FP8 quantization की तुलना में MXFP4 को GPQA-Diamond, tau2, GSM8K में लगभग बिना नुकसान वाला माना गया
| evaluation | FP8 baseline | MXFP4 | Δ |
|---|---|---|---|
| GSM8K, 200 प्रश्न, 5-shot, greedy | 0.965 ± 0.013 | 0.955 ± 0.014 | −0.010 |
| GPQA-Diamond, 198 प्रश्न × 2 seeds, temp 1.0 | 0.9217 ± 0.027 | 0.9026 ± 0.029 | −0.019 |
| tau2 macro | 0.819 | 0.834 | +0.015 |
- inference framework के 3 उम्मीदवार थे: vLLM, ATOM, sglang
- vLLM में MXFP4 + GlmMoeDsa path काम नहीं करता था, इसलिए MXFP4 weights का लाभ नहीं मिल सका
- ATOM में लंबे context पर output quality गिरती थी
- sglang में native support तक पहुंचने का friction सबसे कम था, और यह quantization का उपयोग करते हुए भी consistent output बनाए रखता था
speculative decode को रोकने वाली दो समस्याएँ
- throughput सुधारने के लिए sglang में speculative decode सक्षम करना चाहा गया, लेकिन sglang ROCm image इसे default रूप से support नहीं करती थी
- MTP के सही तरह से काम करने के लिए दो fixes ज़रूरी थे
- पहली समस्या यह थी कि MTP head का shared expert bf16 में stored था, लेकिन module prefix mismatch के कारण sglang की quantization lookup उसे MXFP4 में build करने की कोशिश कर रही थी
- Quark bf16 shared expert को
model.layers.78.mlp.shared_experts.*नाम देता है - MTP layer का वास्तविक prefix
model.decoder.*है - इस mismatch की वजह से load के समय full-width bf16 weights को half-width 4-bit slot में पढ़ने की कोशिश होती थी और shape mismatch के कारण initialization fail हो जाता था
- Wafer ने layer 78 entries को sglang द्वारा वास्तव में इस्तेमाल किए जाने वाले decoder नाम में एक बार और copy किया, जिससे speculative decode खुल गया और single-stream throughput लगभग 3 गुना बढ़ गया
- Quark bf16 shared expert को
- दूसरी समस्या यह थी कि z-ai द्वारा सुझाया गया 5/1/6 configuration जैसा गहरा speculative decode रुक रहा था
- draft depth 4 या उससे अधिक के लिए ज़रूरी fused multi-step metadata kernel ने ROCm guard के बिना
#include <cuda_runtime.h>लिखा हुआ था - इसे एक
#ifdef USE_ROCMguard से ठीक किया गया
- draft depth 4 या उससे अधिक के लिए ज़रूरी fused multi-step metadata kernel ने ROCm guard के बिना
- speculative decode सही तरह से चलने के बाद
--kv-cache-dtype fp8_e4m3,--enable-aiter-allreduce-fusionजैसी settings optimization जोड़कर single-stream decode 213 tok/s तक पहुंचा
aggregate throughput bottleneck और MoE tuning
- परिभाषित workload में केवल decode optimization काफ़ी नहीं था, और 20k input तथा 60% cache शर्तों में मुख्य bottleneck prefill था
- single-stream decode के लिए tuned TP8 configuration में MI355X ने GLM-5.2-MXFP4 को 1461 tok/s/node पर चलाया
- TP4×DP2 में बदलने पर उसी workload में 1944 tok/s/node और 2.0 RPS हासिल हुए
- हालांकि Wafer द्वारा मापा गया Blackwell performance 3.0 RPS पर 3192 tok/s/node था, और MI355X का prefill performance तुलनात्मक रूप से धीमा था
- एक बड़ा कारण यह था कि sglang image में GLM-5.2 का fp4 MoE चुपचाप धीमे FlyDSL heuristic fallback पर गिर रहा था
- aiter केवल a8w8/fp8 path के लिए tuned settings देता है
- Wafer ने GLM के fp4 shape के अनुसार MoE kernel selection को सीधे tune किया
- target shape था
model_dim 6144,moe_inter 2048,E=256,topk=8
- इस tuning से aggregate throughput 2626 tok/s/node और 2.4 RPS तक पहुंच गया
AMD पर SOTA performance पाने के लिए क्या चाहिए
- MI355X पर सर्वोत्तम cost-per-performance हासिल करने की प्रक्रिया में कुछ friction था, लेकिन इसे विशेष रूप से कठिन नहीं माना गया
- Qwen3.5 397B वाले काम से अलग, इस बार custom kernel नहीं लिखा गया
- इस अध्ययन में multi-node performance पर विचार नहीं किया गया, लेकिन single-node deployment अभी भी वास्तविक वातावरण में व्यापक रूप से इस्तेमाल होता है
- AMD पर SOTA performance निकालने की समस्या अब धीरे-धीरे software से ज़्यादा support का मुद्दा बनती जा रही है
- निष्कर्ष यह है कि CUDA moat रीयल टाइम में कमजोर हो रही है
1 टिप्पणियां
Hacker News की राय
काश ऐसी तुलना में performance per watt को भी एक metric के रूप में शामिल किया जाता। मैं जानना चाहूँगा कि AMD वास्तविक performance बनाम cost के हिसाब से कहाँ खड़ा है
अमेरिका के बाहर data center बनाने की कोशिश कर रही कंपनियों से बात करें तो वे कहती हैं कि पर्याप्त scale पर Nvidia की supply हासिल करना मुश्किल है
अगर AMD का performance per watt प्रतिस्पर्धी है और software support भी कुल मिलाकर भरोसेमंद है, तो यह काफ़ी महत्वपूर्ण होगा, क्योंकि अमेरिका के बाहर कई जगह बिजली अपेक्षाकृत महँगी होती है
अगर यह उचित कीमत पर छोटे data center संभव बनाता है, तो जहाँ Nvidia की supply सीमित है वहाँ AMD stack का एक हिस्सा बन सकता है
हालाँकि AMD GPU की procurement वास्तव में कैसी है, यह मुझे नहीं पता, और अमेरिका की Wafer व कुछ कंपनियों को छोड़कर मैंने AMD इस्तेमाल करने वाली कंपनियाँ लगभग नहीं देखीं, इसलिए शायद मैं Nvidia bubble के भीतर फँसा हुआ हूँ
अगर मान लें कि यह 8 साल तक 100% पर लगातार चलता रहे, तो लगभग 1GWh बनता है, और जर्मनी जैसी महँगी बिजली वाली जगह पर भी इसकी लागत करीब 1 लाख यूरो होगी, जो शुरुआती 5 लाख डॉलर के hardware cost की तुलना में 8 साल में बहुत बड़ी नहीं है
ऊँची बिजली खपत की असली समस्या बिजली का बिल नहीं, बल्कि data center तक लाई जा सकने वाली power supply limit है। ज़्यादा efficient configuration का मतलब है कि सीमित power intake के भीतर अधिक equipment रखा जा सकता है
बाज़ार को सचमुच Nvidia के एक वास्तविक competitor की ज़रूरत है, और खासकर performance/watt बहुत महत्वपूर्ण है
OpenAI भी: https://www.amd.com/en/newsroom/press-releases/2025-10-6-amd...
यह अच्छा तो है, लेकिन वास्तविक उपयोग में FP4 quantization का लगभग lossless होना बहुत कम मामलों में सच होता है। कई providers Kimi और GLM में ऊँची tokens-per-second दर का विज्ञापन करते हैं, लेकिन मॉडल functional रूप से इतना सीमित हो जाता है कि वह अब frontier quality के क़रीब भी नहीं रहता
काश यह सच न हो
यह GLM से अलग है, जहाँ 16-bit precision default है और 8-bit भी आम तौर पर इस्तेमाल होती है
इसलिए लोगों को MXFP6 quantization बनानी चाहिए, जो लगभग lossless के क़रीब हो और FP8 की तुलना में FP4 performance के कहीं ज़्यादा क़रीब हो
मैंने GLM 5.2 के अलावा Nvidia द्वारा NVFP4 में बदले गए मॉडलों को काफ़ी test नहीं किया, लेकिन मुझे वह ठीक लगा
खुद इस्तेमाल करने पर नतीजे मॉडल-दर-मॉडल काफ़ी अलग थे
मुझे लगा था कि इसमें तेज़ और सस्ता सुधार करने के रास्तों पर चर्चा होगी, लेकिन इस लेख में तो quantized version को full version जितनी कीमत पर दिया जा रहा है, और तेज़ version को उससे भी बहुत महँगा बेचा जा रहा है
क्या यह लगभग स्वाभाविक नहीं है? performance per dollar को एक ratchet की तरह सिर्फ़ एक ही दिशा में बेहतर होना चाहिए। कोई ज़्यादा महँगी चीज़ सस्ती चीज़ की जगह कैसे ले सकती है?
मेरा मानना है कि ऐसे लेखों के शीर्षक में quantization method साफ़-साफ़ लिखना अनिवार्य होना चाहिए
.aiसे होता है या नहीं। अगर ऐसा दिखे, तो उसके low-effort, clickbait, सतही, बेकार, या भ्रामक होने की संभावना बहुत ज़्यादा होती हैin-memory computing और neuromorphic paradigms अगले 10 सालों में इस रुझान को और भी ज़ोर से आगे बढ़ा सकते हैं
जैसे-जैसे ज़्यादा radical improvements labs के बाहर आएँगी, वैसे-वैसे नए materials और nano devices भी आएँगे, और efficiency कई orders of magnitude तक बेहतर हो सकती है
MRAM जैसी मौजूदा तकनीकों को scale up करने भर में भी काफ़ी गुंजाइश है
fp8 से mxfp4 में जाने पर accuracy drop साफ़ नज़र आता है
इसके बावजूद implementation साफ़ तौर पर कमज़ोर है, और वे quantization से cost और घटाने पर शेख़ी बघार रहे हैं
[1] https://www.ycombinator.com/launches/Q9i-wafer-pass-flat-rat...
यह कोई नया phenomenon नहीं है। performance per dollar लगभग 1900 से काफ़ी लगातार exponential रूप से बेहतर होती आई है
1900~2010: https://www.thekurzweillibrary.com/exponential-growth-of-com...
1939~2023: https://medium.com/@timventura/kurzweils-law-for-the-ai-age-...
Blackwell से प्रतिस्पर्धा करना हैरान करने वाली बात नहीं है। Rubin inference में Blackwell से 5 गुना तेज़ है, और Blackwell Nvidia की आख़िरी ऐसी generation है जिसे inference के लिए खास तौर पर optimize नहीं किया गया था
अगर मैं कुछ मिस कर रहा हूँ तो बताइए
disaggregated configuration में prefill nodes और decoding nodes को अलग करना तो दिखता है, लेकिन उसके अलावा क्या है, समझ नहीं आता
खासकर तब, जब कई currencies कमज़ोर हो रही हों