Routing cerdas: penyedia termurah yang cukup cepat untuk prompt Anda
Beberapa penyedia menjual model yang sama, dan yang termurah seringkali yang paling lambat untuk prompt panjang. Jadi untuk setiap permintaan, UberLLM memeriksa seberapa cepat setiap penyedia mulai menjawab pada ukuran prompt tersebut dan berapa biaya permintaan ini pada masing-masing penyedia, memilih penyedia yang cukup cepat (dalam 2x dari yang tercepat, atau di bawah 1 detik), dan mengirimkan permintaan ke yang termurah di antara mereka. Tidak ada yang perlu diatur: ini berjalan pada setiap permintaan chat kecuali Anda meneruskan opsi routing Anda sendiri.
Mengapa penyedia termurah tidak cukup baik
Model seperti DeepSeek V4.1 Flash dijual oleh beberapa penyedia dengan harga berbeda. Mengirim setiap permintaan ke yang termurah berfungsi untuk prompt pendek. Ini bermasalah pada prompt panjang, karena sebelum model menulis kata pertamanya, ia harus membaca seluruh prompt, dan beberapa penyedia membaca prompt panjang jauh lebih lambat daripada yang lain.
Kami mengukurnya pada lalu lintas langsung pada 28 Oktober 2026. Pada DeepSeek V4.1 Flash, penyedia termurah membutuhkan waktu 15 detik untuk mengirim kata pertama untuk prompt 32k–128k token, dan 34 detik di atas 128k. Penyedia lain membutuhkan waktu 1.5–2 detik untuk prompt yang sama.
Itu paling penting untuk coding agents. Claude Code, Cline, dan alat serupa mengirimkan seluruh konteks kerja pada setiap giliran, seringkali 60k–130k token, dan sebagian besar adalah cache read.
Harga saja juga tidak tepat untuk prompt tersebut. Peringkat berdasarkan harga input normal mengabaikan harga cache reads, sehingga prompt yang di-cache panjang bisa masuk ke pengecer yang mengenakan biaya $0.07 per juta cached tokens ketika penyedia lain mengenakan biaya $0.0013. Panggilan itu lebih lambat dan sekitar 50x lebih mahal.
Apa yang terjadi pada setiap permintaan
- Ukur kecepatan berdasarkan ukuran prompt. UberLLM mencatat waktu setiap penyedia untuk token pertama untuk setiap model, dalam empat kelompok ukuran: di bawah 8k token, 8k–32k, 32k–128k dan di atas 128k. Penyedia yang sama menjawab prompt 31-token dalam 1.7 detik dan prompt 105k-token dalam 15.5 detik, jadi satu angka per penyedia akan salah. Data berasal dari panggilan nyata. Pemeriksaan kecepatan terpisah setiap 5 menit pada sekitar 20k, 60k dan 150k token menangkap perlambatan pada satu ukuran bahkan ketika panggilan singkat cepat.
- Harga permintaan tepat ini pada setiap penyedia. Input, input yang di-cache, dan output dihargai secara terpisah, berdasarkan campuran token permintaan ini. Untuk prompt agen yang panjang, harga baca cache biasanya merupakan sebagian besar tagihan.
- Pertahankan penyedia yang cukup cepat. Penyedia memenuhi syarat ketika waktu tipikalnya untuk token pertama berada dalam 2x dari penyedia tercepat yang diukur, atau di bawah 1 detik. Kecepatan dinilai berdasarkan median. Pencilan lambat dihitung dengan bobot seperempat setelah penyedia memiliki setidaknya 10 sampel, sehingga satu panggilan buruk tidak mengeluarkan penyedia yang baik.
- Kirim permintaan ke yang termurah di antara mereka. Penyedia tercepat hanya menang ketika yang lebih murah terlalu lambat.
- Jaga data tetap terkini. 5% dari permintaan masuk ke penyedia yang datanya terlalu sedikit, sehingga penyedia yang menjadi lebih cepat akan diperhatikan. Penyedia yang menolak panggilan diperlakukan sebagai tidak dapat digunakan dan dicoba lagi dalam 15 menit.
Jika belum ada data kecepatan untuk suatu model, permintaan akan dikirim ke penyedia termurah yang tersedia. Penyedia yang harganya di atas harga biasa model hanya dipilih karena kecepatan ketika harganya masih setidaknya 50% di bawah harga daftar resmi model.
Prompt panjang: penyedia kedua saat yang pertama lambat
Bahkan penyedia yang cepat terkadang memulai dengan lambat. Pada satu prompt 120k-token yang di-cache, penyedia yang sama memulai dalam 0.45, 3.7, dan 8.5 detik pada tiga panggilan berturut-turut. Memilih penyedia yang tepat tidak dapat memperbaiki hal itu, jadi permintaan streaming yang panjang mendapatkan cadangan:
- Prompt 32k–128k token: jika tidak ada kata pertama yang tiba setelah 1 detik, permintaan yang sama juga dikirim ke penyedia cepat yang berbeda.
- Prompt di atas 128k token: kedua permintaan dimulai sekaligus.
- Penyedia pertama yang menjawab akan melakukan streaming balasan. Permintaan lainnya dibatalkan segera setelah kata pertama tiba.
Anda mendapatkan satu balasan dan membayar untuk satu balasan. Kami membayar untuk permintaan yang dibatalkan, dari anggaran harian tetap. Ketika anggaran itu habis, permintaan panjang akan dikirim ke satu penyedia hingga hari berikutnya (UTC).
Percobaan Ulang Dialihkan ke Penyedia Berbeda
Jika panggilan gagal sebelum ada balasan yang sampai kepada Anda, UberLLM mengulanginya melalui rute lain, hingga 4 kali percobaan. Sebelum perutean cerdas, percobaan ulang bisa saja kembali ke penyedia lambat yang sama lagi. Panggilan yang gagal pada setiap percobaan berbiaya $0. Detailnya ada di model dan perutean.
Hasil pada lalu lintas langsung
DeepSeek V4.1 Flash, waktu hingga kata pertama:
| Ukuran prompt | Sebelum | Sesudah |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Lebih dari 128k tokens | 40 s | 3.4 s |
Pada panggilan streaming yang melebihi 32k token (28 Oktober 2026), 10% panggilan paling lambat berubah dari 57 detik menjadi 8.7 detik. Biaya 1,000 dari panggilan tersebut berubah dari $2.49 menjadi $1.04, karena harga baca-cache kini diperhitungkan dalam pilihan. Pada 29 Oktober, prompt 203k-token mulai menjawab dalam sekitar 4 detik.
Satu batasan: tidak ada penyedia yang memulai prompt 100k-token secara instan. Dibutuhkan beberapa detik pada semuanya. Smart routing menghilangkan waktu tunggu ekstra dari penyedia yang lambat. Ini tidak dapat menghilangkan waktu yang dibutuhkan penyedia cepat untuk membaca prompt.
Apa yang Anda bayar
Setiap permintaan ditagih sesuai biaya yang dikenakan oleh penyedia yang melayaninya, tanpa biaya tambahan dari UberLLM. Setiap panggilan dan biayanya terdaftar di Dashboard → Activity. Untuk membatasi harga, kirim provider.max_price dengan prompt dan completion. Perutean cerdas kemudian hanya memilih penyedia di bawah batas Anda, dan permintaan tidak akan pernah ditagih di atasnya.
Menggunakan routing Anda sendiri sebagai gantinya
Anda tidak perlu mengubah apa pun untuk mendapatkan smart routing. Jika Anda menyebutkan penyedia di provider.only, provider.ignore atau provider.order, mengatur provider.sort, atau menambahkan sufiks :floor atau :nitro ke ID model, pilihan Anda akan digunakan dan smart routing tidak akan berjalan untuk permintaan tersebut:
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price adalah pengecualian: ini bekerja bersama dengan smart routing. Semua opsi tercantum di model dan routing.