Models, deployments, और fine-tuning

Model prompts को जवाब में बदलने वाला इंजन है। Deployment वह नाम वाला endpoint है जिसे आपका app या agent एक model version तक पहुँचने के लिए कॉल करता है, चुनी हुई capacity और billing के साथ। Fine-tuning तब का विकल्प है जब आपके examples पर extra training से व्यवहार बेहतर हो, और instructions व retrieval अब quality gap नहीं भर पाते। अवधारणा 4 में deployment types, keys, और quota आ चुके हैं; यह अवधारणा models चुनना, retirements के बीच चालू रखना, traffic को models में बाँटना, और customization कब लागत के लायक है, यह गहराई से समझाती है।

Catalog में कुछ भी production में तब तक नहीं चलता जब तक आप deploy न करें (या preview में सीमित instant access इस्तेमाल न करें)। Production code हर request में deployment name भेजता है। Model version, region support, deployment type, और lifecycle stage यह तय करते हैं कि endpoint अगले छह महीनों में भी उपलब्ध रहेगा या नहीं।

• Engineering time लगाने से पहले Foundry Models catalog से capability, कीमत, region, और lifecycle की तुलना करें।
• हर deployment का size deployment type rules (data कहाँ process हो और billing कैसे हो) और subscription quota (shared throughput pools) दोनों से मिलाकर तय करें।
• Fine-tuning को measured experiment समझें, evaluation के साथ—अच्छे prompts, knowledge, या safety controls का shortcut नहीं।

Microsoft Foundry portal खोलें और model catalog browse करें। Models दो समूहों में हैं: Foundry Models sold by Azure और Foundry Models from partners and community। यह बँटाव support, billing, और retirement dates कौन देता है, इसके लिए ज़रूरी है। हर entry में versions, supported regions, deployment types, और lifecycle stage labels (जैसे Preview जब model अभी experimental हो) दिखते हैं।

• ज़रूरी capability से सूची छाँटें: chat completion, reasoning, tool calling, embeddings, audio, या industry-specific models।
• जाँचें कि model version आपके Foundry project region में उपलब्ध है और जो deployment type आप चाहते हैं वह supported है।
• Catalog में provider का model card और description पढ़ें; lawful use और documented limits समझना आपकी ज़िम्मेदारी है।

Deploy से पहले playground या benchmarks से candidates compare करें। अवधारणा 8 में evaluators से quality score करना दिखाया गया था; model बदलते समय वही datasets दोबारा चलाएँ ताकि अनुमान की जगह numbers से तुलना हो।

Discover या Build से model चुनें, Deploy दबाएँ, और जब तक organization को Custom settings न चाहिए, Default settings रखें। Deployment name लिख लें; SDK calls catalog model name नहीं, यही name इस्तेमाल करती हैं। Production traffic जोड़ने से पहले Models + endpoints page पर status Succeeded दिखने तक wait करें। Serverless API deployments में deployment type तय करता है inference के दौरान prompts और answers कहाँ process हों, billing कैसे हो, और throughput कितनी मिले।

• जो data store होता है वह आपके resource geography में रहता है; live prompt और answer processing उसी deployment type के मुताबिक होता है जो आपने चुना।
• Foundry portal की Quota page पर Scope column देखें: Global या Data Zone का मतलब उस model version के लिए subscription-level shared pools; region name का मतलब per-region quota।
• हर model हर deployment type support नहीं करता; deploy fail हो तो उस model और region के लिए supported SKU चुनें।

Model Router एक Foundry model deployment है जो हर request के लिए underlying large language model चुनता है। आप इसे किसी chat model की तरह अपने router deployment name से कॉल करते हैं। Default में यह supported model set पर Balanced routing use करता है। ज़्यादातर underlying chat models आपको अलग deploy नहीं करने पड़ते; Model Router उन्हें खुद call करता है। Anthropic Claude models अपवाद हैं—custom subset में रखने से पहले catalog से deploy करें।

• Model catalog में model-router ढूँढें, deploy करें, और subset या non-default routing mode चाहिए तभी Custom settings use करें।
• Routing mode या model subset बदलने में पाँच मिनट तक लग सकते हैं।
• Production load shift करने से पहले fixed deployment के मुकाबले router traffic की परख करें; response में बताता है किस underlying model ने जवाब दिया।

हर catalog model preview से retirement तक किसी lifecycle stage में होता है। Deployment एक model version पर pinned रहता है। Version Retired होने पर inference 410 Gone देता है और deployment काम करना बंद कर देता है, इसलिए published date से पहले upgrade की योजना बनाएँ। GA replacements के लिए Microsoft overlap windows देता है ताकि पुराना version चलते हुए नया test कर सकें। Fine-tuned models के training और deployment का अलग retirement schedule होता है।

• Version तभी pin करें जब evaluation pass हो, फिर model retirements schedule की date से पहले move की योजना बनाएँ।
• अगले version पर दूसरी deployment रखें और scores baseline से match या बेहतर हों तब traffic shift करें।
• नए models आमतौर पर पहले Global Standard पर आते हैं; geography-bound types capacity खुलने पर बाद में आ सकते हैं।

Fine-tuning आपके task-specific data पर extra training से pretrained model adapt करता है—weights adjust होते हैं, हर prompt में और examples भरने से नहीं। Microsoft Foundry managed fine-tuning (data और settings submit) और interactive training (preview) देता है, जहाँ आप Foundry-managed infrastructure पर Python training loop चलाते हैं, GPUs provision किए बिना। फायदे guaranteed नहीं; hosting और inference pay करने से पहले अवधारणा 8 के held-out evaluation से fine-tuned model को baseline से compare करें।

Training type (Standard, Data zone, Global, या Developer) तय करता है training job कहाँ चले और pricing व residency कैसे लागू हों। Deployment type तय करता है trained artifact बाद में कैसे serve हो—ये अलग choices हैं। Training के बाद serverless hosting default path है; managed compute (preview) और Fireworks on Foundry (preview) अलग serving options देते हैं, अपने deployment type rules के साथ।

उदाहरण: एक online shop refund-policy wording consistent चाहता है। Team पहले knowledge search और prompts tune करती है, पर evaluators long threads पर tone drift flag करते हैं। Approved agent transcripts से कुछ सौ supervised examples बनाते हैं, queue cost कम रखने Global training पर managed SFT चलाते हैं, Global Standard endpoint पर deploy करते हैं, और वही evaluation set दोबारा चलाते हैं। Scores और cost prompt-only baseline से बेहतर हों तभी fine-tuned deployment production में लाते हैं।

• Data Foundry resource region में रहना चाहिए तो Standard training; US data zone में रहना चाहिए तो Data zone (आज सिर्फ US zone supported)।
• Price-sensitive experiments के लिए Developer training tier use करें, यह जानकर jobs preempt हो सकती हैं और residency guarantee नहीं।
• Data upload से पहले fine-tuning supported models table में method, training type, और deployment option support जाँचें।
• Interactive training preview है; sessions बनाने से पहले explicit access approval चाहिए।

• Production में catalog model name call करना deployment name की जगह (जब तक West US 3 Foundry projects में instant access preview जानबूझकर use न कर रहे हों)।
• Retired model या unavailable region deploy करना, फिर DeploymentModelNotSupported को transient error समझना।
• Playground चल रहा है इसलिए retirement dates ignore करना—upgrade की योजना product features वाले backlog में रखें।
• Noisy या duplicate data पर fine-tune करके held-out test set के बिना पहला checkpoint release करना।
• Claude models को Model Router subset में रखना बिना उन्हें same Foundry account पर deploy किए।

अवधारणा 11 agents, identity, workflows, और routines cover करती है—चुना हुआ model deployment users की तरफ tools call करने वाले agents का base कैसे बनता है। Deployment names, lifecycle dates, और evaluation baselines agent versions के साथ document रखें ताकि rollouts traceable रहें।

• Catalog categories, filters, और model lifecycle overview। What are Foundry Models?
• Lifecycle stages, overlap commitments, और retirement schedules। Foundry Models lifecycle and support policy
• Model Router deploy, routing modes, subsets, और monitoring। Use model router for Microsoft Foundry
• Training methods, training types, deployment options, और supported models। Fine-tuning in Microsoft Foundry