Foundry की architecture और rollout

Microsoft Foundry आपके AI काम को परतों में रखता है: साझा governance के लिए ऊपर Foundry resource, जहाँ टीमें बनाती और परीक्षण करती हैं वहाँ project, और storage, search और secrets के लिए जुड़ी Azure services। layout जल्दी सही रखने से टीमें एक-दूसरे की quota नहीं खातीं, access नहीं फैलता, और compliance बाद में मना कर दे—ऐसा deployment shape भी शुरू में नहीं चुन लेते।

Concept 8 में ship करने से पहले agent को नापना देखा। यह अवधारणा बताती है कि वह agent Azure में कहाँ रहे और Foundry टीमों में कैसे लाएँ, बिना security छेद या बेकाबू लागत के। resource और project model तब लें जब model access, agent hosting और evaluation एक जगह चाहिए; जब कई टीमों को अलग workspace पर shared deployment चाहिए; जब policy private networking, customer-managed encryption, या resource और project दोनों पर सीमित अनुमति माँगे; या जब standalone Azure OpenAI resource से आ रहे हों और policies रखकर agents और evaluations जोड़ना हो।

• Foundry आज़माने वाले अकेले developer के लिए एक Foundry resource और एक project शुरुआत के लिए सुझाया default है।
• अगर सिर्फ Azure OpenAI completions चाहिए, agent hosting या evaluation नहीं, तो standalone Azure OpenAI resource अभी काफी हो सकता है।
• कोई provision करे उससे पहले तय कर लें हर workload को कौन-सी Foundry सुविधाएँ और APIs चाहिए, क्योंकि हर API एक जैसी authentication, storage encryption, या project-level isolation नहीं देती।

Foundry resource (Azure में मुख्य खाता-संसाधन) वह ऊपरी Azure object है जहाँ IT जैसी सेटिंग्स रहती हैं: networking, security, model deployments, और दूसरी services से connections। Foundry project उस resource के अंदर workspace है जहाँ टीम agent बनाती है, evaluation चलाती है, files अपलोड करती है, और बार-बार setup किए बिना deployments दोबारा इस्तेमाल करती है। Project assets—files, agents, evaluations और संबंधित artifacts—उसी project की सीमा में रहते हैं।

Azure Storage, Azure Key Vault, और Azure AI Search जैसी जुड़ी resources अलग Azure services हैं। Foundry resource connections से उन्हें जोड़ता है, पर हर एक की अपनी governance सीमा रहती है। networking, access policies और compliance Foundry के अंदर ही नहीं—उन services पर अलग से संभालें।

• ज़्यादातर नए agent-centric APIs project scope पर मिलती हैं, इसलिए रोज़ का builder काम आमतौर पर project पर होता है।
• कुछ पुरानी Foundry Tools सुविधाएँ सिर्फ Foundry resource level पर रहती हैं—उदाहरण: Translator API project से नहीं, resource level से मिलती है। structure उन API scopes के हिसाब से बनाएँ जिन्हें आपका app कॉल करता है।
• Parent Foundry resource पर बनी connections उसके सभी projects को दिखती हैं; project पर बनी connection जब tighter isolation चाहिए तब सिर्फ उस project तक सीमित रहती है।

जब ऐसी सीमाएँ तय हो जाएँ जिन पर समझौता न हो—business units, data domains, environment tiers, और security incident का मालिक कौन—तब तय करें हर environment में कितने Foundry resources चाहिए। Microsoft की rollout guidance production को default पर isolation और exploration को default पर sharing मानती है, जब तक compliance अलग न माँगे।

Agent capabilities—agents, responses, evaluations, datasets, indexes, files, playground assets—shared resource के अंदर project-per-use-case layout में अच्छी तरह बैठती हैं। अगर हर टीम को अलग fine-tune चाहिए, अलग Foundry resources की योजना बनाएँ, क्योंकि fine-tune training default project से जुड़ा है और fine-tuned deployments resource के अंदर projects के बीच साझा होते हैं। Translator जैसी resource-scoped APIs पर strict isolation हो तो अलग resources सुरक्षित रास्ता है।

Foundry अलग करता है कौन platform बदल सकता है और कौन agent बनाने व चलाने के लिए इस्तेमाल करता है। Admin जैसे कामों में projects बनाना, deployments संभालना, connections जोड़ना शामिल है। Builder जैसे कामों में playground में chat, files अपलोड, evaluations चलाना, agents कॉल करना शामिल है। Azure role assignments Foundry resource, किसी project, या दोनों पर लग सकते हैं, ताकि अनुमति संकीर्ण रहे।

• असली लोगों और automation accounts को सबसे छोटी role दें जिससे काम चल जाए। common onboarding developer accounts को Foundry resource scope पर Foundry User देता है; जब टीमें एक-दूसरे की assets न देखें तो role project पर भी scope कर सकते हैं।
• Subscription Owner या Contributor हर builder scenario नहीं ढकते—कोई Azure resources संभाल सके, फिर भी portal में agent से chat के लिए अतिरिक्त Foundry roles चाहिए हो सकते हैं।
• Role names हाल में बदले (उदाहरण: Azure AI User से Foundry User); rename के दौरान role IDs और core permissions वैसे ही रहे।
• लोगों और services के लिए Microsoft Entra ID और role-based access पसंद करें; API keys तभी जब coarse access चले।

Microsoft Foundry portal में administrators Manage toolbar button से current project की Project details, Resource details, Users tab, Connected resources, और parent resource का Projects tab देखते हैं। दूसरी टीम की सेटिंग्स बदलने से पहले ऊपर बाएँ project name dropdown से project बदलें।

Model deployments इस आधार पर समूहित होती हैं कि inference data कहाँ process हो सकता है: global (cross-region), data zone (US या EU जैसी तय boundary के अंदर), या regional (एक Azure region)। यह चुनाव compliance को headline price से ज़्यादा चलाता है। Foundry rest data designated Azure geography में रखता है; prompts और completions inference समय deployment type के हिसाब से चलते हैं।

Data rules जितना strict अनुमति दें उतना strict scope चुनें, फिर commit से पहले target region में model, deployment type, Agents support, और evaluations support जाँचें। Foundry automatic cross-region failover नहीं देता; multi-region availability चाहिए तो region प्रति अलग Foundry resources deploy करें और routing व data sync app में संभालें। Production traffic से पहले models और agents की quotas और rate limits देख लें।

चरणबद्ध rollout workloads को shared exploration से सिद्ध होने पर मज़बूत isolation की ओर ले जाता है। कई संगठन innovation के लिए co-located Foundry resource रखते हैं—सीमित capacity और पहले से जुड़े data और tools—जबकि परिपक्व use cases को ही dedicated dev/test या production resources मिलते हैं, जहाँ policy private networking और customer-managed keys माँगे।

• Exploration policy colocation पर default रखें ताकि तेज़ी मिले, जब तक compliance isolation न माँगे; production policy isolation पर default रखें जब तक documented exception sharing की अनुमति न दे।
• Environment के हिसाब से networking: managed virtual network सरल secure setup के लिए, या bring-your-own virtual network जब पूरा control और custom routing चाहिए; production शुरू करने से पहले private DNS और private endpoint flow validate करें।
• Microsoft-managed encryption या customer-managed keys चुनें; customer-managed keys पर Key Vault Foundry resource के same region में soft delete और purge protection के साथ deploy करें।
• तय करें कौन projects बना सकता है, models deploy कर सकता है, external tools जोड़ सकता है; shared environments production load लेने से पहले budgets और token-based limits सेट करें।
• Rollout से पहले region feature support, resource और project role scopes, network paths, encryption और Key Vault connections, और quota headroom validate करें।

Agents, evaluations, और batch jobs Microsoft-managed compute पर चलते हैं। Agents external systems कॉल करें तो outbound isolation के लिए managed virtual network या अपने subnet में injection इस्तेमाल कर सकते हैं। कुछ पूरी तरह private setups SDK या CLI माँगते हैं—उदाहरण जब private endpoints सारा public access बंद कर दें।

मान लें Concept 8 वाली online shop का evaluated support agent है। shop shared exploration Foundry resource में शुरू करती है: support टीम के लिए एक project, बीच का GPT deployment और parent resource पर shared Azure AI Search index connection दोबारा इस्तेमाल। Developers को सिर्फ उस project पर Foundry User; deployment बनाना IT resource पर रखता है।

• APIs की सूची: project scope पर agent chat, evaluations, file search; resource-only Tools APIs जैसे Translator पर निर्भरता न हो, यह पुष्टि करें।
• Regional deployment type चुनें क्योंकि return policies चुने Azure region में रहनी चाहिए; उस region में model और Agents feature verify करें।
• नेतृत्व production के लिए बजट दे तक shared project में pilot; फिर production के लिए अलग Foundry resource, policy हो तो private link और customer-managed keys के साथ।
• Secrets और evaluation export production boundary में रहें, इसलिए Storage और Key Vault project-scoped connections से फिर जोड़ें।
• Storefront live shopper traffic published agent endpoint पर भेजे, उससे पहले production resource पर token limits और budget alerts सेट करें।

• मान लेना subscription पर एक Owner role से portal के सारे builder काम ढक जाते हैं।
• Setup बचाने के लिए unrelated data domains का एक production resource साझा करना।
• Legal ने एक region माँगा हो और फिर भी global deployments चुनना।
• Production agents public APIs कॉल करने लगने के बाद private networking जोड़ना।
• Peak holiday traffic पर throttling दिखे तब quota check करना।

अब Foundry resource, projects, connected services, topology, access patterns, deployment scopes, और staged rollout की तस्वीर साफ है। Concept 10 models, deployments, और fine-tuning में गहराई देता है—वे knobs जो shell संगठन में फिट हो जाने के बाद resource के अंदर घुमाते हैं।

• पूरा hierarchy diagram, storage modes, networking models, और validation checklist। Microsoft Foundry architecture
• Enterprise rollout steps, capability matrix, security baseline, और Contoso sample topology। Foundry rollout across my organization
• Role names, scopes, और admin बनाम builder tasks के लिए कौन-से combinations चाहिए। Role-based access control for Microsoft Foundry
• Regions और models finalize करने से पहले deployment limits और rate limits। Foundry Models quotas and limits