Platform Penyajian LLM Internal Netflix

• Netflix tidak memisahkan LLM ke dalam silo tersendiri, melainkan mengoperasikannya bersama infrastruktur ML yang sudah ada, dengan menghubungkan vLLM dan Triton ke sistem penyajian terpadu
• vLLM, yang dipilih sebagai engine utama, mendukung model kustom, mudah di-debug, memiliki hook ekstensi, dan familier bagi lingkungan riset; melalui backend vLLM di Triton, keterikatan antara model dan frontend juga dikurangi
• Netflix menyediakan API gRPC yang sudah ada dan API kompatibel OpenAI sekaligus, tetapi harus menambal sendiri celah yang muncul di produksi seperti hilangnya response_format, ketidakcocokan versi Triton·vLLM, dan penanganan model nonstandar
• Untuk deployment yang stabil, strategi Red-Black berbiaya rendah diterapkan lebih dulu, sementara strategi Versioned yang mempertahankan beberapa versi sekaligus hanya digunakan ketika perubahan I/O yang tidak kompatibel tidak bisa dihindari
• Logits processor yang memaksakan batasan per permintaan di dalam loop decoding diimplementasikan ulang untuk pemrosesan batch vLLM V1 dan C++ multithread; ke depan akan diperluas ke kernel fusi GPU, penjadwalan asinkron, dan model presisi rendah

---

Struktur penyajian yang terintegrasi dengan infrastruktur ML yang ada

• Sistem penyajian terpadu berbasis JVM milik Netflix menangani routing dan A/B testing, pembuatan kandidat, pengambilan fitur, inferensi, pascapemrosesan, serta logging per tahap, dan mendukung jalur real-time maupun batch yang di-cache
• Pemanggil mengakses inferensi melalui jalur gRPC pada sistem penyajian yang ada atau jalur HTTP langsung untuk aplikasi LLM baru
• Lokasi eksekusi berbeda menurut ukuran model
  • Model CPU kecil dijalankan di dalam proses untuk menghindari biaya panggilan jarak jauh
  • Model GPU besar menjalankan pra- dan pascapemrosesan secara lokal, lalu mendelegasikan inferensi ke Model Scoring Service(MSS) jarak jauh
• MSS menyediakan XGBoost, TensorFlow, PyTorch, dan LLM melalui satu antarmuka; NVIDIA Triton Inference Server di lapisan bawah menangani pemuatan model, pemrosesan batch, dan penjadwalan GPU
• Control plane Java di atas Triton menangani deployment, manajemen versi, health check, autoscaling, dan rollout multi-region
  • Ketika pengembang model mengemas artefak dan konfigurasi deployment, sistem memprovisi instance GPU dan mengonfigurasi Triton
  • Upgrade dikoordinasikan dengan tanpa downtime

Memilih vLLM sebagai engine inferensi utama

• Platform awal menggunakan TensorRT-LLM, yang saat itu berkinerja tinggi dan sudah terintegrasi dengan Triton di MSS
• Pada musim panas 2025, engine open source sudah hampir menutup sebagian besar selisih performa dengan stack khusus, dan workload juga melebar ke area berikut
  • Pembuatan embedding
  • Inferensi prefill-only untuk ranking dan pencarian
  • Decoding autoregresif
  • Model kustom dengan logika batasan bertahap yang kompleks
• Setelah melakukan benchmark ulang pada workload ini, vLLM dipilih sebagai engine jalur utama berdasarkan kesesuaian operasional
  • Dapat memuat arsitektur model kustom tanpa kompilasi bertahap, sehingga iterasi pengembangan model nonstandar menjadi lebih cepat
  • Menyediakan hook ekstensi untuk logika decoding kustom
  • Lebih mudah menyelidiki kegagalan dan state antara dibanding TensorRT-LLM awal yang berbasis engine kompilasi
  • Banyak praktisi ML sudah familier dengan vLLM pada tahap riset, sehingga biaya transisi ke produksi berkurang

Cara pengemasan Triton dan vLLM

• Triton memiliki dua jalur pengemasan, yaitu Python backend dan vLLM backend; perbedaan utamanya adalah seberapa kuat upgrade frontend terikat dengan artefak model
• Pada Python backend, pengembang mendefinisikan spesifikasi tensor input-output saat pengemasan
  • Spesifikasi tersebut terkunci pada artefak dan harus cocok dengan request builder milik frontend eksternal
  • Jika I/O berubah karena upgrade frontend, kode pengemasan juga harus diubah; jika tidak, permintaan runtime akan gagal
• Artefak vLLM backend terdiri dari konfigurasi JSON yang menunjuk ke bobot model dan tokenizer
  • Saat deployment, backend Triton membuat spesifikasi tensor I/O secara dinamis
  • Pengembang model tidak perlu mendefinisikan spesifikasi tensor, dan model serta frontend dapat diubah secara independen
• Pilihan default adalah vLLM backend, tetapi di produksi muncul dua batasan
  • Ketidakcocokan versi: backend Triton dikompilasi berdasarkan API vLLM tertentu, sehingga jika kedua versinya tidak selaras, seluruh backend tidak dapat dimuat
    • Misalnya Triton 25.09 mengimpor vllm.engine.metrics, tetapi modul tersebut dihapus di vLLM 0.11.2
    • Saat membuat image layanan, versi yang kompatibel harus dipin, dan pengembang model tidak boleh dapat menimpa versi vLLM pada tahap pengemasan
  • Logika eksekusi kustom: vLLM backend mengasumsikan model standar yang kompatibel dengan HuggingFace dan seluruh siklus hidup inferensi
    • Untuk eksekusi nonstandar seperti pra-/pascapemrosesan kustom, pipeline ensemble, atau tokenisasi terpisah, diperlukan Python backend yang dapat mengendalikan execute()
    • Beberapa model masih membutuhkan jalur bypass ini

API gRPC dan HTTP kompatibel OpenAI

• Dari ensemble XGBoost hingga LLM skala besar dievaluasi melalui panggilan gRPC yang sama, sehingga library klien, health check, dan pipeline deployment yang sudah ada dapat digunakan kembali
• Karena engine inferensi, framework orkestrasi, alat evaluasi, dan library klien di ekosistem LLM menggunakan antarmuka kompatibel OpenAI, antarmuka ini disediakan berdampingan dengan gRPC
• Dengan mempertahankan API yang sama, perubahan kode menjadi kecil saat berpindah dari model hosting ke model self-hosted yang sudah di-fine-tune karena alasan kualitas, latensi, biaya, atau privasi data
• Implementasinya menggunakan ulang frontend kompatibel OpenAI milik Triton dari NVIDIA
  • Memulai server Triton bawaan
  • TritonLLMEngine mengubah skema permintaan menjadi permintaan inferensi Triton
  • Menyajikan respons melalui FastAPI
  • Frontend KServe HTTP/gRPC juga diaktifkan agar control plane Java dapat mengakses instance Triton yang sama melalui gRPC
• Ditemukan masalah bahwa frontend diam-diam membuang response_format yang diizinkan oleh skema sebelum meneruskannya ke vLLM
  • Meskipun output JSON diminta, eksekusi berjalan tanpa batasan guided decoding sehingga dapat mengembalikan JSON yang salah, dan error platform juga tidak terekspos
  • Frontend dibawa masuk sebagai Git subtree lalu dipatch agar mengubah permintaan response_format menjadi parameter guided decoding milik vLLM

Strategi deployment model tanpa downtime

• Deployment GPU memiliki waktu start lebih lama daripada layanan CPU, dan skema I/O dapat berubah antarversi model, sehingga rollout tanpa menghentikan permintaan memerlukan penyesuaian tambahan
• Deployment Red-Black menaikkan versi baru di samping versi lama, lalu mengalihkan traffic secara bertahap setelah lolos health check
  • Scale up versi baru dan scale down versi lama dilakukan dengan rasio yang sama
  • Jika gagal pada tahap mana pun, rollback dilakukan secara atomik
  • Cocok ketika antarmuka model stabil
• Jika skema I/O berubah, seperti dimensi tensor baru, Red-Black menimbulkan celah koordinasi
  • Sebelum model baru aktif sepenuhnya, konsumen di lapisan atas tidak dapat mengubah konfigurasi
  • Jika permintaan dalam format lama dikirim ke deployment baru selama masa transisi, permintaan itu akan gagal
• Deployment Versioned menyelesaikan masalah ini dengan mempertahankan deployment independen untuk setiap pasangan (modelId, modelVersion)
  • Karena beberapa versi dilayani sekaligus, deployment model dan pembaruan konsumen menjadi terpisah
  • Konsumen mengubah konfigurasi setelah versi baru sepenuhnya siap, sementara versi lama terus menangani traffic legacy
  • Deployment lama yang sudah tidak aktif dibersihkan, tetapi versi terbaru selalu dipertahankan
  • Selama periode versi bertumpang tindih saat transisi, biaya GPU meningkat sementara
• Konfigurasi yang dapat berubah seperti bentuk tensor disarankan dimasukkan langsung ke dalam model inferensi agar independen dari versi, lalu menggunakan Red-Black yang lebih murah
• Versioned hanya digunakan ketika perubahan antarmuka yang tidak kompatibel tidak dapat dihindari

Prosedur startup dan cache model

• Instance vLLM-on-Triton harus menyelesaikan beberapa tahap startup sebelum dapat membuka port gRPC
• Saat memulai LLM besar, mengunduh langsung dari S3 atau Hugging Face membuat cold start begitu lama hingga melampaui toleransi scheduler
  • Pada saat model dirilis, model terlebih dahulu dimaterialisasi ke Amazon FSx
  • Setelah itu, proses startup menggunakan sistem file berkinerja tinggi alih-alih object storage
• Pada deployment yang membutuhkan API kompatibel OpenAI, Triton dijalankan sebagai server bawaan di dalam proses frontend tersebut
  • Deployment lain menjalankan Triton secara mandiri
  • Cara eksekusi diatur per deployment saat pengemasan
• Sisa prosedur startup mencakup ekstraksi paket model, instalasi plugin vLLM kustom melalui entry_points Python, pembersihan direktori multiproses Prometheus, dan pemblokiran port gRPC hingga engine siap

Integrasi metrik Triton dan vLLM

• vLLM mencatat metrik sebagai file .db di PROMETHEUS_MULTIPROC_DIR, sementara Triton menyediakan metrik server melalui endpoint Prometheus terpisah
• Kedua sistem tidak saling mengenali metrik masing-masing, dan bridge bawaan Triton hanya mengekspos 9 dari lebih dari 40 metrik vLLM
  • Throughput token
  • Tingkat penggunaan KV cache
  • Metrik inti seperti tingkat hit prefix cache tidak ada
• Proxy HTTP ringan mengambil metrik Triton melalui HTTP, membaca metrik vLLM di disk dengan Prometheus MultiProcessCollector, lalu menggabungkannya menjadi satu respons /metrics
• Dashboard dan alert yang sudah ada dapat tetap digunakan tanpa perubahan

Memaksakan batasan output selama proses decoding

• Sebagian workload produksi membutuhkan kontrol halus atas pembuatan token, sehingga alih-alih mencoba ulang atau memulihkan hasil yang salah setelah inferensi, batasan diterapkan di dalam loop decoding
• Setiap batasan dimodelkan sebagai state machine yang statenya berubah menurut riwayat token yang dihasilkan dan mengeluarkan mask token yang diizinkan pada setiap tahap
• Antarmuka logits processor kustom vLLM digunakan, dan karena aturan berbeda untuk setiap permintaan, processor yang dikonfigurasi terpisah dialokasikan
• Awalnya vLLM V0 digunakan karena kesenjangan fitur, lalu bermigrasi pada kuartal IV 2025 ketika V1 sudah matang

Bottleneck scaling yang terjadi di vLLM V0

• Implementasi awal murni Python berfungsi secara fungsional, tetapi tidak dapat diskalakan saat jumlah permintaan bersamaan meningkat
• Logits processor kustom di vLLM V0 berjalan per permintaan
  • GPU menghasilkan logits untuk seluruh batch
  • CPU menyalinnya dan menunggu hingga transfer selesai
  • Logika batasan tiap permintaan dijalankan secara berurutan
• Karena GIL Python, pekerjaan per permintaan tidak dapat diparalelkan, sehingga waktu CPU untuk pemrosesan logits meningkat sebanding dengan ukuran batch dan latensi ekor membesar
• Meski forward pass model di GPU diproses batch secara efisien, latensi keseluruhan tetap terikat oleh CPU
• Bottleneck ini tidak terlihat pada benchmark satu permintaan, dan hanya muncul pada konkurensi tingkat nyata

Pemrosesan per batch di vLLM V1

• vLLM V1 memindahkan pemrosesan logits dari cara per permintaan ke per batch
• Processor kustom ditulis ulang berbasis struktur data batch untuk menghitung mask beberapa permintaan sekaligus
• Jalur kritis performa diimplementasikan ulang dalam C++ multithread agar menghindari GIL, sehingga waktu pemrosesan logits tetap konstan meski ukuran batch membesar
• Pada API V1, perubahan anggota batch harus dilacak secara eksplisit melalui update_state(batch_update)
  • Lebih kompleks daripada antarmuka per permintaan di V0
  • Diperlukan untuk menjaga state per permintaan secara akurat pada batch yang berubah dinamis

Penguatan operasional untuk pemrosesan batasan berbasis state

• Setelah bottleneck performa diselesaikan, masih muncul dua masalah pada logika decoding yang memiliki state

• Prefill parsial

  • V1 melakukan prefilling per chunk, sehingga prefill satu permintaan dapat berlangsung dalam beberapa langkah engine
  • BatchUpdate saja tidak dapat membedakan prefill lengkap dan prefill parsial, sehingga pelacakan internal ditambahkan

• Preemption

  • Jika memori tidak cukup, vLLM menghapus KV cache dari sebagian permintaan yang belum selesai, lalu nantinya dapat menjadwalkannya kembali dengan daftar prompt dan token output lain
  • Ini mematahkan asumsi state machine bahwa daftar token output terus bertambah
  • Sistem mendeteksi apakah riwayat token memendek di antara langkah decoding, menginisialisasi ulang state machine, lalu membangunnya kembali dengan prompt baru

Area investasi berikutnya

• Platform saat ini menargetkan latensi rendah, kustomisasi mendalam, dan integrasi dengan infrastruktur yang ada, serta menyediakan jalur dari eksperimen ke produksi melalui vLLM dan Triton serta API yang konsisten
• Dengan menambal pinning versi, field API yang diam-diam hilang, dan trade-off pilihan pengemasan, stabilitas platform dan pengalaman developer ditingkatkan
• Empat peningkatan berikut direncanakan
  • Kompresi system prompt yang mengurangi panjang prompt tanpa mengorbankan kualitas
  • Penjadwalan asinkron vLLM V1
  • Logits processor tervektorisasi yang berjalan sebagai kernel fusi GPU, bukan kode CPU
  • Varian model presisi rendah yang mengurangi penggunaan memori dan meningkatkan throughput
• Netflix akan terus memanfaatkan library ML open source seperti Triton, vLLM, dan PyTorch, serta berencana bekerja sama dengan komunitas terkait