मुफ़्त पूरी गाइड
एक LLM inference gateway design कीजिए जो internal product teams और कई model providers/backends के बीच बैठता है, और company scale पर routing, streaming, quotas तथा safety controls संभालता है।
Interview की लय संक्षिप्त रहती है, ताकि page असली design निर्णयों पर ध्यान लगा सके.
सिर्फ requirements मत बताइए — पूछिए। हर card एक design constraint को उस clarification सवाल से जोड़ता है जो आप architecture बनाने से पहले बोल सकते हैं.
01इसे कौन call करता है — हर product team, या कुछ ही?
हर team इसे call करती है। Gateway ही model providers तक पहुँचने का इकलौता दरवाज़ा है। हर team को एक API key और हर use case को एक policy मिलती है, इसलिए failover, quotas, और redaction चालीस जगहों की बजाय एक ही जगह रहते हैं।
02कोई provider fail होने लगता है — यह किसकी समस्या है?
इसे gateway संभालता है। हर use case schema-compatible models की एक fallback chain declare करता है, और हर provider का health check होता है। Responses में model_used और fallback_reason होते हैं, ताकि callers जान सकें कि किस model ने जवाब दिया।
03क्या users answer को word by word दिखते देखते हैं — क्या पहले word तक का समय product के लिए मायने रखता है?
हाँ — provider जिस पल token emit करता है उसी पल वे gateway से गुज़र जाते हैं, कभी buffer नहीं होते; gateway बीच-stream में token meter करता है ताकि quota और cost को streaming traffic भी दिखे।
04limits requests में गिनी जाती हैं या tokens में?
Tokens। एक request 100 tokens की हो सकती है या 100,000 की, इसलिए हर team को एक tokens-per-minute rate और एक monthly dollar budget मिलता है। Requests गिनना असली खर्च को चूक जाएगा।
05वही prompt हज़ार बार आता है — हज़ार बार generate करें?
नहीं — एक identical repeat को एक बार जवाब देकर दोबारा इस्तेमाल किया जा सकता है, पर केवल उसी team के भीतर जिसने पूछा; personalized या user-specific traffic हमेशा fresh generate होना चाहिए।
06provider एक नया model version निकालता है — कौन upgrade करता है, और कब?
Per-team policy। एक team stable output के लिए एक version pin कर सकती है, या provider जैसे-जैसे upgrades भेजे उन्हें ले सकती है। Pinned teams को उस दिन एक countdown मिलता है जिस दिन provider उनके model को deprecate करता है।
Scope से बाहरmodels को train या fine-tune करना (सिर्फ़ serving traffic) · GPU serving stack खुद बनाना (वह provider की तरफ़ का काम है) · end-user identity और sessions — callers internal services हैं
01gateway खुद कितनी latency जोड़ सकता है?
Org रोज़ करीब 2M requests चलाता है, और gateway request path पर सिर्फ़ ~10-20 ms जोड़ता है। First-token latency ही product metric है। Gateway कभी उसके दोगुना होने की वजह नहीं बनना चाहिए।
02किसी मरते हुए provider का पता कितनी तेज़ी से चलना चाहिए?
एक मरता provider सेकंडों में पकड़ा जाता है, हर provider और हर model के हिसाब से। कितने सेकंड, यह एक product decision है। देरी का हर सेकंड मतलब और ज़्यादा user requests का fail होना।
03prompts और responses में से क्या log होता है?
Metadata हमेशा log होता है: tokens, model, cost, latency, trace id। Prompt और response content तभी log होते हैं जब PII (personally identifiable information) redaction hook चल जाता है। Logs में raw prompts gateway को एक compliance incident में बदल देंगे।
04किसी team का budget cap कितना कड़ा है — अगर requests limit पर ही एक burst में आएँ, तो क्या एक छोटा overshoot सहनीय है?
Cap पक्का है। सौ parallel requests हर एक आख़िरी dollar खर्च न कर दें। एक team का budget किसी burst से कभी overshoot न हो, क्योंकि ये असली invoice वाले dollars हैं।
05रात 2 बजे spend भड़कता है — हमें कितनी जल्दी पता चलता है कौन और क्यों?
हर call एक usage ledger में उतरता है: team, use case, model, tokens, cost, और cache व fallback flags। Attribution लगभग real time में queryable है। आप महीने के अंत में provider invoices से उसे फिर से जोड़ने का इंतज़ार नहीं करते।
असली interview एक साफ list से कहीं गहरा probe करते हैं. ये scope सवाल उन्हें अलग करते हैं जो problem को कुरेदते हैं बनाम जो रटते हैं.
हर estimate को एक दबाव मानिए जो किसी component को justify करता है: cache, queue, partition, replica, worker pool, या fallback path.
cost attribution — tokens, requests नहीं
एक team: 200,000 requests/day, हर एक ~3,000 input + 800 output tokens, $3 per 1M input और $15 per 1M output tokens पर600M input × $3 + 160M output × $15 = $1,800 + $2,400 = $4,200/day ≈ $126K/month
एक per-request rate limit इस bill को देख ही नहीं सकता। Quotas और budgets tokens में गिनने होंगे, input और output की कीमत अलग-अलग लगाकर।
failover detection budget
org volume ~2M requests/day है (NFRs में दिया गया): 2M ÷ 86,400 s ≈ 23 requests/s औसत, और ~4× औसत का workday peak ≈ 100 requests/s, अधिकतर primary provider पर; breaker 20% error threshold के साथ एक 10 s sliding window इस्तेमाल करता है100 requests/s × 10 s ≈ window में 1,000 calls; एक total outage में, 1,000 का 20% = 200 errors 200 ÷ 100 ≈ 2 s के बाद जमा होती हैं — तो breaker खुलने से पहले ≈ 200 requests fail होती हैं
Window की लंबाई तय करती है कि आप कितना user pain झेलेंगे। छोटा window तेज़ trip करता है पर एक-सेकंड के झटकों पर flap करता है। इसे एक product number की तरह चुनो, और साथ में half-open probes रखो।
streaming vs buffered first token
~60 tokens/s पर generate होता एक 800-token answer; एक buffering gateway forward करने से पहले पूरी response रोक रखता हैbuffered first byte: 800 ÷ 60 ≈ 13 s; passthrough first token: ~0.5-1 s → perceived latency लगभग 15-25× बदतर
stream path पर जोड़ा गया हर synchronous hop सभी requests पर चुकाया जाता है — stream को गति में ही inspect करना होगा, कभी park नहीं करना।
semantic cache economics
org-wide 2M requests/day, 15% combined exact + semantic hit rate, ~$0.021 provider cost per request (ऊपर के token math से)300,000 hits × $0.021 ≈ $6,300/day ≈ $190K/month की बचत; एक hit ~13 s के बजाय ~50 ms में जवाब देता है
असली पैसा और एक बड़ी latency जीत — पर हर hit गलत answer परोसने का एक मौका है, इसलिए keys में tenant, model version और template version होने ही चाहिए।
brownout में queue depth
एक brownout ~100 requests/s peak पर primary provider का throughput 5 minutes के लिए आधा कर देता है: 100 आ रहे, 50 serve, कुछ shed नहींbacklog बढ़ता है (100 - 50) × 300 s = 15,000 requests; recovery के बाद ~20 requests/s spare capacity पर, drain होने में और ~12 minutes लगते हैं
सब कुछ queue करना 5 minutes के brownout को ~18 minutes के degradation और 15K open connections में बदल देता है — इसके बजाय batch traffic shed कीजिए और interactive traffic को fail over कीजिए।
निर्णय उदाहरण
चालीस teams में रोज़ बीस लाख requests, हर एक करीब दो सेंट की, यानी करीब $42,000 रोज़ का provider खर्च। और उनमें से हर provider महीने के किसी हफ़्ते कुछ मिनटों के लिए brown out हो जाता है।
मैं एक ही gateway path बनाऊँगा। वह team को authenticate करता है, उसके budget के ख़िलाफ़ max_tokens reserve करता है, पहले exact-match फिर semantic cache check करता है, use case की model chain से route करता है साथ में एक per-provider error-rate breaker, और provider tokens को सीधे stream करता है जबकि बीच-stream में उन्हें meter करता है। Usage एक per-team ledger में settle होती है। Prompt content logs को तभी छूती है जब redaction hook चल जाता है। Model versions per-team policy हैं — या तो एक deprecation countdown के साथ pinned, या एक eval canary के पीछे auto-upgraded।
जो मैं नहीं करूँगा। पहला, teams को सीधे providers call करने देना — वह failover के चालीस implementations और शून्य साझा attribution है। दूसरा, quota के लिए requests गिनना, क्योंकि एक 100-token ping और एक 100,000-token agent loop एक ही खर्च नहीं हैं। तीसरा, streams को inspect करने के लिए buffer करना। जो gateway पूरे response का इंतज़ार करता है वह 1-सेकंड के first token को 13 सेकंड की चुप्पी में बदल देता है।
अगर एक ही team, एक ही model, और चार अंकों वाला monthly खर्च हो, तो retries के साथ एक पतली साझा client library ही ईमानदार जवाब है। Gateway अपनी जटिलता तभी कमाता है जब teams, providers, या खर्च कई गुना हो जाएँ।
पहले एक पूरी तस्वीर, फिर हर path को अपना अलग diagram — write path और read path अलग traffic ढोते हैं और अलग components justify करते हैं.
पूरी तस्वीर
hot path है auth → budget reserve → cache → route → stream; ledger settlement और health bookkeeping उससे बाहर बैठते हैं। एक breaker trip सिर्फ़ router की पसंद बदलती है — callers वही contract रखते हैं और बस model_used बदलते देखते हैं।
Path 1
gateway tokens को बहते हुए गिनता है और stream के अंत में ledger को reserved से actual पर settle करता है — quota और cost streaming traffic को बिलकुल blocking calls की तरह देखते हैं।
Path 2
fallback को primary के साथ schema-compatible होना चाहिए, और response बताता है कि किस model ने जवाब दिया — silent substitution हर उस team को तोड़ देता है जो output shape पर निर्भर है।
optimize करने से पहले contract को inspectable बनाइए: endpoints, entities, ownership, retries, और state.
POST/v1/responses
req{ use_case, messages, max_tokens, stream: true, output_schema? }
resSSE token stream; trailers में model_used, token counts, cost, cache/fallback flags होते हैं
team identity API key से आती है, कभी request body से नहीं — हर provider के आगे एक ही contract, इसलिए provider बदलना product code को कभी नहीं छूता।
GET/v1/usage (team_id, window=month)
res{ tokens, cost_usd, by_model, by_use_case }
cost attribution एक product feature के रूप में — team leads और finance इसे पढ़ते हैं, provider invoices नहीं।
PUTinternal: policy(team_id, changes)
reshot-reloaded policy: pins, budgets, model chain, kill switch
किसी बेकाबू team को बंद करना एक config write है, कोई emergency deploy नहीं।
Core entities
TeamPolicyteam_id (PK) · use_case · model_chain (primary → fallbacks) · version_policy: pinned/auto · tokens_per_min · monthly_budget_usd · redaction_profile
Hot-reloadable — कोई budget change या kill switch किसी deploy का इंतज़ार नहीं कर सकता।
UsageLedgerEntryrequest_id (PK) · team_id · model_used · input_tokens · output_tokens · cost_usd · cache_hit · fallback_reason?
attribution का source of truth — call से पहले एक reservation के रूप में लिखा जाता है, call के बाद actuals पर settle होता है।
ProviderHealthprovider + model · error_rate (sliding window) · p95 latency · breaker: closed/open/half-open
router हर dispatch से पहले यही पढ़ता है; half-open probes तय करते हैं कि traffic कब वापस आने दिया जाए।
CacheEntryembedding key · tenant_scope · model + template version · response · ttl
इनमें से किसी भी एक key को नज़रअंदाज़ करने वाला hit ही वह तरीका है जिससे कोई stale या cross-tenant answer निकल जाता है।
interview के आखिरी एक-तिहाई के लिए एक lane चुनें. हर lane आपको topic, वह interviewer सवाल जिसका जवाब देना है, और बचने वाला failure mode देती है.
एक stream 800 में से token 400 पर provider 500 के साथ मर जाती है। client को क्या दिखता है, और क्या आप एक in-flight generation को fail over कर सकते हैं?
Stream को एक explicit error event के साथ ख़त्म करो। कभी चुप मत होओ, और कभी दूसरे model के tokens बीच में मत जोड़ो — वह उसी आधे-लिखे sentence को पूरा नहीं करेगा। एक generation को बीच में resume नहीं कर सकते, तो failover fallback पर एक explicit restart है। मरी हुई call को ledger में settle करो — सिर्फ़ उन 400 tokens के लिए जो उसने बनाए।
provider B पर चुपचाप regenerate करके tokens splice करना — client आधा answer पहले ही render कर चुका है, और नया model वही continuation नहीं देगा; resume एक restart है और explicit होना चाहिए।
एक team के बेकाबू agent loop ने दो दिनों में org का monthly budget जला दिया। जो controls होने चाहिए थे उन्हें उस क्रम में बताइए जिस क्रम में उन्हें fire करना चाहिए था।
पहले reserve-then-settle checks चलते हैं। हर call अपने max_tokens पहले से reserve करती है और बाद में असली use पर settle होती है, तो parallel loops सब एक ही आख़िरी dollar खर्च नहीं कर सकते। फिर, एक per-team tokens-per-minute cap loop को धीमा करता है। Dollars-per-hour में एक burn-rate alert इसे पहले ही दिन पकड़ लेता है — monthly cap तो बस backstop है।
monthly invoice को इकलौता control मानना — per-call token metering, per-team caps, और burn RATE (baseline के मुक़ाबले dollars प्रति घंटा) पर alerts इसे तीसवें दिन नहीं, पहले दिन पकड़ते हैं।
एक user prompt में एक अहम शब्द बदलता है और फिर भी उसे पुराने prompt का cached answer मिलता है। semantic cache कहाँ गलत हुई, और उसे क्या सीमित करता है?
गलती थी सिर्फ़ similarity पर भरोसा करना। Negation 0.98 cosine similarity पर भी मतलब उलट देता है, तो एक लगभग एक जैसा prompt वही prompt नहीं है। पहले exact match करो और semantic tier को शक होने पर miss होने दो। हर entry को key से scope करो: tenant, model version, और template version। Personalized traffic को बाहर रखो, और हर hit को एक TTL दो।
similarity threshold को पूरी safety कहानी मानना — 0.98 cosine similarity पर negation अर्थ पलट देता है; keys में tenant, model और template version चाहिए, personalized traffic बाहर रहे, और hits में TTL हो।
provider घोषणा करता है कि आपका pinned model 90 दिनों में मर जाएगा। यह किसकी समस्या है, और gateway का upgrade path कैसा दिखता है?
Gateway इसे सामने लाता है; फ़ैसला team करती है। Countdown उसी दिन शुरू होता है जिस दिन provider announce करता है, day 90 पर नहीं। फिर एक eval gate: team के golden prompts को नए version पर replay करो, एक छोटा live slice canary करो, उनके sign-off पर cut over करो। एक pinned team को चुपचाप auto-upgrade करना उसी stability को मार देता है जिसके लिए उन्होंने pin किया था।
सबको चुपचाप auto-upgrade करना — output stability के लिए pinned teams को उनके अपने golden prompts पर एक eval gate, एक canary slice, और एक sign-off मिलता है, और countdown पहले दिन से सामने रखा जाता है।
safety generation से पहले एक synchronous moderation call जोड़ती है और first-token latency दोगुनी हो जाती है। आप guardrail भी और latency budget भी कैसे बनाए रखते हैं?
Checks को parallel में चलाओ, सामने नहीं। Input moderation को routing और provider dispatch के साथ-साथ चलाओ, और fail होने पर generation cancel कर दो। तब उसकी latency पहले से चल रहे काम के पीछे छिप जाती है। Output के लिए, stream को rolling windows में scan करो एक hard mid-stream cut-off के साथ — 13-second के answer को अंत में inspect करने के लिए buffer मत करो।
हर check को provider call के आगे serialize करना — input checks routing के साथ parallel चलते हैं, और output moderation पूरे answer को buffer करने के बजाय rolling windows में एक cut-off के साथ stream scan करती है।
LLM inference gateway को ज़ोर से समझाइए और अपनी व्याख्या पर AI scoring पाइए.