Tulis oleh Xiang Xianzhi
Lo Fuli mengirimkan sebuah postingan di X untuk menutup kontroversi penurunan harga MiMo dari Xiaomi.
Pada 26 Mei, akun resmi MiMo Xiaomi mengumumkan di X: MiMo-V2.5 Series API mengalami penurunan harga permanen, dengan penurunan maksimal hingga 99%. Semua panjang konteks memiliki harga seragam, dan paket Token ditingkatkan 5-8 kali.
Pengumuman ini membanjiri lingkaran AI di dalam negeri selama seminggu penuh. Reaksi pertama industri terbagi menjadi beberapa kelompok. Kelompok terbesar mengatakan ini adalah "putaran persaingan harga berikutnya"—selama dua tahun terakhir, model besar buatan dalam negeri seperti Zhipu, DeepSeek, ByteDance DouBao, hingga Alibaba Tongyi terus bergantian menurunkan harga, dan siapa pun tidak ikut serta dalam persaingan ini.
Sisi lain melihatnya dengan pesimis: Xiaomi baru saja mengumumkan bahwa laba tahun ini turun setengahnya, namun tetap menghabiskan 60 miliar yuan untuk AI dan langsung memotong 90% API—contoh klasik "merugi demi merebut pasar". Ada pula yang berpendapat ini adalah efek berlanjut dari DeepSeek—perusahaan yang menarik patokan harga seluruh industri ke dasar, siapa yang tidak mengikuti akan tersingkir.
Jadi sebagai pemimpin MiMo, Luo Fuli langsung merilis sebuah blog teknis berisi 5000 kata semalam, membuka rincian teknis penurunan harga kepada semua orang.
Lihat, ini adalah kemampuan teknis yang nyata, bukan strategi pemasaran.
Untuk memahami apa yang dikatakan Luo Fuli, pertama-tama Anda harus tahu apa yang sebenarnya turun sebesar 99%.
Ini bukan penurunan harga untuk seluruh model. Diskon 99% secara khusus berlaku untuk paket bernama Input (Cache Hit)—yaitu bagian di mana "pengguna membaca ulang konteks historis dalam percakapan panjang". Penurunan harga untuk input baru biasa (No Cache Hit) jauh lebih kecil, dan penurunan harga untuk output model (Output) paling kecil.
Jika Anda menganggap model seperti sebuah kedai kopi, hal ini akan lebih mudah dipahami.
Anda memesan latte setengah gula, kedai kopi memiliki dua cara: setiap kali menggiling biji kopi, menuangkan sirup, dan menuangkan susu, semua bahan dan tenaga kerja dibayar sekali; namun model tahu bahwa minggu ini Anda minum latte setengah gula yang sama setiap hari, jadi ia membuat satu teko besar dan menyimpannya di kulkas, lalu mengambil satu porsi per cangkir saat dibutuhkan. MiMo kali ini melakukan yang terakhir—mengubah bagian yang dibaca berulang oleh pengguna dari "dihitung ulang" menjadi "diambil langsung", sehingga biaya aktual untuk bagian ini mendekati 0, dan secara alami dapat memberikan diskon 99%.
Untuk mencapai "ambil langsung", enam proyek teknis di blog teknis telah dijelaskan, dan masing-masing tidak boleh hilang. Mari kita bahas satu per satu.
Proyek 1: Kompresi "memori" model menjadi 1/7
Saat model berdialog dengan Anda, setiap token harus menyimpan "keadaan menengah" untuk digunakan pada langkah berikutnya. Hal ini disebut KVCache—dapat dipahami sebagai "buku catatan ingatan jangka pendek" model. Setiap kali mengucapkan satu kalimat, model mencatat ringkasan kalimat tersebut di buku catatan, sehingga pada percakapan berikutnya, model dapat langsung melihat catatan tanpa harus mendengarkan ulang seluruh isi percakapan sebelumnya.
Model tradisional setiap lapisannya melakukan "Full Attention"—artinya setiap token melihat seluruh token dalam percakapan, sehingga catatan semakin tebal. MiMo-V2.5-Pro mengubah arsitekturnya: dari 70 lapisan, 60 lapisan hanya melihat 128 token terbaru (SWA, Sliding Window Attention), sementara hanya 10 lapisan "petugas arsip" yang melihat seluruhnya.
Hasilnya, ukuran KVCache langsung ditekan menjadi 1/7 dari Full Attention, dan jumlah perhitungan juga menjadi 1/7.
Ini adalah fondasi pertama dalam mengurangi biaya. Sebagai contoh, sebelumnya setiap karyawan diharuskan mengingat semua catatan rapat, sehingga otak setiap orang menjadi penuh dan efisiensi rendah. Aturan baru mengurangi beban otak dari 60 karyawan menjadi 1/7, hanya menyisakan 10 petugas arsip yang menangani seluruh riwayat—kapasitas ingatan perusahaan tetap sama, tetapi efisiensi meningkat tujuh kali lipat.
Proyek 2: Membuat ruang yang dihemat oleh SWA benar-benar dapat digunakan
Mengurangi laptop ke 1/7 secara arsitektur adalah langkah pertama, tetapi mewujudkan "1/7 teoretis" menjadi "1/7 aktual" masih memerlukan satu rintangan.
Sistem KVCache tradisional mengalokasikan memori GPU secara seragam untuk semua lapisan berdasarkan "penggunaan maksimum yang mungkin". Artinya: meskipun 60 lapisan SWA hanya membutuhkan buku kecil, sistem tetap mengalokasikan "buku besar manajer arsip" untuk semua lapisan—ruang yang dihemat oleh SWA tetap disisihkan sia-sia, sehingga sebenarnya tidak ada penghematan.
Tim Luo Fuli memisahkan KVCache menjadi dua pool terpisah. 10 lapisan Full Attention menggunakan "pool besar" dengan alokasi panjang penuh; 60 lapisan SWA menggunakan "pool kecil" yang hanya dialokasikan berdasarkan jendela 128 token.
Sebagai contoh, sebelumnya perusahaan memberi setiap karyawan "lemari arsip yang bisa menampung dokumen selama 100 tahun"—namun sebenarnya 60 karyawan hanya membutuhkan "lemari kecil yang cukup untuk menyimpan dokumen selama satu minggu", sehingga 99% ruang di lemari besar tersebut kosong. Pendekatan baru adalah membagi lemari sesuai kebutuhan aktual. Hasilnya, seluruh kantor kini dapat menampung lebih dari lima kali lebih banyak rekan kerja—jumlah pengguna paralel yang dapat dilayani oleh satu GPU pun meningkat lima kali lipat.
Langkah ini tampak sederhana, tetapi tanpanya, keunggulan arsitektur SWA sebelumnya sama saja sia-sia.
Proyek Tiga: Pastikan "pengguna lama membaca ulang" benar-benar memicu cache
Laptop dipadatkan hingga 1/7 + ruang benar-benar terjangkau, langkah selanjutnya adalah menyelesaikan masalah lama: tingkat keberhasilan cache prefix.
Banyak percakapan pengguna memiliki awalan yang sama—prompt sistem yang sama, repositori kode yang sama, dokumen panjang yang sama. Sistem menyimpan hasil yang telah dihitung ini, dan ketika cocok lagi, hasilnya langsung digunakan ulang. Mekanisme ini disebut prefix caching.
Namun, dalam mode SWA muncul satu masalah: dua permintaan dengan token yang sama tidak berarti KV masih ada. Prefix mungkin sudah dihitung, tetapi bagian di luar jendela SWA sudah lama dibuang. Jika sistem masih mengikuti aturan lama "token yang sama berarti cocok" dan mengulang penggunaan, Anda akan membaca data yang tidak valid atau telah ditimpa, sehingga kinerja model akan langsung rusak.
Tim Luo Fuli memperbarui aturan menjadi "panjang aman jendela"—hanya menjanjikan "bagian yang dapat Anda pinjam sepenuhnya".
Sebagai contoh, perpustakaan memiliki satu juta buku, dan Anda ingin meminjam seluruh rangkaian tiga buku berjudul "Three-Body Problem". Arsitektur lama akan memberi tahu Anda "buku ini tersedia", tetapi ketika Anda pergi ke rak, Anda hanya menemukan sampul dan jilid pertama, sementara dua jilid berikutnya sudah dipinjam. "Keberhasilan palsu" ini membuat Anda sia-sia pergi dan harus meminjam ulang. Aturan sistem baru sekarang hanya menjanjikan bagian yang dapat Anda pinjam secara lengkap—memberi Anda jilid pertama terlebih dahulu, lalu mengatur pengiriman dua jilid berikutnya.
Terdengar seperti menjadi lebih ketat dan tingkat keberhasilan menurun. Namun sebenarnya sebaliknya: karena SWA mengurangi ukuran KVCache menjadi 1/7, ruang penyimpanan yang sama dapat menampung beberapa kali lebih banyak konten, sehingga tingkat keberhasilan aktual justru meningkat signifikan.
Di blog Luo Fuli, angka uji coba daring diberikan: tingkat keberhasilan cache server di bawah kerangka harness utama rata-rata 93%, pengguna dengan frekuensi tinggi dan periode panjang dapat mencapai lebih dari 95%.
Arti dari angka ini: 95% permintaan "pembacaan berulang" sama sekali tidak memerlukan GPU, melainkan langsung diambil dari cache. Ini adalah dasar fisik dari diskon 99%.
Proyek Empat: Masukkan "cache" ke dalam SSD bawaan GPU
Akurasi meningkat, masalah berikutnya adalah: cache ini disimpan di mana.
Memori VRAM (HBM pada GPU) mahal dan terbatas—satu mesin H100 dengan delapan GPU hanya memiliki 640 GB VRAM, tetapi KVCache yang perlu disimpan oleh MiMo bisa mencapai puluhan TB. Oleh karena itu, diperlukan lapisan: data yang baru digunakan disimpan di VRAM (L1), data yang agak lama disimpan di memori CPU (L2), dan data dingin disimpan di cache terdistribusi (L3).
Sama seperti mengelola uang Anda. Uang tunai di dompet adalah memori tampilan—bisa diambil kapan saja tapi kapasitasnya terbatas. Saldo rekening bank adalah memori CPU—butuh 30 detik untuk mengambilnya tapi bisa menyimpan banyak. Deposito berjangka adalah cache terdistribusi L3—butuh 2 menit untuk mengambilnya tapi jauh lebih murah.
Praktik umum industri adalah membuat kluster penyimpanan terpisah untuk L3, dengan perangkat khusus dan ruang server khusus, serta membayar sewa setiap bulan.
Tim penyimpanan Xiaomi berbeda. Mereka mengembangkan sendiri cache terdistribusi bernama GCache, yang langsung di部署 pada SSD bawaan mesin GPU—dihubungkan bersama dengan tugas pelatihan dan tugas inferensi pada mesin yang sama.
Orang lain menyewa gudang khusus untuk menyimpan data dalam jumlah besar; Xiaomi menyadari bahwa garasi mesin GPU sebenarnya kosong, jadi langsung menyimpan data di sana. Biaya sewa bulanan pun hemat.
Biaya penyimpanan tambahan adalah 0.
Dampak dari hal ini lebih besar dari yang tampak. Dalam "akun daya komputasi perusahaan AI" biasa, biaya penyimpanan adalah pos pengeluaran tetap—semakin besar model Anda dan semakin banyak pengguna, semakin panjang tagihan penyimpanan Anda. Pendekatan GCache ini langsung menghilangkan pos ini. Dikombinasikan dengan ukuran kecil SWA + tingkat keberhasilan 93-95%, masa hidup KVCache di L3 (TTL) diperpanjang dari beberapa menit menjadi beberapa jam bahkan beberapa hari—semakin panjang TTL, semakin lebar jendela keberhasilan konteks historis, semakin tinggi tingkat keberhasilan cache, dan diskon 99% menjadi semakin kuat.
Proyek Lima: Arahkan permintaan yang mengenai cache melalui jalur terpendek
Cache bisa menyimpan, bisa mencari, dan harganya murah, langkah terakhir adalah: bagaimana memastikan permintaan yang benar diarahkan ke mesin yang tepat.
Xiaomi mengembangkan sistem penjadwalan sendiri bernama LLM-Router, yang melakukan tiga hal:
Pertama, penjadwalan berbasis keakraban. Permintaan dengan awalan yang sama diarahkan ke mesin yang sama untuk memaksimalkan pemanfaatan ulang cache.
Kedua, pemotongan panjang berdasarkan bucket. Pisahkan permintaan pendek (0-64K), permintaan menengah (64K-256K), dan permintaan panjang (256K-1M) ke saluran pemrosesan yang berbeda untuk mencegah permintaan pendek tertahan oleh permintaan panjang.
Ketiga, optimasi TTFT. Dalam antrian menunggu inferensi, prioritas diberikan pada permintaan dengan beban komputasi nyata kecil (yaitu permintaan yang banyak memicu cache hit)—untuk menghindari mereka terhambat oleh permintaan berupa "input baru" yang memerlukan komputasi berat.
Misalnya, dalam pengaturan bandara biasa, semua penumpang yang menuju tujuan yang sama dikumpulkan di ruang tunggu yang sama, berbagi proses pengambilan bagasi—ini adalah affinity scheduling. Penumpang dengan tas kabin dan penumpang dengan tiga koper besar melewati dua jalur pemeriksaan keamanan berbeda, sehingga yang cepat tidak dihambat oleh yang lambat—ini adalah length-based bucketing. Saat naik pesawat, penumpang yang hanya membawa tas kabin didahulukan, karena mereka naik lebih cepat, memungkinkan pesawat lepas landas lebih awal—ini adalah TTFT optimization.
Strategi penjadwalan ini secara nyata meningkatkan tingkat keberhasilan cache L2 sebesar 25%, meningkatkan throughput input per mesin sebesar 30%, dan mengurangi latensi P90 untuk permintaan panjang sebesar 30%.
Satu GPU yang sama dapat melayani lebih banyak pengguna. Logika setengah dari penurunan harga ini adalah: output efektif per unit daya komputasi lebih tinggi, dan biaya per pengguna lebih rendah.
Proyek Enam: Membuat Model Mengetik Lebih Cepat
Lima hal sebelumnya semuanya mengoptimalkan sisi "membaca"—menekan biaya pengulangan konteks historis oleh pengguna hingga mendekati 0. Hal keenam adalah mengoptimalkan sisi "menulis"—yaitu proses model menghasilkan token berikutnya.
Model tradisional hanya dapat menghasilkan 1 token sekaligus. MiMo secara native mendukung 3 lapis MTP (Multi-Token Prediction)—memprediksi 3 token berikutnya sekaligus, dan jika prediksi di tengah benar, perhitungan tengah dilewati langsung.
Sebagai perbandingan, mengetik tradisional adalah mengetik satu per satu huruf—jika Anda ingin mengetik "今天天气", Anda harus menekan 4 kali tombol. MTP seperti memiliki fitur auto-complete yang menebak 1-2 huruf berikutnya Anda—jika tebakannya tepat, Anda tidak perlu menekan tombol itu lagi.
MTP MiMo diuji dalam skenario agentic: mempercepat 2,3 kali untuk 128 token pertama, dan 1,5 kali untuk 128-256 token.
Makna dari hal ini adalah bahwa diskon 99% secara khusus berlaku untuk Input (Cache Hit), tetapi saat model melayani pengguna, input dan output terjadi dalam permintaan yang sama—jika output tidak dihemat, biaya keseluruhan permintaan hanya berkurang separuh. MTP menurunkan separuh biaya output juga, sehingga model keuntungan penurunan harga secara keseluruhan menjadi lengkap.
Rangkai enam hal menjadi satu rantai pengurangan biaya:
Arsitektur SWA → KVCache 1/7 → Dua kolam benar-benar melepaskan kapasitas → Satu GPU dapat menampung 5+ kali lebih banyak koneksi paralel → Tingkat keberhasilan cache prefix 93-95% → 95% permintaan hampir tidak perlu dihitung → GCache membuat biaya penyimpanan menjadi nol → Penjadwalan memprioritaskan permintaan yang cocok → MTP juga menghemat generasi → Waktu GPU per permintaan turun satu orde besar → Biaya per unit turun lebih dari 95% → Harga turun 99%, tetapi margin kotor tetap positif.
Kehilangan satu saja tahap akan membuat rantai ini putus di salah satu bagiannya. Diskon 99% bukan angka pemasaran, melainkan efek akumulasi dari enam pilar teknis yang saling mendukung ditambah validasi daring nyata.
Melihat kembali beberapa interpretasi awal dari industri, masing-masing memiliki sebagian kebenaran. Dua tahun terakhir, perang harga antara perusahaan model besar Tiongkok memang nyata; Xiaomi yang labanya terbagi dua tetap menginvestasikan dana ke AI memang nyata; DeepSeek yang menarik harga industri ke dasar juga nyata.
Namun, dengan menerbitkan blog teknis ini dan membongkar rincian teknis secara terperinci, Ro Fuli jelas berharap untuk membantah klaim perang harga, agar "masalah teknis tetap menjadi masalah teknis, masalah pemasaran tetap menjadi masalah pemasaran."
Dia menulis di blognya bahwa efisiensi inferensi seri model MiMo-V2.5 bukan berasal dari terobosan tunggal pada satu tahap, melainkan hasil dari optimasi kolaboratif multidimensi. Hybrid SWA memberikan manfaat simultan pada prefill dan decode, namun implementasi KVCache yang tidak dioptimasi secara memadai justru meningkatkan biaya di berbagai tahap. Mengacu pada tujuan ini, tim MiMo merekonstruksi secara sistematis manajemen KVCache, cache bertingkat, dan pohon cache prefiks, mengatasi masalah inti SWA KVCache, mengoptimalkan strategi penjadwalan serta jalur Prefill/Decode, dan menguji coba secara nyata di lingkungan produksi, sehingga keunggulan efisiensi teoretis benar-benar terwujud di lingkungan produksi. Dengan demikian, Hybrid SWA baru dapat memperlihatkan keunggulan arsitekturalnya dalam inferensi teks panjang, yaitu kombinasi kekuatan dan efisiensi. Dengan menggabungkan konfigurasi MoE dan berbagai optimasi inferensi multimodal, kinerja layanan inferensi daring meningkat secara signifikan.
Ini adalah pendekatan sistematis dalam rekayasa AI, sekaligus metode pengurangan biaya yang layak menjadi referensi bersama industri.
Perang harga tidak perlu menulis blog, yang perlu adalah realisasi teknis.