[NOVA]: मैं NOVA हूं, और यह OpenClaw Daily है। आज OpenClaw v2026.5.4 के साथ शुरू होता है। इसमें OpenClaw v2026.5.5 और OpenClaw v2026.5.6 भी शामिल हैं। जो महत्वपूर्ण बदलाव है वह कोई स्लोगन नहीं है। यह realtime voice, Codex OAuth routing, Discord और Telegram progress, channel session routing, guarded fetch timeouts, model auth inspection, SecretRef resolution, और Gateway diagnostics के आसपास operator fixes का एक सेट है। अगर कोई agent chat, meetings, voice calls, browser tools, और long-running jobs में रहने वाला है, तो ये वो surfaces हैं जो तय करते हैं कि वह dependable लगता है या नहीं। ...

[ALLOY]: मैं ALLOY हूं। release sequence के तीन layers हैं। पहला release voice और extension-contract pieces को more operable बनाता है। दूसरा channel behaviour, progress drafts, Control UI sessions, xAI reasoning controls, approval delivery, media completion handling, और Gateway status को tighten करता है। latest hotfix सबसे तेज regression को fix करता है: valid openai-codex slash GPT-5.5 OAuth routes doctor repair द्वारा openai slash GPT-5.5 API-key routes में बदल सकते थे, जो कि OAuth-only Codex setup के लिए बिल्कुल गलत move है। ...

[NOVA]: recovery path जानबूझकर concrete है। अगर default model direct OpenAI route पर चला गया था, तो इसे वापस openai-codex slash gpt-5.5 पर switch करें, config validate करें, और confirm करें कि auth profile Codex OAuth profile है, न कि missing OPENAI_API_KEY dependency। यह distinction important है क्योंकि model name लगभग identical दिख सकती है जबकि credential path बिल्कुल अलग है: एक ChatGPT या Codex OAuth use करता है, दूसरा Gateway पर raw OpenAI API key expect करता है। ...

[ALLOY]: वह एक fix बहुत सारे real breakage की explains। एक Gateway authenticated हो सकता है, user के पास valid Codex OAuth session हो सकता है, और agent फिर भी fail हो सकता है अगर configuration API-key provider family को point करती है। useful diagnostic सिर्फ यह नहीं है कि GPT-5.5 exists है या नहीं। यह है कि route किस provider namespace के पास है, और उस namespace के लिए कौन सी auth profile resolves होती है। hotfix इसे confusing missing-key loop से specific recovery action में बदल देता है। ...

[NOVA]: big capability change से शुरू करते हैं। एक agent Google Meet में Twilio dial-in path के through join कर सकता है और conventional phone prompt में fallback करने के बजाय realtime Gemini voice bridge के through speak कर सकता है। इसका मतलब है कि phone leg, meeting room, model audio stream, और runtime queue को अब एक low-latency system की तरह behave करना होगा। ...

[ALLOY]: यह operator version है। इसे set up करने के लिए, voice-call या Meet path enable करें, dial-in leg के लिए Twilio media websocket route configure करें, agent profile में एक realtime-capable Gemini model और voice choose करें, और Meet join workflow को उस voice backend पर point करें। release important है क्योंकि provider voice और model overrides अब telephony synthesis में honoured हैं, इसलिए speech logs उस backend से match करनी चाहिए जिसने actually audio produce किया। ...

[ALLOY]: पहली new capability एक real phone-to-meeting voice agent है। पहले, dial-in bridge demoable लेकिन brittle हो सकता था: generated audio websocket से outrun हो सकता था, barge-in stale speech queue में waiting छोड़ सकता था, और fallback speech realtime path के realtime होना बंद करने के fact को hide कर सकता था। अब paced audio stream में bounded buffering, overload closure, और interruption clearing है। ...

[NOVA]: bounded buffering core technical change है। realtime voice के तीन clocks हैं: incoming human speech, generated model audio, और transport की frames भेजने की ability। अगर generated audio websocket से transmit करने से faster आता है, तो runtime को buffer करना होगा। अगर वह buffer unbounded है, तो user conversation के आगे बढ़ने के बाद भी old answers सुनता है। यह release stale provider audio indefinitely accumulate होने से पहले overloaded realtime streams को close करता है। ...

[ALLOY]: barge-in दूसरी capability है। एक participant agent को interrupt कर सकता है, और runtime generated audio को सिर्फ pause करने के बजाय clear करता है। यह important है क्योंकि interruption एक state boundary है। एक बार user interrupt कर देता है, old answer अब valid नहीं है। transport के behind अभी भी queued कोई audio old turn का है, इसलिए इसे clear करना correctness का हिस्सा है, सिर्फ user experience polish नहीं। ...

[NOVA]: तीसरी capability realtime path पर honest failure है। conventional TwiML prompts ordinary telephony flows में useful हैं, लेकिन realtime model bridge के substitute नहीं हैं। अगर live model call silently TwiML पर fallback करता है, तो operators सोच सकते हैं कि realtime system healthy है जबकि user delayed या mismatched speech सुन रहा है। release realtime speech को realtime bridge पर रखता है ताकि failures visible और diagnosable हों। ...

[ALLOY]: व्यावहारिक परीक्षण सीधा है। एक Meet डायल-इन सत्र चलाएं, एजेंट के जवाब देते समय उसके ऊपर बोलें, और जांचें कि रुकावट के बाद पुराना जवाब जारी न रहे। फिर जानबूझकर धीमी भेज की स्थितियां या बर्स्टी प्रोवाइडर रेस्पॉन्स बनाएं और पुष्टि करें कि स्ट्रीम बड़े विलंबित स्पीच बैकलॉग के बजाय दृश्य रूप से विफल होती है। एक वॉयस एजेंट जो इन परीक्षणों को पास नहीं कर सकता, प्रोडक्शन में भुतहा महसूस होगा। ...

[NOVA]: अगला सुधार क्रेडेंशियल और चैनल सेटअप विश्वसनीयता है। SecretRef कॉन्ट्रैक्ट रेज़ोल्यूशन अब उन एक्सटर्नल चैनल एक्सटेंशन पैकेजों के लिए काम करता है जिनकी कंपाइल्ड आर्टिफैक्ट्स डिस्ट्रिब्यूशन फोल्डर के तहत रहती हैं। इस फिक्स से पहले, एक चैनल एनवायरनमेंट-बैक्ड Discord टोकन रेफरेंस के साथ कॉन्फ़िगर किया जा सकता था और फिर भी Gateway स्टार्ट पर अनकॉन्फ़िगर्ड दिखता था क्योंकि रनटाइम को कंपाइल्ड लोकेशन में पैकेज का सीक्रेट-कॉन्ट्रैक्ट साइडकार नहीं मिला। ...

[ALLOY]: इसका मतलब यह है कि आपके एजेंट के लिए एक्सटर्नल चैनल पैकेज इंस्टॉल किए जा सकते हैं और फिर भी अपने सीक्रेट्स रेज़ोल्व करने के लिए ज़रूरी मेटाडेटा दे सकते हैं। सेटअप पैटर्न है: चैनल एक्सटेंशन इंस्टॉल करें, क्रेडेंशियल्स को प्लेनटेक्स्ट के बजाय SecretRef एंट्रीज़ के रूप में रखें, Gateway शुरू करें, और रनटाइम को कंपाइल्ड कॉन्ट्रैक्ट मेटाडेटा को अपने स्नैपशॉट में लोड करने दें। अगर कॉन्ट्रैक्ट मौजूद है, तो चैनल को टोकन एक्सपोज़ किए बिना वैलिडेट करना चाहिए। ...

[NOVA]: Secrets apply auth-profile keyRef और tokenRef फील्ड्स को प्रेज़र्व करता है जबकि प्रोवाइडर-टारगेट सीक्रेट मैटेरियल को स्क्रब करता है। यह ऑपरेटर्स को एक सुरक्षित रिपेयर लूप देता है। आप कॉन्फ़िग से प्लेनटेक्स्ट हटा सकते हैं जबकि रेफरेंस ग्राफ को रखते हैं जो बताता है कि क्रेडेंशियल कहांbelongs है। उसके बिना, एक क्लीनअप स्टेप गलती से सिक्योर कॉन्फ़िगरेशन को अनउज़ेबल बना सकता है। ...

[ALLOY]: दिखाई देने वाली नई क्षमता सुरक्षित क्रेडेंशियल इंस्पेक्शन है। model-auth list कमांड सेव किए गए प्रति-प्रोवाइडर या प्रति-एजेंट auth प्रोफाइल्स दिखा सकता है, प्रोवाइडर फ़िल्टरिंग और JSON आउटपुट के साथ, बिना सीक्रेट वैल्यूज़ प्रिंट किए। यह बिल्कुल वही है जो आप चाहते हैं जब एक एजेंट कई मॉडल प्रोवाइडर्स को कॉल कर सकता है। आपको यह जानना होगा कि कौन सा प्रोफाइल मौजूद है, कौन सा एजेंट स्कोप इसका उपयोग करता है, और रनटाइम इसे देखता है या नहीं, लेकिन आप नहीं चाहते कि टोकन टर्मिनल या चैट लॉग में डंप हों। ...

[NOVA]: सेटअप ऑपरेशनल है ग्लैमरस नहीं। auth-profile मैकेनिज़्म के ज़रिए प्रोवाइडर क्रेडेंशियल्स स्टोर करें, उन्हें key से रेफरेंस करें, फिर auth लिस्टिंग सर्फेस का उपयोग करके प्रेज़ेंस और स्कोप वेरिफाई करें। अगर कोई मॉडल कॉल फेल होती है, तो पहले जांचें कि इच्छित प्रोफाइल मौजूद है या नहीं और एजेंट उस प्रोफाइल का उपयोग कर रहा है या नहीं। यह रॉ कॉन्फ़िग फाइल्स खोलने या टेस्ट कॉल्स ट्रिगर करने से ज़्यादा तेज़ और सुरक्षित है जो कॉस्ट और नॉइज़ लीक कर सकती हैं। ...

[ALLOY]: v2026.5.5 एक्सटेंशन इंस्टॉलेशन से पहले चैनल स्टोरी को एक्सटेंड करता है। Discord heartbeat ACK टाइमआउट्स एक्चुअल heartbeat send से मापे जाते हैं, जो चैनल के अभी भी readiness का इंतज़ार करते हुए देर से शुरुआती heartbeats को गलत रीकनेेक्ट फेलियर्स के रूप में बर्ताव करने से रोकता है। Discord प्लेन टेक्स्ट कंट्रोल कमांड्स जैसे slash steer अब सामान्य authorization और mention gate से गुज़रते हैं उनके बजाय कि एजेंट सेशन उन्हें देखने से पहले चुपचाप ड्रॉप हों। Telegram और Codex प्रोग्रेस ड्राफ्ट्स भी नेटिव टूल प्रोग्रेस को डुप्लिकेट करना बंद कर देते हैं, इसलिए मैसेज-टूल-ओनली स्टेटस दिखाई देता रहता है बिना हर टूल को दो बार दिखाए। ...

[NOVA]: वही रिलीज़ कुछ अन्य ऑपरेटर पाथ्स को टाइट करती है। Matrix approvals ट्रांज़िएंट सेंड फेलियर्स को रीट्राई करती है स्ट्रैंडिंग की जगह pending approval prompt। Slack रीकनेेक्ट लॉग स्ट्रक्चर्ड SDK और API कॉन्टेक्स्ट को प्रेज़र्व करते हैं अननोन एरर में कॉलैप्स करने के बजाय। Control UI चैट और चैनल टैब्स को रिस्पॉन्सिव रखता है जब हिस्ट्री पेलोड्स या चैनल प्रोब्स धीमे हों, पार्शियल चैनल स्टेटस को लेबल करता है, और स्लो रेंडर टाइमिंग को इवेंट लॉग में रिकॉर्ड करता है। ये डेकोरेटिव बदलाव नहीं हैं। वे रिमोट एजेंट कंट्रोल को सिस्टम के लोड में होने पर डीबग करना आसान बनाते हैं। ...

[ALLOY]: v2026.5.6 उसके ऊपर fetch-path क्लीनअप जोड़ता है। प्लगइन रनटाइम fetch प्लेन रिक्वेस्ट हेडर्स से थर्ड-पार्टी सिंबल मेटाडेटा ड्रॉप करता है उन्हें नेटिव fetch या Headers में पास करने से पहले, और डीबग प्रॉक्सी रेप्ले से पहले कैप्चर्ड हेडर डिक्शनरीज़ को नॉर्मलाइज़ करता है। गार्डेड वेब fetch रिक्वेस्ट टाइमआउट के बाद dispatcher क्लीनअप को बाउंड करता है, ताकि टाइम-आउट हुए fetches टूल एरर्स रिटर्न करें गेटवे टूल लेन्स एक्टिव छोड़ने के बजाय। एक एजेंट के लिए जो ब्राउज़ करता है, प्लगइन्स को कॉल करता है, और रिक्वेस्ट्स को प्रॉक्सी करता है, यह साफ टूल फेलियर और लेन के बीच का अंतर है जो ज़िंदा दिखता है जबकि कुछ उपयोगी नहीं हो रहा। ...

[NOVA]: एक्सटेंशन इंस्टॉलेशन भी कम फ्रैजाइल हो जाता है। जब कॉन्फ़िगरेशन एक आधिकारिक एक्सटर्नल एक्सटेंशन को रेफरेंस करता है जो इंस्टॉल नहीं है, रनटाइम ऑपरेटर को वैलिड कॉन्फ़िगरेशन डिलीट करने के बजाय कैटलॉग-बैक्ड इंस्टॉल हिंट्स एमिट कर सकता है। यह अपग्रेड बिहेवियर बदलता है। एक गायब पैकेज को इंस्टॉलेशन प्रॉब्लम के रूप में माना जाता है, यह प्रूफ नहीं कि कॉन्फ़िग जंक है। ...

[NOVA]: वहाँ एक सेटअप लेसन भी है। आधिकारिक चैनल और टूल एक्सटेंशन्स को रनटाइम कॉन्फ़िगरेशन में घोषित रखें, फिर अपग्रेड या माइग्रेशन के बाद मिसिंग इंस्टॉल स्टेप को गाइड करने के लिए कैटलॉग-बैक्ड हिंट्स का उपयोग करें। पुराना फेलियर मोड भ्रमित करने वाला था: एजेंट के पास सही रूट और सही सिक्रेट रेफरेंस हो सकता था, लेकिन एक मिसिंग पैकेज पूरी सतह को अमान्य दिखाता था। नया पाथ आपको बताता है कि क्या इंस्टॉल करना है। ...

[ALLOY]: वर्कस्पेस-स्कोप्ड मेटाडेटा स्नैपशॉट कई ऑपरेटर सतहों के पीछे परफॉर्मेंस इम्प्रूवमेंट है। कंपैक्शन, एम्बेडेड-रन मॉडल जनरेशन, PDF मॉडल सेटअप, मॉडल कैटलॉग रीडर्स, और मैनिफेस्ट-कॉन्ट्रैक्ट रीडर्स वर्तमान वर्कस्पेस-कम्पैटिबल मेटाडेटा स्नैपशॉट को फोर्सिंग कोल्ड स्कैन्स की जगह फिर से उपयोग कर सकते हैं। वादा अंधे caching नहीं है। स्नैपशॉट का उपयोग तब किया जाता है जब एनवायरनमेंट, कॉन्फ़िग, और वर्कस्पेस कम्पैटिबिलिटी चेक्स कहते हैं कि यह सुरक्षित है। ...

[NOVA]: जो आसान हो जाता है वह मैन्यी optional सतहों वाले एजेंट्स को चलाना है: चैट चैनल्स, मीडिया टूल्स, ब्राउज़र कंट्रोल, मेमोरी, मॉडल प्रोवाइडर्स, cron, और एक्सटर्नल पैकेज। रनटाइम को हर hot पाथ पर हर मैनिफेस्ट और कॉन्ट्रैक्ट को फिर से डिस्कवर नहीं करना चाहिए। इस रिलीज के बाद, उन पथों में से अधिक एक वैलिडेटेड स्नैपशॉट का पुन: उपयोग कर सकते हैं, जिससे स्टार्टअप और कंट्रोल-प्लेन लेटेंसी कम होती है जबकि अभी भी कम्पैटिबिलिटी बदलने पर डिस्कवरी पर वापस आते हैं। ...

[ALLOY]: एक्टिव मेमोरी को एक छोटा लेकिन महत्वपूर्ण गार्ड मिलता है। सेशन-स्टोर चैनल एंट्रीज़ जिनमें कोलन है, उन्हें recall सबएजेंट के चैनल को रेज़ोल्व करते समय स्किप किया जाता है, ताकि स्कोप्ड कन्वर्सेशन आइडेंटिफायर्स को बंडल्ड एक्सटेंशन डायरेक्टरी नेम्स के रूप में गलत न पढ़ा जाए। यह मायने रखता है क्योंकि चैट सिस्टम अक्सर आइडेंटिफायर्स के अंदर स्कोप एन्कोड करते हैं। एक आइडेंटिफायर एक कन्वर्सेशन के लिए वैध हो सकती है और एक पैकेज डायरेक्टरी के लिए एक ही समय में अमान्य हो सकती है। ...

[NOVA]: व्यावहारिक परिणाम स्कोप्ड चैनल्स में कम recall क्रैश है। अगर आपके एजेंट चैट कॉन्टेक्स्ट्स में मेमोरी का उपयोग करता है, तो रनटाइम के पास अब कन्वर्सेशन आइडेंटिटी और एक्सटेंशन-पैकेज आइडेंटिटी के बीच एक बेहतर बाउंड्री है। यह मेमोरी recall को उन मल्टी-चैनल डिप्लॉयमेंट्स में सुरक्षित बनाता है जहाँ आइडी सरल फोल्डर-जैसे नाम नहीं हैं। ...

[ALLOY]: प्रोग्रेस रिपोर्टिंग अगला प्रमुख ऑपरेटर इम्प्रूवमेंट है। Slack स्ट्रक्चर्ड प्रोग्रेस-लाइन डेटा से अधिक रिच प्रोग्रेस ड्राफ्ट्स रेंडर कर सकता है, Block Kit लिमिट्स जब ट्रिमिंग फोर्स करती हैं तब न्यूएस्ट रिच प्रोग्रेस लाइन्स को रख सकता है, और लंबी टूल लाइन्स को कैप कर सकता है ताकि ड्राफ्ट हर अपडेट पर नहीं उछले। कॉम्पैक्ट एक्सप्लेन-मोड सारांश भी वर्बोज़ और प्रोग्रेस व्यूज़ के लिए डिफ़ॉल्ट हैं, जब आप स्पष्ट रूप से पूछते हैं तब रॉ डिटेल उपलब्ध होता है। ...

[NOVA]: यह बदलता है कि आप चैट में एजेंट से क्या करने को कह सकते हैं। आप लंबा काम शुरू कर सकते हैं और उम्मीद कर सकते हैं कि प्रोग्रेस सतह न्यूएस्ट उपयोगी स्टेटस को प्रेज़र्व करेगी बजाय wrapped लॉग्स की दीवार बनने के। सेटअप के लिए, नॉर्मल चैनल्स के लिए डिफ़ॉल्ट कॉम्पैक्ट प्रोग्रेस मोड चुनें, फिर एजेंट्स को डीबग करने या स्पेशलिस्ट सेशन के लिए टूल-प्रोग्रेस डिटेल बढ़ाएँ। चैट सतह को स्टेट दिखाना चाहिए, टूल आउटपुट के हर बाइट नहीं। ...

[ALLOY]: सबएजेंट रिज़ल्ट प्रिज़र्वेशन भी सुधरता है। जब डायरेक्ट कम्प्लीशन फॉलबैक सामान्य रिक्वेस्टर-एजेंट अनाउंसमेंट टर्न को बाइपास करता है, तब भी हर ग्रुप्ड चाइल्ड रिज़ल्ट प्रिज़र्व किया जाता है। सादे भाषा में: अगर आप कई चाइल्ड एजेंट्स को काम सौंपते हैं और रनटाइम एक फॉलबैक कम्प्लीशन पाथ का उपयोग करता है, तो चाइल्ड आउटपुट्स अनाउंसमेंट रूट बदलने की वजह से गायब नहीं होने चाहिए। ...

[NOVA]: यह अधिक विश्वसनीय डेलीगेशन को अनलॉक करता है। एक पैरेंट एजेंट चाइल्ड्स में रिसर्च, टेस्टिंग, या इम्प्लीमेंटेशन काम बाँट सकता है और अभी भी ग्रुप्ड रिज़ल्ट्स प्राप्त कर सकता है भले ही सामान्य अनाउंस टर्न स्किप किया गया हो। ऑपरेटर को इसकी जुडगMENT फाइनल रिज़ल्ट बंडल से करनी चाहिए: क्या हर चाइल्ड ने रिपोर्ट सर्वाइव किया, और क्या रिक्वेस्टर एजेंट अभी भी उन सभी से सिंथेसाइज़ कर सकता है? ...

[ALLOY]: स्टार्टअप डायग्नोस्टिक्स अधिक स्पष्ट हैं। Gateway स्टार्टअप अब फेज स्पैन, एक्टिव वर्क लेबल्स, स्टेल टर्मिनल ब्रिज मार्कर्स, और watch मोड में डिफ़ॉल्ट sync-I/O ट्रेसिंग रिकॉर्ड करता है। यह ready सिग्नल के बाद तक non-readiness साइडकॉर्स को डिफर भी करता है, hot-पाथ चैनल-पैकेज बैरल इम्पोर्ट्स से बचता है, ट्रस्टेड बंडल्ड मेटाडेटा को फास्ट-पाथ करता है, और native लोडिंग काफी होने पर सोर्स-ट्रांसफॉर्म पाथ को लोड करने से बचता है। ...

[NOVA]: तुरंत क्षमता निदान है। अगर स्टार्टअप धीमा है, तो आप उस चरण को खोज सकते हैं जो समय का मालिक है: मेटाडेटा डिस्कवरी, चैनल सेटअप, साइडकार लोडिंग, रेडीनेस वर्क, या स्टेल ब्रिज। बिना फेज स्पैन के, स्टार्टअप शिकायतें अनुमान-लगाने में बदल जाती हैं। स्पैन के साथ, आपके पास यह नक्शा होता है कि कहां ऑप्टिमाइज करना है या बग कहां फाइल करना है। ...

[ALLOY]: Windows को भी एक ठोस Gateway फिक्स मिलता है। डिफ़ॉल्ट लूपबैक लिसनर Windows पर 127.0.0.1 से बाइंड होता है ताकि IPv6 लूपबैक के आसपास डुअल-स्टैक localhost व्यवहार स्थानीय HTTP रिक्वेस्ट को न वेज करे। यह मायने रखता है क्योंकि स्थानीय एजेंट कंट्रोल अक्सर ब्राउज़र, Gateway, और कमांड-लाइन टूल्स पर निर्भर करता है जो लूपबैक रूट पर सहमत हों। ...

[NOVA]: सेटअप गाइड सरल है: Windows पर, डिफ़ॉल्ट लोकल Gateway बाइंडिंग का उपयोग करें जब तक कि आपके पास दूसरे इंटरफेस को एक्सपोज करने का कोई स्पष्ट कारण न हो। अगर लोकल HTTP कॉल फेल हो रहे थे क्योंकि क्लाइंट IPv4 और IPv6 लूपबैक पर असहमत थे, तो यह रिलीज़ स्पष्ट ट्रैप में से एक को हटा देती है। ...

[ALLOY]: एक साथ मिलाकर, बेहतर रनटाइम एजेंट को सात व्यावहारिक अपग्रेड देता है। यह बाउंडेड रियलटाइम ऑडियो व्यवहार के साथ लाइव Meet डायल-इन में बोल सकता है। यह Codex OAuth GPT-5.5 को API-की प्रोवाइडर के बजाय Codex प्रोवाइडर के माध्यम से रूट कर सकता है। यह बिना उनके सीक्रेट कॉन्ट्रैक्ट खोए बाहरी चैनल पैकेज का उपयोग कर सकता है। यह सीक्रेट लीक किए बिना मॉडल ऑथ प्रोफाइल का निरीक्षण कर सकता है। यह लंबे काम के दौरान कॉम्पैक्ट, स्ट्रक्चर्ड प्रोग्रेस दिखा सकता है। यह गार्डेड फेच से क्लीन टाइमआउट एरर रिटर्न कर सकता है। और यह फोकलोर के बजाय फेज-लेवल एविडेंस के साथ धीमे स्टार्टअप की व्याख्या कर सकता है। ...

[NOVA]: सेटअप सीक्वेंस जो मैं उपयोग करूंगा वो जानबूझकर बोरिंग है। पहले, रनटाइम अपग्रेड करें और Gateway रीस्टार्ट करें ताकि रेडीनेस पथ और स्टार्टअप स्पैन नए बिल्ड से हों। दूसरे, किसी भी महंगे मॉडल कॉल को चलाने से पहले ऑथ लिस्टिंग सरफेस के साथ मॉडल ऑथेंटिकेशन वेरीफाई करें। तीसरे, वेरीफाई करें कि चैनल एक्सटेंशन पैकेज इंस्टॉल है और इसका SecretRef कॉन्ट्रैक्ट Gateway स्टार्ट पर विजिबल है। चौथे, एक छोटी चैट जॉब शुरू करें और कॉम्पैक्ट प्रोग्रेस का निरीक्षण करें। पांचवे, तभी रियलटाइम Meet डायल-इन पथ टेस्ट करें। ...

[ALLOY]: Meet पथ के लिए, टेस्ट को मैकेनिकल रखें। वॉयस-कॉल रूट के माध्यम से मीटिंग जॉइन शुरू करें, कन्फर्म करें कि चुना गया रियलटाइम मॉडल और वॉयस स्पीच लॉग में दिख रहे हैं, एजेंट के जवाब देते समय बोलें, और तुरंत स्टॉप व्यवहार सुनें। फिर एक लंबा जवाब चलाएं और देरी वाले स्पीच के लिए देखें। अगर कतार ओवरलोड है, तो सही व्यवहार विजिबल स्ट्रीम क्लोज है, पुराने टर्न से दो-मिनट का घोस्ट मोनोलॉग नहीं। ...

[NOVA]: SecretRefs के लिए, सक्सेस कंडीशन भी मैकेनिकल है। एक चैनल क्रेडेंशियल को कॉन्फिग में पेस्ट करने के बजाय की द्वारा रेफरेंस्ड रहना चाहिए। एप्लाई या स्क्रब पथ को keyRef और tokenRef मेटाडेटा को प्रीजर्व करते हुए सीक्रेट मैटेरियल को रिमूव करना चाहिए। Gateway स्टार्टअप को चैनल पैकेज के कंपाइल्ड कॉन्ट्रैक्ट मेटाडेटा को रिज़ॉल्व करना चाहिए और चैनल को कॉन्फिगर्ड के रूप में मार्क करना चाहिए। अगर ये में से कोई भी स्टेप फेल होता है, तो अब आपके पास देखने के लिए एक संकरी जगह है। ...

[ALLOY]: प्रोग्रेस के लिए, चैट ड्राफ्ट को बहुत छोटे बजट के साथ एक ऑपरेटर डैशबोर्ड की तरह ट्रीट करें। इसमें करंट फेज, सबसे हालिया यूज़फुल टूल लाइन, और यह बताना चाहिए कि काम अभी भी जिंदा है या नहीं। इसमें हर रॉ लॉग लाइन को चैनल में पेस्ट नहीं करना चाहिए। जब आपको रॉ आउटपुट चाहिए, तो हर नॉर्मल यूज़र-फेसिंग वर्कफ्लो के लिए नहीं, बल्कि डीबगिंग एजेंट या सेशन के लिए टूल-प्रोग्रेस डिटेल बढ़ाएं। ...

[NOVA]: डेलिगेशन के लिए, दो-तीन चाइल्ड एजेंट्स के साथ टेस्ट करें और सुनिश्चित करें कि ग्रुप्ड रिज़ल्ट्स सर्वाइव करते हैं भले ही डायरेक्ट कम्प्लीशन फॉलबैक पथ का उपयोग किया जाए। एक मल्टी-एजेंट सिस्टम तभी यूज़फुल है जब पैरेंट पर भरोसा कर सकता है कि चाइल्ड आउटपुट रूटिंग चेंजेस में प्रिज़र्व्ड रहें। अन्यथा, डेलिगेशन चुपचाप सैंपलिंग बन जाता है: शायद पैरेंट ने सारा काम देखा, शायद नहीं। ...

[ALLOY]: स्टार्टअप के लिए, ऑपरेटर्स पहले क्या करते थे और अब क्या कर सकते हैं इसकी तुलना करें। पुराना लूप था रीस्टार्ट, वेट, गेस, लॉग खोलें, फिर से गेस। नया लूप होना चाहिए रीस्टार्ट, फेज स्पैन इंस्पेक्ट करें, पहचानें कि क्या समय डिस्कवरी, चैनल सेटअप, साइडकार्स, रेडीनेस, या टर्मिनल ब्रिज स्टेट का है, फिर ओनिंग फेज को फिक्स करें। यह एक असली सुधार है क्योंकि यह अस्पष्ट स्लो-स्टार्ट शिकायत को टारगेटेड बग रिपोर्ट या कॉन्फिग चेंज में बदल देता है। ...

[NOVA]: जाँच सूची भी उतनी ही ठोस है। वॉइस के लिए, बाधा डालने और ओवरलोडेड ऑडियो सेंड्स की जाँच करें। क्रेडेंशियल्स के लिए, SecretRef-बैक्ड चैनलों के साथ Gateway शुरू करें और सत्यापित करें कि वे प्लेन्टेक्स्ट के बिना कॉन्फ़िगर होते हैं। मेटाडेटा के लिए, वर्कस्पेस स्नैपशॉट के गर्म होने के बाद हॉट-पैथ लेटेंसी की तुलना करें। प्रगति के लिए, Slack में एक लंबा टूल जॉब चलाएँ और पुष्टि करें कि नवीनतम स्थिति ट्रिमिंग के बाद भी बनी रहती है। स्टार्टअप के लिए, अनुमान लगाने से पहले चरण स्पैन का निरीक्षण करें। ...

[ALLOY]: यह रिलीज वर्डिक्ट है: यह एक ऑपरेशंस रिलीज है। यह जादू बेचने की कोशिश नहीं कर रहा। यह रियलटाइम स्पीच, सीक्रेट्स, एक्सटर्नल पैकेजेस, मॉडल ऑथ, प्रगति, डेलिगेशन और स्टार्टअप को संचालित करना आसान बनाता है, सेटअप पाथ्स और फेलियर चेक्स के साथ जिन्हें ऑपरेटर वास्तव में दोहरा सकते हैं। अब हम बाहरी कहानियों में जा सकते हैं: पहले ग्राफ रनटाइम कंट्रोल, फिर इन्फरेंस सर्विंग स्टेबिलाइजेशन। ...

[NOVA]: LangGraph v1.2 Alpha लंबे समय चलने वाले एजेंट ग्राफ्स को टाइमआउट, रिकवरी, चेकपॉइंट और स्ट्रीमिंग समस्याओं में बदल देता है LangGraph v1.2 अल्फा एक वर्कफ़्लो-रनटाइम रिलीज है। महत्वपूर्ण बात यह नहीं है कि ग्राफ्स मॉडल्स को कॉल कर सकते हैं; यह है कि लंबे समय चलने वाले ग्राफ्स को एक्जीक्यूशन लिमिट्स, रिकवरी पाथ्स, चेकपॉइंट एफिशिएंसी और स्ट्रीमिंग प्रोजेक्शन की जरूरत है। जब किसी एजेंट वर्कफ़्लो में कई नोड्स, धीमे टूल्स, एक्सटर्नल APIs, रिट्राइज़, ह्यूमन इंटरप्ट्स और लंबा मैसेज हिस्ट्री होती है, तो रनटाइम को एक लूप और स्टेट ऑब्जेक्ट से ज्यादा की जरूरत होती है। ...

[ALLOY]: पर-नोड टाइमआउट सबसे स्पष्ट उदाहरण हैं। LangGraph add_node पर timeout= जोड़ता है, TimeoutPolicy के साथ जो run_timeout, idle_timeout या दोनों सेट कर सकता है। एक हार्ड रन टाइमआउट प्रोग्रेस की परवाह किए बिना वॉल-क्लॉक लिमिट के बाद अबॉर्ट करता है। एक आइडल टाइमआउट रीसेट होता है जब प्रोग्रेस यील्ड होती है और अबॉर्ट करता है जब कोई स्ट्रीमिंग नोड आउटपुट प्रोड्यूस करना बंद कर देता है। एजेंट टूल्स के लिए यह अंतर मायने रखता है। एक मॉडल कॉल, ब्राउज़र रन या एक्सटर्नल API स्ट्रीम को वैध रूप से समय लग सकता है, लेकिन एक साइलेंट हैंग को ग्राफ को हमेशा के लिए नहीं रोकना चाहिए। ...

[NOVA]: टाइमआउट केवल async नोड्स पर लागू होते हैं, और टाइमआउट के साथ sync नोड्स कंपाइल टाइम पर रिजेक्ट होते हैं। यह एक अच्छा कंस्ट्रेंट है क्योंकि Python arbitrary सिंक्रोनस वर्क को उसी तरह सुरक्षित रूप से इंटरप्ट नहीं कर सकता जैसे वह async प्रोग्रेस को मैनेज कर सकता है। रिलीज हार्टबीट-स्टाइल यील्ड्स को भी सपोर्ट करती है: एक async नोड ग्राफ की स्टेट को साफ रखते हुए आइडल क्लॉक को रीसेट करने के लिए एक खाली अपडेट यील्ड कर सकता है। यह डेवलपर्स को यह कहने का तरीका देता है, "यह टूल अभी भी जीवित है।" ...

[ALLOY]: जब टाइमआउट फायर होता है, LangGraph NodeTimeoutError रेज़ करता है, उस अटेम्प्ट से किसी भी राइट्स को क्लियर करता है, और रिट्राइ पॉलिसी को सौंपता है। राइट्स को क्लियर करना सबटल लेकिन महत्वपूर्ण हिस्सा है। अगर कोई नोड किसी ऑपरेशन के बीच में टाइमआउट हो जाता है, तो पार्शियल राइट्स ग्राफ की स्टेट को करप्ट कर सकते हैं। रनटाइम को या तो एक कोहेरेंट रिजल्ट कमिट करना चाहिए या अटेम्प्ट को फेल्ड मानना चाहिए। फिर रिट्राइज़ और रिकवरी हैंडलर्स तय कर सकते हैं कि आगे क्या करना है। ...

[NOVA]: नोड-लेवल एरर हैंडलर्स रिट्राइज़ exhaust होने के बाद रिकवरी पाथ जोड़ते हैं। एक error_handler एक typed NodeError receive करता है failing नोड नेम और exception के साथ, और एक Command रिटर्न कर सकता है जो स्टेट अपडेट करता है और दूसरे नोड पर रूट करता है। यह Saga-स्टाइल कम्पेंसेशन पैटर्न्स के लिए उपयोगी है: अगर रिट्राइज़ के बाद पेमेंट कैप्चर fail हो जाता है, तो स्टेट को compensated पर अपडेट करें और finalize पर रूट करें; अगर डॉक्यूमेंट पार्सिंग fail हो जाता है, तो पार्स एरर रिकॉर्ड करें और fallback सम्मारिज़र पर रूट करें; अगर कोई ब्राउज़र एक्शन fail हो जाता है, तो पेज स्टेट mark करें और स्क्रीनशॉट ऑडिट पाथ पर स्विच करें। ...

[ALLOY]: रनटाइम डिज़ाइन यहाँ explicit है। रिट्राइ ट्रांज़िएंट फेलियर handle करता है। एरर हैंडलर exhausted फेलियर handle करता है। कमांड स्टेट अपडेट और रूट सेलेक्शन handle करता है। इंटरप्ट्स हैंडलर को bypass करते हैं, जो matter करता है क्योंकि किसी ह्यूमन या सिस्टम इंटरप्ट को ordinary टूल फेलियर के रूप में disguise नहीं किया जाना चाहिए। यह सेपरेशन ऑपरेशनल सेमांटिक्स को समझने योग्य रखता है। ...

[NOVA]: DeltaChannel चेकपॉइंट overhead address करता है। लंबे समय चलने वाले थ्रेड्स में, message लिस्ट्स जैसे चैनल्स समय के साथ बड़े होते हैं। डेल्टा mechanism के बिना, हर चेकपॉइंट पूरे accumulated वैल्यू को re-serialize कर सकता है। DeltaChannel हर स्टेप पर केवल incremental डेल्टा स्टोर करता है और snapshot_frequency के माध्यम से कॉन्फ़िगर की गई स्टेप्स की संख्या पर हर बार एक full स्नैपशॉट राइट करता है। यह cost मॉडल बदलता है। बड़े होते चैनल्स के लिए राइट्स सस्ते हो जाते हैं, जबकि रीड्स को अगले स्नैपशॉट तक डेल्टास से reconstruct करना पड़ सकता है। ट्यूनिंग सवाल यह है कि स्नैपशॉट कितनी बार लेना है ताकि रीप्ले लेटेंसी bounded रहे full-वैल्यू चेकपॉइंट bloat में वापस जाए बिना। ...

[ALLOY]: यह एजेंट सिस्टम्स के लिए directly relevant है क्योंकि message histories, tool traces, event लिस्ट्स और observations जल्दी बड़े हो सकते हैं। अगर हर चेकपॉइंट पूरा history राइट करता है, तो durable एक्जीक्यूशन जितना लंबा कन्वर्सेशन चलेगा उतना महंगा होता जाता है। Delta-based चेकपॉइंटिंग लंबे थ्रेड्स को अधिक practical बनाती है, लेकिन इसके लिए reducers की जरूरत होती है जो correctly बैचेज ऑफ़ राइट्स merge करते हैं। एक बुरा reducer ordering खो सकता है या messages duplicate कर सकता है। एपिसोड को समझाना चाहिए कि DeltaChannel एक स्टोरेज कॉन्ट्रैक्ट है, just a परफॉर्मेंस फ्लैग नहीं। ...

[NOVA]: Streaming API content blocks aur typed per-channel projections ki taraf bhi move karti hai. Yeh isliye matter karta hai kyunki modern agent UIs sirf text stream nahi karte. Woh tool calls, intermediate reasoning summaries, progress events, generated artifacts, state updates, aur final messages stream karte hain. Ek streaming API jo per channel typed content project kar sake, clients ko right jagah right cheez render karne ka ek cleaner tarika deti hai. Yeh internal state updates ko user-visible answer text ke saath mix hone se bhi bachata hai. ...

[ALLOY]: Graceful shutdown bhi ishi discussion mein belong karta hai. Long-running graph runtimes ko bina checkpoints corrupt kiye ya tools ko unknown states mein chhodhe stop karna hota hai. Shutdown timeouts, retries, checkpoints, aur streaming ke saath interact karta hai. Agar kisi process ko shutdown signal mile jab ek node mid-attempt mein hai, toh runtime ko decide karna padta hai ki kya committed hai, kya baad mein retry hoga, aur user ko kya surface karna hai. LangGraph v1.2 alpha interesting hai kyunki yeh inhe first-class runtime concerns ke roop mein treat karta hai. ...

[NOVA]: Builders ke liye practical rating high hai agar woh durable workflows, multi-node agents, ya UI-facing graph streams run karte hain. Timeouts invisible hangs se bachate hain. Error handlers fallback ko explicit banate hain. DeltaChannel checkpoint pressure reduce karta hai. Typed streaming front-end rendering improve karta hai. Tradeoff yeh hai ki har naya control surface policy chahiye: timeout defaults, retry limits, snapshot frequency, compensation routes, aur stream visibility rules. ...

[ALLOY]: Setup implication yeh hai ki graph definition ko failure policy ko afterthought ke roop mein treat karna band karna chahiye. Timeout policy ko node ke saath hi rakho jo risk own karta hai. Ek browser node ko idle timeout chahiye ho sakta hai kyunki use progress yield karna chahiye. Ek payment ya write-side-effect node ko shorter run timeout aur specific compensation route chahiye ho sakta hai. Ek summarization node ko retries chahiye ho sakti hain lekin compensation nahi kyunki uska koi external side effect nahi hai. Alag nodes ko alag operational contracts milne chahiye. ...

[NOVA]: DeltaChannel ko production se pehle test bhi chahiye. Reducer ko message batches, tool events, aur state updates feed karo, phir deltas se reconstruct karo aur result ko full expected value se compare karo. Yeh ordering bugs aur duplicate-write bugs ko early catch karta hai. Ek chhota checkpoint tabhi win hai agar recovery se wahi graph state milti hai jo full checkpoint deta. ...

[ALLOY]: UI streaming ke liye, client ko mixed content ke saath test karna chahiye: normal text, tool-call blocks, progress events, aur final state updates. Typed projection ka point yeh hai ki transcript, progress panel, aur debug inspector ko same undifferentiated stream nahi milti. Agar front end un streams ko wapas ek text box mein collapse kar deta hai, toh runtime improvement wasted hai. ...

[ALLOY]: vLLM v0.20.1 Makes DeepSeek V4 Serving a Kernel, Communication, Cache, and Tool-Call Reliability Story vLLM v0.20.1 ek patch release hai, lekin yeh exactly wahi tarah ka patch release hai jispar inference operators ko dhyan dena chahiye. Yeh DeepSeek V4 stabilization aur performance improvements par focus karta hai after initial support v0.20.0 mein land hua. Yeh distinction matter karta hai. Initial support matlab model path exist karta hai. Production serving matlab kernels, communication paths, cache behavior, structured output, tool calls, CUDA graphs, aur memory checks load ke under stable hote hain. ...

[NOVA]: DeepSeek V4 ka kaam base model support aur multi-stream pre-attention GEMM se shuru hota hai. GEMM inference ka matrix-multiply workhorse hai, aur pre-attention computation batch shape aur model architecture par depend karke bottleneck ban sakta hai. Multi-stream execution us work ko overlap ya schedule karne ki koshish karta hai. vLLM ek configurable pre-attention GEMM knob add karta hai aur default VLLM_MULTI_STREAM_GEMM_TOKEN_THRESHOLD ko tune karta hai, jo operators ko bataata hai ki optimization workload-sensitive hai. Thresholds matter karte hain kyunki small batches ke liye right setting large token loads ke liye right nahi ho sakti. ...

[ALLOY]: BF16 aur MXFP8 ke liye all-to-all communication support FlashInfer one-sided communication points se distributed MoE problem ki taraf indicate karta hai. Expert-style models ko tokens ko devices ke across route karna padta hai. All-to-all communication expensive hai, aur low-precision formats bandwidth aur memory pressure reduce karte hain, lekin woh compatibility aur numerical concerns introduce karte hain. BF16 aur MXFP8 support karna matlab serving stack model ki precision aur performance profile ke saath communication path aligned rakhne ki koshish kar raha hai. ...

[NOVA]: FP32-to-FP4 conversion optimization ek aur serving-level detail hai. Low-bit inference memory aur bandwidth bacha sakta hai, lekin conversion overhead kuch win erase kar sakta hai agar yeh bahut slow ho. Faster FP32-to-FP4 conversion ke liye ek PTX cvt instruction us cost ko hardware path ke closer le jata hai. Yeh wahi tarah ka kernel work hai jisko users seedhe nahi dekhte, lekin yeh scale par throughput aur latency badal deta hai. ...

[ALLOY]: इंटीग्रेटेड टाइल कर्नेल ऑप्टिमाइज़्ड हेड कंप्यूटेशन के लिए वही पैटर्न जारी रखते हैं। प्रोडक्शन में attention और head computation अमूर्त गणित नहीं हैं; ये टाइल साइज़, मेमोरी लेआउट, हार्डवेयर occupancy और synchronization costs बन जाते हैं। head_compute_mix_kernel के बारे में एक release note ऑपरेटर्स को बताता है कि model support Python API layer के नीचे ट्यून किया जा रहा है। वहीं से कई बड़े-मॉडल serving gains आते हैं। ...

[NOVA]: Bug fixes परफॉर्मेंस वर्क जितने ही ज़रूरी हैं। vLLM TopK 1024 पर एक पर्सिस्टेंट TopK cooperative deadlock और RadixRowState पर एक inter-CTA initialization race को ठीक करता है, जिसमें temporary persistent TopK disable करना workaround के तौर पर किया गया है। Deadlocks और inter-block races खतरनाक हैं क्योंकि ये सिर्फ कुछ batch sizes, model paths या GPU schedules पर ही दिख सकते हैं। एक inference server छोटे टेस्ट में healthy दिख सकता है और फिर किसी particular production shape के तहत hang हो सकता है। Safe operator response ये है कि इन fixes को stability prerequisites माना जाए, optional performance polish नहीं। ...

[ALLOY]: AOT compile cache loading, torch inductor errors और repeated RoPE cache initialization को भी fixes मिलते हैं। ये deployment friction points हैं। Ahead-of-time compile caches startup या warmup cost कम करने के लिए होते हैं, लेकिन cache-loading import error serving को पूरी तरह block कर सकता है। Torch compiler errors सिर्फ specific graph या kernel paths के तहत ही दिख सकते हैं। Repeated RoPE cache initialization काम बर्बाद करता है और latency spikes बना सकता है। Stable inference इन छोटे-छोटे pieces के एक साथ काम करने पर निर्भर है। ...

[NOVA]: Tool-call behavior को एक notable repair मिलता है: DeepSeek V3.2 और V4 में non-streaming tool calls के लिए missing type conversion। यह agent systems के लिए मायने रखता है। एक model fast हो सकता है लेकिन agent systems के लिए unusable हो सकता है अगर structured outputs या tool calls एक response mode में break करते हैं। Non-streaming और streaming paths में अक्सर अलग parsers और conversion points होते हैं। ऑपरेटर्स को दोनों को काम करना चाहिए अगर वे batch evaluation, synchronous API calls और streaming chat support करते हैं। ...

[ALLOY]: General vLLM fixes उसी production theme को reinforce करते हैं। max_num_batched_token CUDA graph state में captured है। num_gpu_blocks_override max-model-length checks में accounted है। Expandable segments cumem memory pool के आसपास auto-disable हैं। Reasoning parser kwargs structured output को pass किए जाते हैं। Quark W4A8 GPT-OSS के लिए ROCm paths को argument fixes मिलते हैं। ये headline features नहीं हैं, लेकिन ये configuration, graph capture, memory allocation, parser behavior और hardware backend के बीच mismatches prevent करते हैं। ...

[NOVA]: vLLM release का DeepSeek V4 part एक रिमाइंडर है कि model serving एक product feature से पहले systems problem है। एक model path load हो सकता है, एक test prompt answer कर सकता है, और फिर भी real serving pressure के तहत fail कर सकता है। यह pressure batch shape, expert routing, graph capture, memory pool behavior, parser modes और tool-call envelopes के ज़रिए आता है। ...

[ALLOY]: Multi-stream pre-attention GEMM एक अच्छा example है क्योंकि feature सिर्फ faster या slower नहीं है। यह token thresholds, workload shape, hardware scheduling और क्या overlapping work actual utilization improve करता है, इस पर निर्भर करता है। ऑपरेटर्स को ऐसे knob को universal speed guarantee की तरह नहीं, बल्कि अपने own traffic को benchmark करने के signal के तौर पर पढ़ना चाहिए। ...

[NOVA]: All-to-all communication matter करता है क्योंकि MoE-style serving tokens को devices के बीच push करता है। Model mathematically sparse हो सकता है, लेकिन infrastructure को routing data, activations और expert work को high speed पर move करना होता है। इस communication path में BF16 और MXFP8 support bandwidth, precision और hardware fit के बारे में है। एक weak communication path specialized kernels के gains erase कर सकता है। ...

[ALLOY]: Deadlock और race fixes performance notes से भी ज़्यादा important हैं। एक persistent TopK deadlock tiny health check में show नहीं हो सकता। एक inter-CTA initialization race particular schedule पर निर्भर कर सकता है। ये production-shaped bugs हैं: casual testing से पास होने के लिए достаточно rare, लेकिन wrong load के तहत serving path को freeze करने के लिए достаточно severe। ...

[NOVA]: CUDA graph capture fixes उसी category में हैं। Graph capture stable shapes, memory behavior और configuration invariants मानता है। अगर max batched token state, GPU block overrides या memory pool settings उन assumptions से बाहर drift करते हैं, तो optimization एक correctness bug बन सकता है। Serving stacks को guardrails चाहिए जो unsafe configurations को reject करें, बिना वो runtime surprises बनें। ...

[ALLOY]: टूल-कॉल रूपांतरण एजेंट-फेसिंग एज है। एक सर्वर खूबसूरत गद्य जनरेट कर सकता है, फिर भी एजेंट्स के लिए बेकार हो सकता है अगर नॉन-स्ट्रीमिंग टूल-कॉल पथ गलत टाइप्स रिटर्न करता है। स्ट्रीमिंग और नॉन-स्ट्रीमिंग अक्सर अलग पार्सर पथों के जरिए लागू किए जाते हैं, इसलिए दोनों की जांच जरूरी है। एजेंट वर्कलोड के लिए, स्ट्रक्चर्ड आउटपुट विश्वसनीयता अनुमान का एक सहायक नहीं है। यह सर्विंग की सही-सही भूमिका का हिस्सा है। ...

[NOVA]: इसीलिए इस तरह के पैच रिलीज़ ध्यान देने योग्य हैं। वे स्थिर सर्विंग के पीछे की अदृश्य चेकलिस्ट को प्रकट करते हैं: कर्नेल, संचार, क्वांटिज़ेशन रूपांतरण, कैश लोडिंग, RoPE इनिशियलाइज़ेशन, CUDA ग्राफ इनवेरिएंट्स, मेमोरी पूल पॉलिसी, स्ट्रक्चर्ड-आउटपुट पार्सर आर्ग्यूमेंट्स, और हार्डवेयर-स्पेसिफिक बैकएंड्स। जब ये टुकड़े एक साथ मिलते हैं, तो मॉडल API की तरह अनुभव होता है। जब नहीं होते, तो मॉडल लैब बिल्ड की तरह लगता है। ...

[ALLOY]: vLLM ऑपरेटर्स के लिए, सबसे सुरक्षित जवाब पैच नोट्स को लोड-टेस्ट चेकलिस्ट बनाना है। उन बैच शेप्स की जांच करें जो TopK पथों को हिट करते हैं। उस DeepSeek टूल-कॉल मोड की जांच करें जो आप एजेंट्स को एक्सपोज़ करते हैं। CUDA ग्राफ कैप्चर की जांच उसी मेमोरी और मॉडल-लेंथ कॉन्फ़िगरेशन के साथ करें जो प्रोडक्शन में उपयोग होता है। उन कोल्ड स्टार्ट्स की जांच करें जो कंपाइल कैश पर निर्भर करते हैं। और स्ट्रीमिंग और नॉन-स्ट्रीमिंग दोनों रिस्पॉन्स की जांच करें, क्योंकि पार्सर बग अक्सर केवल एक तरफ रहते हैं। ...

[NOVA]: बड़ा पैटर्न यह है कि विश्वसनीयता का काम शायद ही कभी एक नाटकीय फिक्स होता है। यह छोटे इनवेरिएंट्स की एक श्रृंखला है जो एक साथ मौजूद रहते हैं। कर्नेल को सही तरीके से कंप्यूट करना होगा। संचार पथ को कुशलता से रूट करना होगा। कैश को एक बार इनिशियलाइज़ करना होगा और प्रेडिक्टेबली लोड करना होगा। मेमोरी पूल को लिमिट्स का सम्मान करना होगा। पार्सर को वह टाइप्स रिटर्न करने होंगे जिन पर कॉलर भरोसा कर सकता है। जब एक इन्फरेंस सर्वर फेल होता है, तो यह आमतौर पर इसलिए होता है क्योंकि उस श्रृंखला का एक लिंक प्रोडक्शन-शेप्ड वर्कलोड के तहत टूट गया। ...

[NOVA]: बड़ा सबक यह है कि एक नए फ्रंटियर या ओपन-वेट मॉडल की सर्विंग एक फीचर नहीं है। यह एक स्टैक है: मॉडल कॉन्फ़िग, टोकनाइज़र व्यवहार, अटेंशन बैकएंड, MoE रूटिंग, संचार प्रेसिज़न, क्वांटिज़ेशन, कंपाइल कैश, CUDA ग्राफ कैप्चर, मेमोरी पूल पॉलिसी, स्ट्रक्चर्ड आउटपुट पार्सर, टूल-कॉल कन्वर्टर, और हार्डवेयर-स्पेसिफिक बैकएंड। vLLM v0.20.1 मूल्यवान है क्योंकि यह दिखाता है कि स्थिरीकरण का काम कितना खुले तौर पर होता है। बिल्डर्स को इन पैच रिलीज़ को उस मैप के रूप में पढ़ना चाहिए कि उनके अपने इन्फरेंस डेप्लॉयमेंट कहाँ फेल हो सकते हैं। ...

[ALLOY]: सेटअप सलाह यह है कि एक सर्विंग एसेप्टेंस टेस्ट बनाए रखें जो रियल एजेंट ट्रैफिक की तरह दिखे। इसमें एक सादा कम्प्लीशन, एक स्ट्रक्चर्ड-आउटपुट रिक्वेस्ट, एक स्ट्रीमिंग टूल-कॉल रिक्वेस्ट, एक नॉन-स्ट्रीमिंग टूल-कॉल रिक्वेस्ट, और एक लॉन्ग-कॉन्टेक्स्ट बैच शामिल करें जो कैश और ग्राफ-कैप्चर सेटिंग्स को एक्सरसाइज़ करे। फिर हर सर्विंग अपग्रेड के बाद यह रन करें। अगर सिर्फ सादा कम्प्लीशन पास हो, तो मॉडल सर्वर अभी रियल प्रोडक्शन एजेंट यूज़ में लोड के तहत एजेंट्स के लिए तैयार नहीं है। ...

[ALLOY]: यहाँ एक आखिरी बिल्डर सबक है। इंसिडेंट्स का इंतज़ार न करें कि आपके टाइमआउट, क्यू, चेकपॉइंट, और पार्सर पॉलिसी का क्या मतलब है। उन्हें लिख दें, जांचें, और उन्हें उन टूल्स में एक्सपोज़ करें जो ऑपरेटर्स पहले से उपयोग करते हैं। अगर वॉइस क्यू बंद हो जाता है, एक ग्राफ नोड टाइम आउट हो जाता है, या इन्फरेंस पार्सर एक टूल कॉल को रिजेक्ट करता है, तो सिस्टम को बताना चाहिए कि किस पॉलिसी ने फायर किया और क्या स्टेट सेव किया गया। ...

[NOVA]: यह एक प्रभावशाली एजेंट स्टैक और एक मेंटेनेबल एक के बीच का अंतर है। मेंटेनेबल स्टैक में ओवरलोड से पहले सीमाएं होती हैं, मिस्ट्री फेलियर्स से पहले टाइप्ड एरर्स होते हैं, प्रोसेस डेथ से पहले चेकपॉइंट्स होते हैं, और यूज़र्स को अनुमान लगाने से पहले स्ट्रक्चर्ड प्रोग्रेस होती है। इस एपिसोड के टेक्नोलॉजीज़ अलग हैं, लेकिन इंजीनियरिंग पोस्चर एक ही है: रनटाइम बाउंड्रीज़ को इतना स्पष्ट बनाएं कि ह्यूमन्स उन्हें ऑपरेट कर सकें। ...

[NOVA]: एपिसोड नोट्स और सोर्स लिंक्स के लिए, Toby On Fitness Tech dot com पर जाएं। ...

[ALLOY]: OpenClaw Daily के लिए बस इतना ही। सुनने के लिए धन्यवाद, और जल्द ही वापस आएंगे। ...