Latensi vs Throughput LLM: Cara Pembeli API Mengukur Kecepatan

Saat mengevaluasi API model, memahami trade-off antara latency dan throughput LLM sangat penting untuk mengoptimalkan pengalaman pengguna sekaligus biaya infrastruktur. Latency mengukur waktu yang berlalu bagi sebuah model untuk merespons kueri, sementara throughput mengukur volume token yang diproses atau dihasilkan oleh sistem selama periode waktu tertentu. Bagi pengembang dan pembuat produk AI, mengoptimalkan satu metrik sering kali mengharuskan adanya kompromi pada metrik lainnya.

Memilih metrik kecepatan yang salah dapat menyebabkan antarmuka pengguna menjadi lambat atau tagihan API yang membengkak tanpa alasan. Analisis ini menyediakan kerangka kerja untuk mengukur metrik tersebut, memilih API yang tepat untuk beban kerja spesifik Anda, dan menerapkan strategi optimasi.

Poin Penting

• Time to First Token (TTFT) adalah metrik latency yang krusial untuk aplikasi interaktif seperti antarmuka chat, yang berdampak langsung pada kecepatan yang dirasakan pengguna.
• Tokens Per Second (TPS) per stream adalah metrik throughput utama untuk tugas pemrosesan latar belakang, seperti ringkasan dokumen atau ekstraksi data massal.
• Arsitektur dan ukuran model menentukan performa dasar, dengan model yang lebih kecil seperti DeepSeek V4 Flash atau Gemini 3.5 Flash menawarkan kecepatan yang lebih tinggi dibandingkan model unggulan seperti Claude Fable 5 atau GPT-5.5.
• Multi-provider routing memungkinkan pengembang untuk mengoptimalkan latency atau throughput secara dinamis berdasarkan performa penyedia secara real-time.

---

Mendefinisikan Metrik Utama: Latency vs. Throughput

Untuk membuat keputusan yang tepat saat membeli atau melakukan routing API, pengembang harus memecah "kecepatan" menjadi komponen yang terukur dan berbeda.

Timeline of an LLM API Request:
[User Sends Request] 
       │
       ▼ (Network Transit + Prompt Processing)
[Time to First Token (TTFT)] <--- Critical for interactive UX
       │
       ▼ (Autoregressive Generation: Tokens Per Second)
[Inter-Token Latency (ITL)]  <--- Dictates reading comfort
       │
       ▼ (Generation Complete)
[Total Latency]              <--- Critical for non-streaming blocking calls

1. Time to First Token (TTFT)

TTFT adalah durasi antara pengiriman permintaan API dan penerimaan token pertama dari respons. Metrik ini mencakup waktu perjalanan pulang-pergi jaringan (round-trip time), serialisasi prompt, dan waktu yang diperlukan model untuk memproses token input (fase prefill). Untuk aplikasi interaktif, TTFT adalah metrik terpenting karena menentukan seberapa cepat pengguna melihat respons mulai muncul.

2. Inter-Token Latency (ITL)

ITL adalah waktu rata-rata yang berlalu di antara pembuatan token berturut-turut selama fase streaming. Jika ITL terlalu tinggi, teks akan muncul lebih lambat daripada kecepatan baca manusia, yang mengakibatkan pengalaman pengguna yang mengecewakan. ITL yang stabil dan rendah memastikan rendering teks yang mulus.

3. Tokens Per Second (TPS)

TPS merepresentasikan throughput pembuatan model. Ini dihitung sebagai jumlah total token output dibagi dengan total waktu pembuatan (tidak termasuk fase prefill). Saat mengevaluasi throughput, pengembang harus membedakan antara:

• Single-user TPS: Kecepatan pembuatan dari satu stream aktif.
• System throughput: Jumlah total token yang dapat diproses oleh penyedia API secara bersamaan di semua pengguna aktif.

4. Total Latency

Total latency adalah durasi lengkap permintaan API dari awal hingga akhir. Untuk permintaan non-streaming, seperti ekstraksi JSON terstruktur atau klasifikasi latar belakang, total latency adalah metrik utama yang harus dipantau.

---

Trade-off Arsitektural: Mengapa Kecepatan Bervariasi

Trade-off antara latency dan throughput LLM berakar pada fisika arsitektur transformer dan bandwidth memori perangkat keras. Selama fase prefill (yang menentukan TTFT), komputasi sangat dapat diparalelkan karena seluruh prompt input diproses sekaligus. Fase ini biasanya bersifat compute-bound.

Selama fase pembuatan (yang menentukan TPS), model menghasilkan token satu per satu. Setiap token baru memerlukan pemuatan semua bobot model dari High Bandwidth Memory (HBM) ke GPU SRAM. Proses autoregresif ini bersifat memory-bandwidth bound.

Karena kendala ini, pengembang harus menyelaraskan pilihan model mereka dengan kebutuhan performa utama mereka:

• Model Unggulan: Model seperti Claude Fable 5, Claude Opus 4.8, dan GPT-5.5 memprioritaskan kedalaman penalaran di atas kecepatan mentah. Model ini memiliki jumlah parameter yang sangat besar, yang menghasilkan TTFT lebih tinggi dan TPS lebih rendah.
• Model Cepat dan Hemat Biaya: Model seperti DeepSeek V4 Flash, Gemini 3.5 Flash, dan Laguna XS 2.1 dioptimalkan untuk kecepatan. Mereka menggunakan jumlah parameter yang lebih kecil, speculative decoding, atau arsitektur terdistilasi untuk memberikan TTFT yang sangat rendah dan TPS yang tinggi.

Pengembang dapat melihat TokenLab LLM API Leaderboard for Developers untuk membandingkan metrik kecepatan real-time di seluruh tingkatan model ini.

---

Kerangka Kerja Keputusan: Kapan Harus Memprioritaskan Latency vs. Throughput

Prioritas antara latency dan throughput sepenuhnya bergantung pada kasus penggunaan aplikasi.

Kasus Penggunaan	Metrik Utama	Metrik Sekunder	Kelas Model yang Direkomendasikan
Chatbot Interaktif	Time to First Token (TTFT)	Inter-Token Latency (ITL)	Fast Frontier (misal: Gemini 3.5 Flash)
Asisten Coding	TTFT & Single-stream TPS	Total Latency	Specialized Coding (misal: Claude Sonnet 5, Kimi K2.7 Code)
Ekstraksi Data Massal	System Throughput	Biaya per Tugas	Low-Cost Open-Weight (misal: DeepSeek V4 Flash, GLM-5.2)
Agen Otonom	Total Latency (Non-streaming)	TTFT	High-Reasoning Open-Weight (misal: DeepSeek V4 Pro)
Pembuatan Gambar/Video	Total Latency	Biaya per Gambar	Specialized Media APIs (misal: Nano Banana 2, Seedance)

Aplikasi Interaktif (Latency-First)

Untuk UI percakapan, bot dukungan pelanggan, dan asisten pencarian langsung, retensi pengguna akan turun jika sistem terasa tidak responsif. Pengembang harus memprioritaskan minimalisasi TTFT. Meskipun total pembuatan memakan waktu beberapa detik, TTFT di bawah 300 milidetik akan membuat pengguna tetap terlibat.

Pemrosesan Batch dan Pipeline (Throughput-First)

Untuk tugas offline seperti memproses ribuan faktur PDF, membuat laporan harian, atau menjalankan evaluasi batch, TTFT tidak relevan. Tujuannya adalah memaksimalkan volume total token yang diproses per menit dengan biaya serendah mungkin. Pengembang harus fokus pada throughput sistem dan efisiensi biaya. Untuk analisis mendalam tentang optimasi biaya selama pemrosesan batch, lihat TokenLab AI Model Routing Benchmark Cost Per Task.

---

Mengukur Performa API: Contoh Kode Praktis

Untuk mengukur TTFT, ITL, dan TPS secara akurat, pengembang harus menggunakan API streaming dan mencatat stempel waktu pada titik-titik tertentu dalam siklus hidup permintaan. Berikut adalah skrip Python yang dapat dijalankan menggunakan klien yang kompatibel dengan OpenAI untuk mengukur metrik ini untuk model tertentu.

import time
import os
from openai import OpenAI

# Initialize client (configured for OpenRouter or any compatible provider)
client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)

def measure_api_performance(model_name: str, prompt: str):
    print(f"Evaluating speed metrics for: {model_name}")
    
    start_time = time.time()
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": prompt}],
        stream=True
    )
    
    ttft = None
    token_timestamps = []
    total_tokens = 0
    
    for chunk in response:
        chunk_time = time.time()
        # Check if text content is present in the chunk
        if chunk.choices and chunk.choices[0].delta.content:
            content = chunk.choices[0].delta.content
            # Estimate token count (1 token ≈ 4 characters for rough measurement)
            estimated_tokens = max(1, len(content) // 4)
            total_tokens += estimated_tokens
            
            if ttft is None:
                ttft = chunk_time - start_time
                print(f"-> Time to First Token (TTFT): {ttft:.3f} seconds")
            
            token_timestamps.append(chunk_time)
            
    end_time = time.time()
    total_duration = end_time - start_time
    generation_time = total_duration - ttft if ttft else total_duration
    
    # Calculate Inter-Token Latency (ITL) and Tokens Per Second (TPS)
    if len(token_timestamps) > 1:
        intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
        avg_itl = sum(intervals) / len(intervals)
        tps = total_tokens / generation_time if generation_time > 0 else 0
    else:
        avg_itl = 0
        tps = 0
        
    print(f"-> Total Latency: {total_duration:.3f} seconds")
    print(f"-> Average Inter-Token Latency (ITL): {avg_itl:.3f} seconds")
    print(f"-> Estimated Throughput (TPS): {tps:.2f} tokens/sec")
    print("-" * 50)

# Example usage with a fast, low-cost model
if __name__ == "__main__":
    test_prompt = "Write a 200-word essay on the history of computing."
    # Using a current low-cost routing model example
    measure_api_performance("google/gemini-3.5-flash", test_prompt)

---

Strategi Optimasi untuk Pembeli API

Jika pengukuran Anda menunjukkan bahwa API yang Anda pilih terlalu lambat atau terlalu mahal, beberapa strategi optimasi dapat meningkatkan performa.

1. Optimasi Prompt dan Pengurangan Prefill

Karena fase prefill berskala dengan ukuran prompt input, mengurangi panjang prompt akan langsung menurunkan TTFT.

• Hapus instruksi yang berlebihan.
• Gunakan caching prompt sistem jika didukung oleh penyedia. Ini memungkinkan host API untuk menyimpan status terkompilasi dari prompt sistem yang panjang, sehingga melewati komputasi prefill pada permintaan berikutnya.

2. Dynamic Provider Routing

Menurut dokumentasi pemilihan penyedia OpenRouter, performa model dapat bervariasi secara signifikan tergantung pada host (penyedia) dasar mana yang melayani permintaan tersebut. Beberapa penyedia mengoptimalkan untuk latency rendah, sementara yang lain menawarkan biaya lebih rendah dengan mengorbankan kecepatan.

Dengan menggunakan lapisan routing, pengembang dapat:

• Melakukan kueri ke beberapa penyedia untuk menemukan latency terendah saat ini.
• Mengatur jalur fallback sehingga jika penyedia utama mengalami lonjakan latency, permintaan secara otomatis dialihkan ke alternatif yang lebih cepat.
• Memfilter penyedia berdasarkan ambang batas performa tertentu.

3. Model Tiering

Jangan gunakan model unggulan seperti Claude Fable 5 atau GPT-5.5 untuk tugas yang dapat ditangani oleh model yang lebih kecil. Terapkan router yang mengirimkan kueri sederhana (misal: klasifikasi, pemformatan) ke DeepSeek V4 Flash atau GLM-5.2, dan cadangkan model mahal hanya untuk langkah penalaran yang kompleks.

---

Keterbatasan Tolok Ukur Kecepatan

Saat mengevaluasi metrik kecepatan, pengembang harus mengingat keterbatasan berikut:

• Varians Jaringan: Latency API sangat bergantung pada jarak fisik antara server aplikasi Anda dan wilayah hosting penyedia API. Selalu jalankan tolok ukur dari server yang berlokasi di wilayah yang sama dengan deployment produksi Anda.
• Kemacetan Penyedia: Throughput dan latency berfluktuasi sepanjang hari berdasarkan pola lalu lintas global. Satu kali menjalankan tolok ukur tidak mewakili performa produksi yang konsisten.
• Diskrepansi Estimasi Token: Model yang berbeda menggunakan tokenizer yang berbeda. Model dengan TPS yang lebih tinggi mungkin tidak benar-benar lebih cepat jika tokenizernya memecah kata menjadi token yang lebih kecil dan lebih banyak daripada model pesaing.

---

Pertanyaan yang Sering Diajukan

Apakah throughput (TPS) yang lebih tinggi selalu berarti pengalaman pengguna yang lebih cepat?

Tidak. Jika API memiliki throughput tinggi tetapi TTFT buruk, pengguna akan mengalami jeda panjang yang tidak responsif sebelum teks tiba-tiba muncul di layar. Untuk aplikasi interaktif, TTFT yang rendah lebih krusial daripada TPS yang tinggi.

Bagaimana prompt caching memengaruhi latency?

Prompt caching secara signifikan mengurangi TTFT untuk prompt yang panjang. Dengan menyimpan token yang telah diproses dari instruksi sistem atau dokumen konteks, penyedia melewati fase prefill yang berat komputasi pada permintaan berikutnya, yang menghasilkan waktu respons yang lebih cepat.

Haruskah saya memilih model open-weight atau closed-source untuk kecepatan terbaik?

Itu tergantung pada infrastruktur hosting. Model open-weight seperti Qwen3.7 Plus, GLM-5.2, atau DeepSeek V4 Pro dapat di-deploy pada perangkat keras pribadi yang didedikasikan, memungkinkan Anda untuk menjamin throughput. Namun, API closed-source terkelola sering kali menggunakan infrastruktur besar yang dioptimalkan yang mungkin sulit direplikasi secara hemat biaya pada instance pribadi. Anda dapat membandingkan peringkat performa saat ini di TokenLab Model Rankings.

---

Langkah Selanjutnya

Untuk mengoptimalkan kecepatan dan efisiensi biaya aplikasi Anda, mulailah dengan mengukur beban kerja produksi Anda saat ini menggunakan metrik streaming yang diuraikan di atas.

Siap untuk mengevaluasi dan membandingkan model terbaru untuk pipeline produksi Anda? Mulai dengan peringkat model komprehensif TokenLab untuk menemukan keseimbangan optimal antara latency, throughput, dan biaya untuk aplikasi Anda.