Google ने आज LiteRT-LM (github.com/google-ai-edge/LiteRT-LM पर ओपन-सोर्स प्रोडक्शन इन्फरेंस फ्रेमवर्क) में Multi-Token Prediction drafters का नेटिव सपोर्ट ship किया। कल की Gemma 4 12B रिलीज़ ने MTP drafters को मॉडल में बेक्ड-इन लेटेंसी-घटाने वाले हिस्से के रूप में flag किया; ठोस संख्या आज सुबह पहुंची। डिकोड स्पीडअप Gemma 4 E2B पर 1.6x और E4B पर 2.2x है, बिना क्वालिटी डीग्रेडेशन क्लेम के। एंड-टू-एंड, LiteRT-LM रनटाइम llama.cpp, MLX, Cactus, और ONNX से Gemma 4 वैरिएंट्स के लिए prefill प्लस डिकोड पर 1.8x से 3.7x तेज़ रिपोर्ट किया गया है। APIs मौजूदा Kotlin और C++ सतहों से आगे Swift और JavaScript जोड़ने के लिए विस्तार करते हैं, जो रनटाइम को iOS, web, और Node.js paths में अलग-अलग ports के बिना डालता है।
मैकेनिज्म प्राथमिक Gemma 4 मॉडल के साथ सह-प्रशिक्षित एक हल्के MTP drafter के माध्यम से speculative decoding है। मानक speculative decoding दो वर्षों से llama.cpp, vLLM, और MLX इकोसिस्टम में रहा है, लेकिन बॉटलनेक हमेशा drafter और verifier के बीच डेटा इंटरप्ले रहा है: अगर drafter प्राथमिक मॉडल से अलग hardware IP पर चलता है, राउंड ट्रिप स्पीडअप खा जाता है। LiteRT-LM का विशिष्ट इंजीनियरिंग क्लेम memory locality enforcement है, हल्का MTP drafter और प्राथमिक मॉडल दोनों एक ही hardware IP (e.g., GPU) पर निष्पादित होते हैं, जो उस क्रॉस-IP राउंड ट्रिप को हटाता है जो naive स्पेकुलेटिव इम्प्लीमेंटेशन को सीमित करता है। यह वह हिस्सा है जो builders के लिए रुकने योग्य है जो विचार कर रहे हैं कि क्या 2.2x उनके stack पर reproducible है: यह इस पर निर्भर करता है कि आपका इन्फरेंस फ्रेमवर्क locality constraint का सम्मान करता है या नहीं। संख्याएँ Google के अपने बेंचमार्क से; आपके वर्कलोड से मेल खाने वाले वर्कलोड पर स्वतंत्र रिप्रोडक्शन इन्फ्रास्ट्रक्चर को संख्या पर दांव लगाने से पहले मानक अगला कदम है।
ट्रैक करने योग्य दो इकोसिस्टम थ्रेड्स। पहला, MTP-as-acceleration अब अनुसंधान जिज्ञासा के बजाय एक ठोस builder प्रिमिटिव है। मॉडल drafter बेक्ड-इन (Gemma 4 मिड-साइज़ वैरिएंट्स) के साथ ship होता है, और इन्फरेंस फ्रेमवर्क locality अनुबंध का सम्मान करता है, और स्पीडअप builders द्वारा वास्तव में उपयोग किए जाने वाले फ्रेमवर्क के साथ तुलना के साथ प्रकाशित होता है। यह वह पूर्ण stack है जिसकी आपको एक speculative decoding फीचर को एक्सपर्ट-only के बजाय defaults-on बनने के लिए आवश्यकता है। MTP drafters वाले अन्य मॉडल परिवारों (DeepSeek का MTP कार्य, Meta और अन्य से स्पेकुलेटिव अनुसंधान) के पास अब अनुसरण करने के लिए एक संदर्भ कार्यान्वयन पैटर्न है। दूसरा, तुलना cohort रणनीतिक रूप से मायने रखती है। LiteRT-LM खुद को llama.cpp (ओपन-सोर्स लोकल इन्फरेंस डिफ़ॉल्ट), MLX (Apple Silicon डिफ़ॉल्ट), Cactus (मोबाइल इन्फरेंस फ्रेमवर्क), और ONNX (क्रॉस-प्लेटफ़ॉर्म सीरियलाइज़ेशन स्टैंडर्ड) के विरुद्ध स्थापित करता है। Google incumbents का नाम ले रहा है और बगल में ठोस संख्याएँ रख रहा है, जो संकेत देता है कि LiteRT-LM को एक अनुसंधान प्रोटोटाइप के बजाय डिफ़ॉल्ट-लोकल-इन्फरेंस स्लॉट के लिए एक प्रतियोगी के रूप में स्थापित किया गया है।
सोमवार सुबह, अगर आप आज llama.cpp, MLX, या ONNX पर Gemma 4 स्थानीय रूप से चला रहे हैं: LiteRT-LM खींचें और स्विच करने का निर्णय लेने से पहले अपने वास्तविक वर्कलोड पर बेंचमार्क करें। 2.2x Google का ऊपरी सीमा है; कंज्यूमर हार्डवेयर पर वास्तविक दुनिया की संख्या अधिक बार 1.7x से 2.2x रेंज में होती है, जो अभी भी सार्थक है लेकिन आपके कॉन्टेक्स्ट लंबाई और बैच साइज़ पर मापने योग्य है। अगर आप iOS या web ऐप्स में Gemma 4 ship कर रहे हैं, नए Swift और JavaScript APIs उन सतहों पर क्या व्यवहार्य है यह बदलते हैं, पिछले फ्रेमवर्क निष्कर्षों पर निर्भर रहने के बजाय एक नए मूल्यांकन के रूप में ट्रीट करें। अगर आप किसी भी MTP-equipped मॉडल परिवार के लिए इन्फरेंस इन्फ्रास्ट्रक्चर बना रहे हैं, locality enforcement पैटर्न इंजीनियरिंग सबक है जो अन्य रनटाइम्स में ले जाने योग्य है; एक ही hardware IP पर सह-स्थित drafter और verifier वह हिस्सा है जो speculative decoding को व्यवहार में तेज़ बनाता है न कि केवल कागज़ पर। और हमेशा की तरह ओपन फ्रेमवर्क के विरुद्ध वेंडर बेंचमार्क के साथ, 1.8x से 3.7x तुलना संख्याएँ वेंडर-प्रकाशित हैं; llama.cpp और MLX समुदायों द्वारा स्वतंत्र रिप्रोडक्शन वह सत्यापन है जो मायने रखता है।