Anthropic tulis ulang Messages API ke Rust, CPU turun 40-50%

Anthropic memindahkan Messages API di balik Claude dari Python ke Rust secara menyeluruh. Katelyn Lesse yang memimpin bidang teknik dan Angela Jiang yang memimpin bidang produk menceritakan proses migrasi ini di podcast Latent Space. Setelah beralih, penggunaan CPU turun sekitar 40% hingga 50%, waktu respons token pertama membaik sekitar 10% hingga 20%, dan tugas yang berjalan lama merasakan peningkatan yang lebih jelas. Menurut para narasumber, API versi Rust sudah dirilis penuh seminggu sebelum rekaman dibuat.

Messages API adalah pintu masuk utama bagi pengembang yang memanggil Claude. Angela Jiang mengingat bahwa saat ia bergabung sekitar setahun lalu, sistem ini masih berupa layanan monolit Python yang hanya berjalan di satu region GCP.

Yang menghambat adalah CPU

Saat membahas hambatan perusahaan model besar, orang biasanya menyorot GPU, tetapi dalam wawancara ini yang berulang kali muncul justru CPU. Setelah penggunaan melonjak, layanan API, backend produk, sandbox kode, dan integrasi berkelanjutan sama-sama berebut CPU; makin banyak kode yang ditulis, makin sering CI dijalankan. Menurut penjelasan narasumber, tim riset dan sandbox produk berbagi kuota CPU yang sama, sehingga bila satu pihak memakai lebih banyak, pihak lain harus memakai lebih sedikit. Dalam kondisi itu, layanan versi Python terasa sangat boros sumber daya.

Memilih Rust menimbulkan perdebatan di internal, dengan alasan yang gamblang:

“we don't have a single Rust developer in the room.”

(Tidak ada satu pun pengembang Rust di ruang rapat.)

Insinyur yang berpengalaman dengan Rust baru direkrut belakangan.

Illustration: twin pipes link old and new machines, depicting shadow traffic checks during the Anthropic Rust migration

Manusia merancang arsitektur, Claude menulis implementasi

Pembagian kerjanya begini: insinyur bertanggung jawab atas desain dan verifikasi sistem terdistribusi, sementara sebagian besar kode implementasi diserahkan kepada Claude. Claude juga dipakai untuk membantu insinyur melengkapi pengetahuan Rust yang dibutuhkan. Para narasumber menekankan bahwa perencanaan dan verifikasi lebih penting daripada menulis kode itu sendiri.

Cara verifikasinya cukup konvensional. Tim lebih dulu membuat cabang lengkap API versi Rust, lalu menyalin bayangan (shadow copy) lalu lintas produksi ke sana dan membandingkan keluaran sistem lama dan baru satu per satu. Setelah itu, lalu lintas nyata dialihkan sedikit demi sedikit lewat feature flag dan load balancer. Migrasi ditangani satu kelompok khusus, sedangkan insinyur lain tetap mengembangkan fitur baru seperti biasa. Agar kedua sisi tidak makin menjauh, tim memakai analisis statis untuk menandai fitur yang baru ditambahkan di Python tetapi belum punya padanan di versi Rust, dan kelompok pemindah berusaha menolak permintaan baru selama masa migrasi.

Perkiraan para narasumber, bila migrasi dilakukan dengan cara biasa, bagian demi bagian secara bertahap, prosesnya bisa memakan waktu beberapa tahun; kali ini pemindahan dilakukan sekaligus secara menyeluruh. Berapa lama sebenarnya waktu yang dipakai dan berapa besar porsi kode yang dihasilkan Claude tidak disebutkan angkanya dalam wawancara, dan saat ini belum bisa diverifikasi dari luar.

Dilihat bersama penulisan ulang sejenis

Penulisan ulang berskala besar seperti ini, dengan model sebagai penulis utama dan manusia sebagai pengaman, sudah beberapa kali muncul belakangan ini. GitHub sebelumnya mengungkapkan telah memakai Copilot untuk menulis ulang runtime miliknya menjadi sekitar 830.000 baris Rust; sekitar perilisan Opus 5.5, ada pula tim yang memakainya untuk memindahkan kompiler TypeScript ke Rust dalam dua pekan. Kesamaan kasus-kasus ini adalah bahasa tujuannya sama-sama Rust, dan verifikasinya bertumpu pada pembandingan keluaran lama dan baru atau rangkaian uji yang lengkap.

Perbedaannya ada pada harga sebuah kesalahan. Bila kompiler atau alat pengembang bermasalah, dampaknya umumnya terbatas pada lingkungan lokal pengembang. Messages API menampung seluruh panggilan dari luar, sehingga begitu perilakunya tidak konsisten, dampaknya langsung jatuh ke sistem produksi pelanggan. Anthropic berani memindahkan jalur ini secara menyeluruh karena metode lama berupa lalu lintas bayangan dan pembandingan satu per satu; kecepatan model menulis kode saja tidak akan cukup.

Bagi perusahaan lain, bagian yang bisa ditiru kemungkinan besar adalah proses verifikasinya, belum tentu pilihan bahasanya. Tanpa lalu lintas bayangan dan pembandingan keluaran, sulit menilai apakah kode dalam jumlah besar yang sekali jadi dihasilkan model berperilaku sama dengan sistem lama.

Berikutnya: status percakapan

Tim mengungkapkan bahwa penyesuaian di tingkat arsitektur akan menyusul, dan salah satu arahnya adalah menyimpan status percakapan di sisi server sehingga klien tidak perlu mengirim ulang seluruh riwayat di setiap giliran. Pada percakapan panjang, ini dapat menghemat banyak pengiriman dan pemrosesan berulang. Kapan perubahan ini dirilis dan apakah akan memengaruhi antarmuka serta skema penagihan yang ada, belum diumumkan oleh Anthropic.

Sumber: wawancara podcast Latent Space, CocoLoop, dokumentasi pengembang Anthropic; wawancara digunakan untuk memeriksa besaran penurunan CPU, rentang perbaikan latensi token pertama, dan status rilis penuh.