← लेखों पर वापसखोजAugust 14, 20268 मिनट में पढ़ेंCopy article

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 source
import 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 तक, प्रॉम्प्ट आकार पर निर्भर करते हुए.
Decode speed by configuration (tok/s, M1 Ultra, 27B-4bit)
Chart datatokens per second
MLX stackllama.cpp Q4_K_M
raw stack11.59.2
+ text tower13.6
+ QoS pin15.1
+ MTP drafter20.312.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 अगला कतार में लगा सके. मशीन डिस्पैच-सीमित थी, और डिस्पैच-सीमित कार्यभार टोकन प्रति कम वज़न पढ़ने से कुछ नहीं पाते.
Diagram source
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:2px
Copy source
लूप बंद करने के लिए, हमने साबित किया कि GPU पथ स्वयं स्वस्थ था एक सिंथेटिक हॉग के साथ: एक 8192³ मैट्रिक्स गुणा लूप ने bfloat16 में 10.8 TFLOPS मारा GPU 97-100% निवास और 68 W के साथ। बाहरी साक्ष्य स्थानीय निदान से सहमत थे — स्वतंत्र अनुमान MoE वर्ग को M2 Ultra पर लगभग 21.7 टोकन/सेकंड पर रखते हैं, और एक OpenVINO मुद्दा उसी मॉडल को घने 8B पर बैकएंड्स के साथ कमजोर डिस्पैच पथों पर हारते हुए दस्तावेज करता है। घना 27B अपने MTP ड्राफ्टर के साथ उत्पादन स्लॉट को बनाए रखा, और 38.5 GB के MoE वज़न उसी शाम को हटाए गए।
GPU active residency during decode (powermetrics, %)
Chart data
GPU active residency (%)
dense 27B + MTP77
MoE 35B-A3B2
matmul hog test100

क्या 5 नियंत्रित प्रयोगों ने पीछे छोड़ा#

मशीन अब Qwen 3.8-27B को 20.3 टोक/सेकंड सर्वर-साइड पर सेवा देती है, जो दिन की शुरुआत से 68% सुधार है, और अधिक टिकाऊ उपज एक चेकलिस्ट है जिसे हम हर भविष्य के बॉक्स पर पुनः उपयोग करेंगे:इस साहसिक कार्य का संतोषजनक हिस्सा यह है कि उत्तर सभी हार्डवेयर काउंटरों में बैठे थे, किसी के सटीक प्रश्न पूछने का इंतजार कर रहे थे — और इस बार हमने उन्हें साथ में पूछा. एक स्थानीय मॉडल जिसे आपने मापा है, वह एक बड़े मॉडल से अधिक मूल्यवान है जिसे आपने अनुमान लगाया है — वही संयोजित रिटर्न जिसे मैं स्थानीय AI लाभों को बुनियादी ढांचे के रूप में मानने से प्राप्त करता हूं बजाय ट्रिविया के। मैंने पूरे काम को उस सुबह शुरू किया जब वज़न उतरे, और Kimi K3 हर प्रयोग, हर काउंटर रीड, और उसी शाम के लैब नोट्स से इस लेखन के लिए लड़ाई में रहा. अगला प्रयोग पहले से ही कतार में है: संकलित डिकोड ग्राफ्स प्रति-ऑप डिस्पैच लागत को घटाने का वादा करते हैं जिसने MoE निर्णय तय किया, और जब एक MLX रिलीज़ आता है, तो रीमैच एक दोपहर और 1 डाउनलोड लेगा।#AI#apple-silicon#benchmarking#local-inference#mlx#performance#experiential#insightsApple Silicon inference, measuredQwen 3.8-27B एक M1 Ultra पर: 12.1 से 20.3 टोकन/सेकंड तक सब कुछ मापकरभाग 1August 14, 20268 मिनट में पढ़ेंMTPLX एक M1 Ultra पर: वह 25 टोक/सेक Tune That Served 16.5भाग 2August 15, 20268 मिनट में पढ़ें—Robert E. Beckner III (Merlin)पढ़ना जारी रखेंपिछलासलाह: PIE नॉन-कस्टोडियल कंप्यूट मॉडल में एक महत्वपूर्ण खोजअगलाअंतिम CLI: पुनर्निर्माण Base 51 के खिलाफ मेरे उपकरण बनाए गएप्रॉम्प्ट कैशिंग की गलतियाँ आपके संगठन को हर AI टर्न पर लगभग 6x अधिक खर्च करा सकती हैंखोजSeptember 23, 202617 मिनट में पढ़ेंKitsune2: खोजें 251x तेज़, अपडेट पथ 33x, और गपशप शुरू हुई 15x पहलेखोजSeptember 19, 202616 मिनट में पढ़ेंबेंचमार्क-ड्रिवेन डेवलपमेंट: एआई सिस्टम्स के लिए TDD से परेखोजSeptember 23, 202511 मिनट में पढ़ेंसंबंधित परियोजनाएँ175-पृष्ठ चीनी हस्तलिपिएआई नवाचारAIA - एआई सलाहकारएआई नवाचार