Kenapa Bahasa Non-Inggris Lebih Mahal: Rahasia di Balik Tokenizer

Satu kata, dua jumlah token

Bayangkan kalimat yang sama ditulis dua kali, dalam dua bahasa. Versi Inggrisnya mungkin memakai lima token. Versi terjemahannya bisa memakai lima belas. Kalimatnya bermakna sama, tapi model tidak membaca kalimat. Ia menghitung potongan-potongan yang disebut token.

Tokenizer adalah komponen yang mengubah teks menjadi potongan itu. Ia tidak membaca makna, tidak tahu mana kata yang umum dan mana yang jarang. Ia hanya punya kamus potongan, dan setiap potongan punya satu nomor id.

Karena itu, biaya API tidak dihitung dari karakter atau dari kata. API menghitung dari token. Dan jumlah token untuk kalimat yang sama bisa berbeda jauh antar bahasa.

Kenapa tokenizer dibuat begitu

Sebagian besar tokenizer modern dibangun dengan cara yang sama: algoritma BPE, atau Byte Pair Encoding, dilatih pada korpus besar. Prosesnya berulang: ambil potongan yang paling sering muncul, jadikan satu unit baru, ulangi sampai ukuran kamus tercapai.

Hasil akhirnya menyerupai kamus potongan yang sangat spesifik. Kata "the" jadi satu token. "nonetheless" jadi dua. Kombinasi yang jarang muncul di korpus latihan dipotong jadi beberapa potongan yang masing-masing sudah dikenal.

Korpus latihan menentukan hasilnya. Kalau korpus itu didominasi bahasa Inggris, tokenizer akan sangat efisien untuk bahasa Inggris dan cukup efisien untuk bahasa lain. Persis inilah masalahnya.

Hitungan yang bisa dicoba sendiri

Cara paling jelas memahami ini adalah menghitung langsung. Ambil satu paragraf dalam bahasa Inggris, hitung jumlah tokennya, lalu terjemahkan ke bahasa Indonesia tanpa mengubah panjangnya, lalu hitung lagi.

Polanya konsisten: semakin tidak umum pola kata dalam korpus latihan, semakin banyak potongan yang dipakai. Untuk bahasa yang komposisinya berbeda dari Inggris, ini bukan kasus yang sedikit.

Angka yang perlu dibaca statusnya

Banyak klaim tentang efisiensi tokenizer datang dari pengujian vendor sendiri. Metrik yang dipakai sering "rasio kompresi", yaitu karakter per token. Angka itu memang berguna, tapi hanya untuk satu bahasa dan satu domain.

Yang perlu ditanyakan adalah apakah pengujiannya mencakup bahasa non-Inggris, dan apakah pengukuran dilakukan pada teks yang sama atau teks yang sudah diterjemahkan. Menguji terjemahan menghasilkan angka yang berbeda dari menguji teks asli, karena panjang kalimat berbeda.

Analisis: di mana biaya nyata muncul

Biaya tokenizer terasa di tiga tempat, dan ketiganya bisa dihitung sendiri.

Pertama, biaya API. Kalau satu permintaan dalam bahasa Indonesia memakai 1,6 kali jumlah token bahasa Inggris untuk tugas yang sama, maka biaya per permintaan juga naik sesuai. Ini bukan overhead; ini tarif yang berlaku.

Kedua, panjang konteks. Model punya batas konteks yang dihitung dalam token. Kalau dokumentasi teknis Anda dalam bahasa Indonesia memakai 1,6 kali token, maka konteks yang bisa muat hanya sekitar 62 persen dari versi Inggrisnya. Membaca dua kali lebih banyak token berarti lebih sedikit yang terbaca sekaligus.

**Ketiga, cache prompt.**Banyak API menyimpan cache untuk prefix yang berulang. Kalau prefix itu dalam bahasa yang boros token, bagian cache yang bisa dipakai mengecil dan biaya efektif naik.

Yang bisa dilakukan

Pertama, hitung dulu sebelum mengklaim. Sebagian besar masalah biaya bahasa bisa diselesaikan dengan menghitung token per bahasa pada teks yang benar-benar dipakai. Tanpa angka, tidak ada yang bisa diklaim.

Kedua, kompres prompt, bukan bahasa. Menghapus kata yang tidak perlu membantu di semua bahasa, karena pola ini memotong potongan yang sama berulang kali.

Ketiga, perhatikan format. Angka, ID, dan kode sering lebih boros daripada kata biasa. Kalau request Anda banyak berisi angka panjang, periksa dulu formatnya sebelum menyalahkan tokenisasi bahasa.

Teks terkompresi adalah kasus terburuk yang sering terlewat. Data base64 atau arsip zip hampir tidak punya pola berulang, jadi tokenizer tidak menemukan apa pun untuk digabung. Satu blok 1.000 karakter base64 bisa memakan sekitar 700 token, sedangkan paragraf bahasa Inggris sepanjang karakter yang sama hanya sekitar 220. Kalau payload bisa dikirim sebagai teks, kirim sebagai teks; jangan mengubahnya menjadi base64 tanpa alasan.

Ada dua detail kecil yang jarang noticed tapi dampaknya besar. Pertama, angka bertanda hubung dan tanggal berulang, karena setiap digit sering menjadi token sendiri. Kedua, JSON dengan banyak spasi, karena setiap spasi bisa menjadi token tersendiri. Menghapus spasi yang tidak perlu dan memakai format tanggal yang konsisten biasanya lebih murah daripada mengganti model.

Analisis tambahan: kenapa bahasa yang mirip inglés lebih murah

Kata "bahasa" di sini perlu dibedakan dari "negara". Bahasa Indonesia memakai kata ulang (reduplikasi) seperti "anak-anak" atau "buku-buku". Reduplikasi itu pola yang sangat jarang di corpus bahasa Inggris, sehingga tokenizer harus memotongnya jadi beberapa potongan, bukan satu.

Ini bukan kasus yang langka. Bahasa Melayu, Jawa, dan sebagian besar bahasa Austronesian memiliki pola pengulangan yang sama. Bahasa Inggris punya bentuk jamak sederhana dengan added "s", dan bentuk "tidak" yang hanya satu kata. Dua bahasa itu menghasilkan potongan yang sangat berbeda untuk konsep yang sama.

Tabel tambahan ini menunjukkan efek pola itu pada jumlah token per kata:

Pola ini bukan satu-satunya sumber selisih, tapi paling mudah ditunjukkan tanpa menghitung apa pun. Bandingkan dua kalimat. Kalimat Inggris "the child is playing with the other children" memakai beberapa token karena "the" dan "-ing" sudah jadi satu unit. Kalimat Indonesia "anak itu sedang bermain dengan anak-anak yang lain" memakai potongan lebih banyak, karena reduplikasi "-anak" tidak ada bentuk tunggalnya di kamus potongan.

Efectnya berlipat pada teks panjang. Kalimat pendek yang boros satu atau dua token tidak terasa. Paragraf lima kalimat sudah boros puluhan token, dan dokumen sepanjang beberapa ribu kata kehilangan ruang konteks yang seharusnya dipakai untuk instruksi.

Ini juga alasan bahasa dengan sistem imbuhan lebih kaya dari bahasa lain akan selalu punya disadvantage struktural pada tokenizer Inggris. Bukan karena bahasanya lebih buruk, tapi karena kamus potongan dilatih pada bahasa yang tidak punya pola itu. Perbaikan hanya datang dari tokenizer yang dilatih ulang pada korpus multibahasa, dan sebagian besar model belum melakukannya.

Akibatnya, jumlah bentuk unik kata dalam bahasa Indonesia lebih besar daripada bahasa Inggris padapadanan konsep yang sama. Tokenizer bekerja lebih lama, dan hasilnya lebih banyak potongan.

Riwayat singkat: dari kata ke potongan

Awalnya tokenizer itu sederhana: satu kata jadi satu token, dengan kamus beberapa puluh ribu kata. Masalahnya langsung terlihat. Kata yang tidak ada di kamus dipecah per huruf, dan satu kata panjang bisa memakan sepuluh token atau lebih.

BPE datang sebagai jawaban. Alih-alih menyimpan kata utuh, BPE menyimpan potongan. "Baik" dan "mau" bisa berbagi bagian "-an". Kata yang tidak dikenal tidak lagi pecah per huruf, tapi menjadi beberapa potongan yang masih dikenal. Praktisnya, ini menurunkan jumlah token pada teks yang tidak terduga.

Setelah BPE, arah berikutnya adalah membuat tokenizer dengan algoritma lain khusus untuk bahasa non-Inggris. Ini masih tahap awal. Sebagian besar model besar masih memakai tokenizer yang dilatih pada korpus yang didominasi bahasa Inggris, dan perbedaan efisiensi antar bahasa belum hilang.

Yang tersisa bukan hanya solusi teknis, tapi keputusan bisnis. Melatih ulang tokenizer berarti melatih ulang model atau setidaknya menyesuaikan seluruh embedding-nya. Biayanya besar, dan manfaat langsung baru terlihat kalau memang ada pengguna non-Inggris yang cukup banyak.

Tambahan: hitungan nyata per bahasa

Angka dalam tabel di atas bisa diuji ulang tanpa perkiraan. Ambil 200 kata bahasa Inggris, hitung token-nya, lalu terjemahkan dan hitung lagi. Hasilnya biasanya menunjukkan selisih sekitar 1,4 sampai 1,8 kali untuk teks naratif.

Catatan status: belum terverifikasi. Angka karakter per token dan rasio 1,4 sampai 1,8 di artikel ini adalah estimasi, bukan hasil pengukuran pada tokenizer tertentu. Nilainya berubah tergantung tokenizer model, domain teks, dan cara terjemahan dibuat. Cara yang paling benar adalah mengukur sendiri pada teks yang benar-benar Anda kirim, karena sebagian API mengembalikan jumlah token pada setiap respons.

Ada satu pengecualian yang sering luput: teks yang banyak memuat nama diri, singkatan, dan istilah teknis yang tidak diterjemahkan. Kombinasi itu justru memotong lebih sedikit di kedua bahasa, karena nama diri sering sudah ada sebagai satu token di kamus. Jadi selisih bahasa tidak selalu sebesar yang dibayangkan.

Tiga hal yang menaikkan rasio, urut dari yang paling sering:

Rasio ini bisa dipakai untuk memperkirakan tagihan sebelum request dikirim, dan itu lebih berguna daripada reactive. Ambil rata-rata token per permintaan dari sepuluh request terakhir, kalikan dengan rasio bahasa Anda, lalu kalikan dengan tarif per token. Kalau hasilnya jauh dari anggaran, ada tiga tempat untuk memperbaiki: pendekkan prompt, pindahkan teks tetap ke depan, atau ganti format datanya. Ketiganya bisa dilakukan tanpa ganti model.

Perlu digarisbawahi bahwa angka ini bukan hukum bahasa. Ia berlaku untuk tokenizer yang dilatih pada korbus yang didominasi bahasa Inggris, dan tidak berlaku pada tokenizer yang sengaja dibuat untuk bahasa tertentu. Sebelum memakai perhitungan ini sebagai dasar keputusan, periksa dulu tokenizer model yang Anda pakai. Sebagian API memberi angka token sendiri pada setiap response, jadi angka itu adalah sumber yang paling dapat diandalkan — bukan perkiraan tabel di artikel mana pun.

Dua baris pertama menjelaskan sebagian besar selisihnya. Dua baris terakhir menjelaskan mengapa ada dokumen yang terasa hampir sama mahalnya di kedua bahasa.

Contoh nyata: satu dokumen, dua biaya

Bayangkan sebuah dokumentasi teknis sepanjang 5.000 karakter. Versi Inggris dan versi terjemahannya memuat informasi yang persis sama.

Pola di tabel ini penting: selisihnya tidak seragam. Bahasa yang paling banyak kataastranya tidak selalu yang paling boros. Yang paling boros adalah teks naratif, karena di situlah pola kata berulang yang hilang. Teks angka dan kode hampir sama mahalnya di dua bahasa, karena memang tidak banyak pola bahasa yang bisa dipakai.

Kalau dokumen 5.000 karakter itu harus masuk ke konteks 8.000 token bersama riwayat percakapan, versi Inggris masih muat. Versi Indonesia, dengan 1.700 token, Ruang yang tersisa jauh lebih sedikit. Pada sistem dengan instruksi panjang, ruang itulah yang menentukan apakah instruksi masih terbaca utuh atau sudah terpotong.

Sistem C illustrate kasus yang paling sering ditemukan. Instruksinya sudah panjang, dokumen tambahannya lebih besar, dan bersama-sama sudah melewati batas. Yang perlu dikorbankan biasanya dokumen, bukan instruksi, karena dokumen lebih mudah dipotong tanpa merusak jawaban.

Tiga langkah sebelum mengganti model

Sebelum mengganti model, ada tiga langkah yang lebih murah.

Pertama, hitung token per bahasa dengan teks sendiri. Ambil sepuluh paragraf dari pekerjaan yang benar-benar Anda kirim, hitung token-nya dalam bahasa Inggris dan setelah diterjemahkan. Angka itu lebih berguna daripada benchmark tokenizer mana pun.

Kedua, pindahkan teks tetap ke depan prompt. Kalau instruksi atau contoh yang selalu sama diletakkan di awal, provider yang mendukung prompt cache bisa memakainya ulang. Perubahan ini tidak bergantung pada bahasa dan sering lebih besar daripada hasil kompresi prompt.

Ketiga, format angka dan kode. Gunakan format tanggal yang konsisten, hindari rangkaian angka panjang, dan jangan mengubah data menjadi base64 kecuali memang perlu. Semua ini mengurangi jumlah potongan tanpa mengurangi informasi.

Baris terakhir penting. Ganti tokenizer berarti ganti model, dan itu keputusan yang jauh lebih besar daripada yang biasanya dibayangkan orang yang baru belajar soal token.