Qwen 3.8-27B एक M1 Ultra पर: 12.1 से 20.3 टोकन/सेकंड तक सब कुछ मापकर
5 नियंत्रित प्रयोग Qwen 3.8-27B को 128 GB M1 Ultra पर चला रहे हैं: शेड्यूलर QoS पिनिंग, MTP स्पेकुलेटिव डिकोडिंग, एक GGUF चैलेंजर, और एक MoE जिसने डिपैच ओवरहेड पर हार मान ली — Kimi K3 के साथ उच्च सोच पर चलाया गया, प्रत्येक कॉल के लिए पावरमेट्रिक्स साक्ष्य के साथ।
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
Qwen3.8-27B के वज़न सुबह में पहुँचे, और उसी दिन मैंने Kimi K3 के साथ उच्च-सोच मोड में एक साहसिक कार्य शुरू किया. मैंने पूरे काम को एक ही सवाल से शुरू किया: क्या यह ताज़ा घना 27B — अपने आकार वर्ग में सबसे मजबूत ओपन मॉडल — Mac Studio पर M1 Ultra, 20 CPU कोर, 128 GB एकीकृत मेमोरी, और 800 GB/s मेमोरी बैंडविड्थ के साथ वास्तविक गति पर मेरे कोडिंग एजेंटों की सेवा कर सकता है? सामान्य ज्ञान कहता है कि घने मॉडल Apple सिलिकॉन पर धीमे डिकोड करते हैं क्योंकि वे मेमोरी-बैंडविड्थ-बाउंड होते हैं, और मैं जानना चाहता था कि क्या इतना RAM और बैंडविड्थ पैटर्न तोड़ सकता है। 4-बिट MLX वज़न 15 GB पर आए, फ्रेमवर्क वर्तमान था, बॉक्स पर कुछ और नहीं चल रहा था, और पहला नंबर 12.1 टोकन प्रति सेकंड था. यह गलत लगा.मैं इस तरह के प्रयोग को कुछ समय से घुमा रहा था. मार्च में, अपने ऑटोनॉमस रिफ़ाइनमेंट लैब में एक अन्य AI के साथ काम करते हुए, हमने M4 Max पर 30B मॉडलों के लिए 20 टोकन/सेकंड से कम दीवार को OS-स्तरीय पेजिंग से बैंडविड्थ स्टार्वेशन के कारण ट्रेस किया — और उस जांच ने एक प्लेबुक छोड़ी:powermetrics पहले, प्रति-क्लस्टर सैंपलिंग, मेमोरी पिनिंग पहले दोष। इस बार का रन शुद्ध जिज्ञासा से शुरू हुआ: मैंने Qwen3.8 के ऑप्टिमाइज़ेशन के बारे में सुना था, और मैं जानना चाहता था कि क्या यह इस मशीन पर इतना RAM के साथ बॉक्स से बाहर तेज़ चलेगा। केवल मध्य-प्रयोग में बैंडविड्थ-बाउंड वास्तविकता ने खुद को महसूस कराया. इसके बाद एक नियंत्रित प्रयोगों की स्प्रिंट हुई जिसे हमने साथ में डिज़ाइन किया — Kimi ने परिकल्पनाएँ तैयार कीं और मेरे पास हार्डवेयर काउंटर पढ़े जबकि मैंने अपने हाथ धातु पर रखे। प्रत्येक प्रयोग एक स्टैक के एक परत को दंडित या बचाने के लिए बनाया गया था. जीतें 2 स्थानों से आईं जिन्हें लोकल-इन्फरेंस लोककथाएँ कम आँकती हैं: CPU शेड्यूलर संकेत और स्पेकुलेटिव डिकोडिंग. 2 फैशनेबल विकल्प — एक GGUF बिल्ड जिसे llama.cpp द्वारा सेवा दी गई, और एक मिश्रण-ऑफ़-एक्सपर्ट्स मॉडल जो कागज़ पर अविजेय दिखता था — दोनों मापन पर हार गए. यह लेख वह पूर्ण साक्ष्य ट्रेल है जिसे हमने साथ में बनाया, क्योंकि विधि किसी भी एक संख्या से अधिक मूल्यवान साबित हुई.नेटवर्क रिले और सर्वर पहले संदिग्ध थे, और दोनों निर्दोष थे#
सर्विंग पथ में 3 होप थे: मेरा वर्कस्टेशन, एक SSH-आधारित एक्ज़ेक रिले, और स्टूडियो के लूपबैक पर मॉडल सर्वर। रिले को दोष देना आसान होता, इसलिए हमने पहले इसे मापा. सर्वर के अपने टाइमिंग्स ने 12.1 टोक/सेक डिकोड कहा; एक कच्चा इन-प्रोसेस जनरेशन बेंचमार्क, बिना सर्वर और बिना रिले के, ने 11.5 टोक/सेक उत्पन्न किया. ट्रांसपोर्ट लगभग 25% प्रति कनेक्शन ओवरहेड के माध्यम से लागत कर रहा था, और मॉडल स्वयं धीमा स्तर था.एक ट्रांसपोर्ट बग को ठीक करना फिर भी मूल्यवान था, और यह वह विवरण है जो घंटे खर्च करता है यदि आपने इसे कभी नहीं देखा: एक Python TCP रिले जो बफ़र्डread(65536) का उपयोग करता है, एक चटपटा स्थानीय प्रोटोकॉल के खिलाफ डेडलॉक हो जाएगा, क्योंकि बफ़र्ड रीडर एक पूर्ण बफ़र या EOF का इंतज़ार करता है लौटने से पहले। read1() पर स्विच करना, जो एकल अंतर्निहित रीड के बाद लौटता है, ने रिले को व्यवहार किया। लक्षण नेटवर्क स्टॉल जैसा दिखता था; कारण stdio सेमांटिक्स.ट्रांसपोर्ट को निपटाने के बाद, हमने सामान्य sysctl स्तर से काम किया. GPU वायर्ड-मेरी सीमा (iogpu.wired_limit_mb) को बढ़ाने से 128 GB RAM मुक्त होने पर कुछ नहीं बदला, इसलिए हमने इसे वापस कर दिया। Python प्रक्रिया मूल arm64 थी, MLX ने GPU को उसके डिफ़ॉल्ट डिवाइस के रूप में रिपोर्ट किया, और powermetrics ने GPU को 54-62% सक्रिय निवासीता पर 20-23 W खपत करते हुए डिकोड के दौरान दिखाया। इस राउंड में हर संदिग्ध स्वतंत्र रूप से चला — जो स्वयं उपयोगी परिणाम था, क्योंकि इसने जांच को CPU की ओर इंगित किया।शेड्यूलर ने दक्षता कोर पर इन्फरेंस पार्क किया#
प्रति CPU क्लस्टर परpowermetrics पढ़ने के बजाय प्रति मशीन पर, पहले वास्तविक निष्कर्ष का पता चला। डिकोड के दौरान, दक्षता क्लस्टर 75-93% व्यस्त थे जबकि प्रदर्शन क्लस्टर 1-12% पर निष्क्रिय थे।. SSH पर लॉन्च किया गया कोई भी कार्य एक गुणवत्ता-सेवा वर्ग को विरासत में लेता है जिसे macOS कम प्राथमिकता वाले कार्य के रूप में पढ़ता है, और शेड्यूलर ने उस संकेत का पालन करते हुए विलंब-क्रिटिकल वर्कलोड को धीमे कोर पर रखा।सुधार 1 ctypes की पंक्ति थी, जिसे मॉडल वज़न लोड होने से पहले निष्पादित किया गया:pythonCopy sourceimport ctypesctypes.CDLL("libSystem.B.dylib").pthread_set_qos_class_self_np(0x21, 0) # QOS_CLASS_USER_INTERACTIVEवह पिन, साथ ही मॉडल के टेक्स्ट टॉवर को mlx-lm के माध्यम से लोड करना बजाय पूरी विज़न स्टैक के, रॉ डिकोड को 11.5 से 15.1 टोक/सेकंड तक ले गया — शेड्यूलर प्लेसमेंट से 31% लाभ और एक पतला लोडर, मॉडल में कोई बदलाव नहीं। बाद में हमने सीखा कि पिन की पहुँच की एक सीमा है: यह कॉलिंग थ्रेड को स्थानांतरित करता है, और MLX के वर्कर थ्रेड्स अपनी स्वयं की शेड्यूलिंग क्लास रखते हैं. इस मॉडल के लिए मुख्य थ्रेड ने पर्याप्त कार्य वहन किया ताकि इसका महत्व हो.अनुमानित डिकोडिंग ने वह कूद दिया जिसे कोई sysctl नहीं कर सकता था#
सबसे बड़ा एकल लाभ एक फीचर से आया जिसे बेस मॉडल पहले से ही रखता था. Qwen3.8 एक मल्टी-टोकन-भविष्यवाणी हेड के साथ आता है — एक छोटा सहायक मॉड्यूल जो कई टोकन आगे ड्राफ्ट करता है — और MLX कन्वर्टर शांतिपूर्वक उन 15 टेन्सर को रूपांतरण के दौरान हटा देता है. एक समुदाय पैकेज हेड को एक स्वतंत्र 253 MB ड्राफ्टर के रूप में पुनः होस्ट करता है, जिसने मुझे इसे उस मॉडल के साथ फिर से जोड़ने दिया जिसे यह साथ में प्रशिक्षित किया गया था.सर्विंग पैटर्न ड्राफ्ट-फिर-प्रमाणित है: ड्राफ्टर कुछ टोकन प्रस्तावित करता है, पूरा मॉडल उन्हें 1 पास में जांचता है, और स्वीकार किए गए टोकन सभी गिने जाते हैं. सर्वर पर--draft-model और --draft-kind mtp के साथ, ड्राफ्ट स्वीकृति वास्तविक कोडिंग और चैट प्रॉम्प्ट पर 94% मापी गई, और डिकोड 15.1 से 20.3 टोकन/सेकंड सर्वर-साइड — 13.4 टोकन/सेकंड एंड-टू-एंड रिले के माध्यम से, 9.0 से बढ़कर। GPU ने पुष्टि करने वाली कहानी बताई: 77% सक्रिय निवास, सब कुछ पूर्ण 1296 MHz पर, 48 W खींचते हुए, प्रदर्शन क्लस्टर 97% व्यस्त. प्रीफिल उसी उन्नयन में सुधरा, 14.7 टोकन/सेकंड से 18-55 तक, प्रॉम्प्ट आकार पर निर्भर करते हुए.| MLX stack | llama.cpp Q4_K_M | |
|---|---|---|
| raw stack | 11.5 | 9.2 |
| + text tower | 13.6 | |
| + QoS pin | 15.1 | |
| + MTP drafter | 20.3 | 12.2 |
GGUF चैलेंजर 40% द्वारा हार गया#
कम्युनिटी पोस्ट्स ने llama.cpp को एक अनुमानित ड्राफ्ट के साथ 25-32 टोक/सेकंड पर इस मॉडल क्लास के लिए M1 Ultra पर रखा, हमारे MLX नंबरों से आराम से आगे, इसलिए हमने चैलेंजर को एक उचित रिंग दी: आधिकारिक Q4_K_M GGUF, एक मैचिंग MTP-ओनली ड्राफ्ट मॉडल, और एक वर्तमान llama.cpp बिल्ड जिसमें Metal एक्सेलेरेशन सक्रिय पुष्टि की गई है. GGUF लेन ने 9.2 टोक/सेकंड बेसलाइन और 12.2 ड्राफ्ट के साथ मापा — लगभग 40% पीछे MLX स्टैक के, जिसे यह उखाड़ फेंकने के लिए बनाया गया था.llama.cpp उत्कृष्ट इंजीनियरिंग बनी रहती है; अंतर संभवतः इस चेकपॉइंट को इस चिप पर प्रत्येक रनटाइम के Metal कर्नेल्स कैसे हैंडल करते हैं, में है. स्थायी सबक सरल है: कोई संख्या जिसे किसी और ने अपनी मशीन पर, अपने बिल्ड पर, और अपने चेकपॉइंट पर मापा, वह आपकी स्थिति के बारे में एक परिकल्पना है. 18 GB के चैलेंजर वज़न उसी दोपहर में मशीन से बाहर हो गए, और 50 MB llama.cpp बाइनरी भविष्य के रीमैच के लिए बनी रही. मैंने इस नियम के बारे में पहले लिखा है benchmark-driven development — यह SEOReport from heuristics to a product को ले गया — और यहाँ इसने एक माइग्रेशन बचाया।एक 3B-एक्टिव MoE जीतना चाहिए था, और GPU मीटर ने हानि समझाई#
अंतिम चुनौतीकर्ता के पास सबसे मजबूत सिद्धांत था — वही सामान्य ज्ञान जिसे हमने शुरुआत में परीक्षण करने के लिए सेट किया था. घने मॉडल Apple सिलिकॉन पर धीरे-धीरे डिकोड करते हैं क्योंकि हर उत्पन्न टोकन लगभग सभी वज़न पढ़ने के लिए भुगतान करता है; 35B कुल पैरामीटर वाला मिश्रण-ऑफ-विशेषज्ञ मॉडल प्रति टोकन केवल लगभग 3B सक्रिय करता है, इसलिए एक बैंडविड्थ-सीमित मशीन पर इसका डिकोड घने 27B से कई गुना तेज चलना चाहिए — हर टोकन लगभग 11% वज़न पढ़ता है। हमने 4-बिट MoE और उसका मिलान करने वाला MTP ड्राफ्टर डाउनलोड किया, सर्वर को गर्म किया, और 14.7 टोकन/सेकंड कच्चा मापा: वही गति जैसा घना मॉडल जिसे यह अपमानित करने के लिए था। सट्टा डिकोडिंग के साथ यह 19 टोकन/सेकंड वास्तविक प्रॉम्प्ट पर और 26.3 अत्यधिक पूर्वानुमेय पाठ पर पहुंचा — घने मॉडल के 20.3 के खिलाफ एक बराबरी, बिना गुणवत्ता तर्क के टाई तोड़ने के लिए.powermetrics ने 1 नमूने में शासन की पहचान की। MoE डिकोड के दौरान GPU 0-3% सक्रिय निवास पर था जबकि दक्षता क्लस्टर 60-90% पर जमीन से नीचे जा रहे थे। मॉडल अपनी प्रति-टोकन बजट CPU-पक्ष के काम पर खर्च करता है, और ऑप-स्तरीय टाइमिंग ने दिखाया क्यों: प्रत्येक डिस्पैच ऑपरेशन 50-100 माइक्रोसेकंड ओवरहेड लागत करता है, और यह हाइब्रिड आर्किटेक्चर — GatedDeltaNet रैखिक ध्यान और 256 विशेषज्ञ एक छोटे 2048-चौड़े छिपे हुए स्टेट के पीछे — लगभग 78 ऑपरेशन प्रति परत 40 परतों में जारी करता है। बैच आकार 1 पर, GPU प्रत्येक छोटे कर्नेल को समाप्त करता है इससे पहले कि CPU अगला कतार में लगा सके. मशीन डिस्पैच-सीमित थी, और डिस्पैच-सीमित कार्यभार टोकन प्रति कम वज़न पढ़ने से कुछ नहीं पाते.graph TB
A[धीमा डिकोड
बैच पर 1] --> B{GPU व्यस्त
डिकोड के दौरान?}
B -->|हाँ| C[बैंडविड्थ-सीमित
कम बाइट्स जीतते हैं]
B -->|नहीं| D[डिस्पैच-सीमित
कम ऑप्स जीतते हैं]
C --> E[MoE मदद करता है
छोटा क्वांट मदद करता है]
D --> F[सट्टा डिकोडिंग
सबसे अधिक मदद करता है]
style E fill:transparent,stroke:#10B981,stroke-width:2px
style F fill:transparent,stroke:#3B82F6,stroke-width:2pxCopy source| GPU active residency (%) | |
|---|---|
| dense 27B + MTP | 77 |
| MoE 35B-A3B | 2 |
| matmul hog test | 100 |
क्या 5 नियंत्रित प्रयोगों ने पीछे छोड़ा#
मशीन अब Qwen 3.8-27B को 20.3 टोक/सेकंड सर्वर-साइड पर सेवा देती है, जो दिन की शुरुआत से 68% सुधार है, और अधिक टिकाऊ उपज एक चेकलिस्ट है जिसे हम हर भविष्य के बॉक्स पर पुनः उपयोग करेंगे:- बैच आकार 1 पर डिकोड के 2 नियम हैं, बैंडविड्थ-सीमित और डिस्पैच-सीमित, और 2-सेकंड
powermetricsनमूना आपके पहले गलत सुधार पर डाउनलोड खर्च करने से पहले आपका पहचान करता है। - अनुमानित डिकोडिंग एकल-उपयोगकर्ता बॉक्स के लिए सबसे अधिक लीवरेज वाला सर्विंग नॉब है. इसने यहाँ 34% जोड़ा और हर अन्य अनुकूलन के साथ बढ़ता है, क्योंकि सत्यापन बैच GPU पर काम करते हैं जबकि ड्राफ्टर निष्क्रिय अंतराल को अवशोषित करता है.
- शेड्यूलर QoS macOS पर एक वास्तविक अनुमान पैरामीटर है। SSH से अधिक लॉन्च किया गया कोई भी कार्य जानबूझकर अपने थ्रेड्स को पिन करना चाहिए, और पिन का प्रभाव क्लस्टर-प्रति सत्यापित किया जा सकता है बजाय वाइब्स के।
- समुदाय थ्रूपुट दावे चेकपॉइंट्स, बिल्ड्स, और चिप्स के बीच खराब यात्रा करते हैं. एक स्थानीय बेंचमार्क माइग्रेशन से सस्ता है.
- विलोपन कार्यप्रवाह का हिस्सा है. हर चुनौतीकर्ता जिसने हार गया, दिन के भीतर डिस्क छोड़ गया, जो अगले प्रयोग को ईमानदार रखता है और मशीन को पतला रखता है.