Tulisan | Xiang Xianzhi
Luofuli telah memposting di X untuk menutup isu penurunan harga MiMo oleh Xiaomi.
Pada 26 Mei, akaun rasmi MiMo Xiaomi mengeluarkan pengumuman di X: MiMo-V2.5 Series API mengalami penurunan harga kekal, penurunan tertinggi 99%. Semua panjang konteks ditetapkan dengan harga seragam, pakej Token dinaikkan sebanyak 5-8 kali.
Pengumuman ini menjadi viral di kalangan AI tempatan selama seminggu penuh. Tindakan pertama industri terbahagi kepada beberapa faksi. Faksi terbesar mengatakan ini adalah "putaran pertarungan harga seterusnya"—selama dua tahun ini, model besar tempatan seperti Zhipu, DeepSeek, ByteDance DouBao, dan Alibaba Tongyi telah bergilir menurunkan harga, dan tiada siapa yang tidak terlibat dalam persaingan.
Pandangan pesimis lain: Xiaomi baru sahaja mengumumkan keuntungan tahun ini merosot separuh, namun masih menghabiskan RM60 bilion untuk AI dan mengurangkan API sebanyak 90%—contoh klasik "mengalahkan rugi untuk merebut pasaran". Ada juga yang percaya ini adalah kesan berterusan DeepSeek—yang telah menarik patokan harga seluruh industri ke aras terendah; siapa yang tidak mengikuti akan tersingkir.
Oleh itu, sebagai pengendali MiMo, Luo Fuli secara langsung mengeluarkan sebuah blog teknikal 5000 patah perkataan semalam, memaparkan akaun kejuruteraan penurunan harga kepada semua orang.
Lihat, ini adalah kemampuan kejuruteraan yang sebenar, bukan strategi pemasaran.
Untuk memahami apa yang dikatakan Luo Fuli, terlebih dahulu anda perlu tahu apa yang sebenarnya diturunkan sebanyak 99%.
Ia bukan penurunan harga keseluruhan model. Diskaun 99% khusus untuk satu pakej harga bernama Input (Cache Hit)—iaitu bahagian di mana pengguna membaca semula konteks sejarah dalam perbualan panjang. Penurunan untuk input baru biasa (No Cache Hit) jauh lebih kecil, dan penurunan untuk output model (Output) paling kecil.
Jika anda menganggap model sebagai sebuah kedai kopi, perkara ini akan lebih mudah difahami.
Anda memesan seorang latte setengah manis, kedai kopi mempunyai dua cara: setiap kali menggiling biji kopi, menuangkan sirap, dan menuangkan susu semula, dengan membayar bahan dan tenaga kerja setiap kali; tetapi model mengetahui bahawa anda akan minum latte setengah manis yang sama setiap hari seminggu ini, jadi ia membuat satu periuk besar dan menyimpannya di peti sejuk, kemudian mengambil satu cawan pada satu masa untuk setiap pesanan. MiMo kali ini melakukan yang kedua—mengubah bahagian pembacaan ulangan pengguna dari "kira semula" kepada "ambil terus", jadi kos sebenar bahagian ini hampir 0, dan dengan sendirinya boleh memberikan diskaun 99%.
Untuk mencapai "ambil segera", enam projek kejuruteraan telah dibincangkan dalam blog teknikal, dan setiap satu tidak boleh hilang. Mari kita uraikan satu per satu.
Projek Satu: Tekan "ingatan" model kepada 1/7
Semasa model berdialog dengan anda, setiap token akan mengira satu "keadaan sederhana" dan disimpan untuk digunakan pada langkah seterusnya. Perkara ini dipanggil KVCache — boleh difahami sebagai "buku ingatan jangka pendek" model. Setiap kali mengucapkan satu ayat, model akan mencatat ringkasan ayat itu dalam buku itu, dan pada percakapan seterusnya, ia boleh terus merujuk nota itu tanpa perlu mendengar semula keseluruhan perkataan anda sebelumnya.
Model tradisional setiap lapisan melakukan "Full Attention"—iaitu setiap token melihat keseluruhan token dalam perbualan, sehingga buku nota semakin tebal. MiMo-V2.5-Pro mengubah arsitektur: daripada 70 lapisan, 60 lapisan hanya melihat 128 token terkini (SWA, Sliding Window Attention), manakala hanya 10 lapisan "pengurus arkib" yang melihat keseluruhan.
Hasilnya, saiz KVCache secara langsung dikurangkan kepada 1/7 daripada Full Attention, dan jumlah pengiraan juga 1/7.
Ini adalah fondasi pertama untuk mengurangkan kos. Sebagai contoh, sebelum ini setiap pekerja syarikat dikehendaki mengingat semua notis mesyuarat, menyebabkan setiap orang kehabisan kapasiti otak dan efisiensi rendah. Peraturan baharu mengurangkan beban otak 60 pekerja kepada 1/7, hanya meninggalkan 10 pentadbir arkib yang bertanggungjawab atas semua sejarah — kemampuan ingatan keseluruhan syarikat tidak berkurang, tetapi efisiensi meningkat tujuh kali ganda.
Projek Dua: Membuat ruang yang dijimatkan oleh SWA benar-benar boleh digunakan
Mengurangkan butiran laptop kepada 1/7 adalah langkah pertama, tetapi untuk mewujudkan "1/7 teori" menjadi "1/7 sebenar", masih ada rintangan lagi.
Sistem KVCache tradisional mengalokasikan memori GPU secara seragam kepada semua lapisan berdasarkan "penggunaan maksimum yang mungkin". Ini bermaksud: walaupun 60 lapisan SWA hanya memerlukan buku kecil, sistem masih mengalokasikan "buku besar pengurus arkib" kepada semua lapisan—ruang yang dijimatkan oleh SWA dibiarkan terbiar, sama saja seperti tidak dijimatkan.
Pasukan Luo Fuli membahagikan KVCache menjadi dua tong yang berasingan. 10 lapisan Full Attention menggunakan "tong besar" dengan pengagihan penuh panjang; 60 lapisan SWA menggunakan "tong kecil" dengan pengagihan hanya berdasarkan tetingkap 128 token.
Sebagai contoh, sebelum ini syarikat memberikan setiap pekerja "almari fail yang boleh menyimpan dokumen selama 100 tahun"—tetapi 60 pekerja sebenarnya hanya memerlukan "almari kecil yang boleh menyimpan dokumen seminggu", dengan 99% ruang dalam almari besar itu kosong. Pendekatan baharu ialah membahagikan almari mengikut keperluan sebenar. Akibatnya, seluruh pejabat kini boleh menampung lebih daripada lima kali ganda bilangan rakan sekerja—jumlah pengguna serentak yang boleh dilayan oleh satu GPU meningkat lima kali ganda.
Langkah ini kelihatan mudah, tetapi tanpanya, kelebihan arkaitektur SWA sebelumnya sama sahaja seperti direka sia-sia.
Projek Tiga: Pastikan "pengguna lama membaca semula" benar-benar menghentikan cache
Laptop ditekan ke 1/7 + ruang benar-benar boleh dijangka, langkah seterusnya adalah menyelesaikan masalah lama: kadar kejayaan cache awalan.
Banyak percakapan pengguna bermula dengan sama—prompt sistem yang sama, perpustakaan kod yang sama, dokumen panjang yang sama. Sistem akan menyimpan hasil yang telah dikira ini, dan apabila terdapat kecocokan seterusnya, ia akan digunakan semula secara langsung. Mekanisme ini dipanggil cache awalan.
Namun, dalam mod SWA, terdapat satu masalah: dua permintaan dengan token yang sama tidak bermakna KV masih ada. Mungkin awalan telah dikira, tetapi bahagian di luar tetingkap SWA sudah lama dibuang. Jika sistem masih mengikuti peraturan lama "token yang sama bermakna berjaya", ia akan membaca data yang tidak sah atau telah ditimpa, dan kesan model akan runtuh secara langsung.
Rofuli team telah meningkatkan peraturan kepada "panjang keselamatan jendela"—hanya menjanjikan "bahagian yang boleh anda pinjam sepenuhnya".
Sebagai contoh, perpustakaan mempunyai satu juta buku, dan anda ingin meminjam seluruh siri tiga jilid "Three-Body Problem". Arsitektur lama akan memberitahu anda "buku ini tersedia", tetapi apabila anda pergi ke sana, anda mendapati hanya sampul dan jilid pertama yang ada, manakala dua jilid seterusnya telah dipinjam. "Pemenuhan palsu" ini menyebabkan anda berlari sia-sia dan perlu meminjam semula. Peraturan sistem baharu kini hanya menjanjikan bahagian yang boleh anda pinjam sepenuhnya—iaitu, memberikan jilid pertama terlebih dahulu, kemudian menghantar dua jilid seterusnya kepada anda.
Kedengarannya seperti lebih ketat dan kadar ketepatan akan menurun. Tetapi sebenarnya sebaliknya: kerana SWA mengurangkan saiz KVCache kepada 1/7, ruang penyimpanan yang sama mampu menyimpan beberapa kali ganda lebih banyak data, sehingga kadar ketepatan sebenar meningkat secara besar-besaran.
Ruo Fuli memberikan angka ujian maya dalam blognya: kadar kejayaan cache pelayan di bawah kerangka harness utama purata 93%, pengguna frekuensi tinggi dengan tempoh panjang boleh mencapai lebih daripada 95%.
Maksud nombor ini: 95% permintaan "baca ulang" tidak menggunakan GPU sama sekali, tetapi diambil terus dari cache. Ini adalah asas fizikal untuk diskaun 99%.
Rekabentuk 4: Masukkan "cache" ke dalam SSD binaan dalam GPU
Ketepatan peringatan meningkat, masalah seterusnya ialah: cache ini disimpan di mana.
Memori HBM pada GPU mahal dan terhad; satu mesin H100 dengan lapan GPU hanya mempunyai 640GB memori GPU, tetapi KVCache yang perlu disimpan oleh MiMo mungkin berukuran puluhan TB. Oleh itu, ia mesti dihuraikan secara bertingkat: data yang baru digunakan disimpan di memori GPU (L1), data yang sedikit lebih lama disimpan di memori CPU (L2), dan data yang tidak aktif disimpan dalam cache teragih (L3).
Ia sama seperti menguruskan wang anda. Wang tunai dalam dompet adalah memori paparan—boleh diambil sewaktu-waktu tetapi kapasitinya terhad. Baki kad bank adalah memori CPU—mengambilnya memerlukan 30 saat tetapi boleh menyimpan banyak. Simpanan tetap adalah cache teragih L3—mengambilnya memerlukan 2 minit tetapi jauh lebih murah.
Amalan biasa industri ialah membina satu kumpulan storan tersendiri untuk L3, dengan mesin khas dan ruang mesin khas, dengan bayaran sewa bulanan.
Pendekatan pasukan penyimpanan Xiaomi berbeza. Mereka membangunkan cache teragih sendiri bernama GCache, yang dideploy terus pada SSD yang disediakan oleh mesin GPU—dipasang bersama-sama dengan tugas latihan dan tugas inferens di mesin yang sama.
Orang lain menyewa sebuah gudang khas untuk menyimpan data dalam jumlah besar; Xiaomi mendapati ruang letak kereta mesin GPU sebenarnya kosong, dan terus menyimpan data ke sana. Menjimatkan sewa bulanan.
Kos penyimpanan tambahan adalah 0.
Kesan perkara ini lebih besar daripada yang kelihatan. Dalam "perhitungan kekuatan komputasi syarikat AI" biasa, kos penyimpanan adalah perbelanjaan tetap—semakin besar model anda dan semakin ramai pengguna, semakin panjang bil penyimpanan anda. Pendekatan GCache ini secara langsung menghapuskan perbelanjaan ini. Digabungkan dengan saiz kecil SWA + kadar kejayaan 93-95%, masa hayat (TTL) KVCache di L3 diperpanjangkan dari beberapa minit kepada beberapa jam atau bahkan beberapa hari—semakin panjang TTL, semakin luas jendela kejayaan konteks sejarah, semakin tinggi kadar kejayaan cache, dan semakin kukuh diskaun 99% itu.
Projek Lima: Arahkan permintaan yang berjaya di cache melalui laluan paling pendek
Cache boleh simpan, boleh cari, dan murah, langkah terakhir ialah: bagaimana memastikan permintaan yang betul dihantar ke mesin yang betul.
Xiaomi telah membangun sistem penjadwalan sendiri bernama LLM-Router, yang melakukan tiga perkara:
Pertama, penjadualan yang mesra. Permintaan dengan awalan yang sama dihantar ke mesin yang sama untuk memaksimakan penggunaan semula cache.
Kedua, penggalian panjang. Kelompokkan permintaan pendek (0-64K), permintaan sederhana (64K-256K), dan permintaan panjang (256K-1M) ke saluran pemprosesan yang berbeza untuk mengelakkan permintaan pendek dihambat oleh permintaan panjang.
Ketiga, pengoptimuman TTFT. Dalam antrian menunggu inferensi, utamakan penjadwalan permintaan yang memerlukan jumlah komputasi nyata kecil (iaitu permintaan yang banyak berjaya mencapai cache) — mengelakkan mereka dihalang oleh permintaan komputasi berat seperti "input baru".
Sebagai contoh, dalam pengurusan lapangan terbang biasa, semua penumpang yang terbang ke destinasi yang sama dikumpulkan di ruang tunggu yang sama dan berkongsi proses pengambilan bagasi—ini adalah penjadualan afiniti. Penumpang dengan beg tangan dan penumpang dengan tiga beg besar yang perlu disimpan melalui dua salur pemeriksaan keselamatan yang berbeza, supaya yang pantas tidak dipelankan oleh yang perlahan—ini adalah penghuluan berdasarkan panjang. Semasa naik pesawat, penumpang yang hanya membawa beg tangan didahulukan, kerana mereka naik lebih cepat dan membolehkan pesawat berlepas lebih awal—ini adalah pengoptimuman TTFT.
Strategi penjadualan ini secara nyata meningkatkan kadar kejayaan cache L2 sebanyak 25%, meningkatkan throughput input per mesin sebanyak 30%, dan mengurangkan latensi P90 untuk permintaan panjang sebanyak 30%.
Satu GPU yang sama boleh melayani lebih banyak pengguna. Separuh lagi logik penurunan harga ialah di sini—keluaran berkesan bagi unit pengiraan lebih tinggi, kos per pengguna lebih rendah.
Projek Enam: Membuat Model Menaip Lebih Cepat
Lima perkara sebelumnya semuanya mengoptimumkan sisi "baca" — menekan kos pengulangan konteks sejarah oleh pengguna hampir kepada 0. Perkara keenam adalah mengoptimumkan sisi "tulis" — iaitu proses model menghasilkan token seterusnya.
Model tradisional hanya dapat menghasilkan 1 token pada satu masa. MiMo menyokong secara asli 3 lapisan MTP (Multi-Token Prediction) — meramal 3 token seterusnya sekaligus, dan jika ramalan di tengah betul, pengiraan di tengah akan dilompati.
Sebagai contoh, menaip tradisional adalah menaip satu perkataan pada satu masa—jika anda ingin menaip "hari ini cuaca", anda perlu menekan 4 kali. MTP seolah-olah mempunyai pengisian automatik yang menebak perkataan seterusnya 1-2 anda—jika ia menebak dengan betul, anda tidak perlu menekan dua kali itu.
MTP MiMo diuji dalam skenario agentic: mempercepat 2.3 kali untuk 128 token pertama, 1.5 kali untuk 128-256 token.
Makna perkara ini ialah, diskaun 99% secara khusus merujuk kepada Input (Cache Hit), tetapi semasa model melayani pengguna, input dan output berlaku dalam permintaan yang sama—jika output tidak diselamatkan, kos keseluruhan permintaan hanya berkurang separuh. MTP menjadikan separuh output itu juga turun, sehingga model keuntungan penurunan harga keseluruhan menjadi tertutup.
Rangkai enam perkara menjadi satu rantai pengurangan kos:
Struktur SWA → KVCache 1/7 → Dua kolam benar-benar melepaskan kapasiti → Satu GPU yang sama boleh memuatkan 5+ kali ganda konsisten → Kadar kejayaan cache awalan 93-95% → 95% permintaan hampir tidak perlu dikira → GCache menjadikan kos penyimpanan sifar → Penjadualan mengutamakan permintaan yang berjaya dicache → MTP menjimatkan penghasilan juga → Masa GPU setiap permintaan turun satu peringkat sepuluh → Kos unit turun 95%+ → Harga turun 99%, tetapi margin kasar masih positif.
Kehilangan mana-mana peringkat akan memutuskan rantai tersebut pada satu bahagian. Penurunan 99% bukan nombor pemasaran, tetapi kesan akumulasi daripada enam tiang kejuruteraan yang ditambahkan + pengesahan maya sebenar.
Melihat semula beberapa tafsiran awal industri, setiap satu mempunyai sebahagian kebenaran. Dua tahun ini, perang harga antara syarikat model besar China adalah benar; Xiaomi yang keuntungannya separuhnya berkurang masih melabur dalam AI adalah benar; DeepSeek yang menarik harga industri ke paras terendah juga adalah benar.
Namun, dengan menerbitkan blog teknikal ini dan membongkar butiran teknikal secara terperinci, Ro Fuli jelas ingin menanggapi tuduhan perang harga, agar "masalah teknikal tetap menjadi masalah teknikal, dan masalah pemasaran tetap menjadi masalah pemasaran."
Dalam blognya, dia menulis bahawa kecekapan inferens model siri MiMo-V2.5 bukan hasil daripada terobosan tunggal di satu peringkat, tetapi hasil daripada pengoptimuman berbilang dimensi secara bersamaan. Hybrid SWA membolehkan prefill dan decode mendapat faedah serentak, tetapi implementasi KVCache yang tidak dioptimumkan dengan cukup justru akan meningkatkan kos di setiap peringkat. Mengikut matlamat ini, pasukan MiMo telah merekabentuk semula secara sistematik pengurusan KVCache, cache berperingkat, dan pokok cache awalan, menyelesaikan isu utama SWA KVCache, mengoptimumkan strategi penjadualan serta laluan Prefill/Decode, dan menguji ia dalam skenario sebenar secara maya, akhirnya mewujudkan kelebihan kecekapan teori ke dalam persekitaran pengeluaran. Dengan ini, Hybrid SWA baru dapat memperlihatkan kelebihan struktur yang menggabungkan kekuatan dan kecekapan dalam inferens teks panjang. Apabila digabungkan dengan konfigurasi MoE dan pelbagai pengoptimuman inferens multimodal, prestasi perkhidmatan inferens maya ditingkatkan secara besar-besaran.
Ini adalah pendekatan sistemik rekabentuk AI, dan juga merupakan cara pengurangan kos yang patut dirujuk dan diambil contoh oleh industri.
Perang harga tidak memerlukan penulisan blog, hanya pencapaian kejuruteraan yang memerlukannya.