Token, Context Window, dan Parameter LLM
Cara kerja tokenisasi, batas context window, dan parameter API (temperature, top_p, max_tokens) yang mengontrol perilaku dan biaya output.
Tiga konsep di bab ini, token, context window, dan parameter API, adalah yang paling langsung mempengaruhi keputusan desain dan biaya sistem AI yang kamu bangun. Hampir setiap keputusan teknis yang kamu buat, dari cara menyusun prompt hingga cara memilih model, berkaitan dengan ketiga konsep ini.
8.1 Apa itu Token
LLM tidak membaca teks seperti manusia membaca, tidak per kata, tidak per karakter. LLM membaca dalam satuan yang disebut token: potongan teks yang ukurannya bervariasi tergantung pada model dan bahasa yang digunakan.
Sebuah token bisa berupa satu kata utuh, bagian dari kata, tanda baca, atau bahkan spasi. Proses memotong teks menjadi token disebut tokenisasi, dan setiap model memiliki tokenizer-nya sendiri yang menentukan cara pemotongan dilakukan.
Perhatikan bagaimana teks yang sama dipotong menjadi unit-unit token yang berbeda tergantung pada isinya.
8.2 Context Window
Context window adalah jumlah maksimum token yang bisa "dilihat" oleh model dalam satu request, termasuk seluruh riwayat percakapan, System Prompt, dokumen yang disisipkan, dan output yang dihasilkan sejauh ini.
Ini bukan sekadar batasan teknis. Context window adalah fondasi dari cara LLM memproses informasi: model hanya bisa "mengingat" apa yang ada di dalam context window-nya. Teks di luar batas ini tidak diproses, seolah tidak pernah ada.
Model memotong pesan lama dari riwayat percakapan, bukan error, tapi model "lupa" percakapan awal.
Perbandingan context window model-model yang umum digunakan.
| Model | Context Window | Setara dengan | Relevansi |
|---|---|---|---|
| Gemini 1.5 Pro Google | 1.000.000 token | ~750.000 kata - sekitar 10 novel tebal | Context window terbesar yang tersedia secara umum. Biaya per token lebih tinggi. |
| GPT-4o OpenAI | 128.000 token | ~96.000 kata - sekitar 1 novel | Standar de facto untuk banyak use case produksi saat ini. |
| Claude 3.5 Sonnet Anthropic | 200.000 token | ~150.000 kata - sekitar 2 novel | Cocok untuk analisis dokumen panjang atau percakapan yang sangat panjang. |
| Gemini 1.5 Flash Google | 1.000.000 token | ~750.000 kata | Context window besar dengan biaya lebih rendah dari Pro. Cocok untuk development dan testing. |
8.3 Parameter API yang Wajib Dikuasai
Setiap request ke LLM API bisa dikonfigurasi dengan beberapa parameter yang mengontrol perilaku output. Tiga parameter yang paling penting dan paling sering digunakan adalah Temperature, Top-p, dan Max Tokens.
Temperature (rentang 0.0 sampai 2.0)
Mengontrol distribusi probabilitas token output. Secara teknis, temperature membagi logit (nilai mentah sebelum softmax) sebelum probabilitas dihitung. Nilai rendah membuat distribusi lebih "tajam", token dengan probabilitas tertinggi mendominasi. Nilai tinggi membuat distribusi lebih "datar", token yang kurang probable punya kesempatan lebih besar untuk dipilih.
| Nilai | Efek pada Output | Cocok untuk |
|---|---|---|
0.0 | Sepenuhnya deterministik, input sama selalu menghasilkan output identik | Testing dan debugging |
0.0 - 0.2 | Sangat konsisten, selalu memilih token probabilitas tertinggi | RAG, ekstraksi data terstruktur, akurasi faktual |
0.3 - 0.5 | Sedikit variasi, masih cukup konsisten | Customer service chatbot, use case umum |
0.6 - 0.9 | Variasi cukup tinggi, terasa natural dan tidak repetitif | Chatbot percakapan umum, pembuatan konten |
1.0 - 2.0 | Sangat variatif hingga hampir acak, bisa tidak koheren | Brainstorming, generasi ide (jarang dipakai produksi) |
response = client.generate(
"Pertanyaan pengguna",
temperature=0.1 # untuk RAG dan ekstraksi data
)
top_p (rentang 0.0 sampai 1.0)
Nucleus sampling. Alih-alih mempertimbangkan semua token yang mungkin, model hanya mempertimbangkan token-token yang total probabilitasnya mencapai nilai top_p. Nilai 0.9 berarti model hanya mempertimbangkan token-token yang secara kolektif mencakup 90% probabilitas, token yang sangat tidak mungkin dikeluarkan dari pertimbangan.
Umumnya gunakan salah satu antara temperature atau top_p untuk mengontrol variasi output, tidak keduanya sekaligus. top_p = 0.1 sangat konservatif, hanya 10% token teratas dipertimbangkan. top_p = 0.9 adalah nilai default yang umum digunakan. top_p = 1.0 berarti semua token dipertimbangkan, variasi sepenuhnya dikontrol oleh temperature.
max_tokens (rentang 1 sampai batas model)
Batas maksimum jumlah token yang bisa dihasilkan model dalam satu response. Model berhenti menghasilkan output ketika mencapai batas ini, meskipun kalimat atau pemikiran belum selesai. Ini adalah parameter penting untuk mengontrol biaya dan mencegah response yang terlalu panjang.
| Nilai | Cocok untuk |
|---|---|
| ~100 token | Jawaban satu kalimat atau klasifikasi singkat |
| ~256 token | Jawaban pendek dan ringkas, sekitar 1-2 paragraf |
| ~1.024 token | Jawaban percakapan umum, ringkasan pendek, ekstraksi informasi |
| ~2.048 token | Penjelasan mendetail, analisis singkat, output JSON kompleks |
| ~3.000 token | Dokumen panjang, artikel, atau kode kompleks |
| ~4.096+ token | Output sangat panjang, pertimbangkan biayanya |
8.4 Menghitung Estimasi Token dan Biaya
Sebelum sistem AI kamu masuk ke produksi, kamu perlu bisa memperkirakan berapa token yang akan digunakan per request dan berapa biaya yang akan ditanggung. Ini bukan langkah opsional, ini adalah bagian dari tanggung jawab desain sistem.
# Instalasi: pip install tiktoken
import tiktoken
def hitung_token(teks: str, model: str = "gpt-4o") -> int:
"""Hitung jumlah token untuk teks tertentu."""
encoding = tiktoken.encoding_for_model(model)
return len(encoding.encode(teks))
# Untuk model Gemini, gunakan pendekatan estimasi:
# ~4 karakter per token untuk bahasa Inggris
# ~2-3 karakter per token untuk Bahasa Indonesia
def estimasi_token_indonesia(teks: str) -> int:
"""Estimasi kasar untuk Bahasa Indonesia."""
return len(teks) // 2 # konservatif: 2 karakter/token
# Kalkulator biaya per request
HARGA_PER_1K_TOKEN = {
"gemini-1.5-flash": {"input": 0.000075, "output": 0.0003},
"gemini-1.5-pro": {"input": 0.00125, "output": 0.005},
"gpt-4o": {"input": 0.005, "output": 0.015},
"gpt-4o-mini": {"input": 0.00015, "output": 0.0006},
}
def estimasi_biaya(
token_input: int,
token_output: int,
model: str,
request_per_hari: int = 1000
) -> dict:
"""
Estimasi biaya per request dan per bulan.
Harga dalam USD berdasarkan tarif per 1.000 token.
"""
harga = HARGA_PER_1K_TOKEN.get(model, {"input": 0, "output": 0})
biaya_per_req = (
(token_input / 1000) * harga["input"] +
(token_output / 1000) * harga["output"]
)
biaya_per_hari = biaya_per_req * request_per_hari
biaya_per_bulan = biaya_per_hari * 30
return {
"biaya_per_request_usd": round(biaya_per_req, 6),
"biaya_per_hari_usd": round(biaya_per_hari, 4),
"biaya_per_bulan_usd": round(biaya_per_bulan, 2),
}
# Contoh penggunaan
system_prompt = "Kamu adalah asisten customer service..." # ~50 token
dokumen_rag = "[Konten dokumen yang diambil]" # ~500 token
pertanyaan = "Apa kebijakan pengembalian barang?" # ~10 token
jawaban_est = "[Estimasi jawaban]" # ~200 token
total_input = 50 + 500 + 10 # = 560 token
total_output = 200
hasil = estimasi_biaya(
token_input=total_input,
token_output=total_output,
model="gemini-1.5-flash",
request_per_hari=1000
)
print(hasil)
# {'biaya_per_request_usd': 0.0000017,
# 'biaya_per_hari_usd': 0.0017,
# 'biaya_per_bulan_usd': 0.05}
Kesalahan Umum
Temperature tinggi membuat model lebih cenderung memilih token yang kurang probable, termasuk token yang tidak akurat atau tidak berdasar. Untuk sistem yang membutuhkan kepatuhan pada fakta dan konsistensi format, gunakan temperature di rentang 0.0 sampai 0.2.
Kedua parameter ini mempengaruhi distribusi output melalui mekanisme yang berbeda. Mengubah keduanya sekaligus membuat perilaku model sulit diprediksi. Pilih salah satu: ubah temperature dan biarkan top_p di 1.0, atau sebaliknya.
Biaya dihitung berdasarkan jumlah token yang dikirim dan diterima, bukan berdasarkan seberapa besar context window model. Mengirim dokumen 100.000 token ke Gemini 1.5 Pro setiap request akan menghasilkan biaya yang sangat besar seiring waktu. Gunakan RAG untuk mengambil hanya bagian dokumen yang relevan.
Teks dalam Bahasa Indonesia dengan panjang yang sama bisa membutuhkan hingga 2 kali lebih banyak token. Estimasi biaya yang dibuat berdasarkan asumsi bahasa Inggris akan terlalu rendah untuk sistem berbahasa Indonesia. Selalu hitung estimasi token menggunakan teks aktual dalam bahasa yang akan digunakan.
Meskipun temperature 0.0 membuat model memilih token dengan probabilitas tertinggi secara deterministik, beberapa penyedia API memiliki implementasi yang masih menghasilkan sedikit variasi karena faktor infrastruktur seperti floating-point rounding di GPU yang berbeda.
Gunakan fungsi estimasi biaya dari bagian 8.4 untuk memodelkan skenario penggunaan yang realistis. Pasang budget limit di dashboard penyedia API sebagai jaring pengaman. Kejutan tagihan API hampir selalu bisa dicegah dengan kalkulasi awal yang sederhana.
Ringkasan Bab 8
- Saya memahami apa itu token dan mengapa LLM tidak membaca teks per kata atau per karakter, melainkan dalam satuan token yang ukurannya bervariasi.
- Saya memahami mengapa Bahasa Indonesia membutuhkan lebih banyak token dari Bahasa Inggris untuk teks yang setara, dan implikasinya terhadap biaya API.
- Saya bisa menjelaskan apa itu context window, apa saja yang memakan ruang di dalamnya, dan apa yang terjadi ketika context window penuh.
- Saya memahami cara kerja parameter temperature secara teknis, bukan hanya sebagai "kreativitas" tapi sebagai kontrol distribusi probabilitas token.
- Saya tahu kapan menggunakan temperature rendah (RAG, ekstraksi data) vs temperature tinggi (generasi kreatif), dan mengapa tidak menggunakan temperature dan top_p secara bersamaan.
- Saya memahami fungsi parameter max_tokens dan cara memilih nilainya berdasarkan kebutuhan output sistem.
- Saya bisa menghitung estimasi jumlah token per request dan memperkirakan biaya bulanan berdasarkan volume penggunaan yang direncanakan.
- Saya sudah memasang atau berencana memasang budget limit di dashboard penyedia API sebelum sistem saya masuk ke produksi.