Belajar 9router - Performance Optimization

#Pendahuluan

Sejauh ini gateway kalian aman (episode 12–13) dan bisa dipertanggungjawabkan (episode 14). Tapi keamanan dan audit tidak ada artinya kalau setiap request butuh 3 detik padahal modelnya butuh 300 milidetik. Di gateway AI, latensi bukan sekadar soal kenyamanan — ia kualitas layanan, biaya per token, dan pengalaman pengguna.

Episode 15 memoles performa di tiga lini: optimasi latensi routing dan throughput, trade-off cost/latency saat memilih model, serta caching respons dan reuse embeddings. Tujuannya jelas: request lebih cepat, biaya lebih hemat, dan provider tidak dipanggil untuk hal yang sama dua kali.

#Mengukur Latensi dan Throughput

Sebelum mengoptimalkan, kalian harus bisa mengukur. Latensi di gateway AI terurai menjadi komponen-komponen yang bisa dioptimalkan satu per satu: waktu penanganan di gateway (deteksi intent, evaluasi kebijakan, pemilihan model), waktu antrean ke provider, dan waktu respons model.

metrics:
  enabled: true
  latencies:
    - name: gateway_overhead
    - name: provider_ttft
    - name: provider_total
    - name: total_request
  throughput:
    requests_per_second: true
    tokens_per_second: true
  percentiles: [p50, p95, p99]

Perhatikan dua ukuran penting: TTFT (time to first token) menentukan kapan user mulai melihat jawaban mengalir, dan throughput diukur per detik dalam request maupun token. Optimasi yang salah fokus — mengejar rata-rata tapi melupakan p95/p99 — akan meninggalkan sejumlah user dengan pengalaman buruk. Aktifkan pengukuran dengan 9router metrics enable sebelum mengganti apa pun.

9router metrics latency --percentile p95 --window 1h
9router metrics throughput --window 1h

#Optimasi Overhead Routing dan Throughput

Lapisan paling mudah dioptimalkan adalah overhead gateway sendiri. Setiap guardrail dan evaluasi kebijakan memakan waktu; terlalu banyak layer yang menjalankan klasifikasi besar akan menambah puluhan milidetik sebelum request sampai ke provider. Prioritaskan guard yang murah di lintasan panas, dan pindahkan yang berat ke jalur async bila bisa.

runtime:
  max_connections_per_provider: 128
  connection_idle_timeout: 30s
  request_timeout: 60s
  stream_first_token_timeout: 5s
  http2: true

Connection pooling adalah kemenangan besar berikutnya. Membuka koneksi TLS ke provider setiap request itu mahal; dengan pool, koneksi dipakai ulang. http2: true memungkinkan banyak stream berbagi satu koneksi, dan stream_first_token_timeout memastikan provider yang macet di tengah streaming tidak menggantungkan user.

#Model Selection: Trade-off Cost dan Latency

Model bukan barang bebas. gpt-4o lebih pintar tapi lebih mahal dan lambat; gpt-4o-mini murah dan cepat tapi kurang kuat. Seni routing adalah menempatkan request pada model yang tepat — cukup kuat untuk tugasnya, sekecil mungkin biayanya. 9router menyediakan penilaian model berdasarkan profil request:

routes:
  - name: chat-general
    match:
      intent: general_chat
      complexity: low
    model: gpt-4o-mini
    provider: openai-prod
  - name: chat-complex
    match:
      intent: general_chat
      complexity: high
    model: gpt-4o
    provider: openai-prod
    budget:
      max_tokens: 2048
      max_cost_per_request: 0.05

Route chat-complex menetapkan budget sebagai jaring pengaman: jika model terpilih melebihi batas token atau biaya yang ditetapkan, gateway bisa beralih ke model yang lebih kecil atau menolak dengan pesan yang jelas. Trade-off cost/latency dengan demikian menjadi kebijakan, bukan keputusan ad hoc.

9router models compare --route chat-general
9router route test --prompt "Jelaskan apa itu routing" --all

Command models compare menampilkan estimasi biaya dan latensi tiap kandidat model sehingga kalian bisa memilih dengan data, bukan tebakan.

#Caching Respons

Banyak request AI yang berulang: FAQ, template, jawaban yang hampir identik. Memanggil provider untuk pertanyaan yang pernah dijawab kemarin adalah pemborosan biaya dan latensi. Response caching menyimpan respons model dan memenuhinya langsung dari cache bila pertanyaannya identik.

cache:
  response_cache:
    enabled: true
    ttl: 3600s
    max_size: 512MB
    include_metadata:
      - model
      - temperature
    exempt_routes: [chat-complex]

Kunci cache dibentuk dari isi prompt plus metadata penting (model, temperature), sehingga jawaban untuk gpt-4o tidak bocor ke gpt-4o-mini. Route seperti chat-complex dikecualikan karena jawabannya personal dan terlalu sering berubah. Cache hit bukan hanya hemat biaya — ia memangkas latensi total secara dramatis karena tidak ada perjalanan ke provider sama sekali.

{
  "event": "cache_hit",
  "request_id": "req_88bc12",
  "cache_key_hash": "3f9a21e7",
  "ttl_remaining_s": 1840
}

#Semantic Cache dan Reuse Embeddings

Response cache masih kaku: pertanyaan yang maknanya sama tapi kalimatnya beda tidak akan kena cache. Solusinya semantic cache — membandingkan kemiripan embedding pertanyaan baru dengan pertanyaan yang sudah dijawab, lalu memakai jawaban yang cocok jika kemiripannya cukup tinggi.

cache:
  semantic_cache:
    enabled: true
    embedding_model: text-embedding-3-small
    similarity_threshold: 0.97
    store: redis
    ttl: 7200s
embeddings:
  reuse: true
  store: redis
  namespace: embeddings-app

Embedding untuk pertanyaan yang sama sering dihitung berulang kali oleh banyak fitur. embeddings.reuse memastikan embedding dihitung sekali lalu dipakai ulang — baik oleh semantic cache, RAG retrieval, maupun klasifikasi intent. Di episode 5 kalian sudah berkenalan dengan routing ke model embedding; kini embedding itu menjadi aset yang di-cache dan dibagi antar rute.

9router cache hit-rate
9router cache invalidate --route chat-general

Hati-hati dengan invalidate: jelas diperlukan setelah konten berubah, tapi jangan dipakai berlebihan karena membuang semua nilai cache. Pantau hit-rate dan sesuaikan TTL per rute — cache yang nyaris tidak pernah kena justru menambah overhead, bukan menguranginya.

#Penutup

Episode 15 membuat gateway kalian lebih cepat dan murah secara terukur: metrik latensi dan throughput dengan fokus pada p95/p99, overhead routing dan connection pooling yang memangkas waktu tunggu, model tiering dengan budget cost/latency sebagai kebijakan, serta response cache dan semantic cache plus reuse embeddings yang menghentikan panggilan berulang ke provider.

Inti yang harus dibawa pulang:

• Ukur dulu dengan metrik berlapis (gateway overhead, TTFT, total) dan perhatikan p95/p99, bukan cuma rata-rata.
• Connection pooling, HTTP/2, dan timeout yang tepat lebih berdampak dari pada micro-optimasi di tempat lain.
• Taruh trade-off cost/latency di konfigurasi routing, bukan di tebakan — model kecil cukup untuk tugas sederhana.
• Response cache menangani pertanyaan identik; semantic cache menangani pertanyaan dengan makna sama.
• Cache dan reuse embedding untuk menghindari perhitungan ulang, tapi pantau hit-rate agar cache tidak jadi beban.

Gateway yang cepat dan hemat sudah ada di tangan. Di episode 16 kita melebarkan logikanya: Route Extensions & Custom Actions — custom routing hooks, plugin-based decision logic, aksi domain-specific, dan modul rute yang bisa dipakai ulang. Sampai jumpa di sana!