Models | The .NET Blog

Foundry में Claude Opus 4.8 एक और संकेत है कि Model Choice एक Platform Feature बन रहा है

Emiliano Montesdeoca — Mon, 15 Jun 2026 00:00:00 +0000

यह लेख स्वचालित रूप से अनुवादित किया गया है। मूल संस्करण के लिए, यहां क्लिक करें.

किसी बिंदु पर, मॉडल उपलब्धता की घोषणाएं सिर्फ विशिष्ट मॉडल के कारण दिलचस्प होना बंद कर देती हैं।

वे दिलचस्प हो जाती हैं क्योंकि वे प्लेटफॉर्म की कहानी को मजबूत करती हैं।

यह है कि मैं Claude Opus 4.8 को Microsoft Foundry में आते हुए कैसे पढ़ता हूं।

मॉडल महत्वपूर्ण है, लेकिन बड़ी कहानी ज्यादा महत्वपूर्ण है

हाँ, Claude Opus 4.8 अपने आप में एक महत्वपूर्ण मॉडल अपडेट है।

लेकिन मुझे लगता है कि अधिक उपयोगी संकेत यह है कि Foundry अपने गंभीर मॉडल विकल्प को एक प्रबंधित ऑपरेटिंग सतह के तहत विस्तारित करता रहता है।

यह महत्वपूर्ण है क्योंकि यह टीमों को अधिक जगह देता है:

मॉडल को वर्कलोड से मेल खाना
लागत और क्षमता को संतुलित करना
जब मॉडल गुणवत्ता या मूल्य निर्धारण बदलता है तो लचीला रहना
शासन और तैनाती अनुशासन को एक जगह रखना

यह वह हिस्सा है जिसकी मुझे ज्यादा परवाह है।

यह प्लेटफॉर्म सोच के लिए क्यों महत्वपूर्ण है

अगर आपका AI प्लेटफॉर्म केवल तब काम करता है जब एक मॉडल विक्रेता हमेशा के लिए प्रभावशाली रहता है, तो आपके पास वास्तव में एक लचीला प्लेटफॉर्म नहीं है।

आपके पास अच्छी मार्केटिंग के साथ एक निर्भरता है।

तो हर बार जब Foundry एक और गंभीर मॉडल विकल्प जोड़ता है, तो दिलचस्प सवाल सिर्फ “क्या यह मॉडल अच्छा है?” नहीं है।

यह भी है:

क्या यह मेरी आर्किटेक्चरल लचीलापन को बढ़ाता है?
क्या यह विक्रेता लॉक-इन दबाव को कम करता है?
क्या यह वर्कलोड-विशिष्ट राउटिंग को अधिक वास्तविक बनाता है?

यह वह स्तर है जहां मॉडल उपलब्धता रणनीतिक रूप से उपयोगी हो जाती है।

मेरी राय

यह एक विशिष्ट मॉडल मील का पत्थर के बारे में कम है और Foundry के एक गंभीर बहु-मॉडल प्लेटफॉर्म की तरह व्यवहार जारी रखने के बारे में अधिक है।

यह बड़ी कहानी है।

और जितना अधिक Foundry उस कहानी को मजबूत करता है, यह उतना ही विश्वसनीय हो जाता है कि टीमें मॉडल विकल्प को संचालित कर सकें, सिर्फ प्रतिक्रिया करने के बजाय।

मूल पोस्ट: Claude Opus 4.8 is now available in Microsoft Foundry

Microsoft Foundry मई 2026: वे अपडेट जिन्हें मैं सच में ध्यान से देखूंगा

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

यह लेख स्वचालित रूप से अनुवादित किया गया है। मूल संस्करण के लिए, यहां क्लिक करें।

मासिक platform roundups बहुत जल्दी feature overload में बदल सकते हैं।

तो यहाँ What’s New in Microsoft Foundry | May 2026 का छोटा संस्करण है: platform उन क्षेत्रों में और गहराई से जा रहा है जो वास्तविक AI systems के लिए सबसे ज़्यादा मायने रखते हैं।

जिन धागों पर मैं नज़र रखूंगा वे हैं:

trace-based evaluation
broader model choice
stronger agent tooling
बेहतर managed isolation और cost visibility
Foundry Local के ज़रिए local AI के आसपास लगातार momentum

यह एक घना roundup है, इसलिए pattern count से ज़्यादा महत्वपूर्ण है

मूल लेख में बहुत सारे individual bullets हैं।

यह ठीक है, लेकिन मुझे नहीं लगता कि इस तरह की पोस्ट को feature-by-feature पढ़ना सबसे अच्छा तरीका है।

बेहतर सवाल यह है: platform किस दिशा को स्पष्ट रूप से reinforce कर रहा है?

और मुझे लगता है जवाब यह है:

Foundry agents के आसपास operational layers में मज़बूत हो रहा है, सिर्फ़ model catalog में नहीं।

यह बहुत अच्छा संकेत है।

सबसे महत्वपूर्ण theme trace-based evaluation है

अगर मुझे पूरे roundup से एक theme चुननी हो, तो वह शायद trace-based evaluation होगी।

क्यों? क्योंकि यह evaluation कहानी को इस तरह बदल देती है:

एक static dataset बनाना
benchmark चलाना
उम्मीद करना कि वह production को reflect करेगा

से बदलकर कुछ अधिक वास्तविक बनाती है:

वास्तविक behavior observe करना
वास्तविक traces evaluate करना
सिस्टम वास्तव में क्या कर रहा है, उससे सीखना

यह production AI के लिए कहीं अधिक mature model है।

Model breadth महत्वपूर्ण है, लेकिन तभी जब वह operable रहे

Grok, DeepSeek, Fireworks, और reinforcement fine-tuning से जुड़ी additions अपने-अपने तरीके से उपयोगी हैं।

लेकिन मेरे लिए ज़्यादा महत्वपूर्ण बात यह नहीं है कि बस एक और model आ गया।

महत्वपूर्ण यह है कि model breadth के साथ यह सब भी जुड़ रहा है:

operational visibility
evaluation tooling
governance surfaces
deployment consistency

यही चीज़ model ecosystem को chaos में बदलने से बचाती है।

Foundry Local एक recurring strategic signal बनता जा रहा है

एक और बात जिसे मैं ignore नहीं करूँगा, वह है कि Foundry Local अब Foundry story का एक serious हिस्सा बनता हुआ कितनी बार दिख रहा है।

इससे मुझे लगता है कि Microsoft अब local AI को side experiment नहीं मानता।

यह broader platform narrative का हिस्सा बन रहा है:

privacy
device-local inference
hardware portability
edge deployment
hybrid operational models

यह ध्यान देने योग्य है।

मेरी राय

Details महत्वपूर्ण हैं, लेकिन बड़ा pattern उससे भी ज़्यादा महत्वपूर्ण है।

Foundry उस दिशा में आगे बढ़ रहा है जहाँ agents, evaluations, models, local runtimes और governance ज़्यादा स्वाभाविक रूप से connect होते हैं।

यही दिशा मुझे सबसे ज़्यादा महत्व रखती है।

और यह roundup, कई छोटे individual announcements से भी ज़्यादा, उस दिशा को एक ही जगह पर देखना आसान बनाता है।

मूल लेख: What’s new in Microsoft Foundry | May 2026

AI विकास की सबसे मुश्किल बात अब पहुँच नहीं रही। सही मॉडल को अच्छे से चलाना है

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

यह लेख स्वचालित रूप से अनुवादित किया गया है। मूल संस्करण के लिए, यहां क्लिक करें.

हम उस चरण से आगे निकल चुके हैं जहाँ केवल एक शक्तिशाली model तक पहुँच होना पर्याप्त था।

यही बात इस नई Foundry guide to managing models, cost and quality में सही पकड़ी गई है।

असल चुनौती अब operational है:

हर workload के लिए सही model चुनना
उसे अपने data के खिलाफ validate करना
latency और spend को manage करना
upgrades और regression risk को govern करना

यही वह चीज़ है जिसमें गंभीर teams को अच्छा होना है।

स्रोत लेख समस्या को सही तरह परिभाषित करता है

मूल लेख की एक पंक्ति यह बदलाव बहुत अच्छी तरह पकड़ती है:

“आज AI systems बनाने का सबसे कठिन हिस्सा अब सक्षम model तक पहुँच नहीं है। यह जानना है कि एक वास्तविक application के पूरे lifecycle में सही model को कैसे चुनना, validate करना, optimize करना और operate करना है।”

यह बिल्कुल सही diagnosis है।

बहुत-सी टीमों को अब भी लगता है कि model selection ही मुख्य निर्णय है।

ऐसा नहीं है।

Model operation बड़ी समस्या है:

किस workload को कौन सा model मिलता है?
quality कैसे verify होती है?
स्वीकार्य cost shape क्या है?
जब नया model आता है या पुराना drift करता है तो क्या होता है?
real workflows तोड़े बिना change कैसे test करें?

अब यही असली engineering work है।

यह Foundry piece क्यों उपयोगी है

मुझे यह लेख इसलिए पसंद है क्योंकि यह AI systems के बारे में उसी तरह बात करता है जैसे अनुभवी platform engineers को सोचना पड़ता है।

ना कि “सबसे smart model चुनो और आगे बढ़ो”।

बल्कि ऐसे systems के रूप में जो trade-offs के नीचे रहते हैं:

capability
latency
cost
safety
governance
upgrade pressure

यह benchmark-driven optimism से कहीं अधिक उपयोगी है।

सबसे महत्वपूर्ण बदलाव criteria-first सोच है

मूल लेख model catalog खोलने से पहले success criteria define करने की सलाह देता है।

मुझे लगता है यह उन सबसे महत्वपूर्ण आदतों में से एक है जो teams अपना सकती हैं।

अगर आप पहले catalog खोलते हैं, तो आप reputation पर टिक जाते हैं।

अगर आप पहले criteria define करते हैं, तो आप workload reality पर टिकते हैं।

यह एक healthier process है।

क्योंकि जो model benchmark जीतता है, वही ज़रूरी नहीं कि जीतता हो:

आपके prompts पर
आपके latency budget पर
आपके cost guardrails के भीतर
आपकी governance requirements में

यही distinction mature AI engineering की शुरुआत है।

Multi-model कहानी एक वास्तविक advantage बन रही है

एक और चीज़ जो मुझे पसंद है, वह है model-agnostic framing।

लेख Foundry को single-model destination की तरह नहीं, बल्कि एक operating surface की तरह प्रस्तुत करता है:

Microsoft models
partner models
open-source models
post-trained variants
routing और optimization strategies

यह इसलिए मायने रखता है क्योंकि model flexibility अब luxury नहीं है। यह risk management का हिस्सा है।

यदि quality बदलती है, prices हिलते हैं, या quota सीमित हो जाती है, तो teams को options चाहिए।

Cost control secondary concern नहीं है

लेख यह भी सही कहता है कि cost एक architectural concern है।

यह “बाद में optimize करेंगे” वाली समस्या नहीं है।

अगर आप हर task को default रूप से सबसे heavy model पर भेजते हैं, तो यह demo में शानदार काम कर सकता है और production economics में ढह सकता है।

इसलिए मुझे लगता है कि sections on:

routing
batching
caching
provisioned throughput
quota management

कई लोगों की अपेक्षा से अधिक महत्वपूर्ण हैं।

जो teams cost discipline को system design का हिस्सा मानती हैं, वे उन teams से कहीं बेहतर उम्र पाएँगी जो इसे बाद की सफाई का काम मानती हैं।

मेरी राय

यह एक उपयोगी Foundry piece है क्योंकि यह AI systems के बारे में उसी तरह बात करता है जैसे अनुभवी engineers को वास्तव में उन्हें run करना पड़ता है।

ना कि demos की तरह। ना कि one-off prototypes की तरह। और ना ही leaderboard tourism की तरह।

बल्कि workloads, constraints, trade-offs, और निरंतर बदलाव के operating systems की तरह।

हमें बातचीत को इसी स्तर की ओर ले जाते रहना होगा।

और अगर आप production AI systems बना रहे हैं, तो यही mindset है जिसे teams को जल्दी internalize करना चाहिए।

मूल लेख: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry