Menyalakan constrained decoding bikin tool call vLLM akurat 100%

Insinyur Ubicloud menemui kegagalan yang umum saat melayani Kimi K2.6 di vLLM: model hanya menghasilkan skema tool call yang valid 92% dari waktu, jadi sekitar satu panggilan dari dua belas rusak. Panggilan rusak ini tidak sepele. Ia mengotori context window, menurunkan kualitas keluaran berikutnya, dan menambah biaya lewat retry. Akarnya sederhana. Model bahasa mengambil token berdasar probabilitas dan tidak pernah mencocokkan keluarannya dengan skema, dan data pelatihan dari berbagai setup tool-calling bisa mendorongnya memakai nama yang tak ada di lingkungan Anda, misalnya search_web padahal tool-nya bernama web_search.

Ada penyebab kedua yang lebih licik. Ketika Ubicloud pindah ke constrained decoding bawaan vLLM di v0.25, akurasinya turun ke 91%, karena vLLM diam-diam mengubah default sehingga constrained decoding mati kecuali sebuah permintaan memintanya. Tim Ubicloud menjelaskan vLLM melayani banyak model dan constrained decoding punya keanehan per-model, jadi mematikannya secara default itu keputusan yang masuk akal bagi proyeknya meski mengejutkan pengguna.

Solusinya adalah constrained decoding itu sendiri. Di tiap langkah, vLLM memakai structural tag XGrammar untuk menutup token mana pun yang akan merusak struktur panggilan, sehingga skema yang valid menjadi jaminan saat runtime, bukan sekadar harapan, dan menurut penulis overhead-nya dapat diabaikan karena mask-nya sudah dihitung lebih dulu. Setelah dinyalakan lagi dan diuji pada benchmark K2VV ToolCall, kepatuhan skema mencapai 100% di semua versi model yang dilayani Ubicloud, dan kini sudah dipakai untuk endpoint Kimi dan DeepSeek-nya.

Kenapa ini penting

Kalau Anda menjalankan open model untuk beban kerja agent, jangan anggap tool call yang valid datang gratis: periksa apakah build vLLM Anda sudah menyalakan constrained decoding, karena default-nya mungkin mati dan tingkat keberhasilan 92% diam-diam merusak satu langkah agent dari dua belas.