Cara Mengatasi Nondeterminisme dalam Inferensi LLM
(thinkingmachines.ai)- Dalam inferensi LLM (large language model), muncul masalah nondeterminisme (nondeterminism) di mana hasil dapat berbeda meskipun input dan kondisinya sama
- Selama ini, konkurensi (concurrency) dan non-asosiativitas (non-associativity) dari operasi floating-point dianggap sebagai penyebab utama nondeterminisme
- Penyebab deterministik yang sebenarnya berasal dari perubahan urutan perhitungan di dalam kernel (kode komputasi) akibat perubahan ukuran batch (batch size)
- Jika semua operasi di dalam kernel diimplementasikan agar memiliki invariansi batch (batch invariance), maka reproducibility yang sepenuhnya terjamin dapat dicapai
- Dengan operasi paralel data, split reduction, strategi split berukuran tetap dan sebagainya, kernel yang invariant terhadap batch dapat dibuat untuk operasi utama seperti RMSNorm, matmul, dan attention
Pendahuluan dan ringkasan masalah
- Reproducibility, elemen inti kemajuan ilmiah, tidak terjaga dengan baik dalam inferensi LLM (large language model)
- Bahkan jika pertanyaan yang sama diajukan ke ChatGPT beberapa kali, sering kali dihasilkan jawaban yang berbeda
- Hal ini karena proses sampling hasil pada LLM merupakan pemilihan probabilistik yang didasarkan pada distribusi probabilitas
- Namun, bahkan jika temperature diatur ke 0, pada praktiknya API LLM tidak selalu deterministik (yakni, hasil untuk input yang sama tidak selalu identik)
- Masalah nondeterminisme juga tetap ada saat dijalankan dengan pustaka inferensi open source (vLLM, SGLang, dll.) maupun pada hardware sendiri
Hipotesis lama dan keterbatasannya
- Hipotesis yang dikenal luas: nondeterminisme terjadi karena konkurensi + non-asosiativitas floating-point
- Operasi floating-point di GPU sedikit berbeda hasilnya tergantung urutan operasi dan urutan thread selesai
- Namun, pada kenyataannya, bahkan jika perkalian matriks yang sama diulang pada data yang sama dengan cara yang sama, hasilnya selalu identik secara bitwise (bw=bitwise equal)
- Diperlukan analisis yang lebih mendalam untuk mengidentifikasi penyebab sebenarnya
Analisis mendalam penyebab nondeterminisme pada inferensi LLM
Hakikat non-asosiativitas floating-point
- Operasi floating-point memiliki relasi (a+b)+c ≠ a+(b+c)
- Saat menghitung nilai dengan ukuran berbeda (exponent), terjadi kehilangan presisi dan kehilangan informasi, sehingga hasil berubah tergantung urutan operasi
- Karena urutan operasi dapat berubah, jika penjumlahan dilakukan berkali-kali secara acak maka akan muncul beragam hasil (juga terkonfirmasi secara eksperimen)
Perubahan urutan operasi di kernel dan konkurensi
- Umumnya, masalah konkurensi seperti atomic add sering ditunjuk sebagai penyebab utama nondeterminisme
- Namun, sebagian besar kernel yang digunakan dalam inferensi LLM (terutama forward pass) dapat berjalan tanpa atomic add
- Melalui strategi paralel yang tepat sebelumnya, split (reduction), dan sebagainya, urutan operasi yang sama dapat dipastikan
Penyebab inti yang sesungguhnya: tidak adanya "invariansi batch (batch invariance)"
- Kernel individual selalu mengembalikan hasil yang sama jika inputnya sama (run-to-run deterministic)
- Tetapi karena permintaan serentak dari banyak pengguna (batch size) berubah secara nondeterministik, maka hasil untuk tiap permintaan pada praktiknya tidak konsisten
- Bergantung pada ukuran batch, urutan pembagian atau penggabungan operasi secara internal berubah, sehingga nondeterminisme muncul
- Dengan kata lain, penyebab kuncinya adalah beban server dan paralelisme (ukuran batch) yang bersifat nondeterministik
Desain kernel invariant terhadap batch dan contoh operasi utama
RMSNorm
- Menerapkan strategi data-parallel: tiap elemen batch diproses secara independen oleh satu core
- Saat ukuran batch besar, paralelisme yang cukup tetap terjaga, sehingga strategi paralelnya konsisten dan invariansi batch dapat dipastikan
- Saat ukuran batch sangat kecil, strategi alternatif seperti split reduction digunakan, tetapi dalam kasus ini sebagian invariansi batch dikorbankan
Perkalian matriks (matmul)
- Menggunakan strategi paralel data dengan paralelisasi per tile
- Untuk optimalisasi penggunaan tensor core, perlu dibagi ke tile 2D, dan pada batch yang sangat kecil dibutuhkan strategi khusus seperti split-K
- Saat menggunakan strategi split-K, invariansi batch dapat rusak
- Meski harus mengorbankan sebagian performa, urutan operasi yang konsisten dan dapat direproduksi dapat dipastikan dengan memaksa konfigurasi kernel yang sama
Attention
- Pada FlashAttention2 dan sejenisnya, invariansi batch dipastikan melalui strategi paralelisasi arah query dan reduction simultan Key/Value
- Jika urutan reduction berubah bergantung pada ukuran batch atau pemotongan sekuens (chunked prefill, prefix caching, dll.), invariansi akan rusak
- Pada strategi split-reduction seperti split-KV (FlashDecoding), urutan operasi tetap sama dengan menetapkan ukuran split tetap (fixed split-size)
- Secara internal, key/value cache dan token baru tidak diproses secara terpisah; layout key/value harus dijaga konsisten di semua operasi
Implementasi
- Demo inferensi deterministik yang menerapkan kernel batch-invariant disediakan menggunakan vLLM dan torch.Library
- Kernel pengganti untuk operasi terkait dapat dilihat di repo GitHub (thinking-machines-lab/batch-invariant-ops)
Eksperimen dan performa
Eksperimen pengukuran nondeterminisme
- Menggunakan model Qwen/Qwen3-235B-A22B-Instruct-2507, dilakukan 1000 kali generasi pada prompt yang sama (“Tell me about Richard Feynman”) dengan temperature 0
- Dihasilkan 80 penyelesaian yang berbeda (meskipun prompt sama, nondeterminisme tetap ada)
- Hingga 102 token pertama hasilnya sama, dan percabangan pertama terjadi pada token ke-103 (“Queens, New York” vs “New York City”)
- Saat menggunakan kernel batch-invariant, semua 1000 hasil identik, sehingga reproducibility penuh tercapai
Evaluasi performa
- Menjalankan Qwen-3-8B pada 1 GPU, dengan 1000 permintaan sekuens masing-masing sepanjang 90~110
- vLLM bawaan: 26 detik
- deterministic vLLM yang belum dioptimalkan: 55 detik
- setelah menerapkan kernel attention yang diperbaiki: 42 detik
- Optimisasinya masih kurang, tetapi tingkat performanya tetap layak digunakan secara praktis
Nilai bagi on-policy RL
- Sebelumnya, karena perbedaan numerik kecil antara training dan inference, on-policy RL tidak dapat diimplementasikan secara tepat
- Jika inferensi deterministik dimungkinkan, maka sampling dan training dapat dibuat identik secara bitwise, sehingga on-policy RL yang sesungguhnya dapat diimplementasikan
- Hasil pada metrik utama seperti KL-divergence dan reward juga dipastikan sepenuhnya identik
Kesimpulan
- Dalam sistem inferensi LLM, nondeterminisme dan galat numerik mudah diabaikan, tetapi jika akar masalahnya (ketiadaan invariansi batch) dipahami dan diperbaiki, maka reproducibility dan determinisme yang sepenuhnya dapat diperoleh
- Penelitian ini menjelaskan cara mengatasi masalah nondeterminisme pada inferensi LLM dan membantu pengembang mendapatkan reproducibility penuh dalam sistem mereka sendiri
Informasi sitasi
- Saat mengutip penelitian ini, gunakan informasi berikut
He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference",
Thinking Machines Lab: Connectionism, Sep 2025.
atau
@article{he2025nondeterminism,
author = {Horace He and Thinking Machines Lab},
title = {Defeating Nondeterminism in LLM Inference},
journal = {Thinking Machines Lab: Connectionism},
year = {2025},
note = {https://thinkingmachines.ai/blog/…},
doi = {10.64434/tml.20250910}
}
1 komentar
Opini Hacker News
Bahkan jika nondeterminisme yang "teoretis" diselesaikan sepenuhnya pada pasangan input-output individual yang sepenuhnya tertutup, tetap ada dua masalah nondeterminisme yang nyata: input yang sama menghasilkan hasil berbeda tergantung konteks sebelumnya, dan input yang sedikit dimodifikasi gagal menghasilkan hasil yang termodifikasi dengan benar. Selama masalah ini belum terselesaikan, nondeterminisme dalam sistem tertutup tidak terlalu membantu kecuali dalam situasi di mana tabel lookup saja sudah cukup. Sulit membuktikan apa pun dengan unit test atau set evaluasi yang "akurat" untuk input yang belum diuji
Situasi "input yang persis sama tetapi hasilnya berubah karena konteks sebelumnya berbeda" sebenarnya tidak ada. Konteks sebelumnya itu sendiri adalah input. Jika sebuah prompt input selalu menghasilkan hasil yang sama, itu berarti konteksnya diabaikan. Artinya sama saja seperti selalu memulai dari konteks kosong terlepas dari state dalam sesi. Yang diinginkan sebagian orang adalah,
Mengapa fakta bahwa 'konteks sebelumnya' menghasilkan hasil berbeda dianggap masalah? Jika konteks tidak memengaruhi hasil, konteks itu bisa dibuang saja. Mengapa justru menginginkan perilaku seperti itu? Sebagai alat, kita justru berharap ia merespons berbeda sesuai niat atau pergantian mode kita (misalnya perubahan perilaku di vim setelah masuk ke insert mode). Kita juga berharap kecerdasan bekerja seperti itu. Mengabaikan konteks malah terasa lebih dekat dengan confirmation bias yang ekstrem
Sangat berguna saat mereproduksi bug
Saya setuju sampai pada bagian yang mengatakan "tidak terlalu membantu". Mungkin maksudnya adalah "tidak sepenuhnya menyelesaikan masalah"
Saya penasaran mengapa orang begitu peduli pada determinisme dalam sistem probabilistik. Dari sudut pandang pengguna, sekalipun input "How do I X?" selalu menghasilkan jawaban deterministik yang sama, itu tidak banyak berarti jika input bermakna sama seperti "how do i x?", "how do I x", "how do I X??" justru menghasilkan keluaran yang sama sekali berbeda. Yang benar-benar dibutuhkan dari LLM adalah kemampuan menjamin bahwa input yang secara semantik sama selalu menghasilkan output yang secara semantik sama. Ini konsep yang sama sekali berbeda dari determinisme seperti yang biasa kita maksud dalam algoritme
Tidak semua aplikasi berbasis LLM hanya punya antarmuka chat tempat pengguna mengetik spontan. Dalam kasus seperti memanggil tool 10 kali berturut-turut untuk evaluasi, atau terus-menerus menguji prompt dengan tool seperti DSPy Optimizer tautan, jika saya sepenuhnya mengendalikan input sampai level token, maka mengurangi ketidakpastian itu penting. Dalam lingkungan seperti ini, jika variabilitas level token bisa dihilangkan sehingga hanya ambiguitas input itu sendiri yang tersisa, perilaku sistem bisa dipetakan jauh lebih andal ke struktur tree atau graph
Perkataan Anda tidak salah, tetapi itu juga tidak berarti tingkat determinisme seperti ini tidak berguna. Jika hasil selalu berubah bahkan saat token input-nya sama persis, akan sulit mereproduksi dan membagikan hasil dengan rekan kerja, atau menguji situasi ketika LLM menghasilkan output yang sangat jarang dan sulit diprediksi (misalnya red teaming)
Saya sedang mengerjakan proyek yang menyisipkan informasi ke output LLM dengan steganografi: innocuous. Kami hanya mengambil sekitar 10 token teratas dari model, dan karena kebanyakan diuji pada model 8B berbasis CPU, kekhawatiran bahwa urutan token berubah karena pengaruh hardware tidak terlalu besar, tetapi saya tetap berencana membuat kondisi guard eventually agar perubahan pilihan tidak terjadi karena kehilangan presisi yang sangat kecil
Ini bisa sangat berguna bagi pelanggan platform AI. Mereka bisa menjalankan prompt berkali-kali dengan temperature 0 untuk memeriksa apakah hasilnya selalu sama, sehingga dapat memverifikasi apakah penyedia AI diam-diam mengganti model PRO dengan model lain yang lebih murah
Untuk tujuan mereproduksi "bug", ini mutlak diperlukan. Jika saat memasukkan string input yang sama persis kita bisa mereproduksi output yang salah atau aneh yang sama setiap kali, debugging jadi jauh lebih mudah. Jika hasilnya berubah sekali setiap 100 kali, itu jauh lebih sulit
(Pengalaman kerja dengan JAX/XLA) Ini cukup dikenal. Saya sendiri beberapa kali menghadapi fenomena seperti ini (variabilitas per batch), dan mendapat penjelasan di issue berikut: penzai issue #82, komentar issue jax
Kadang sumber nondeterminisme adalah detail implementasi. Misalnya, dalam source code GPT-2, meskipun temperature di GUI diatur ke 0, yang sebenarnya dimasukkan adalah nilai "epsilon" (angka yang sangat kecil), bukan 0. Ini masuk akal karena untuk mencegah error division by zero. Nondeterminisme itu "tidak berguna" dalam banyak aplikasi. Ini juga masalah lama pada model topik LDA. Khususnya di bidang hukum, keuangan, dan regulasi, penggunaan metode yang tidak deterministik bahkan bisa ilegal. Atau bisa menimbulkan kewajiban tambahan yang tidak diinginkan (misalnya harus menyimpan seluruh rekaman layar agar nantinya dapat merekonstruksi satu per satu apa yang terjadi)
Muncul pembahasan tentang "bekerja di Thinking Machines bersama orang lain". Saya jadi rindu masa ketika melihat langsung mesin dengan kubus LED merah yang menyala di depan MIT AI Lab. Richard Feynman melakukan hal yang benar-benar keren, dan ada tulisan terkait Feynman and the Connection Machine. Di AS, merek dagang “THINKING MACHINES” tidak didaftarkan atas nama Hillis, melainkan perusahaan yang ia dirikan, lalu dibatalkan pada 1998–1999. Perusahaan itu bangkrut pada 1994, dan asetnya berpindah ke Sun Microsystems (kemudian Oracle) dan pihak lain. Thinking Machines Lab Inc. yang didirikan Amira Murati sedang mengajukan merek dagang baru “THINKING MACHINES” pada 2025
Saya sangat senang melihat kembali diskusi riset bergaya blog dengan kualitas tinggi belakangan ini. Anthropic memimpin budaya ini dan tampaknya semakin meluas, yang membuat saya optimistis. Dulu pada masa riset RL, OpenAI juga seperti ini
Bahasa alami itu sendiri ambigu. Dan memang harus ambigu. Saya rasa upaya di sini untuk 'membuat lingkaran menjadi persegi lalu mencoba menjelaskan mengapa itu harus dilakukan' adalah pendekatan yang keliru. Diskusi seperti ini pada akhirnya akan berkembang menjadi pembahasan tentang menerima dengan lebih baik hakikat bahasa dan keacakan, serta menafsirkan bahasa pada level yang lebih tinggi daripada sekadar subpola mini-tata-bahasa seperti QKV projection matrix
Saya masih tidak suka nama perusahaannya. Saya heran mengapa pola penamaan seperti ini terus berulang. Mungkin konteksnya berharap karakter organisasi legendaris menular ke venture baru. Rasanya tidak mungkin inovasi jaringan Anda otomatis mewarisi semangat itu hanya karena startup berikutnya dinamai PARC
Maksud Anda perusahaan “Thinking Machines” yang hilang pada 1994? Saya baru tahu setelah mencari-cari, dan tampaknya tidak cukup terkenal untuk menjelaskan niat seperti itu. Menurut saya itu hanya nama yang keren dan intuitif
Cukup dengan memberi nama seperti itu, manfaat pemasaran datang gratis, sama seperti alasan lahirnya sistem merek dagang
Sangat menarik. Bagi yang belum tahu, perusahaan ini didirikan oleh mantan CTO OpenAI Mira Murati