Lesson 123 — Advanced

Platform Anatomy: Bedrock, Vertex AI & Azure AI Foundry

Teen clouds ke teen AI platforms alag naam rakhte hain, par andar ka shape lagbhag ek hi hai: ek model catalog, ek endpoint style, ek identity system, ek network boundary aur ek bill. Is lesson mein hum wo shared shape samjhenge, catalog padhna seekhenge, aur ek platform par chalaya hua skill doosre par map karna.

Teeno platforms ka shared shape

Sabse badi baat: ek platform seekh lo, doosre ki docs padhne mein tumhe sirf vocabulary translate karni hai. Concept ek hi hai — project ya account kahan bana, model kis naam se pin hua, request kis format mein jaati hai, identity kis object se aati hai.

Model catalog padhna — model card ki tarah

{
  "model_id": "some-provider/some-model-v1",
  "provider": "upstream provider name",
  "modality": ["text", "image-input"],
  "available_regions": ["region-a", "region-b"],
  "lifecycle": "active | pending | retired",
  "invocation_modes": ["platform-unified", "provider-native"],
  "pricing": "per input token + per output token"
}

• Provider kaunsa hai: catalog entry upar se platform ki hai, andar se provider ki. Provider-native features (kuch tools, modalities) unified format mein kabhi kabhi nahi aate.
• Region listing: model har region mein nahi hota — allowed region hi tumhara design space hai.
• Lifecycle status: active, pending (aane wala), retired (jaane wala). Retirement ka notice period platform khud decide karta hai.
• Pricing model: per token input/output, kabhi kabhi batch ya provisioned options alag rate par. Catalog page hi asli source hai — rate guess mat karo.

Platform se invoke karna — unified API ka shape

# Platform SDK ka pattern (shape sab platforms mein similar)
import boto3  # example: AWS SDK — doosre clouds ka SDK bhi yahi shape rakhta hai

client = boto3.client(
    "bedrock-runtime",
    region_name="ap-south-1",
)

resp = client.converse(
    modelId="some-provider/some-model-v1",
    messages=[{"role": "user", "content": [{"text": "Ek chhota summary do"}]}],
    system=[{"text": "Tum ek helpful assistant ho"}],
    inferenceConfig={"maxTokens": 512, "temperature": 0.2},
)

print(resp["output"]["message"]["content"][0]["text"])
print(resp["usage"])  # input/output tokens — cost isi se nikalta hai

• Unified (converse-style) API: har model ek hi request/response format — messages, system prompt, max tokens, usage. Model swap karoge toh sirf model id badlegi.
• Provider-native passthrough: kuch platform raw provider API ko bhi expose karte hain — zaroorat tab jab unified format mein koi feature na ho.
• Usage block: har response ke saath input/output token counts aate hain — cost attribution aur logging isi se banti hai.
• Auth: request mein key nahi jaati — cloud SDK credentials (role, service account, managed identity) request sign karte hain.

Same ideas, alag vocabulary

idea                AWS Bedrock      Vertex AI (GCP)    Azure AI Foundry
----------------------------------------------------------------------------
account boundary    account          project            subscription+RG
AI project unit     -                vertex AI project  AI Foundry resource
model reference     model id         publisher/model    deployment name
invoke              converse API     prediction/generatefoundry SDK / REST
identity            IAM role         service account    managed identity
region              region setting   location           region of resource
billing + tags      cost allocation  labels             resource tags

• Model reference alag chalta hai: kahin catalog id seedha lagti hai, kahin pehle deployment banao, phir us deployment ka naam use karo. Deploy = "is account mein ye model enabled hai" — quota aur billing yahin se judti hai.
• Identity objects alag naam ke, ek hi principle ke: principal ko sirf itna permission do jitna model invoke karne ke liye chahiye.
• Tags/labels ek hi kaam karte hain: har resource pe team, env, cost-center ke labels — bill split isi se hota hai.

Ek hi catalog mein model swap

# Ek hi wrapper, do models — auth, network, billing same
MODELS = {
    "fast": "provider-a/fast-model",
    "smart": "provider-b/smart-model",
}

def ask(prompt: str, tier: str = "fast") -> str:
    resp = client.converse(
        modelId=MODELS[tier],
        messages=[{"role": "user", "content": [{"text": prompt}]}],
        inferenceConfig={"maxTokens": 512},
    )
    return resp["output"]["message"]["content"][0]["text"]

# swap = sirf config change — identity, network, billing same rehte hain

• Yehi platform ka asli fayda hai: do models compare karna — auth setup, network path aur billing sab common. Sirf model id badlo aur output compare karo.
• Par quality same nahi hogi: har model apne prompt style, tool format aur limits rakhta hai — swap sirf syntax mein aasaan hai, behavior mein nahi.
• Eval se prove karo: model swap se pehle apna chhota eval set chalao — aankhon se "accha lagta hai" decision production ke liye kaafi nahi.

Platform kya nahi deta — tumhara hi kaam hai

• Prompt quality: platform pipeline chalata hai, prompt tumhara. System prompt, examples, guard instructions — sab tumhari zimmedari.
• Retrieval design: knowledge base option ho toh bhi — chunking strategy, retrieval tuning, citation rules tum define karte ho.
• Evaluation depth: built-in metrics basic hote hain; tumhare use case ke sawaal ka jawab dene wala eval suite tumhara kaam hai.
• Product behavior: fallback, retry, rate limit handling, user-facing error messages — platform inko nahi sambhaalega.

Exercise

Common mistakes

• Har platform ka SDK alag hai soch kar code likhna: Unified converse-style API ka shape teeno mein similar hai. Fix: apna chhota wrapper banao — platform ka SDK wrapper ke andar hi rehne do, app code clean rakho.
• Catalog ke default version par andha bharosa: Platform retirement ke schedule par version khud badal sakta hai. Fix: model id explicitly pin karo aur deprecation notices track karo.
• Platform ko model ka provider samajhna: Catalog mein kai upstream providers ho sakte hain — kuch features unified format mein nahi aate. Fix: catalog entry pe provider check karo, feature parity assume mat karo.
• Managed = app bhi managed: Platform sirf inference plumbing deta hai — prompt, retrieval, evals, product behavior tumhare. Fix: ownership matrix likho, kaunsa layer kiska hai.

mall gate    -> ek identity check (roles)
mall counter -> ek bill (cloud bill + tags)
dukaanein    -> kai providers ke models
par: har dukaan ka saman alag quality ka — test tum karo