Membangun AI Model Router Sendiri: Hemat 70% Biaya API LLM dengan Smart Routing

Tagihan API LLM Anda membengkak bukan karena modelnya mahal — tapi karena Anda memakai model yang salah untuk pekerjaan yang salah. Tutorial ini membimbing Anda membangun AI model router: satu pintu API yang cerdas memilih model termurah yang cukup bagus untuk setiap request, lengkap dengan fallback, load balancing, dan pelacakan biaya — dari nol sampai siap produksi.

Masalah yang Tidak Disadari Hampir Semua Tim AI

Coba jawab jujur: di aplikasi AI yang Anda bangun, berapa banyak model yang dipakai? Kalau jawabannya "satu — yang paling pintar", Anda hampir pasti membayar 10–50 kali lebih mahal dari yang seharusnya.

Lihat jurang harga yang nyata di pasar per Oktober 2026 (harga katalog OpenRouter, sinkron dengan tarif provider):

*Angka bertanda bintang adalah estimasi dari tarif resmi provider; angka lainnya dari katalog publik OpenRouter.

Jurang antara model flagship dan model ringan itu nyata: input Claude Opus 4.6 sekitar 53 kali lebih mahal daripada Mistral Small 3.2. Dan ingat — sisi output biasanya mendominasi tagihan pada pekerjaan generatif, karena output hampir selalu lebih mahal per token daripada input.

Namun kualitas tidak selalu mengikuti harga secara linear. Untuk klasifikasi sentimen, ekstraksi entitas, ringkasan pendek, atau menjawab FAQ dari konteks yang sudah disediakan, model sekelas Gemini 2.5 Flash Lite atau Mistral Small 3.2 memberikan hasil yang secara praktis tidak bisa dibedakan dari model flagship — dengan biaya kurang dari 2% saja. Model mahal baru benar-benar "membayar dirinya sendiri" pada pekerjaan yang sulit: penalaran multi-langkah, coding kompleks, atau agen otonom yang memakai tools.

Kesimpulannya sederhana tapi jarang dieksekusi: jangan pilih satu model untuk semua request. Pilih model yang tepat untuk setiap request. Itulah pekerjaan sebuah AI model router.

Apa itu AI Model Router?

AI model router (kadang disebut LLM gateway atau LLM proxy) adalah lapisan di antara aplikasi Anda dan para provider model. Aplikasi Anda memanggil satu endpoint yang seragam — biasanya kompatibel dengan API OpenAI — dan router memutuskan:

1. Model mana yang menangani request ini (berdasarkan aturan, kompleksitas, atau biaya),
2. Provider/deployment mana yang melayaninya (load balancing antar key dan provider),
3. Apa yang terjadi kalau gagal (retry, fallback ke model lain, cooldown),
4. Berapa biayanya (pelacakan spend per key, per tim, per user).

Pola ini sudah menjadi standar industri di 2026. LiteLLM — proyek open source MIT yang menjadi standar de-facto gateway self-hosted — mengekspos 100+ provider lewat satu API yang kompatibel OpenAI, lengkap dengan virtual key, budget per tim, rate limit, load balancing/fallback, caching, dan integrasi observabilitas seperti Langfuse dan OpenTelemetry. Alternatifnya: OpenRouter sebagai marketplace model ter-hosting (satu key untuk ratusan model, tanpa markup per-token — tapi ada biaya ~5,5% saat membeli kredit), atau Portkey dengan fitur enterprise seperti guardrails dan semantic caching.

Tutorial ini mengambil jalan tengah yang paling mendidik: membangun router sendiri, supaya Anda paham mekanismenya, lalu menunjukkan kapan sebaiknya memakai LiteLLM yang sudah matang. Target pembaca: backend developer yang sudah nyaman dengan Python atau Node.js dan sudah pernah memanggil API LLM.

Bagian 1: Tiga Pola Routing yang Dipakai di Produksi

Sebelum menulis kode, pahami dulu tiga pola routing yang dipakai tim-tim produksi. Semuanya bisa dikombinasikan.

Pola 1: Static routing berbasis aturan

Paling sederhana: petakan jenis task ke model secara eksplisit di konfigurasi. Contoh nyata dari sebuah aplikasi customer support:

• Klasifikasi intent tiket → model murah (Gemini 2.5 Flash Lite)
• Draft balasan dari template → model menengah (GPT-5 Mini)
• Eskalasi kompleks / reasoning → model flagship (Claude Sonnet/Opus)

Kelebihannya: deterministik, mudah di-debug, mudah dihitung biayanya. Kekurangannya: kaku — kalau ada task baru, Anda harus menambah aturan manual.

Pola 2: Complexity-based routing (router cerdas)

Router menilai kompleksitas setiap prompt, lalu memilih tier model yang sesuai. Penilaiannya bisa memakai:

• Heuristik murah: panjang prompt, jumlah code block, kata kunci ("analisis", "buktikan", "debug"), bahasa (beberapa model kecil lemah di bahasa tertentu).
• Model klasifier kecil: model murah/fast dipakai sebagai "juri" untuk menilai apakah prompt butuh model besar. Biayanya kecil karena klasifikasi hanya butuh sedikit output token.
• Skor historis: kalau prompt mirip pernah dijawab buruk oleh model murah (dari data eval), naikkan tier.

Pola ini yang memberi penghematan terbesar, karena mayoritas request di aplikasi nyata ternyata "mudah".

Pola 3: Cascade dengan quality gate

Request selalu dicoba dulu ke model murah. Hasilnya dinilai oleh verifier — bisa berupa model lain, aturan deterministik (misalnya: apakah output valid JSON sesuai skema?), atau skor confidence. Kalau lolos, selesai. Kalau gagal, naik ke model yang lebih mahal. Pola ini populer untuk ekstraksi data terstruktur, di mana validasi skema bersifat deterministik dan murah.

Di bagian 2 dan 3 kita akan membangun pola 1 + 2, dengan fondasi fallback dari pola 3.

Kenapa tidak cukup "pakai model termurah saja"?

Karena ada quality cliff: titik di mana model yang lebih murah tiba-tiba gagal total pada task tertentu, bukan sekadar sedikit lebih buruk. Contoh: model kecil sering gagal mengikuti instruksi format JSON yang kompleks atau melakukan tool-calling multi-langkah. Router yang baik bukan sekadar "selalu pilih yang murah", tapi "pilih yang termurah yang terbukti cukup bagus untuk task ini" — dan bukti itu datang dari evaluasi, yang kita bahas di Bagian 5.

Bagian 2: Fondasi — LiteLLM sebagai Router Instan

Membangun router dari nol itu mendidik, tapi untuk produksi, roda yang sudah ada biasanya lebih bulat. LiteLLM adalah titik awal yang masuk akal: satu dependensi Python yang memberi Anda pola 1 dan fondasi pola 3 (fallback, retry, load balancing) tanpa menulis ulang normalisasi parameter untuk 100+ provider — pekerjaan yang menurut sebuah RFC migrasi publik memakan ratusan baris kode per provider kalau dibangun sendiri.

Instalasi dan router paling sederhana

pip install "litellm>=1.90.0"  # pin versi di produksi (lihat catatan keamanan di bawah)

Contoh router in-process dengan dua deployment dan fallback:

from litellm import Router

router = Router(
    model_list=[
        {
            "model_name": "ringkas-cepat",
            "litellm_params": {
                "model": "gemini/gemini-2.5-flash-lite",
                "api_key": "GEMINI_API_KEY_ANDA",
            },
        },
        {
            "model_name": "ringkas-cepat",
            "litellm_params": {
                "model": "mistral/mistral-small-3.2-24b",
                "api_key": "MISTRAL_API_KEY_ANDA",
            },
        },
        {
            "model_name": "coding-berat",
            "litellm_params": {
                "model": "anthropic/claude-sonnet-4-5",
                "api_key": "ANTHROPIC_API_KEY_ANDA",
            },
        },
    ],
    fallbacks=[
        {"ringkas-cepat": ["coding-berat"]},  # kalau semua deployment murah gagal, naik tier
    ],
    num_retries=2,
)

resp = await router.acompletion(
    model="ringkas-cepat",
    messages=[{"role": "user", "content": "Ringkas artikel ini dalam 3 bullet..."}],
)
print(resp.choices[0].message.content)
print("Biaya request ini: $", resp._hidden_params.get("response_cost"))

Perhatikan konsep kuncinya: model_name adalah nama virtual — aplikasi Anda hanya kenal ringkas-cepat dan coding-berat. Di baliknya, Router me-load-balance antar deployment (strategi default: round-robin berbobot penggunaan), melakukan retry, lalu fallback ke model lain kalau semuanya gagal. Ganti provider di balik nama virtual tanpa menyentuh kode aplikasi.

Mode proxy: satu gateway untuk seluruh tim

Untuk dipakai banyak service, jalankan LiteLLM sebagai server proxy mandiri dengan file YAML:

# litellm-config.yaml
model_list:
  - model_name: default-murah
    litellm_params:
      model: openrouter/deepseek/deepseek-chat
      api_key: os.environ/OPENROUTER_KEY
  - model_name: default-murah
    litellm_params:
      model: gemini/gemini-2.5-flash-lite
      api_key: os.environ/GEMINI_KEY
  - model_name: premium
    litellm_params:
      model: anthropic/claude-opus-4-6
      api_key: os.environ/ANTHROPIC_KEY

general_settings:
  master_key: sk-master-anda-yang-panjang

litellm_settings:
  num_retries: 2
  request_timeout: 60

Jalankan:

docker run -d --name litellm-proxy \
  -p 4000:4000 \
  -v $(pwd)/litellm-config.yaml:/app/config.yaml \
  -e OPENROUTER_KEY="..." -e GEMINI_KEY="..." -e ANTHROPIC_KEY="..." \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

Semua aplikasi kini memanggil http://localhost:4000/v1/chat/completions persis seperti memanggil OpenAI — cukup ganti base_url dan api_key. Dari dashboard admin Anda bisa membuat virtual key per tim dengan budget bulanan dan rate limit masing-masing, lalu melihat spend per key secara real-time. Inilah fondasi FinOps untuk AI: tidak ada lagi satu API key raksasa yang dipakai semua orang tanpa akuntabilitas.

Strategi routing yang tersedia

LiteLLM mendukung beberapa strategi pemilihan deployment yang relevan untuk penghematan:

• usage-based-routing-v2: mengarahkan request ke deployment yang masih punya sisa kuota TPM/RPM — penting kalau Anda mencampur provider dengan limit berbeda (misalnya satu deployment OpenRouter 1 RPM vs satu deployment NVIDIA 40 RPM).
• latency-based routing: memilih deployment dengan latensi terendah berdasarkan riwayat.
• Cooldown otomatis: deployment yang gagal berulang (429/500/timeout) diistirahatkan sementara; dengan Redis, status cooldown ini konsisten antar replika.
• Context-window fallback: kalau prompt melebihi context window model murah, otomatis dilempar ke model dengan window lebih besar.

Untuk arsitektur produksi, referensi resmi menempatkan PostgreSQL + Redis di samping proxy — Postgres untuk spend logs dan virtual key, Redis untuk cache, rate limit, dan status cooldown lintas instance.

Catatan keamanan yang wajib dibaca

Radar teknologi publik mencatat dua insiden LiteLLM di 2026 yang relevan untuk operator: rilis PyPI yang dikompromikan pada Maret 2026 (credential stealer) dan rantai kerentanan yang memungkinkan eskalasi hak akses pada gateway pada Juni 2026. Pelajarannya bukan "jangan pakai LiteLLM", melainkan disiplin operasional yang berlaku untuk gateway apa pun:

1. Pin versi image/dependensi dan pantau rilis keamanan.
2. Jangan pernah mengekspos gateway ke internet publik tanpa autentikasi dan network policy yang ketat.
3. Putar master key dan provider key secara berkala; simpan di secret manager, bukan di YAML yang ter-commit.

Bagian 3: Membangun Smart Router Sendiri (Pola 2)

LiteLLM menyelesaikan "bagaimana request disalurkan dengan andal". Bagian ini menyelesaikan "bagaimana memutuskan model termurah yang cukup bagus" — lapisan klasifikasi kompleksitas yang duduk di depan gateway.

Arsitektur

Request user
   │
   ▼
┌─────────────────────┐
│ Complexity Classifier│  ← heuristik + model juri murah
│  → tier: MUDAH /     │
│    SEDANG / SULIT    │
└────────┬────────────┘
         ▼
┌─────────────────────┐
│  LiteLLM Proxy       │  ← /v1/chat/completions
│  model_name =        │
│  tier-mudah/sedang/  │
│  sulit               │
└─────────────────────┘

Pemisahan ini disengaja: logika bisnis routing (milik Anda, sering berubah) terpisah dari logika reliabilitas (milik gateway, jarang berubah).

Langkah 1: Definisikan tier dan budget kualitas

Jangan mulai dari kode — mulai dari tabel keputusan. Contoh untuk aplikasi asisten dokumen:

Angka biaya hanyalah acuan — yang mengunci keputusan adalah ambang kualitas per tier, yang Anda tentukan lewat eval (Bagian 5).

Langkah 2: Klasifier heuristik (gratis, nol latensi tambahan)

Untuk banyak aplikasi, 80% keputusan routing bisa diselesaikan dengan heuristik deterministik:

import re

CODE_BLOCK = re.compile(r"```")
HARD_KEYWORDS = re.compile(
    r"\b(buktikan|analisis mendalam|debug|refactor|arsitektur|bandingkan secara kritis|"
    r"langkah demi langkah|step by step reasoning)\b", re.IGNORECASE)
TOOL_HINT = re.compile(r"\b(cari|booking|bayar|kirim|jadwalkan)\b", re.IGNORECASE)

def classify_heuristic(prompt: str) -> str:
    score = 0
    score += len(prompt) // 2000                    # prompt panjang → cenderung sulit
    score += 2 * len(CODE_BLOCK.findall(prompt))    # blok kode → butuh ketelitian
    if HARD_KEYWORDS.search(prompt):
        score += 3
    if TOOL_HINT.search(prompt):
        score += 2                                 # butuh tool-calling yang andal
    if score >= 5:
        return "SULIT"
    if score >= 2:
        return "SEDANG"
    return "MUDAH"

Heuristik itu murah tapi buta konteks. Maka tambahkan lapisan kedua.

Langkah 3: Model juri murah untuk kasus abu-abu

Hanya untuk prompt yang skor heuristiknya "SEDANG" (zona abu-abu), tanyakan ke model termurah dengan prompt klasifikasi yang sangat pendek — output hanya satu token:

JUDGE_SYSTEM = (
    "Klasifikasikan kompleksitas pertanyaan pengguna. Jawab HANYA dengan satu kata: "
    "MUDAH, SEDANG, atau SULIT. MUDAH = jawab langsung dari info yang diberikan. "
    "SULIT = butuh penalaran multi-langkah, coding kompleks, atau keputusan kritis."
)

async def classify_with_judge(prompt: str) -> str:
    resp = await cheap_client.chat.completions.create(
        model="mistral-small-3.2",          # ~$0.094/$0.25 per 1M token
        messages=[
            {"role": "system", "content": JUDGE_SYSTEM},
            {"role": "user", "content": prompt[:1500]},
        ],
        max_tokens=5,
        temperature=0,
    )
    label = resp.choices[0].message.content.strip().upper()
    return label if label in ("MUDAH", "SEDANG", "SULIT") else "SEDANG"

Biaya juri ini nyaris nol: input 400 token ($0.00004) dan output 1 token. Bandingkan dengan penghematan karena tidak memakai model flagship untuk request mudah — rasio penghematannya ribuan banding satu.

Langkah 4: Satukan semuanya

TIER_MODEL = {"MUDAH": "tier-mudah", "SEDANG": "tier-sedang", "SULIT": "tier-sulit"}

async def smart_complete(messages, **kwargs):
    prompt = messages[-1]["content"]
    tier = classify_heuristic(prompt)
    if tier == "SEDANG":                       # zona abu-abu → tanya juri
        tier = await classify_with_judge(prompt)

    resp = await gateway_client.chat.completions.create(
        model=TIER_MODEL[tier],                # nama virtual di LiteLLM proxy
        messages=messages,
        extra_headers={"x-routing-tier": tier},  # untuk analitik spend per tier
        **kwargs,
    )
    # Catat untuk evaluasi: prompt hash, tier, model aktual, biaya
    log_routing_decision(prompt, tier, resp)
    return resp

Header x-routing-tier memungkinkan Anda memecah dashboard biaya per tier — data yang Anda butuhkan untuk membuktikan penghematan ke manajemen.

Kapan heuristik tidak cukup: semantic routing

Untuk aplikasi dengan ratusan jenis task, pendekatan yang naik kelas adalah semantic routing: embed contoh prompt per tier (atau per model), lalu arahkan prompt baru ke tier yang embedding-nya paling mirip. Ini memakai vector search — pola yang sama seperti di tutorial RAG — tapi databasenya berisi "contoh task", bukan dokumen. Implementasinya bisa sesederhana satu tabel Postgres + pgvector dengan 200–500 contoh berlabel. Akurasinya biasanya mengalahkan heuristik keyword, dengan biaya satu kali embedding per request yang sangat kecil.

Bagian 4: Tiga Pengungkit Biaya yang Sering Terlewat

Router memilih model termurah yang cukup bagus. Tiga teknik ini membuat "cukup bagus" menjadi lebih murah lagi — dan semuanya kompatibel dengan arsitektur di atas.

1. Prompt caching: diskon untuk konteks yang berulang

Aplikasi RAG dan agen mengirim system prompt + konteks yang sama berulang-ulang. Provider besar memberi diskon cache yang signifikan: misalnya tarif cached input GPT-5 Mini hanya 10% dari tarif normal ($0.025 vs $0.25 per 1M token). Syaratnya: prefix prompt harus identik byte-per-byte antar request. Praktiknya:

• Letakkan konten statis (system prompt, definisi tools, sedikit contoh) di awal, konten dinamis (pertanyaan user) di akhir.
• Jangan menyisipkan timestamp atau ID acak di tengah blok statis — itu merusak cache.
• LiteLLM meneruskan parameter caching provider secara transparan; pastikan format pesannya stabil.

2. Semantic caching: jangan panggil model untuk pertanyaan yang sudah dijawab

Portkey mempopulerkan pola ini di gateway komersial, tapi Anda bisa membangun versi sederhananya: embed pertanyaan user, cari di cache vektor; kalau kemiripan di atas ambang (misalnya 0.97), kembalikan jawaban tersimpan tanpa memanggil model sama sekali. Cocok untuk FAQ dan pertanyaan berulang. Hati-hati: ambang terlalu rendah menghasilkan jawaban basi untuk pertanyaan yang mirip tapi berbeda maksud — ukur dengan eval sebelum mengaktifkan.

3. Pahami biaya tersembunyi agregator

OpenRouter tidak me-markup tarif per-token — angka di katalognya adalah tarif provider. Tapi ada biaya 5,5% saat membeli kredit yang duduk di atas setiap dolar yang Anda belanjakan. Untuk satu model yang sama, jalur langsung ke provider atau agregator yang memberi diskon flat bisa lebih murah secara total. Router Anda seharusnya sadar-biaya-penuh (all-in cost), bukan sekadar tarif stiker: simpan effective_price = sticker_price × (1 + fee) per deployment di konfigurasi, dan biarkan strategi routing mempertimbangkan angka itu.

Bagian 5: Evaluasi — Cara Membuktikan Router Anda Tidak Mengorbankan Kualitas

Router tanpa eval adalah tebakan yang dibungkus kode. Berikut kerangka eval minimal yang dipakai tim produksi.

1. Bangun golden dataset

Kumpulkan 100–300 contoh request nyata dari log produksi (anonimkan PII), beri label tier yang benar menurut penilaian manusia, plus jawaban referensi atau kriteria penerimaan. Bagi per kategori: ekstraksi, ringkasan, Q&A, coding, reasoning.

2. Ukur quality-per-tier, bukan sekadar akurasi global

Jalankan setiap contoh ke model tiap tier, lalu hitung:

• Akurasi per tier (apakah model tier MUDAH menjawab contoh MUDAH dengan benar?)
• Under-routing rate: persentase contoh SULIT yang salah dikirim ke tier murah — metrik yang paling berbahaya, karena inilah kegagalan yang dilihat user.
• Over-routing rate: persentase contoh MUDAH yang dikirim ke tier mahal — inilah pemborosan yang dilihat finance.
• Biaya per 1.000 request pada distribusi traffic nyata Anda.

Router yang baik meminimalkan under-routing (kualitas) sambil menekan over-routing (biaya). Terima sedikit over-routing sebagai asuransi; jangan pernah mentolerir under-routing yang tinggi.

3. Contoh perhitungan penghematan

Misalkan aplikasi Anda memproses 1 juta request/bulan dengan distribusi 70% MUDAH, 20% SEDANG, 10% SULIT. Rata-rata per request: 2.000 token input, 500 token output.

• Tanpa router (semua ke Claude Opus 4.6, $5/$25): 1 jt × (0.002×5 + 0.0005×25) = 1 jt × $0.0225 = $22.500/bulan.
• Dengan router: MUDAH ke Mistral Small 3.2 ($0.094/$0.25): 700 rb × $0.000313 = $219. SEDANG ke DeepSeek V3.2 ($0.259/$0.80): 200 rb × $0.000918 = $184. SULIT ke Opus 4.6: 100 rb × $0.0225 = $2.250. Total ≈ $2.653/bulan.

Penghematan ≈ 88% — dan itu sebelum caching. Angka pastinya tergantung distribusi traffic Anda, tapi orde besarnya konsisten di laporan-laporan produksi: mayoritas request memang mudah.

4. Eval kontinu: sampling produksi

Golden dataset membusuk seiring perilaku user berubah. Ambil sampel acak 1–2% traffic produksi per minggu, kirim ke tier yang lebih tinggi sebagai "pembanding", dan bandingkan kualitasnya dengan penilaian model juri atau reviewer manusia. Kalau under-routing naik, ketatkan klasifier. Ini menutup loop: router Anda belajar dari traffic nyata, bukan dari asumsi awal.

Bagian 6: Checklist Produksi

Sebelum router Anda melayani traffic sungguhan, pastikan daftar ini centang semua:

• Pin versi gateway (image Docker / dependensi Python) dan langganan kanal rilis keamanannya.
• Postgres + Redis terpasang untuk spend tracking, virtual key, dan cooldown lintas replika.
• Virtual key per tim/layanan dengan budget dan rate limit — tidak ada key tanpa pemilik.
• Fallback chain teruji: matikan sengaja satu provider di staging, pastikan traffic pindah otomatis.
• Timeout dan retry budget: batasi retry agar satu request lambat tidak menahan user (contoh: timeout 60 dtk, maks 2 retry).
• Alerting spend: alert harian kalau spend naik >20% dari baseline — router yang bug bisa lebih mahal daripada tanpa router.
• Log keputusan routing (prompt hash, tier, model aktual, biaya) untuk audit dan eval ulang.
• PII handling: kalau prompt mengandung data pribadi, pastikan alur masking/retensinya jelas — beberapa gateway menyediakan hook guardrail untuk ini.
• Jangan ekspos gateway ke publik tanpa autentikasi; perlakukan seperti database.

Studi Kasus Mini: Pola yang Dipakai Produk AI-Router

Menariknya, pola di artikel ini adalah pola yang sama dipakai oleh produk AI-router komersial — termasuk yang sedang dibangun banyak startup Indonesia saat ini. Sebuah layanan AI-router pada dasarnya adalah Bagian 2 + Bagian 3 yang diprodukkan: gateway multi-provider dengan virtual key dan spend tracking, plus lapisan klasifikasi yang memilih model termurah per request. Bedanya dengan membangun sendiri: produk komersial menambah SLA, dashboard analitik siap pakai, dan kurasi model yang selalu diperbarui mengikuti rilis terbaru.

Kapan membangun sendiri, kapan memakai produk jadi? Aturan praktisnya: kalau tim Anda punya kapasitas DevOps untuk menjalankan Postgres + Redis dan kebutuhan routingnya spesifik (misalnya aturan kepatuhan data atau tier kustom per pelanggan), membangun di atas LiteLLM memberi kontrol penuh tanpa biaya lisensi. Kalau yang Anda butuhkan adalah kecepatan — integrasi satu API key hari ini juga, tanpa mengoperasikan infrastruktur — agregator ter-hosting atau produk AI-router jadi pilihan yang rasional, dengan catatan Anda menghitung biaya all-in termasuk fee kredit dan markup.

Satu hal yang berlaku di kedua jalur: data eval adalah aset termahalnya. Siapa pun yang memegang golden dataset dan histori keputusan routing terbaik dialah yang bisa menekan biaya paling agresif tanpa mengorbankan kualitas. Investasikan waktu di Bagian 5 sebelum mengoptimasi kode routernya.

Kesimpulan: Router Adalah FinOps untuk AI

Tiga ide yang dibawa pulang dari artikel ini:

1. Jurang harga antar model adalah 10–50x, tapi jurang kualitas untuk task mudah mendekati nol. Setiap request yang dikirim ke model flagship padahal bisa dijawab model ringan adalah uang yang dibuang.
2. Pisahkan keputusan routing dari keandalan penyaluran. Logika "model termurah yang cukup bagus" adalah milik Anda (klasifier heuristik + juri murah); retry, fallback, load balancing, dan spend tracking adalah pekerjaan gateway seperti LiteLLM.
3. Router tanpa eval adalah tebakan. Golden dataset, metrik under/over-routing, dan sampling produksi adalah yang membedakan penghematan nyata dari penurunan kualitas yang tersembunyi.

Mulai dari yang kecil: petakan tiga tier, jalankan LiteLLM proxy dalam Docker, arahkan satu endpoint non-kritis lewat router, dan ukur selama dua minggu. Dalam pengalaman banyak tim, minggu kedua adalah saat dashboard biaya membuat semua orang bertanya kenapa hal ini tidak dilakukan dari awal.

Seluruh angka harga pada artikel ini mengacu pada tarif publik per Oktober 2026 dan dapat berubah — selalu verifikasi tarif terkini di katalog provider sebelum mengambil keputusan anggaran.