Infra Agent Z.ai: tiru feedback loop-nya, abaikan hype RSI

Apa yang sebenarnya dipublikasikan Z.ai

Z.ai merilis tulisan pagi ini dengan judul "Toward Recursive Self-Improvement", dan klaim utamanya besar: seluruh inferensi produksi GLM-5.3-Flash berjalan di klaster lebih dari 100.000 akselerator AI buatan Tiongkok, dibangun dari nol, dan "sebagian besar pekerjaannya dilakukan oleh sebuah Infra Agent yang ditenagai GLM-5.3." Menurut tulisan itu, model tersebut bergerak dari adaptasi awal ke siap produksi dalam waktu kurang dari dua minggu, melipatgandakan throughput end-to-end tiga kali dibanding baseline awal, dengan utilisasi dan biaya per token yang "sebanding dengan GPU NVIDIA arus utama".

Hacker News menghabiskan seharian berdebat tentang bagian yang salah. Thread-nya mencapai 292 poin dan 226 komentar dalam sepuluh jam, sebagian besar mempersoalkan apakah label "recursive self-improvement" pantas disandang, chip apa yang dipakai (komentator menunjuk Huawei Ascend di SMIC dengan memori Samsung dari masa sebelum sanksi), dan apakah ada satu pun angka yang bisa diverifikasi. Pertanyaan yang wajar. Tetapi bagian yang layak menyita waktu seorang engineer adalah desain feedback loop-nya: bagaimana Z.ai menyusun lingkungan kerja sehingga sebuah agen bisa mengerjakan kernel dan konkurensi yang biasanya membutuhkan engineer infra senior. Desain itu bisa ditiru di silikon apa pun.

Serving stack-nya sendiri konvensional meski padat: tensor parallelism intra-node untuk linear attention dan LM head, ReplaySSM, kuantisasi W8A8, kuantisasi cache campuran INT8/FP8/BF16, Layer Split, dan arsitektur terpisah Encode-Prefill-Decode. Yang menarik adalah bagaimana setiap komponen itu diubah menjadi sesuatu yang bisa diiterasi agen tanpa deployment penuh.

Dense feedback: satu-satunya prinsip desain

Klaim inti Z.ai adalah soal metode, bukan arsitektur. Mereka menyebutnya "dense feedback": tes kebenaran, log runtime, execution trace, microbenchmark dan metrik end-to-end semuanya dirangkai ke dalam loop iterasi agen, sehingga sebuah hipotesis bisa divalidasi secara lokal alih-alih menunggu deployment dan load test. Tulisan itu memberi tiga syarat yang harus dipenuhi feedback. Ia harus "cukup lokal", sehingga perubahan pada satu kernel menghasilkan sinyal tentang kernel itu. Ia harus "murah dan cepat diperoleh", sehingga agen mampu salah berkali-kali. Dan ia harus "mendukung verifikasi objektif", sehingga agen tidak menilai pekerjaan rumahnya sendiri.

Kalau Anda pernah menjalankan coding agent untuk masalah performa, Anda tahu kenapa ini penting. Beri agen kalimat "throughput turun 20%" dan sebuah repo, dan ia akan menghasilkan diff yang terlihat masuk akal tapi tidak berbuat apa-apa, karena jarak antara perubahan dan sinyalnya terlalu jauh untuk dipelajari. Tiga kasus di bawah menunjukkan apa yang didapat ketika jarak itu dipersempit.

Kasus 1: drift numerik yang terlihat oleh tes

Kasus pertama soal kebenaran. Z.ai membandingkan jalur kernel context-parallel dan non-context-parallel untuk kernel atensi KDA dan menemukan drift numerik di antara keduanya. Agen melacaknya ke tl.dot milik Triton yang secara default memakai presisi TF32 pada input FP32; perbaikannya adalah menyetel input_precision="tf32x3", dan perubahan itu sudah masuk upstream di Flash Linear Attention sebagai PR #1180.

Apa yang dilihat agen: dua jalur kode yang seharusnya sepakat dan sebuah tes yang bilang tidak. Apa yang bisa diuji dengan murah: menjalankan kedua jalur pada input yang sama dan membandingkan outputnya, yang memakan waktu hitungan detik. Apa yang disetujui manusia: perubahan upstream-nya. PR berjudul "[CP] use tf32x3 affine chain in kcp" itu digabung pada 27 Agustus oleh pengguna GitHub iclementine, membatasi TF32x3 hanya untuk perangkat keras NVIDIA dengan fallback IEEE, dan menambahkan tiga tes CP. Deskripsinya tidak menyebut agen atau GLM. Satu-satunya artefak yang bisa diperiksa dari luar justru mengkreditkan seseorang, dan tidak ada cara dari luar untuk tahu seberapa besar bagian yang ditulis agen.

Pelajarannya tetap berlaku. Tes diferensial antara dua implementasi dari matematika yang sama adalah feedback termurah, paling lokal, dan paling objektif yang bisa Anda berikan ke agen, dan kebanyakan codebase inferensi tidak memilikinya sampai ada yang rusak.

Kasus 2: masalah GIL dengan ambang penerimaan numerik

Kasus kedua soal konkurensi, dan ini ilustrasi terbaik tentang memberi agen sebuah ambang, bukan keluhan. Para engineer menetapkan kriteria penerimaan eksplisit untuk arsitektur terpisah: Prefill plus transfer KV harus berada dalam rentang 5% dari Prefill saja. Agen mengukur selisih di atas 20%, melacaknya ke intranode_dispatch dan intranode_combine milik DeepEP v1.2.1 yang tidak melepaskan GIL Python, sehingga thread transfer Mooncake kelaparan. Setelah GIL dilepaskan, selisihnya turun ke bawah 1%.

Perhatikan bentuk tugasnya. Agen tidak diberi tahu "transfer KV lambat". Ia diberi dua konfigurasi, sebuah metrik, sebuah target, dan trace. Itu mengubah investigasi terbuka menjadi pencarian yang terbatas: reproduksi selisihnya, bisect komponennya, temukan thread yang menunggu, jelaskan sebabnya. GIL yang tertahan di dalam ekstensi C++ adalah jenis bug yang ditemukan engineer senior dalam satu sore dan tidak pernah ditemukan junior, karena ia tidak muncul di tampilan profiler yang biasa dilihat orang. Dengan execution trace di dalam loop, ini menjadi pencocokan pola.

Ini juga perubahan yang menurut Z.ai tetap berada di bawah review manusia. Tulisan itu eksplisit bahwa engineer "mendefinisikan tujuan optimasi dan batasan sistem", membangun lingkungan feedback, dan mereview apa pun yang menyentuh "arsitektur sistem, konkurensi asinkron, dan risiko produksi". Pelepasan GIL di pustaka dispatch mencakup ketiganya.

Kasus 3: percepatan kernel dari pustaka langkah yang sudah dikenal

Kasus ketiga soal performa mentah pada kernel decode KDA. Agen pertama-tama mengoptimasi sebuah operasi pembagian dan memangkas waktu eksekusi 9,6%. Kemudian ia menggabungkan tile dimensi V ke dalam satu thread block dengan reduksi tingkat warp, menghasilkan percepatan 1,71x dibanding versi sebelumnya. Detail yang membuatnya bisa direproduksi: agen tidak bekerja dari prinsip pertama. Ia mengambil dari pustaka "optimization skeleton" yang disuling dari kernel SGLang, Flash Linear Attention dan DeepGEMM, masing-masing dengan syarat penerapannya.

Ini bagian yang dilewati kebanyakan tim. Agen dengan harness microbenchmark akan menemukan trik pembagian 9,6% itu sendiri; ruang pencariannya kecil. Restrukturisasi 1,71x adalah perubahan dengan orde berbeda, dan agen menemukannya jauh lebih cepat ketika polanya sudah ada sebagai langkah bernama dengan prasyarat: "ketika tile di sepanjang dimensi ini berbagi satu reduksi, gabungkan ke satu block dan lakukan reduksi di tingkat warp". Pustaka skeleton adalah akumulasi penilaian para engineer yang menulis SGLang dan DeepGEMM, dikemas agar model bisa mengambilnya. Microbenchmark lalu mengonfirmasi apakah langkah itu membuahkan hasil, dalam hitungan detik, di perangkat keras sungguhan.

Apa yang tidak bisa diperiksa, dan apa yang tetap layak ditiru

Jelas dulu soal batasannya. Setiap angka dalam tulisan itu berasal dari Z.ai. Tidak ada perbandingan langsung dengan produk NVIDIA tertentu di balik klaim "sebanding". Tulisan itu tidak mengukur berapa porsi kerja agen versus engineer, celah yang ditandai oleh Trending Topics maupun AI/TLDR. Satu-satunya artefak publik, PR #1180, mengkreditkan manusia. Dan Z.ai sendiri menulis bahwa "kami belum mencapai recursive self-improvement", yang terasa janggal di bawah judul yang mengatakan sebaliknya.

Konteks yang memang terverifikasi: GLM-5.3-Flash diluncurkan pada 26 Agustus sebagai MoE multimodal native dengan 320B parameter total dan 18B aktif, konteks 1 juta token, bobot berlisensi MIT di zai-org/GLM-5.3-Flash, dengan harga $0,15 input dan $0,50 output per juta token. Z.ai menyatakan saat peluncuran bahwa preview Ox Alpha sepenuhnya berjalan di chip domestik Tiongkok dengan engine kustom berbasis SGLang, dan tulisan hari ini menambahkan bahwa run anonim Ox-Alpha di OpenCode dan OpenRouter memproses lebih dari 62 triliun token dalam enam hari. Stack-nya nyata dan sudah menanggung beban, berapa pun porsi agen dalam membangunnya.

Inilah yang bisa dibawa ke pekerjaan Anda sendiri kalau coding agent Anda terus gagal pada tugas performa:

• Pecah konfigurasi deployment menjadi tugas yang bisa diuji satu per satu. Kalau hal terkecil yang bisa diuji agen adalah "deploy lalu load test", ia tidak akan pernah konvergen.
• Beri ambang dan baseline, bukan gejala. "Dalam rentang 5% dari Prefill saja" adalah tugas. "Transfer KV terasa lambat" adalah undangan untuk diff halusinasi.
• Tambahkan tes diferensial antara jalur kode yang setara. CP versus non-CP, fused versus unfused, terkuantisasi versus referensi. Biayanya nyaris nol dan mereka sinyal paling objektif yang tersedia.
• Masukkan trace ke dalam loop, bukan hanya metrik. Bug GIL tak terlihat di angka agregat dan jelas terlihat di trace thread.
• Bangun pustaka skeleton. Kumpulkan optimasi yang sudah divalidasi tim Anda, tuliskan kapan masing-masing berlaku, dan biarkan agen mengambilnya. Di sinilah penilaian senior mendapat daya ungkit.
• Buat batas review eksplisit. Aturan Z.ai: arsitektur, konkurensi asinkron dan risiko produksi lewat manusia. Tulis versi Anda sendiri sebelum PR pertama agen, bukan sesudahnya.

Modelnya tidak sepenting yang disiratkan framing-nya. Beri agen feedback yang lokal, murah dan objektif, maka model kelas menengah pun menghasilkan kerja kernel yang berguna. Tahan feedback itu, dan model terbaik di dunia hanya memproduksi diff yang percaya diri tapi tidak mengubah apa pun. Perbaiki observabilitasnya dulu.