Cost, Billing, and Ops12 Oktober 2026Flatkey Team

vLLM vs SGLang: Throughput, Latensi, Dukungan Model, dan Operasi

Bandingkan SGLang vs vLLM untuk inferensi GPU cloud: throughput, latensi, dukungan model, operasional, benchmark, dan kapan Ollama cocok untuk pengujian lokal.

vLLM vs SGLang: Throughput, Latency, Dukungan Model, dan Operasional

Keputusan sglang vs vllm bukanlah kontes generik "server mana yang lebih cepat?". vLLM dan SGLang sama-sama merupakan framework inferensi LLM yang serius, keduanya dapat mengekspos endpoint yang kompatibel dengan OpenAI, dan keduanya dapat melayani traffic produksi pada GPU cloud. Pilihan yang tepat bergantung pada bentuk permintaan, keluarga model, kebutuhan output terstruktur, reuse cache, topologi GPU, dan seberapa besar permukaan operasional yang ingin dimiliki tim Anda.

Jawaban singkatnya: mulai dengan vLLM ketika Anda membutuhkan default produksi yang paling luas, cakupan model yang matang, serving OpenAI-compatible yang familiar, metrik, dan pola penskalaan multi-GPU. Uji SGLang ketika loop agen yang sensitif terhadap latensi, output terstruktur, serving multimodal, reuse sesi/prefix, atau optimisasi model spesifik SGLang merupakan inti beban kerja. Gunakan Ollama untuk pengembangan lokal dan demo, bukan sebagai titik perbandingan utama untuk serving GPU cloud throughput tinggi.

Panduan ini memberi tim AI enterprise sebuah perbandingan vLLM vs SGLang yang praktis lintas throughput, latensi, dukungan model, dan operasional. Panduan ini juga menyertakan rencana benchmark yang bisa Anda salin sebelum berkomitmen pada kapasitas GPU.

Matriks keputusan cepat vLLM vs SGLang

Decision factor	vLLM is usually the safer starting point when...	SGLang is worth a serious canary when...
Throughput	You need a mature serving engine with broad model support, PagedAttention lineage, prefix caching, speculative decoding options, quantization options, metrics, and multi-GPU deployment patterns.	Your workload benefits from SGLang's runtime focus on low-latency/high-throughput serving, Radix-style cache reuse, structured outputs, multimodal paths, or model-specific SGLang release work.
Latency	Tail latency is mostly driven by batching, model size, context length, GPU class, and queue control; you want predictable operations before framework tuning.	You have multi-turn or agent sessions where cache reuse and structured decoding change time-to-first-token and completion latency.
Model support	You need the broadest practical list of generative, pooling, embedding, rerank, reward, multimodal, and hardware-supported models from a single serving stack.	Your exact target model appears in SGLang's supported-models pages, cookbook, or recent release notes, and SGLang has a known optimization path for it.
Structured outputs	You can rely on OpenAI-compatible response formats or app-side validation, and structured output is not the main latency bottleneck.	JSON schema, regex, or EBNF-constrained output is a core endpoint behavior, especially for agents and workflow automation.
Operations	You want production-stack guidance, metrics, parallelism docs, common deployment patterns, and easier hiring/on-call familiarity.	Your platform team can absorb faster-moving serving internals and wants to tune cache/session behavior more aggressively.
Migration risk	You already run OpenAI-compatible clients and want to keep the server swap reversible.	You can isolate one route, benchmark it independently, and rollback if real traffic does not improve.

Untuk sebagian besar tim, jawaban praktisnya bukan "standarkan satu selamanya." Melainkan:

Tempatkan vLLM di belakang rute OpenAI-compatible yang stabil sebagai baseline produksi default.
Canary SGLang untuk workload di mana output terstruktur, reuse cache, atau model yang dioptimalkan SGLang dapat menggerakkan metrik level layanan yang nyata.
Bandingkan keduanya berdasarkan biaya per output yang diterima, latensi p95, latensi p99, tingkat error, utilisasi GPU, dan waktu operator.

Apa itu vLLM?

vLLM adalah engine serving LLM sumber terbuka yang dibangun di sekitar manajemen memori yang efisien untuk inferensi. Makalah awalnya memperkenalkan PagedAttention untuk manajemen memori KV-cache dan memposisikan vLLM sebagai sistem serving throughput tinggi untuk model bahasa besar. Dokumentasi vLLM saat ini mencakup serving yang kompatibel dengan OpenAI, arsitektur model yang didukung, automatic prefix caching, speculative decoding, quantization, metrik, dan pola deployment parallelism/scaling.

Dalam praktiknya, vLLM adalah kandidat default ketika tim Anda bertanya:

Bisakah kita mengekspos endpoint /v1/chat/completions yang familiar atau kompatibel dengan OpenAI?
Bisakah kita melayani model open-weight populer tanpa membangun path runtime kustom?
Bisakah kita menskalakan dari satu GPU ke konfigurasi tensor, pipeline, data, context, atau expert parallel?
Bisakah kita mengekspor metrik yang berguna dan mengintegrasikan endpoint ke dalam stack platform yang sudah ada?
Bisakah kita menemukan engineer dan contoh ketika ada yang rusak pada pukul 2 pagi?

Kematangan itu penting. Sebuah framework serving bukan hanya benchmark kernel; ia juga adalah antrean, scheduler, kebijakan cache, model loader, permukaan metrik, rencana upgrade, dan batas insiden.

Apa itu SGLang?

SGLang adalah framework inferensi untuk serving model bahasa besar dan multimodal pada level produksi. Dokumentasinya menjelaskan runtime yang dirancang untuk inferensi low-latency dan high-throughput dari setup GPU tunggal hingga klaster terdistribusi. Framework ini mendukung API yang kompatibel dengan OpenAI, output terstruktur dengan JSON schema, regex, dan constraint EBNF, perilaku radix cache yang sadar sesi, HiCache, panduan platform hardware, serta katalog model yang didukung di berbagai kelas model seperti text generation, multimodal, embeddings, reranking, reward, classification, dan model khusus.

SGLang sangat menarik ketika endpoint bukan hanya "ambil prompt, kembalikan teks." Framework ini layak diuji canary ketika:

Aplikasi memerlukan output terstruktur yang ketat, bukan sekadar JSON best-effort.
Beban kerja memiliki prefix yang berulang, sesi yang berlangsung lama, agen multi-turn, atau loop alat tempat reuse cache penting.
Famil model tercakup oleh dokumentasi SGLang atau pekerjaan rilis SGLang terbaru.
Tim ingin menyetel perilaku serving untuk aksi agen dengan latensi rendah, serving vision-language, atau kendala output khusus.
Tim nyaman memvalidasi runtime yang bergerak lebih cepat terhadap traffic produksi mereka sendiri.

SGLang bisa menjadi pilihan yang kuat, tetapi jangan memilihnya hanya dari tangkapan layar benchmark. Konfirmasikan model yang tepat, panjang konteks, tokenizer, bentuk batch, mode output terstruktur, kelas GPU, dan mode kegagalan yang akan Anda operasikan.

Throughput: token per detik hanyalah metrik pertama

Untuk throughput vLLM vs SGLang, jangan membandingkan satu angka token per detik dari dua posting blog yang berbeda. Throughput berubah dengan:

Famil model dan jumlah parameter.
Panjang konteks dan panjang output.
Ukuran batch dan pola kedatangan request.
Reuse prefix prompt.
Kendala output terstruktur.
Mode kuantisasi.
Jenis GPU, ukuran memori, interconnect, dan stack driver.
Pengaturan paralelisme tensor, pipeline, data, konteks, atau expert.
Kebijakan kontrol admission dan timeout antrean.

Keunggulan vLLM adalah memberikan banyak tim baseline yang kuat dengan cepat. Dokumentasinya mengekspos jalur serving, dukungan model, metrik, prefix-caching, speculative-decoding, kuantisasi, dan scaling yang jelas. Jika tim platform Anda membutuhkan default produksi minggu ini, vLLM biasanya adalah tempat benchmark pertama harus dimulai.

Keunggulan SGLang muncul ketika beban kerja cocok dengan desain serving-nya. Dukungan output terstruktur dan fitur cache SGLang dapat mengubah throughput praktis dari workflow yang mengulang prefix, menjalankan sesi agen, atau membutuhkan constrained decoding. Jika traffic Anda penuh dengan prompt panjang yang berbagi instruksi sistem, template retrieval, contoh few-shot, atau skema tool, benchmark SGLang dengan perilaku cache diaktifkan alih-alih memperlakukan setiap request sebagai independen.

Gunakan skor throughput ternormalisasi ini:

accepted output throughput =
  accepted output tokens or accepted structured results
  / wall-clock test duration

Kemudian tambahkan ekonomi GPU:

cost per accepted output =
  (GPU rental + storage + load time + retries + operator time)
  / accepted results

Baris kedua itulah tempat keputusan GPU cloud menjadi nyata. Jika suatu framework mencatat throughput mentah yang lebih tinggi tetapi membutuhkan lebih banyak retry yang gagal, lebih banyak tuning manual, atau workaround khusus model, endpoint yang lebih murah mungkin justru yang lain.

Latensi: ukur prefill, decode, dan tail secara terpisah

Untuk latensi vLLM vs SGLang, pecah request menjadi beberapa fase:

Metrik latensi	Apa yang diberikannya kepada Anda	Mengapa penting
Waktu ke token pertama	Perilaku prefill, scheduling, antrean, dan cache	Kritis untuk chat, agen, copilot, dan alat interaktif.
Latensi antar-token	Performa decode di bawah beban	Membentuk kecepatan streaming yang dirasakan.
Latensi end-to-end	Waktu penyelesaian yang terlihat oleh pengguna	Metrik terbaik untuk tugas lengkap dan SLO API.
Latensi p95 dan p99	Risiko ekor di bawah konkurensi	Menentukan apakah layanan bertahan dari traffic nyata.
Waktu tunggu antrean	Kesehatan kontrol admission	Mencegah perbandingan framework menutupi overload.
Latensi yang disesuaikan retry	Biaya pengguna nyata setelah kegagalan	Menangkap OOM, timeout, eviction, dan error upstream.

vLLM sering lebih mudah dijadikan baseline karena lebih banyak tim tahu cara menjalankannya, mengamatinya, dan menskalakannya. SGLang dapat memenangkan kasus latensi tertentu ketika cache dan jalur output terstrukturnya selaras dengan workload Anda. Satu-satunya cara jujur untuk mengetahuinya adalah menjalankan keduanya dengan jejak request yang sama.

Jangan benchmark dengan satu prompt sintetis lalu menyatakan pemenang. Bangun tiga jejak:

Chat singkat: prompt pendek, output pendek, konkurensi tinggi.
RAG konteks panjang: prompt panjang, output sedang, template sistem dan retrieval yang berulang.
Loop agen/alat: skema berulang, output terstruktur, beberapa turn, pembatalan, dan retry.

Jika SGLang mengalahkan vLLM hanya pada loop agen/alat, itu tetap berguna. Arahkan kelas itu secara terpisah. Jika vLLM cukup dekat dengan operasi yang lebih sederhana, kesederhanaan operasional mungkin lebih bernilai daripada kemenangan latensi yang sempit.

Dukungan model: keluasan versus kecocokan yang tepat

Dukungan model adalah tempat banyak perdebatan sglang vs vllm menjadi terlalu abstrak. Pertanyaannya bukan "proyek mana yang mendukung lebih banyak model?" Pertanyaannya adalah "runtime mana yang mendukung model, modalitas, mode presisi, dan hardware deployment yang persis kita butuhkan sekarang?"

Gunakan checklist dukungan model ini:

Pemeriksaan	Mengapa ini penting
Arsitektur model yang tercantum persis	Mencegah fallback tak terduga atau kernel yang tidak didukung.
Kompatibilitas tokenizer dan template chat	Menghindari penurunan halus pada kualitas output atau regresi format.
Jendela konteks diuji pada panjang target	Konteks panjang dapat mengubah tekanan memori KV-cache.
Jalur input multimodal diuji	Beban kerja vision-language tidak sama dengan chat teks saja.
Structured output diuji	Skema JSON atau batasan grammar dapat mengubah latensi dan akurasi.
Mode quantization diuji	Quantization hanya bobot, aktivasi, dan KV-cache memiliki trade-off yang berbeda.
Mode paralelisme diuji	Keberhasilan di satu GPU tidak membuktikan serving multi-GPU.
Backend hardware diuji	NVIDIA, AMD, CPU, XPU, TPU, NPU, dan jalur spesifik platform berbeda-beda.
Jalur upgrade ditinjau	Rilis framework baru dapat meningkatkan dukungan tetapi juga mengubah flag dan perilaku.

Dokumentasi vLLM menampilkan cakupan model yang didukung secara luas dan bagian spesifik hardware. Itu menjadikan vLLM default yang kuat ketika tim procurement atau platform membutuhkan lapisan dasar berisiko lebih rendah lintas banyak keluarga model.

Halaman model yang didukung dan panduan platform hardware SGLang juga menunjukkan set jalur yang dikelola secara luas, termasuk text generation, multimodal, embeddings, reranking, reward, klasifikasi, dan model khusus. Itu membuat SGLang menarik ketika jalur yang didukungnya selaras erat dengan keluarga model yang benar-benar Anda jalankan.

Pola yang keliru adalah memilih framework karena ia mendukung sebuah model di README, lalu menemukan bahwa panjang konteks, mode quantization, kelas GPU, atau mode structured-output yang Anda butuhkan belum divalidasi.

Operasional: bagian yang biasanya dilewati oleh posting benchmark

Perbedaan operasional antara vLLM dan SGLang menjadi lebih penting begitu traffic menghadap pelanggan. Tim on-call Anda membutuhkan jawaban atas pertanyaan produksi yang umum:

Bagaimana cara kami melakukan roll model baru tanpa mematahkan request yang aktif?
Metrik mana yang memberi tahu kami bahwa endpoint kelebihan beban?
Bagaimana kami mengisolasi waktu tunggu antrean dari waktu decode?
Apa yang terjadi ketika satu GPU mengalami OOM?
Bagaimana kami menetapkan max context length, max batch size, dan concurrency tanpa membuat request kecil kelaparan?
Bagaimana kami me-restart worker tanpa kehilangan setiap request yang sedang berjalan?
Bagaimana kami mereproduksi output buruk dengan model, tokenizer, prompt template, dan parameter sampling yang sama?
Bagaimana kami mengatribusikan biaya ke tim, produk, pelanggan, atau lingkungan?

vLLM memiliki ekosistem produksi yang matang di sekitar serving yang kompatibel dengan OpenAI, integrasi production stack, metrik, dan dokumentasi penskalaan. Itu tidak membuatnya otomatis, tetapi menurunkan beban operasional saat pertama kali digunakan.

SGLang juga memiliki fitur operasional yang serius, termasuk serving yang kompatibel dengan OpenAI, dokumen platform hardware, kontrol cache, jalur structured-output, dan materi model gateway. Trade-off-nya adalah tim Anda mungkin membutuhkan validasi yang lebih spesifik terhadap beban kerja karena kekuatan SGLang sering kali terkait dengan pola serving yang tepat.

Untuk tim AI enterprise, pola terbaik adalah menjaga kontrak klien tetap stabil dan membuat engine serving dapat dipertukarkan di belakang sebuah route. Itu berarti:

Satu kontrak endpoint yang kompatibel dengan OpenAI.
Request ID dan envelope error yang stabil.
Alias model yang diberi versi.
Route canary terpisah untuk pengujian SGLang.
Metrik per-route untuk latensi, throughput, error, retry, dan biaya.
Rencana rollback sebelum canary menerima traffic produksi.

Flatkey cocok untuk lapisan di atas keputusan ini. Jika tim Anda melayani sebagian beban kerja melalui GPU yang di-host sendiri dan lainnya melalui API model resmi, Flatkey dapat menyediakan satu kunci, satu saldo, satu tagihan, rekaman penggunaan model dan tool, serta kontrol tata kelola di seluruh beban kerja sisi API. Untuk keputusan GPU cloud, itu memungkinkan Anda membandingkan biaya endpoint yang di-host sendiri dengan perbandingan harga model AI, harga sewa GPU, harga AI gateway, dan kontrol kuota AI API alih-alih memperlakukan setiap layanan inferensi sebagai masalah finansial yang terpisah.

Rencana benchmark vLLM vs SGLang

Gunakan rencana benchmark vLLM vs SGLang ini sebelum membuat keputusan framework.

1. Bekukan beban kerja

Buat trace request dengan:

1.000 hingga 10.000 prompt representatif.
Distribusi panjang token prompt.
Distribusi token output yang diharapkan.
Skema structured-output yang diperlukan, jika ada.
Modalitas yang diperlukan: teks, vision-language, embedding, rerank, atau reward.
Target concurrency yang nyata.
Perilaku cancellation, timeout, dan retry.
SLO p95 dan p99 yang diharapkan.

2. Bekukan hardware

Jalankan kedua framework pada setup GPU yang sama:

Model GPU dan memori.
Jumlah GPU.
SXM atau PCIe jika relevan.
Versi CUDA, ROCm, driver, dan image container.
CPU, RAM, storage, dan jalur jaringan.
Pengaturan tensor atau pipeline parallel.
Bobot model dan tokenizer yang sama.

Jika Anda mengubah hardware di antara pengujian, Anda აღარ lagi membandingkan vLLM vs SGLang. Anda sedang membandingkan dua stack deployment.

3. Bekukan knob serving

Catat:

Panjang model maksimum.
Token batched maksimum.
Permintaan konkuren maksimum.
Pengaturan cache.
Pengaturan kuantisasi.
Pengaturan speculative decoding.
Backend output terstruktur.
Pengaturan tool-calling atau reasoning parser.
Kebijakan kontrol penerimaan.

Pertahankan satu run "default" dan satu run "tuned" untuk setiap framework. Default menunjukkan time-to-production. Tuned menunjukkan batas puncaknya.

4. Ukur output yang tepat

Buat tabel seperti ini:

Metrik	vLLM default	vLLM tuned	SGLang default	SGLang tuned
Permintaan diterima per menit
Token output diterima per detik
Waktu ke token pertama p50 / p95 / p99
Latency end-to-end p50 / p95 / p99
Tingkat error
Latency yang disesuaikan dengan retry
Headroom memori GPU
Utilisasi GPU
Queue wait p95
Biaya per hasil yang diterima
Waktu operator untuk deployment
Waktu operator untuk debugging

Dua baris terakhir sengaja tidak glamor. Sering kali justru itulah yang menentukan pemenang sebenarnya.

5. Jalankan tes kegagalan

Jangan memilih framework serving sebelum Anda menguji perilaku kegagalan:

Banjiri queue.
Kirim context yang terlalu panjang.
Matikan satu worker.
Restart pod saat traffic berjalan.
Picu OOM dengan request buruk yang sudah diketahui.
Batalkan client streaming.
Kembalikan output terstruktur yang tidak valid dan pastikan penanganannya di sisi aplikasi.
Rollback ke container sebelumnya.

Framework yang gagal dengan cara yang dipahami tim Anda bisa jadi lebih aman daripada yang punya run median-latency sedikit lebih baik.

Ollama vs vLLM vs SGLang

Pertanyaan ollama vs vllm vs sglang biasanya mencampur dua pekerjaan yang berbeda.

Ollama sangat bagus untuk pengembangan lokal, demo, alur kerja laptop, dan pengujian lokal sederhana yang kompatibel dengan OpenAI. Ini berguna ketika seorang developer ingin menarik model dan menjalankan API lokal dengan cepat.

vLLM dan SGLang adalah perbandingan yang serius untuk serving inferensi LLM di GPU cloud. Keduanya dibangun untuk deployment server, batching, throughput model-serving, kebutuhan multi-GPU, dan perilaku endpoint produksi. Jika pertanyaan Anda adalah "bagaimana cara menjalankan model di MacBook atau workstation pengembangan saya?", bandingkan Ollama. Jika pertanyaan Anda adalah "bagaimana cara melayani pengguna berbayar di H100, H200, L40S, A100, atau cluster GPU sewaan?", bandingkan vLLM dan SGLang.

Rekomendasi praktis

Kondisi tim	Jalur yang direkomendasikan
Endpoint LLM open-weight pertama di produksi	Mulai dengan vLLM, lalu benchmark SGLang pada kontrak route yang sama.
Layanan agen yang sangat bergantung pada output terstruktur	Canary SGLang lebih awal; bandingkan validitas JSON, latency, dan retry rate terhadap vLLM.
Banyak keluarga model dan modalitas	Gunakan vLLM sebagai baseline pertama, lalu validasi SGLang hanya untuk route yang memiliki jalur dukungan yang jelas.
Workload agen sesi panjang atau prefix berulang	Benchmark perilaku cache/session SGLang secara langsung terhadap prefix caching vLLM.
Pengadaan yang membandingkan rencana GPU cloud	Benchmark keduanya dan hitung biaya workload yang selesai, bukan hanya harga per jam GPU.
Tim kecil tanpa on-call platform	Prioritaskan framework dengan dokumentasi lebih sederhana, metrik lebih mudah, dan lebih sedikit flag kustom untuk model Anda yang spesifik.
Prototyping lokal	Gunakan Ollama secara lokal, lalu benchmark ulang di vLLM atau SGLang sebelum menjanjikan angka produksi.
Workload sisi API dengan utilisasi GPU yang tidak pasti	Bandingkan self-hosting dengan jalur API model melalui Flatkey sebelum menyewa kapasitas jangka panjang.

Pertanyaan yang sering diajukan

Apa itu SGLang vs vLLM?

SGLang dan vLLM adalah framework serving inferensi LLM open-source. vLLM banyak digunakan sebagai baseline serving produksi dengan dukungan model yang luas, serving yang kompatibel dengan OpenAI, metrik, prefix caching, speculative decoding, kuantisasi, dan dokumentasi scaling. SGLang adalah framework serving produksi yang berfokus pada inferensi berlatensi rendah dan throughput tinggi, dengan API yang kompatibel dengan OpenAI, output terstruktur, fitur cache/session, dukungan multimodal, dan dokumentasi model yang didukung.

Apakah SGLang lebih cepat daripada vLLM?

Terkadang, untuk beberapa workload. Jawaban sglang vs vllm yang bermakna bergantung pada model, panjang prompt, panjang output, bentuk batch, mode output terstruktur, reuse cache, kelas GPU, dan tuning. Jangan percaya klaim pemenang universal. Jalankan trace request yang sama pada kedua framework dan bandingkan throughput yang diterima, latency p95/p99, tingkat error, dan biaya per hasil yang diterima.

Apakah vLLM lebih baik untuk produksi?

vLLM sering kali menjadi baseline produksi pertama yang lebih aman karena memiliki dokumentasi yang luas, dukungan model, serving yang kompatibel dengan OpenAI, metrik, dan pola deployment yang umum. Itu tidak berarti ia menang di setiap route. SGLang bisa menjadi pilihan produksi yang lebih baik untuk route di mana output terstruktur, reuse cache, perilaku multimodal, atau dukungan SGLang spesifik model menghasilkan peningkatan yang terukur.

Haruskah saya menggunakan Ollama, vLLM, atau SGLang?

Gunakan Ollama untuk pengembangan lokal dan pengujian model sederhana. Gunakan vLLM atau SGLang untuk serving GPU cloud. Mulailah dengan vLLM ketika Anda menginginkan jalur default yang paling luas; coba SGLang secara bertahap ketika beban kerja Anda membutuhkan output terstruktur, loop agen berlatensi rendah, atau optimasi model yang didukung SGLang.

Bagaimana cara membenchmark vLLM vs SGLang?

Kunci model, tokenizer, hardware, container, jejak permintaan, panjang konteks, konkurensi, dan knob serving. Ukur time to first token, latensi end-to-end p95/p99, throughput output yang diterima, tingkat error, latensi yang disesuaikan dengan retry, memori GPU, utilisasi GPU, waktu tunggu antrean, dan biaya per hasil yang diterima. Jalankan konfigurasi default dan yang telah dituning untuk keduanya.

Sumber resmi yang diperiksa

Perbandingan ini didasarkan pada dokumentasi framework dan paper terbaru, bukan pada satu tangkapan layar benchmark pihak ketiga. Referensi utama yang berguna meliputi:

Kesimpulan

Untuk keputusan sglang vs vllm, pilih vLLM sebagai baseline default ketika tim AI enterprise Anda membutuhkan dukungan model yang luas, dokumentasi serving yang matang, dan operasional yang lebih mudah. Pilih SGLang untuk jalur di mana output terstruktur, perilaku session/cache, serving multimodal, atau dukungan spesifik model dapat meningkatkan latensi, throughput, atau kebenaran secara nyata. Jaga kontrak klien tetap stabil, benchmark keduanya pada traffic Anda sendiri, dan arahkan berdasarkan workload, bukan ideologi.

Jika benchmark menunjukkan bahwa self-hosting belum lebih murah atau lebih sederhana daripada model API, gunakan satu kunci, satu saldo, dan usage ledger Flatkey untuk membandingkan rute API resmi sebelum berkomitmen pada kapasitas GPU jangka panjang.