Deploy Aman Model Serving: Canary, Rollback, dan KV Cache Baru

Deploy aman model serving untuk perubahan KV cache harus diperlakukan sebagai perubahan berisiko tinggi, meskipun terlihat hanya sebagai optimasi internal. Pada layanan inference, perubahan cara menyimpan, mengompresi, atau menukar representasi KV cache dapat memengaruhi latensi, penggunaan memori, stabilitas worker, bahkan kualitas output model.

Jika tim Anda sedang mengadopsi ide seperti speculative KV coding sebagai konteks optimasi performa/memori, fokus operasionalnya bukan pada risetnya, melainkan pada pertanyaan ini: bagaimana merilis perubahan KV cache tanpa merusak SLO produksi? Jawabannya adalah kombinasi baseline metrik yang benar, canary deployment yang ketat, health check yang relevan, rollback cepat, dan verifikasi pascadeploy yang tidak hanya melihat HTTP 200.

Catatan: Perubahan KV cache sering lolos dari pengujian fungsional sederhana karena API tetap merespons normal. Masalah baru terlihat pada pola trafik nyata: prompt panjang, concurrency tinggi, cache eviction, atau kombinasi model dan batch tertentu.

Mengapa perubahan KV cache perlu rollout khusus

Dalam model serving berbasis transformer, KV cache menyimpan state attention agar token berikutnya tidak perlu menghitung ulang seluruh konteks. Ketika mekanisme ini diubah, misalnya lewat kompresi, encoding baru, layout memori berbeda, atau strategi penyimpanan adaptif, ada beberapa area yang ikut berubah:

Latensi prefill dan decode, karena biaya akses atau dekompresi cache bisa bergeser.
Jejak memori, baik di GPU maupun CPU, termasuk fragmentasi dan pressure allocator.
Throughput, terutama saat worker menangani banyak request paralel.
Cache hit/eviction behavior, yang berpengaruh langsung ke performa pada percakapan panjang atau sesi berulang.
Konsistensi output, jika implementasi baru punya bug pada indexing, boundary token, atau fallback path.

Karena itu, perubahan KV cache sebaiknya diperlakukan seperti perubahan pada data plane inference, bukan sekadar refactor internal.

Baseline sebelum rilis: metrik yang wajib ada

Sebelum canary, Anda perlu baseline dari versi lama. Tujuannya bukan hanya membandingkan rata-rata, tetapi memahami distribusi, kondisi puncak, dan perilaku di beban nyata.

SLI/SLO yang relevan untuk model serving

Untuk rollout KV cache baru, SLI yang paling berguna biasanya:

Latency: p50, p95, p99 untuk time-to-first-token, total response time, dan inter-token latency bila tersedia.
Error rate: HTTP 5xx, timeout, cancelled request karena overload, OOM kill, worker crash.
Throughput: request per second, token per second, dan token output per worker.
Memory usage: memory resident, GPU memory used, allocator retry, OOM event, fragmentasi jika metrik tersedia.
Cache behavior: hit ratio, miss ratio, eviction rate, cache occupancy, fallback-to-legacy-path jika ada.
Output quality guardrail: panjang output abnormal, empty output, malformed JSON pada mode structured output, atau deviasi terhadap golden prompts.

Contoh SLO operasional yang praktis:

p95 TTFT tidak boleh memburuk lebih dari ambang internal yang disepakati tim.
Error rate total tidak boleh naik melewati budget error layanan.
Tidak ada kenaikan OOM, restart pod, atau eviction cache yang signifikan.
Golden prompt set harus tetap lolos dengan tingkat kesesuaian minimum yang telah didefinisikan tim.

Hindari menetapkan ambang sukses hanya dari throughput. Optimasi yang menaikkan throughput tetapi memperburuk p99 latency atau meningkatkan output aneh tetap bukan rollout yang aman.

Metrik baseline yang sebaiknya direkam

Sebelum deploy, rekam setidaknya 3 jenis baseline:

Baseline produksi normal pada jam lalu lintas biasa.
Baseline peak traffic pada jam sibuk.
Baseline synthetic dari beban terkontrol dengan campuran prompt pendek, menengah, panjang, dan streaming/non-streaming.

Jika memungkinkan, pisahkan metrik per model, per route, dan per ukuran konteks. Banyak regresi KV cache hanya muncul pada prompt panjang atau sesi multi-turn.

Strategi canary deployment untuk KV cache baru

Pendekatan paling aman adalah menjalankan dua varian serving secara paralel: stable dan candidate. Candidate berisi mekanisme KV cache baru, sementara stable tetap menangani mayoritas trafik.

Pola rilis yang direkomendasikan

Dark launch internal: candidate hidup, tetapi hanya menerima health probe dan request internal terbatas.
Shadow traffic bila memungkinkan: candidate menerima salinan request tanpa memengaruhi respons pengguna. Cocok untuk mendeteksi crash, lonjakan memori, atau output aneh.
Canary kecil: arahkan sebagian kecil trafik nyata ke candidate.
Canary bertahap: naikkan porsi trafik hanya jika metrik stabil pada jendela observasi yang cukup.
Full rollout: setelah metrik, golden prompts, dan alarm tetap sehat.

Untuk perubahan KV cache, canary berbasis persentase sering perlu digabung dengan segmentasi trafik. Misalnya, mulai dari request dengan panjang konteks pendek lebih dulu, lalu baru sesi panjang atau pelanggan berat.

Apa yang harus dibandingkan saat canary

Jangan hanya melihat dashboard global. Bandingkan canary versus stable pada dimensi berikut:

TTFT dan total latency per route.
Token throughput per pod/worker.
Memory usage per pod dan tren pertumbuhan selama beberapa menit/jam.
Restart, OOM kill, dan timeout.
Cache hit dan eviction rate.
Output golden prompts dan validasi format respons.

Canary dinyatakan gagal bukan hanya saat error besar terjadi, tetapi juga saat ada tren memburuk yang konsisten. Kenaikan kecil tetapi stabil pada p99 latency atau eviction rate sering menjadi tanda awal masalah.

Health check, readiness, dan alert yang benar

Health check untuk model serving tidak boleh terbatas pada port terbuka atau HTTP 200. Worker bisa hidup, tetapi jalur KV cache baru sudah rusak secara fungsional atau performa.

Health check minimum

Liveness: proses utama masih responsif.
Readiness: model sudah dimuat, allocator siap, dan worker mampu menjawab prompt uji ringan.
Inference sanity check: prompt pendek dengan ekspektasi format output yang stabil, dijalankan periodik atau saat startup.
Cache-path check: jika ada flag internal, pastikan jalur KV cache baru benar-benar aktif pada candidate dan bukan diam-diam fallback.

Readiness probe sebaiknya gagal jika model belum siap memproses request dengan aman. Ini mencegah pod baru langsung menerima trafik saat cache allocator atau warmup belum stabil.

Contoh readiness dan canary di Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-canary
spec:
  replicas: 2
  selector:
    matchLabels:
      app: inference
      track: canary
  template:
    metadata:
      labels:
        app: inference
        track: canary
    spec:
      containers:
        - name: server
          image: registry.example.com/inference:kv-cache-candidate
          env:
            - name: KV_CACHE_MODE
              value: candidate
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /live
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 10

Di level routing, canary bisa dilakukan oleh service mesh, ingress controller, atau load balancer aplikasi. Yang penting, trafik kandidat bisa dinaik-turunkan cepat tanpa membangun image ulang.

Alert yang perlu dipasang saat rollout

p95/p99 latency canary lebih buruk dari stable selama jendela tertentu.
Error rate canary melampaui ambang aman.
OOM kill, restart pod, atau memory growth terus-menerus.
Cache eviction rate meningkat tajam.
Golden prompt mismatch atau invalid structured output.

Alert rollout sebaiknya dipisah dari alert layanan umum agar tim tahu ini regresi canary, bukan gangguan sistemik di seluruh fleet.

Rollback cepat: desain untuk gagal dengan aman

Rollback yang baik bukan tindakan manual yang rumit. Anda perlu menganggap sejak awal bahwa candidate mungkin harus dimatikan dalam hitungan menit.

Prinsip rollback yang efektif

Gunakan feature flag atau route split agar trafik bisa dialihkan kembali ke stable tanpa menunggu deploy baru.
Pertahankan image stable tetap tersedia dan jangan hapus deployment lama sebelum observasi selesai.
Hindari perubahan skema state bersama yang membuat stable dan candidate tidak kompatibel.
Simpan konfigurasi rollback sebagai artefak yang sudah diuji, bukan improvisasi saat insiden.

Jika KV cache baru membutuhkan metadata atau format internal berbeda, usahakan perubahan itu lokal di memori proses. Jangan memperkenalkan dependensi eksternal yang menyulitkan rollback, kecuali benar-benar perlu.

Contoh rollback operasional di Kubernetes

# Opsi 1: turunkan weight canary ke 0 pada ingress/service mesh
# Implementasi spesifik tergantung tool yang digunakan.

# Opsi 2: scale canary ke nol
kubectl scale deployment/inference-canary --replicas=0

# Opsi 3: rollback deployment stable jika sempat ikut berubah
kubectl rollout undo deployment/inference-stable

Perintah detail split traffic bergantung pada ingress atau mesh yang dipakai, jadi dokumentasikan sesuai stack Anda. Prinsipnya tetap sama: rollback harus lebih cepat daripada waktu yang dibutuhkan masalah untuk menghabiskan error budget.

Verifikasi pascadeploy: jangan berhenti di status hijau

Setelah canary atau full rollout terlihat sehat, lakukan verifikasi pascadeploy yang eksplisit. Tujuannya memastikan tidak ada regresi lambat atau anomali kualitas output.

Checklist verifikasi pascadeploy

Bandingkan latency dan throughput 15-60 menit setelah rollout dengan baseline.
Periksa memory usage per pod, bukan hanya rata-rata cluster.
Lihat pola eviction dan cache occupancy saat beban meningkat.
Jalankan golden prompts dari berbagai panjang konteks.
Periksa structured output, JSON mode, atau template output yang sering dipakai downstream.
Pastikan error di klien tidak naik, misalnya timeout, retry berulang, atau circuit breaker terbuka.

Masalah output aneh sering tidak muncul di metrik infrastruktur. Karena itu, validasi aplikasi tetap wajib.

Runbook insiden ringan untuk rollout KV cache

Berikut runbook singkat yang bisa dipakai saat deploy aman model serving menghadapi gejala umum.

Insiden 1: latensi naik setelah canary

Bandingkan canary vs stable pada TTFT, total latency, throughput, dan memory.
Cek apakah kenaikan hanya pada prompt panjang. Ini sering mengarah ke biaya dekompresi, fragmentasi, atau eviction berlebih.
Lihat restart/OOM dan apakah ada throttle CPU/GPU atau queueing di worker.
Periksa cache hit dan eviction rate. Hit ratio turun atau eviction naik biasanya menjelaskan lonjakan latency.
Turunkan traffic share canary segera jika tren konsisten buruk.
Rollback penuh bila latency memengaruhi SLO atau memicu timeout downstream.

Kemungkinan akar masalah: representasi KV baru mengurangi memori tetapi menambah biaya decode/decompress, ukuran cache efektif mengecil, atau allocator menjadi lebih sering menyalin buffer.

Insiden 2: output aneh atau tidak konsisten

Bandingkan output golden prompts antara stable dan candidate.
Cari pola: hanya pada streaming, hanya pada konteks panjang, hanya format JSON, atau hanya model tertentu.
Aktifkan sampling log yang aman untuk metadata request dan checksum output, tanpa membocorkan data sensitif.
Periksa fallback path. Bug sering terjadi saat sebagian request memakai jalur baru dan sebagian lama.
Rollback lebih cepat daripada mencoba tuning di produksi jika output menyimpang secara nyata.

Kemungkinan akar masalah: indexing token salah, boundary cache tidak sinkron, race condition pada batch processing, atau bug pada jalur konversi internal.

Data yang perlu dikumpulkan saat insiden

Waktu mulai insiden dan perubahan traffic share terakhir.
Model, route, dan tipe request yang terdampak.
Pod atau worker yang paling sering error.
Snapshot metrik latency, memory, cache hit/eviction, restart.
Contoh request internal yang bisa mereproduksi gejala.

Checklist implementasi untuk Docker/Kubernetes

Checklist berikut bisa dipakai sebagai dasar SOP rollout perubahan KV cache.

Sebelum deploy

Feature flag untuk mengaktifkan/mematikan mekanisme KV cache baru sudah tersedia.
Image stable dan candidate dapat berjalan paralel.
Readiness/liveness probe sudah diuji.
Dashboard canary vs stable sudah siap.
Alert rollout sudah aktif dan diuji.
Golden prompts dan validasi output tersedia.
Runbook rollback terdokumentasi dan pernah disimulasikan.

Saat deploy

Mulai dari dark launch atau shadow traffic jika memungkinkan.
Naikkan traffic share secara bertahap, bukan langsung besar.
Monitor p95/p99, error, memory, cache hit/eviction, restart.
Catat waktu setiap kenaikan traffic share.
Jangan gabungkan rollout KV cache dengan perubahan besar lain pada model server.

Setelah deploy

Verifikasi golden prompts dan structured output.
Cek trend memory dan eviction setidaknya selama satu siklus trafik normal.
Tutup canary hanya setelah observasi cukup.
Simpan hasil perbandingan baseline vs candidate untuk referensi rilis berikutnya.

Contoh Docker Compose sederhana untuk memisahkan stable dan candidate

services:
  inference-stable:
    image: registry.example.com/inference:stable
    environment:
      KV_CACHE_MODE: legacy
    ports:
      - "8081:8080"

  inference-candidate:
    image: registry.example.com/inference:candidate
    environment:
      KV_CACHE_MODE: candidate
    ports:
      - "8082:8080"

Compose ini bukan sistem canary penuh, tetapi berguna untuk validasi staging atau pembandingan awal sebelum masuk ke orchestrator produksi.

Postmortem ringkas dan tindakan pencegahan

Jika rollout gagal, buat postmortem singkat yang fokus pada pembelajaran operasional, bukan sekadar menyebut "latensi naik".

Template postmortem singkat

Perubahan: mekanisme KV cache baru diaktifkan pada candidate.
Dampak: p99 latency naik dan sebagian request timeout.
Deteksi: alert canary vs stable dan verifikasi golden prompts.
Akar masalah: misalnya eviction meningkat pada konteks panjang sehingga decode path lebih mahal.
Mitigasi: traffic share diturunkan ke 0, candidate di-scale down.
Pencegahan: tambah uji beban prompt panjang, metrik eviction per model, dan guardrail rollout otomatis.

Tindakan pencegahan yang biasanya paling bernilai

Tambahkan test set realistis dengan distribusi panjang konteks seperti produksi.
Perluas observabilitas cache hingga level hit/miss/eviction per model atau per worker.
Buat auto-abort canary jika error budget atau guardrail kualitas terlampaui.
Pisahkan rollout performa dan rollout model agar diagnosis lebih mudah.
Uji rollback secara berkala, bukan hanya menulis dokumentasinya.

Penutup

Perubahan KV cache pada model serving memang menjanjikan efisiensi memori dan throughput, termasuk saat terinspirasi oleh pendekatan seperti speculative KV coding. Namun dari sudut pandang operasi, keberhasilan rollout bukan ditentukan oleh klaim optimasi, melainkan oleh disiplin rilis: baseline yang tepat, canary yang terukur, health check yang benar, alert yang relevan, rollback cepat, dan verifikasi pascadeploy yang memeriksa kualitas output sekaligus performa.

Jika Anda ingin deploy aman model serving, anggap perubahan KV cache sebagai perubahan inti pada jalur inference. Dengan begitu, tim DevOps dan backend bisa merilis optimasi baru tanpa mempertaruhkan kestabilan layanan produksi.

Quick Search

shopping_cart Keranjang