Netflix का इन-हाउस LLM सर्विंग प्लेटफ़ॉर्म

• Netflix LLM को अलग silo में नहीं रखता, बल्कि मौजूदा ML infrastructure के साथ ही चलाता है, और vLLM और Triton को integrated serving system से जोड़ता है
• default engine के रूप में चुना गया vLLM custom model support, आसान debugging, extension hooks और research environment से familiarity देता है; Triton के vLLM backend से model और frontend के बीच coupling भी कम होती है
• मौजूदा gRPC और OpenAI-compatible API दोनों उपलब्ध हैं, लेकिन response_format का छूट जाना, Triton·vLLM version mismatch, और non-standard models को handle करने जैसी production में सामने आई gaps को खुद भरना पड़ा
• stable deployment के लिए पहले कम-cost वाली Red-Black strategy अपनाई जाती है, और incompatible I/O changes unavoidable होने पर ही कई versions को साथ बनाए रखने वाली Versioned strategy इस्तेमाल होती है
• request-specific constraints को decoding loop में enforce करने वाले logits processor को vLLM V1 की batch processing और multithreaded C++ में फिर से implement किया गया है; आगे GPU fused kernels, async scheduling और low-precision models तक विस्तार करने की योजना है

---

मौजूदा ML infrastructure में integrated serving architecture

• Netflix का JVM-based integrated serving system routing और A/B testing, candidate generation, feature lookup, inference, post-processing और step-wise logging संभालता है, और real-time तथा cached batch paths दोनों support करता है
• callers मौजूदा serving system के gRPC path या नई LLM applications के लिए direct HTTP path से inference access करते हैं
• execution location model size पर निर्भर करती है
  • छोटे CPU models remote call cost से बचने के लिए process के अंदर चलते हैं
  • बड़े GPU models pre/post-processing local में करते हैं और inference को remote Model Scoring Service(MSS) को सौंपते हैं
• MSS XGBoost, TensorFlow, PyTorch और LLM को एक ही interface से उपलब्ध कराता है; नीचे मौजूद NVIDIA Triton Inference Server model loading, batch processing और GPU scheduling संभालता है
• Triton के ऊपर Java control plane deployment, version management, health checks, autoscaling और multi-region rollout संभालता है
  • model developers artifacts और deployment settings package करते हैं, फिर GPU instances provision होते हैं और Triton configure होता है
  • upgrades zero-downtime तरीके से orchestrate किए जाते हैं

default inference engine के रूप में vLLM का चयन

• शुरुआती platform ने TensorRT-LLM इस्तेमाल किया, जो उस समय high performance देता था और MSS के Triton के साथ पहले से integrated था
• 2025 की गर्मियों तक open-source engines ने specialized stacks के साथ performance gap का बड़ा हिस्सा बंद कर दिया था, और workloads भी नीचे तक फैल चुके थे
  • embeddings generation
  • ranking और retrieval के लिए prefill-only inference
  • autoregressive decoding
  • step-wise constraint logic वाले complex custom models
• इन workloads को फिर benchmark करने के बाद operational fit के आधार पर vLLM को default path engine चुना गया
  • multi-stage compilation के बिना custom model architectures load कर सकता है, जिससे non-standard models का iterative development तेज होता है
  • custom decoding logic के लिए extension hooks देता है
  • शुरुआती TensorRT-LLM, जो compiled engine था, की तुलना में failures और intermediate state की जांच करना आसान है
  • research stage में कई ML practitioners पहले से vLLM से परिचित हैं, जिससे production migration cost घटती है

Triton और vLLM की packaging method

• Triton में Python backend और vLLM backend नाम के दो packaging paths हैं; मुख्य फर्क यह है कि frontend upgrades और model artifacts कितनी मजबूती से coupled हैं
• Python backend में developer packaging time पर input/output tensor specifications define करता है
  • specification artifact में fixed हो जाती है और external frontend के request builder से match करनी होती है
  • frontend upgrade से I/O बदलने पर packaging code भी साथ बदलना पड़ता है; नहीं तो runtime requests fail होती हैं
• vLLM backend के artifacts model weights और tokenizer की ओर इशारा करने वाली JSON config से बने होते हैं
  • deployment के समय Triton backend dynamically I/O tensor specification generate करता है
  • model developer को tensor specification define करने की जरूरत नहीं होती, और model तथा frontend को independently बदला जा सकता है
• default choice vLLM backend है, लेकिन production में दो constraints सामने आए
  • version mismatch: Triton backend किसी specific vLLM API के आधार पर compile होता है, इसलिए दोनों versions अलग हो जाएं तो पूरा backend load नहीं हो पाता
    • उदाहरण के लिए Triton 25.09 vllm.engine.metrics import करता है, लेकिन यह module vLLM 0.11.2 में हटा दिया गया
    • service image बनाते समय compatible versions pin करने होंगे, और model developers को packaging stage पर vLLM version overwrite करने से रोकना होगा
  • custom execution logic: vLLM backend standard HuggingFace-compatible models और full inference lifecycle मानकर चलता है
    • custom pre/post-processing, ensemble pipelines, अलग tokenization जैसे non-standard execution के लिए Python backend चाहिए, जिसमें execute() control किया जा सके
    • कुछ models को यह bypass path अभी भी चाहिए

gRPC और OpenAI-compatible HTTP API

• XGBoost ensembles से बड़े LLM तक सबको समान gRPC call से evaluate किया जाता है, जिससे existing client libraries, health checks और deployment pipelines reuse होते हैं
• LLM ecosystem के inference engines, orchestration frameworks, evaluation tools और client libraries OpenAI-compatible interface इस्तेमाल करते हैं, इसलिए इसे gRPC के साथ-साथ provide किया जाता है
• समान API बनाए रखने से quality, latency, cost और data privacy के कारण hosted model से fine-tuned self-hosted model पर जाते समय code changes छोटे रहते हैं
• implementation NVIDIA के Triton OpenAI-compatible frontend को reuse करता है
  • embedded Triton server शुरू करता है
  • TritonLLMEngine request schema को Triton inference request में बदलता है
  • FastAPI के जरिए response देता है
  • KServe HTTP/gRPC frontend भी साथ enable करता है ताकि Java control plane उसी Triton instance को gRPC से access कर सके
• frontend schema में allowed response_format को vLLM तक भेजने से पहले चुपचाप drop कर देने वाली problem मिली
  • JSON output request करने पर भी guided decoding constraints के बिना run होता था, जिससे गलत JSON return हो सकता था, और platform error भी expose नहीं होता था
  • frontend को Git subtree के रूप में लाकर patch किया गया, ताकि response_format requests को vLLM के guided decoding parameters में convert किया जा सके

zero-downtime model deployment strategy

• GPU deployments में CPU services की तुलना में startup time लंबा होता है और model versions के बीच I/O schema तक बदल सकता है, इसलिए requests को रोके बिना rollout के लिए extra coordination चाहिए
• Red-Black deployment में existing version के बगल में नया version लाया जाता है, और health check pass होने पर traffic धीरे-धीरे shift होता है
  • नए और पुराने version का scale up/down समान ratio में किया जाता है
  • किसी भी stage पर failure होने पर atomic rollback होता है
  • model interface stable हो तो यह उपयुक्त है
• नए tensor dimension जैसे I/O schema changes होने पर Red-Black में coordination gap बनता है
  • नया model पूरी तरह active होने से पहले upstream consumers settings नहीं बदल सकते
  • transition window में पुराने format की requests नए deployment को भेजी जाएं तो वे fail होती हैं
• Versioned deployment हर (modelId, modelVersion) pair के लिए independent deployment बनाए रखकर इस problem को solve करता है
  • कई versions साथ service होते हैं, इसलिए model deployment और consumer updates अलग हो जाते हैं
  • consumers नया version पूरी तरह ready होने के बाद settings बदलते हैं, और पुराना version legacy traffic process करता रहता है
  • inactive हुए पुराने deployments clean up किए जाते हैं, लेकिन latest version हमेशा preserve रहता है
  • transition के दौरान versions overlap होने की अवधि में GPU cost temporary बढ़ती है
• tensor shape जैसी बदल सकने वाली settings को inference model के अंदर सीधे रखकर version-independent बनाने और low-cost Red-Black इस्तेमाल करने की सलाह है
• Versioned का उपयोग केवल तभी करें जब incompatible interface changes टाले न जा सकें

startup procedure और model cache

• vLLM-on-Triton instance को gRPC port खोलने से पहले कई startup steps पूरे करने होते हैं
• बड़े LLM शुरू करते समय S3 या Hugging Face से सीधे download करने पर cold start इतना लंबा हो जाता है कि scheduler की allowance से बाहर चला जाता है
  • model publish के समय model को Amazon FSx पर पहले से materialize किया जाता है
  • उसके बाद startup process object storage के बजाय high-performance file system इस्तेमाल करता है
• OpenAI-compatible API की जरूरत वाले deployments में Triton को उस frontend process के अंदर embedded server के रूप में run किया जाता है
  • अन्य deployments में Triton standalone चलता है
  • execution mode packaging time पर per-deployment configure होता है
• बाकी startup procedure में model package unpacking, Python entry_points के जरिए custom vLLM plugins install करना, Prometheus multiprocess directory clean करना, और engine ready होने तक gRPC port block करना शामिल है

Triton और vLLM metrics का integration

• vLLM PROMETHEUS_MULTIPROC_DIR में .db files के रूप में metrics लिखता है, और Triton अलग Prometheus endpoint से server metrics देता है
• दोनों systems एक-दूसरे के metrics नहीं पहचानते, और Triton का built-in bridge vLLM के 40 से ज्यादा metrics में से केवल 9 expose करता है
  • token throughput
  • KV cache utilization
  • prefix cache hit rate जैसे key indicators छूट जाते हैं
• lightweight HTTP proxy Triton metrics को HTTP से fetch करता है, और Prometheus MultiProcessCollector से disk पर vLLM metrics पढ़कर एक ही /metrics response में merge करता है
• existing dashboards और alerts बिना बदलाव के वैसे ही इस्तेमाल किए जा सकते हैं

decoding process में output constraints enforce करना

• कुछ production workloads को token generation पर fine-grained control चाहिए, इसलिए inference के बाद गलत results को retry या repair करने के बजाय decoding loop के अंदर constraints apply किए जाते हैं
• हर constraint को state machine के रूप में model किया जाता है, जिसकी state generated token history के अनुसार बदलती है और जो हर step पर allowed token mask output करती है
• vLLM का custom logits processor interface इस्तेमाल किया जाता है; rules हर request में अलग होते हैं, इसलिए अलग configured processor assign किया जाता है
• शुरुआत में feature gap की वजह से vLLM V0 इस्तेमाल हुआ, और V1 mature होने पर 2025 की Q4 में migrate किया गया

vLLM V0 में आया scaling bottleneck

• पहला pure Python implementation functionally काम करता था, लेकिन concurrent requests बढ़ने पर scale नहीं हुआ
• vLLM V0 का custom logits processor per-request चलता है
  • GPU पूरे batch के logits generate करता है
  • CPU उन्हें copy करता है और transfer खत्म होने तक wait करता है
  • हर request की constraint logic sequentially चलती है
• Python के GIL की वजह से per-request काम parallelize नहीं हो सकता, इसलिए logits processing का CPU time batch size के अनुपात में बढ़ता है और tail latency बढ़ती है
• GPU का model forward pass efficiently batch होता है, फिर भी overall latency CPU से बंध जाती है
• यह bottleneck single-request benchmarks में नहीं दिखता, केवल real-world concurrency पर सामने आता है

vLLM V1 की batch-level processing

• vLLM V1 logits processing को per-request approach से batch-level पर ले गया
• custom processor को batch data structure के आधार पर फिर लिखा गया, ताकि कई requests के masks साथ compute हों
• performance-critical path को GIL से बचाने के लिए multithreaded C++ में reimplement किया गया; batch size बढ़ने पर भी logits processing time स्थिर रहता है
• V1 API में update_state(batch_update) के जरिए batch members में बदलाव को explicitly track करना होता है
  • यह V0 के per-request interface से ज्यादा complex है
  • dynamically बदलते batch में per-request state ठीक से maintain करने के लिए जरूरी है

state-based constraint handling की operational hardening

• performance bottleneck हल करने के बाद भी stateful decoding logic में दो issues सामने आए

• partial prefill

  • V1 chunk-wise prefilling करता है, इसलिए एक request का prefill कई engine steps में फैल सकता है
  • केवल BatchUpdate से full prefill और partial prefill में फर्क नहीं किया जा सकता, इसलिए internal tracking जोड़ा गया

• preemption

  • memory कम होने पर vLLM कुछ partially completed requests का KV cache हटा देता है, और बाद में अलग prompt और output token list के साथ फिर schedule कर सकता है
  • यह state machine की इस assumption को तोड़ता है कि output token list लगातार बढ़ती है
  • decoding steps के बीच token history छोटी हुई है या नहीं, यह detect किया जाता है; फिर state machine reset कर नए prompt से reconfigure किया जाता है

अगले investment areas

• मौजूदा platform low latency, deep customization और existing infrastructure integration को लक्ष्य बनाता है, और vLLM और Triton तथा consistent APIs के जरिए experiment से production तक का path देता है
• version pinning, silently dropped API fields और packaging choices के trade-offs को address करके platform reliability और developer experience बेहतर किए गए हैं
• अगली चार improvements की योजना है
  • quality sacrifice किए बिना prompt length घटाने वाला system prompt compression
  • vLLM V1 की async scheduling
  • CPU code के बजाय GPU fused kernels पर चलने वाला vectorized logits processor
  • memory usage घटाकर throughput बढ़ाने वाले low-precision model variants
• Triton, vLLM, PyTorch जैसी open-source ML libraries का उपयोग जारी रखते हुए संबंधित communities के साथ सहयोग करने की योजना है