चाबियाँ, खर्च और deployment के विकल्प

model deployment (मॉडल चलाने का नाम वाला endpoint) वह पता है जिसे आपका code या agent कॉल करता है। अवधारणा 1 में deployment समझाया गया; अवधारणा 2 में Microsoft Foundry portal में deployment बनाने के चरण थे। यह अवधारणा आगे के फैसले बताती है: कौन सा deployment type चुनें, subscription में क्षमता कैसे बँटती है, कॉल कौन कर रहा है यह कैसे साबित हो, और token इस्तेमाल से अचानक बिल कैसे न बने।

Foundry में भुगतान Azure subscription का होता है, और काम Foundry project में होता है। deployments और quota (ऊपरी सीमा) ज़्यादातर resource और subscription पर रहते हैं। साइन इन का तरीका तय करता है कि कॉल किसी व्यक्ति या app से जुड़ सकती है या नहीं। खर्च tokens और आरक्षित क्षमता से आता है, और जुड़ी Azure services से भी।

serverless API विकल्प से model deploy करते समय आप deployment type चुनते हैं। इसी से तय होता है prompt और जवाब का डेटा model चलते समय कहाँ संसाधित हो सकता है, billing कैसे होगी, और भारी load पर सेवा कितनी स्थिर रहेगी। Microsoft Foundry में मुख्य समूह हैं: हर token पर भुगतान वाला standard, आरक्षित provisioned throughput, और सस्ती batch processing।

संग्रहित डेटा Foundry resource की geography में रहता है, लेकिन model चलते समय का संसाधन deployment type से तय होता है। Global types prompt और जवाब किसी भी Azure region में संसाधित कर सकते हैं। Data Zone types US, EU, या APAC zone के अंदर रखते हैं। Standard और Regional Provisioned चुनी geography के अंदर संसाधित करते हैं। नए काम के लिए ज़्यादातर मामलों में Global Standard से शुरू करें, जब तक संगठन संकरा दायरा न माँगे।

• Global Standard तब चुनें जब सबसे ज़्यादा regions, standard types में सबसे कम कीमत, और सबसे ज़्यादा default quota चाहिए।
• Global Provisioned या Regional Provisioned तब चुनें जब traffic स्थिर हो और सिर्फ हर token पर भुगतान की बजाय आरक्षित क्षमता चाहिए।
• Global Batch या Data Zone Batch तब चुनें जब काम घंटों इंतज़ार कर सके और तुरंत जवाब की बजाय batch pricing चाहिए।

instant access (preview) के अलावा, production code में catalog model name नहीं भेजना चाहिए। आम रास्ते में deployment बनाएँ, deployment name लिख लें, और SDK या REST में वही name भेजें। अवधारणा 2 portal flow बताती है: Discover या Build में model ढूँढें, Deploy चुनें, Default settings लें, और status Succeeded होने तक रुकें।

• हर Foundry resource पर subscription quota rules के तहत प्रति region अधिकतम 32 model deployments हो सकते हैं—नाम ऐसे रखें कि टीमें एक-दूसरे से न टकराएँ।
• deployment के बाद model playground उसी deployment पर खुलता है, ताकि agent जोड़ने से पहले prompts का परीक्षण कर सकें।
• instant access (preview) deployment बिना supported models को model name से कॉल करने देता है। preview के दौरान Foundry project West US 3 में होना चाहिए, और project या account पर Foundry User role चाहिए।
• instant access वही SDK और project endpoint इस्तेमाल करता है जो deployments करते हैं; samples में az login के बाद DefaultAzureCredential इस्तेमाल होता है।

उदाहरण: एक छोटी online shop सहायता assistant बनाती है। टीम gpt-5-mini को Global Standard पर deploy करती है, deployment name app में डालती है, और ग्राहकों को दिखाने से पहले playground में छोटे test prompts भेजती है।

quota subscription के लिए ऊपरी सीमा है कि एक model deployment type से कितने tokens या requests भेजे जा सकते हैं। Tokens per minute (TPM) और requests per minute (RPM) shared Azure capacity की रक्षा करते हैं। deployment TPM से आगे निकलने पर callers को आम तौर पर HTTP 429 Too Many Requests मिलता है। Microsoft Foundry में पूरे subscription पर quota गिनना 7 मई 2026 के बाद शुरू हुआ: जिन models पर यह नियम लागू है, उनमें एक subscription में same model और version की सभी Global Standard deployments सभी regions में एक pool साझा करती हैं, और Data Zone Standard deployments हर data zone में एक pool साझा करती हैं।

• Foundry portal में Manage toolbar button से Quota pane खोलें। default में active deployments वाले models दिखते हैं; Show all चालू करके जिन models को deploy नहीं किया उन regions को भी देखें।
• Scope column जाँचें। Global या Data Zone जैसे मान का मतलब है पूरे subscription के लिए एक साझा pool; region name का मतलब है उस model के लिए उस region में अलग quota।
• जब परीक्षण pass हों लेकिन सीमाएँ production रोकें, Foundry quota increase process से और model quota माँगें।

Pools साझा हैं, इसलिए East US में एक टीम का भार परीक्षण West Europe में दूसरी deployment के लिए quota खा सकता है। बड़े प्रयोगों से पहले deployment types और regions पर सहमति बनाएँ।

Subscription quota Azure capacity की रक्षा करता है। AI Gateway हर project के लिए अलग सीमा देता है ताकि एक project संगठन के सारे tokens न खींच ले। gateway clients और model deployments के बीच होता है और traffic linked Azure API Management instance से गुज़ारता है।

• पहले AI Gateway configured Foundry resource चाहिए, और ऐसा project जिसका deployment उस gateway से जुड़ा हो।
• Microsoft Foundry portal में Manage चुनें, फिर AI Gateway, gateway खोलें, फिर Token management।
• + Set limit चुनें, project और deployment चुनें, और tokens-per-minute सीमा भरें।
• चाहें तो hourly, daily, weekly, monthly, या yearly जैसे period के लिए total token quota भी सेट करें।
• TPM पार होने पर callers को 429 Too Many Requests; quota period खत्म होने पर 403 Forbidden मिलता है।

ये सीमाएँ तब लगाएँ जब कई teams एक subscription साझा करती हों और Azure-wide quota खत्म होने से पहले भी लागत या नियमों के लिए पक्की ऊपरी सीमा चाहिए।

हर deployment call पर यह साबित करना होता है कि कॉल कौन कर रहा है। Foundry API keys और Microsoft Entra ID दोनों स्वीकार करता है। नियत roles सिर्फ Entra ID के साथ काम करते हैं; resource API key बिना role जाँच के पूरी पहुँच देती है, इसलिए production के लिए Microsoft Entra ID की सिफारिश है।

• API keys स्थानीय prototype के लिए तेज़ हैं, लेकिन वे यह नहीं बतातीं कि कौन व्यक्ति request भेज रहा है, और उन्हें संकरे दायरे में सीमित करना मुश्किल है।
• Microsoft Entra ID हर user या app को identity देता है। SDK quickstarts az login के बाद DefaultAzureCredential इस्तेमाल करते हैं, या REST परीक्षण के लिए az account get-access-token --scope https://ai.azure.com/.default से थोड़ी देर का token।
• portal और project काम के लिए Foundry resource पर Foundry User role दें। app चलते समय deployment कॉल के लिए resource पर Foundry User चाहिए, या resource API key। Foundry projects के लिए Azure AI Developer role न दें—यह Azure Machine Learning workspaces और Foundry hubs पर लागू है, project काम पर नहीं।
• Entra से model कॉल के लिए app या user को Foundry resource पर Cognitive Services User role दें, जैसा Azure AI services authentication में लिखा है।

keys को source control में commit न करें और chat में share न करें। Azure में चलने वाले apps के लिए managed identities बेहतर हैं, ताकि configuration में लंबे समय का secret न रहे।

• Pay-per-token deployments (Global Standard, Standard, Data Zone Standard) इस्तेमाल किए input और output tokens का bill बनाते हैं। Provisioned deployments आरक्षित PTUs का bill बनाते हैं, चाहे इस्तेमाल हो या न हो।
• Global Batch और Data Zone Batch तुरंत जवाब की बजाय batch pricing देते हैं—Global Standard की तुलना में लगभग 50% बचत, लगभग 24 घंटे के अंदर नतीजे का लक्ष्य, और real-time service level agreement नहीं।
• instant access (preview) फिर भी tokens खर्च करता है; deployment setup हटाता है, metering नहीं। Foundry platform explore करने के लिए मुफ़्त है, लेकिन हर service अपनी rate पर bill होती है।

Azure Cost Management में subscription या resource group के लिए budget सेट करें। budgets सीमा पार होने पर email alerts भेजते हैं; usage नहीं रोकते। cost और usage data आम तौर पर 8–24 घंटे में दिखता है, और budgets लगभग हर 24 घंटे में उस data के मुकाबले जाँच होती है, इसलिए पहला alert सावधानी से सेट करें।

परीक्षण बढ़ाने से पहले Azure pricing calculator और Microsoft Foundry pricing pages से model और Agent Service charges का अनुमान लगाएँ। playground evaluations default में चालू हो सकती हैं और consumption billing में शामिल हो सकती हैं—अगर सिर्फ आम आज़माइश चाहिए तो agents playground में evaluators बंद करें।

• Production code में catalog model name भेजना deployment name की बजाय (जब तक West US 3 में जानबूझकर instant access न चुन रहे हों)।
• यह मान लेना कि free to explore का मतलब model use मुफ़्त—token और provisioned charges फिर भी लगते हैं।
• Shared subscription quota नज़रअंदाज़ करना, जिससे एक deployment दूसरे को 429 errors दे।
• Shared repositories में API keys पर भरोसा करना Entra ID और Foundry User assignments की बजाय।
• Global Batch चुनना उस chatbot के लिए जिसे तुरंत जवाब चाहिए—batch jobs लगभग 24 घंटे के अंदर पूरे होने का लक्ष्य रखते हैं।

अवधारणा 5 prompts और model settings बताती है—वे विकल्प जो हर request में कितने tokens लगेंगे बदलते हैं। पहले deployment type और साइन इन का तरीका सेट करें, ताकि वे प्रयोग सही endpoint और identity पर चलें।

• deployment types और डेटा कहाँ संसाधित होता है, इसकी पूरी तुलना: Deployment types for Microsoft Foundry Models
• Subscription-level quota pools और default सीमाएँ: Microsoft Foundry Models quotas and limits
• प्रति project TPM और total token quota सेट करें: Enforce token limits for models
• Azure में budgets और alert thresholds बनाएँ: Create and manage budgets in Azure Cost Management