Penghitungan Token dalam LLM: Mengapa Setiap Developer Perlu Memahaminya

Ketika developer pertama kali mulai bekerja dengan API large language model, satu pertanyaan hampir selalu muncul segera: "Seberapa panjang yang terlalu panjang?" Mereka berpikir dalam kata, paragraf, atau karakter — tetapi model berpikir dalam token. Memahami apa itu token, bagaimana dihitung, dan mengapa hitungan itu penting adalah salah satu hal yang paling berguna secara praktis yang bisa Anda pelajari sebelum membangun sesuatu yang serius di atas LLM.

Anda dapat menggunakan BrowseryTools Token Counter — gratis, tanpa pendaftaran, semuanya tetap di browser Anda — untuk menghitung token untuk teks apa pun sebelum Anda mengirimnya ke API.

Apa Itu Token? (Bukan Kata, Bukan Karakter)

Token adalah unit dasar teks yang diproses oleh language model. Ini bukan kata. Ini bukan karakter. Ini adalah potongan teks yang tokenizer model telah belajar untuk diperlakukan sebagai satu unit — dan potongan itu bisa berupa satu karakter hingga fragmen kata multi-karakter atau seluruh kata yang umum.

Berikut beberapa contoh cara kalimat mungkin dipecah menjadi token oleh tokenizer keluarga GPT:

"Hello, world!"
→ ["Hello", ",", " world", "!"]  — 4 token

"unbelievable"
→ ["un", "believ", "able"]  — 3 token

"ChatGPT"
→ ["Chat", "G", "PT"]  — 3 token

"2026-03-22"
→ ["2026", "-", "03", "-", "22"]  — 5 token

Perhatikan bagaimana kata-kata pendek umum seperti "Hello" dipetakan ke satu token, sementara kata-kata yang lebih panjang atau tidak umum dipecah menjadi beberapa token. Tanda baca, angka, dan karakter khusus sering kali merupakan token tersendiri. Tokenizer tidak hanya memisahkan pada spasi atau tanda baca — ia menggunakan kosakata yang dipelajari dari unit sub-kata untuk mencapai keseimbangan terbaik antara ukuran kosakata dan efisiensi representasi.

Cara Kerja Tokenizer: Byte-Pair Encoding

Sebagian besar LLM modern — GPT-4, Claude, Gemini, Llama — menggunakan varian dari Byte-Pair Encoding (BPE) atau algoritma terkait erat yang disebut SentencePiece. BPE awalnya dikembangkan untuk kompresi data; diadaptasi untuk NLP karena secara elegan memecahkan masalah open-vocabulary.

Proses pelatihan BPE dimulai dengan karakter individual (atau byte) sebagai kosakata dasar. Kemudian berulang kali menemukan pasangan simbol yang paling sering muncul bersamaan dalam corpus pelatihan dan menggabungkannya menjadi simbol tunggal baru. Setelah ribuan penggabungan seperti itu, kosakata yang dihasilkan berisi kata-kata umum sebagai token tunggal, awalan dan akhiran umum sebagai token, dan kata-kata langka sebagai urutan token yang lebih kecil. Ukuran kosakata akhir biasanya 32.000 hingga 100.000 token.

Ini berarti tokenisasi teks apa pun sepenuhnya bergantung pada kosakata spesifik yang dilatih model tersebut. GPT-4, Claude, dan Gemini semuanya menggunakan tokenizer yang berbeda — teks yang sama dapat ter-tokenisasi menjadi jumlah yang berbeda di setiap model. Jangan pernah mengasumsikan jumlah token yang Anda ukur untuk satu model berlaku untuk model lain.

Aturan Praktis "750 Kata per 1.000 Token"

Anda sering akan melihat perkiraan "1.000 token ≈ 750 kata" dikutip untuk teks bahasa Inggris. Ini adalah heuristik yang masuk akal untuk prosa biasa — posting blog, artikel, dokumentasi. Ini berasal dari pengamatan bahwa dalam corpus bahasa Inggris yang seimbang, panjang token rata-rata sekitar 4–5 karakter, dan kata bahasa Inggris rata-rata sekitar 5 karakter ditambah spasi. Jadi satu kata dipetakan ke sekitar 1,3 token rata-rata.

Namun "aturan praktis" adalah framing yang tepat — ini cepat rusak dalam praktik:

• Kode ter-tokenisasi lebih padat — Bahasa pemrograman menggunakan banyak kata kunci pendek, operator, dan identifier yang sering berupa token tunggal. Blok Python mungkin ter-tokenisasi ke lebih sedikit token per karakter daripada prosa bahasa Inggris.
• URL dan string teknis mahal — URL panjang seperti https://api.example.com/v2/users/84219/preferences?include=notifications mungkin ter-tokenisasi menjadi 20+ token meskipun terlihat pendek di layar.
• Angka mengejutkan mahalnya — Setiap digit dalam angka panjang sering kali merupakan token terpisah. Angka "1738371600" bisa menjadi 5–7 token.
• Spasi putih berulang dan pemformatan — JSON dengan indentasi pretty-print, tabel Markdown, dan kode dengan sarang yang dalam semuanya menambahkan token dari spasi putih.

Bahasa Non-Inggris: Arab, Cina, dan Perbedaan Biaya Token

Heuristik 750-kata-per-1.000-token adalah heuristik bahasa Inggris. Untuk bahasa lain, rasionya bisa sangat berbeda — dan ini memiliki implikasi biaya nyata untuk aplikasi multibahasa.

Arab dan Ibrani menggunakan morfologi akar-dan-pola, di mana satu akar menghasilkan lusinan bentuk turunan melalui prefiks, akhiran, dan perubahan vokal internal. Kata-kata seperti "وسيستخدمونها" (mereka akan menggunakannya) adalah kata ortografis tunggal tetapi mungkin ter-tokenisasi menjadi 5–8 token karena kosakata BPE dilatih terutama pada data bahasa Inggris dan tidak memiliki bentuk Arab ini sebagai token tunggal.

Cina dan Jepang memiliki tantangan yang berbeda. Karakter bersifat logografis — setiap karakter adalah unit bermakna — tetapi kosakata token mencakup karakter tunggal umum dan beberapa kata multi-karakter umum. Teks Cina biasanya berjalan 1,5–2x lebih banyak token per "setara kata" daripada bahasa Inggris. Jepang, dengan campuran hiragana, katakana, dan kanji, bahkan bisa lebih tinggi.

Implikasi praktis: jika Anda membangun aplikasi untuk Arab, Cina, atau bahasa skrip non-Latin lainnya, estimasi biaya Anda yang berasal dari pengujian bahasa Inggris akan secara signifikan memperkirakan terlalu rendah biaya API aktual. Selalu ukur jumlah token dengan konten aktual Anda menggunakan BrowseryTools Token Counter atau pustaka tokenizer sebelum membuat proyeksi anggaran.

Batas Jendela Konteks: Mengapa Melampaui Batas Merusak Segalanya

Setiap LLM memiliki jendela konteks — jumlah token maksimum yang dapat diproses dalam satu permintaan, menghitung baik input maupun output model Anda. Pada awal 2026:

• GPT-4o — 128.000 token
• Claude 3.5 Sonnet — 200.000 token
• Gemini 1.5 Pro — 1.000.000 token
• Llama 3.1 70B — 128.000 token

Jika input Anda melebihi batas jendela konteks, API akan mengembalikan error — permintaan tersebut hanya gagal. Tidak ada degradasi yang anggun secara default; Anda perlu menangani ini dalam logika aplikasi Anda. Lebih halus lagi, bahkan dalam jendela konteks, ada fenomena yang disebut masalah "lost in the middle": model cenderung mengingat informasi di awal dan akhir konteks mereka lebih baik daripada informasi yang terkubur di tengah. Jendela konteks 200K tidak berarti setiap token di dalamnya diperhatikan secara setara.

Untuk aplikasi chat, jendela konteks terisi seiring percakapan berkembang. Setelah cukup banyak putaran, Anda harus memotong pesan lama, merangkumnya, atau mencapai batas dan gagal. Mengetahui jumlah token Anda di setiap langkah adalah yang memungkinkan Anda membuat keputusan tersebut secara proaktif.

Implikasi Desain Prompt

Kesadaran token mengubah cara Anda menulis prompt. Beberapa implikasi konkret:

• System prompt berlipat ganda di setiap permintaan — System prompt 500 token berharga 500 × permintaan Anda × harga input Anda. Pada 10.000 permintaan harian, memangkas system prompt dari 500 ke 300 token menghemat uang nyata setiap bulan.
• Contoh few-shot mahal tetapi efektif — Menyertakan 3 contoh dalam prompt Anda mungkin menambahkan 300–500 token. Ukur apakah peningkatan kualitas itu sepadan dengan biaya versus fine-tuning model sekali.
• Panjang output dapat dikendalikan — Gunakan max_tokens untuk membatasi output model. Tambahkan instruksi eksplisit dalam prompt Anda: "Balas dalam kurang dari 100 kata." Model umumnya mengikuti instruksi panjang output dengan baik, yang secara langsung mengurangi biaya token output.
• Pemformatan JSON menambahkan overhead — Jika Anda menggunakan output terstruktur (mode JSON), tanda kutip, kurung, dan nama kunci menambahkan token di atas nilai data aktual Anda. Respons dengan 5 kolom pendek bisa dengan mudah memiliki overhead 40% dalam token pemformatan.

Hitung Token Sebelum Anda Mengirim

Kebiasaan terbaik yang perlu dibangun saat bekerja dengan API LLM adalah menghitung token sebelum berkomitmen pada arsitektur atau masuk ke produksi. Tempel system prompt Anda, pesan pengguna representatif, dan konteks apa pun yang Anda rencanakan untuk disertakan ke dalam BrowseryTools Token Counter. Anda akan langsung melihat apakah desain Anda jauh dalam jendela konteks atau berbahaya mendekati batasnya — dan Anda akan memiliki angka yang diperlukan untuk memperkirakan biaya secara akurat.