Bedah Repositori LiteLLM: Membangun Proxy Layer Pribadi untuk Semantic Caching dan Cost Tracking Terpadu

Ada satu momen yang sangat akrab bagi para software engineer yang berkutat dengan Large Language Models (LLM) belakangan ini: melihat tagihan bulanan OpenAI, Anthropic, dan AWS Bedrock membengkak tiga kali lipat, sementara separuh dari pemanggilan API tersebut sebenarnya menanyakan hal yang itu-itu saja.

Kondisi ini diperparah saat aplikasi kita mulai menuntut orkestrasi multi-model. Kita ingin memakai Claude 3.5 Sonnet untuk penalaran kompleks, GPT-4o untuk fungsi terstruktur, dan model lokal atau DeepSeek-R1 untuk tugas-tugas penalaran murah meriah. Seketika, codebase backend berubah menjadi sarang laba-laba: puluhan SDK berbeda, penanganan error rate limit (429) yang tambal sulam, format payload yang tidak seragam, hingga ketiadaan visibilitas mengenai siapa di dalam tim yang menghabiskan kuota paling rakus.

Di titik inilah konsep proxy layer berhenti menjadi sekadar opsi optimasi dan berubah menjadi kebutuhan infrastruktur mutlak.

Salah satu proyek open-source paling elegan yang menjawab kekacauan ini adalah LiteLLM (dikelola oleh BerriAI di GitHub). Repositori ini tidak mencoba menjadi framework agen yang rumit seperti LangChain atau LlamaIndex. LiteLLM memilih satu masalah mendasar dan menyelesaikannya secara tuntas: menjadi penerjemah universal (universal adapter) berkinerja tinggi yang membungkus lebih dari 100 penyedia LLM ke dalam satu antarmuka standar OpenAI, lengkap dengan semantic caching dan pelacakan biaya terpadu.

Mari kita bongkar arsitektur internal repositori LiteLLM, menyelami bagaimana pipa abstraksinya bekerja, dan membangun proxy layer mandiri yang siap menahan beban produksi.

Anatomi Repositori: Bagaimana LiteLLM Bekerja di Balik Layar

Ketika Anda mengkloning repositori BerriAI/litellm, Anda akan menemukan struktur kode Python yang dibangun dengan fokus modularitas tinggi. Alih-alih memaksakan paradigma baru, tim pengembang LiteLLM membuat keputusan desain yang cerdas: jadikan OpenAI API spec sebagai de facto standard.

litellm/
├── proxy/               # FastAPI-based Proxy Server (Enterprise Layer)
│   ├── proxy_server.py  # Router utama, middleware, dan lifecycle handlers
│   └── management_endpoints/ # Endpoint untuk keys, users, budgets, metrics
├── router.py            # Logika load balancing, fallback, dan retry
├── caching/             # Redis, In-Memory, & Semantic Cache managers
├── cost_calculator.py   # Engine kalkulasi token & harga per model
└── main.py              # Core translation layer (Unified Interface)

Arsitektur internal LiteLLM dapat dipecah menjadi empat komponen krusial yang bekerja secara sekuensial pada setiap siklus request-response:

Client App(Cursor, LangChain, Backend)
         │
         ▼  [Standard OpenAI Request: /v1/chat/completions]
┌────────────────────────────────────────────────────────┐
│                   LiteLLM Proxy Core                   │
│                                                        │
│  1. Authentication & Budget Gatekeeper                 │
│     (Cek API Key, Kuota Pengguna, Rate Limit)          │
│                                                        │
│  2. Semantic Cache Interceptor(Redis Stack)           │
│     ├── Hit: Kembalikan respons vektor tersimpan ───────► (Response)
│     └── Miss: Lanjut ke Router                         │
│                                                        │
│  3. Smart Router & Failover Engine                     │
│     (Pilih Target Model -> Claude / OpenAI / DeepSeek) │
│                                                        │
│  4. Payload Transformer & Normalizer                   │
│     (Format input & output ke/dari format spesifik)    │
└────────────────────────────────────────────────────────┘
         │
         ▼  [Provider-Specific Payload]
Upstream Providers(Anthropic, OpenAI, Bedrock, AiStudio.id)

1. The Normalization Engine (main.py & utils.py)

LiteLLM menyelesaikan ini dengan Transformation Maps. Saat Anda memanggil completion(model="claude-3-5-sonnet", messages=...), fungsi inti di main.py akan memetakan payload standar ke format internal Anthropic, mengirimkannya via HTTP client asinkron (httpx), lalu membungkus respons balikan ke dalam objek ModelResponse yang identik dengan output OpenAI. Aplikasi konsumen tidak perlu tahu bahwa di balik layar yang menjawab adalah Claude atau Llama-3.

2. Router & Fault Tolerance (router.py)

Salah satu pemborosan terbesar dalam ekosistem LLM adalah pemrosesan ulang kueri yang secara semantik identik. Exact matching cache tradisional (berbasis hash MD5 atau SHA256) akan gagal total jika pengguna mengetik:

Request A: "Bagaimana cara konfigurasi CORS di FastAPI?"
Request B: "Beri saya contoh setup CORS pada framework FastAPI."

User Prompt ──► Hitung Embedding(misal: text-embedding-3-small)
                      │
                      ▼
             Redis Vector Index(HNSW / Flat)
                      │
           [Kalkulasi Cosine Similarity]
                      │
        ┌─────────────┴─────────────┐
        ▼                           ▼
Similarity >= 0.85          Similarity < 0.85
   (Cache HIT)                 (Cache MISS)
        │                           │
Kembalikan payload          Kirim ke Model Upstream,
tersimpan seketika          simpan vektor & output ke Redis

1. Embedding Generation: Prompt yang masuk diubah menjadi representasi vektor numerik berdimensi 1536 (menggunakan model embedding yang dikonfigurasi).
2. K-Nearest Neighbors (KNN) Query: LiteLLM mengeksekusi kueri RediSearch menggunakan metrik jarak Cosine Similarity:

FT.SEARCH idx:semantic_cache "*=>[KNN 1 @prompt_vector $BLOB AS score]" PARAMS 2 BLOB <embedding_bytes> DIALECT 2

1. Threshold Evaluation: Jika jarak skor berada di bawah ambang batas (misalnya distance <= 0.15 atau similarity >= 0.85), proxy langsung mengembalikan respons yang tersimpan di Redis. Waktu respons terpangkas dari 2.500 ms menjadi di bawah 15 ms, dan biaya token menjadi nol.

mkdir litellm-proxy-layer && cd litellm-proxy-layer
touch docker-compose.yml litellm-config.yaml .env

version: '3.8'

services:
  redis-stack:
    image: redis/redis-stack-server:latest
    container_name: litellm-redis-cache
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    environment:
      - REDIS_ARGS=--save 60 1 --appendonly yes

  litellm-proxy:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: litellm-proxy-core
    restart: always
    ports:
      - "4000:4000"
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
    environment:
      - PORT=4000
      - STORE_MODEL_IN_DB=True
      - DATABASE_URL=postgresql://litellm:password@db:5432/litellm # Opsional untuk multi-user DB
    env_file:
      - .env
    command: ["--config", "/app/config.yaml", "--detailed_debug"]
    depends_on:
      - redis-stack

volumes:
  redis_data:

model_list:
  # Deployment Utama: Claude 3.5 Sonnet
  - model_name: production-reasoning
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 500

  # Deployment Cadangan (Fallback): GPT-4o
  - model_name: production-reasoning
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
      rpm: 1000

  # Model Embedding Khusus untuk Semantic Cache
  - model_name: cache-embedding-model
    litellm_params:
      model: openai/text-embedding-3-small
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  # Aktifkan Fallback Otomatis jika Primary Model Error (Rate Limit / Timeout)
  fallbacks:
    - production-reasoning: ["openai/gpt-4o"]
  
  # Konfigurasi Semantic Caching via Redis Stack
  cache:
    type: "redis-semantic"
    redis_url: "redis://redis-stack:6379/0"
    embedding_model: "cache-embedding-model"
    similarity_threshold: 0.88  # Nilai semakin mendekati 1.0 = semakin ketat kecocokannya
    ttl: 86400                  # Cache valid selama 24 jam

  # Pengaturan Keamanan dan Budgeting
  max_budget: 100.0             # Limit global proxy (USD)
  budget_duration: "30d"

general_settings:
  master_key: sk-master-proxy-layer-secret-key-2026

OPENAI_API_KEY=sk-proj-xxxx...
ANTHROPIC_API_KEY=sk-ant-xxxx...
LITELLM_MASTER_KEY=sk-master-proxy-layer-secret-key-2026

Jalankan proxy cluster:

docker compose up -d

Kirim request pertama:

curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-master-proxy-layer-secret-key-2026" \
  -d '{
    "model": "production-reasoning",
    "messages": [
      {"role": "user", "content": "Jelaskan konsep arsitektur microservices dalam tiga kalimat singkat."}
    ]
  }'

Perhatikan waktu latensi pada respon pertama: berkisar antara 1.500 ms – 3.000 ms (Upstream API Call).

Kirim request kedua dengan struktur kalimat berbeda, namun maksud identik:

curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-master-proxy-layer-secret-key-2026" \
  -d '{
    "model": "production-reasoning",
    "messages": [
      {"role": "user", "content": "Tolong jelaskan apa itu arsitektur microservices secara ringkas, cukup 3 kalimat."}
    ]
  }'

Hasil respons kedua instan: latensi turun drastis ke kisaran 10 - 20 ms. Respons diambil langsung dari Redis Vector Index tanpa memanggil Anthropic maupun OpenAI.

Jika kita menilik berkas litellm/model_prices_and_context_window.json, repositori ini memelihara kamus global yang diperbarui secara berkala berisi biaya input token, output token, batas konteks, hingga tier cached tokens dari hampir setiap model AI di pasaran.

{
  "claude-3-5-sonnet-20241022": {
    "input_cost_per_token": 0.000003,
    "output_cost_per_token": 0.000015,
    "cache_read_input_token_cost": 0.0000003,
    "max_tokens": 8192,
    "max_input_tokens": 200000
  }
}

Setiap kali response stream selesai diterima, fungsi kalkulasi pada cost_calculator.py akan:

1. Menghitung total prompt_tokens dan completion_tokens dari response metadata.


2. Mengalikan jumlah token tersebut dengan nilai di kamus harga.


3. Mencatat metrik biaya ke database internal per API Virtual Key yang Anda bagikan ke tim.

Anda dapat membuat virtual key khusus untuk tim Frontend dengan batasan budget mandiri menggunakan endpoint manajemen LiteLLM:

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-master-proxy-layer-secret-key-2026" \
  -H "Content-Type: application/json" \
  -d '{
    "key_alias": "frontend-dev-team",
    "max_budget": 25.0,
    "duration": "7d",
    "models": ["production-reasoning"]
  }'

Jika tim Frontend menghabiskan kuota $25 dalam rentang 7 hari, proxy otomatis mengembalikan status HTTP 400 (Budget Exceeded), melindungi akun utama Anda dari tagihan tak terkontrol akibat infinite loop saat pengembangan.

Membangun proxy layer sendiri memberikan kendali penuh, namun ada pertimbangan operasional (DevOps overhead) yang harus dievaluasi secara matang sesuai skala tim.

Bagi tim rekayasa perangkat lunak mandiri yang memiliki kapabilitas site reliability engineering (SRE) solid, menjalankan LiteLLM di kluster Kubernetes atau VPS internal memberikan keleluasaan audit dan kedaulatan data penuh.

Namun, jika fokus utama Anda adalah kecepatan iterasi produk tanpa ingin disibukkan dengan urusan memelihara kluster Redis Vector, memory compaction, patch keamanan kontainer, dan pusingnya transaksi kartu kredit internasional di banyak platform terpisah, mengintegrasikan arsitektur ini dengan ekosistem AiStudio.id API Gateway menjadi jembatan yang sangat rasional.

Anda dapat mengarahkan upstream provider LiteLLM langsung ke titik akhir AiStudio.id, atau memanfaatkan gateway terkelolanya secara langsung untuk mendapatkan keandalan routing, cost tracking, dan akses multi-model dengan satu saldo terpusat.

import os
from openai import OpenAI

# Arahkan base_url ke Proxy Layer LiteLLM kita
client = OpenAI(
    api_key="sk-master-proxy-layer-secret-key-2026", # Atau virtual key per-tim
    base_url="http://localhost:4000/v1"
)

def ask_assistant(prompt: str) -> str:
    response = client.chat.completions.create(
        model="production-reasoning", # Virtual alias yang telah kita petakan di proxy
        messages=[
            {"role": "system", "content": "Anda adalah asisten rekayasa software senior."},
            {"role": "user", "content": prompt}
        ],
        temperature=0.2
    )
    
    # Ambil metadata penggunaan token
    usage = response.usage
    print(f"[METRIK] Prompt: {usage.prompt_tokens} | Output: {usage.completion_tokens}")
    
    return response.choices[0].message.content

if __name__ == "__main__":
    jawaban = ask_assistant("Bagaimana cara mendesain idempotency key pada REST API?")
    print("\nRespon Model:\n", jawaban)

Perhatikan bahwa di sisi aplikasi klien, kode di atas murni kode standar OpenAI SDK. Kita tidak lagi mengimpor SDK Anthropic, Mistral, atau penyedia lainnya. Semua kerumitan orkestrasi, perpindahan ke model cadangan saat terjadi gangguan, semantic cache hit, dan pembatasan kuota biaya diselesaikan sepenuhnya di level proxy layer.

Kecepatan perkembangan model AI saat ini luar biasa tinggi. Model yang menjadi standar industri hari ini bisa jadi tergantikan oleh arsitektur yang lebih murah dan cepat dalam hitungan bulan ke depan. Mengikat kode aplikasi kita secara erat (hardcoded coupling) ke salah satu SDK vendor adalah jebakan teknis yang berbahaya.

Membangun atau mengadopsi proxy layer seperti LiteLLM—atau memadukannya dengan infrastruktur terkelola seperti AiStudio.id—bukan sekadar tentang menghemat puluhan dolar melalui semantic caching. Ini adalah tentang kedaulatan arsitektur.

Ketika kode aplikasi Anda hanya berbicara dengan satu protokol universal, Anda memiliki kendali penuh untuk menukar mesin inferensi di balik layar, mengarahkan beban kerja ke penyedia termurah, mengamankan anggaran tim, dan memastikan aplikasi tetap menyala tanpa gangguan meski penyedia utama mengalami insiden down-time. Pemenang dalam perlombaan adopsi teknologi AI bukan mereka yang paling banyak menulis prompt*, melainkan mereka yang membangun saluran pipa infrastruktur paling tangguh dan adaptif.

Catatan Penulis

> Sandra menulis seputar rekayasa prompt, efisiensi arsitektur AI, dan produk digital di AiStudio.id.