Artikulo ni Xiang Xianzhi
Ro Fuli ay nag-post ng isang X upang magtapos sa gulo tungkol sa pagbaba ng presyo ni Xiaomi MiMo.
May 26, ang opisyal na account ni Xiaomi MiMo sa X ay naglabas ng isang pahayag: ang MiMo-V2.5 API Series ay permanenteng bawasan, pinakamataas na bawas ng 99%. Ang lahat ng context length ay may iisang presyo, at ang mga token package ay in-upgrade ng 5-8 beses.
Nakapagpalabas ng isang buong linggo ang anunsyong ito sa loob ng AI community sa bansa. Ang unang reaksyon ng industriya ay nahati sa ilang grupo. Ang pinakamalaking grupo ay sinabi na ito ay "isang ibang ronda ng pakikidigma sa presyo"—sa loob ng dalawang taon, mula sa Zhipu, DeepSeek, ByteDance DouBao hanggang Alibaba Tongyi, ang mga lokal na malalaking modelo ay tumataas-taas ang pagbaba ng presyo, at walang sinuman ang hindi nakikilahok sa pag-aagaw.
Ang isang iba pang pananaw ay malungkot: bago lang ni Xiaomi inanunsyo na bumaba ng kalahati ang kanyang kita taong ito, at ngayon ay patuloy pa rin ang pagbabayad ng 60 bilyon sa AI at pagbawas ng 90% sa API—klasikong "pagkawala ng kita para makakuha ng merkado." Mayroon ding nagsasabing ito ay patuloy na epekto ng DeepSeek—na dinala ang buong industriya sa pinakamababang presyo, at kung sino man ang hindi sumunod, babagsak.
Kaya bilang tagapag-ugnay ng MiMo, inilabas ni Luo Fuli noong gabi ang isang 5000-salitang teknikal na blog at isinampa ang mga teknikal na gastos ng pagbaba ng presyo sa lahat.
Tingnan mo, ito ang totoong kakayahan sa paggawa, hindi isang pampromosyon.
Upang maintindihan kung ano ang sinasabi ni Luo Fuli, kailangan mong maunawaan kung ano ang binalik ng 99%.
Hindi ito pagsabay na pagbaba ng presyo ng buong modelo. Ang 99% na discount ay espesyal na para sa isang pricing tier na tinatawag na Input (Cache Hit)—ang bahagi kung saan ang mga user ay paulit-ulit na binabasa ang historical context sa mahabang usapan. Mas maliit ang pagbaba sa karaniwang bagong input (No Cache Hit), at pinakamaliit ang pagbaba sa model output (Output).
Kung isasalarawan mo ang modelo bilang isang kapehan, mas madaling maintindihan ang bagay na ito.
Ipinipili mo ang isang half-sweet latte, at may dalawang paraan ang kapehan: ang bawat beses ay galing sa pagmamaliit ng kape, paglalagay ng sirap, at paglalagay ng gatas—ang lahat ng materyales at paggawa ay binabayaran nang bawat beses; ngunit alam ng modelo na araw-araw mo itong iiyak na half-sweet latte sa linggong ito, kaya gumawa sila ng malaking kahon at isinaksak sa ref, at sa susunod ay isasagawa lang ang isang baso sa isang kutsara. Ang ginawa ni MiMo sa pagkakataong ito ay ang pangalawa—binago nila ang paulit-ulit na pagbasa ng user mula sa "kalkulahin sa oras" patungo sa "kuhain sa oras", kaya ang tunay na gastos para dito ay malapit sa 0, at natural na maaaring magbigay ng 99% na diskwento.
Upang maisagawa ang "take now," binanggit ng technical blog ang anim na proyekto, at hindi maaaring kulang ang anumang isa sa kanila. Tingnan natin ang bawat isa nang hiwalay.
Proyekto 1: I-reduce ang "memory" ng model sa 1/7
Ang bawat token sa pag-uusap ng model ay nagtataglay ng isang "intermediate state" na itinatabi para sa susunod na hakbang. Ang tawag dito ay KVCache—maaaring isipin ito bilang "notebook ng pansamantalang memorya" ng model. Kapag sinabi mo ang isang pangungusap, isinusulat ng model ang summary nito sa notebook, at sa susunod, direktang titingin ito sa mga tala, hindi na kailangang makinig muli sa lahat ng sinabi mo mula sa simula.
Sa tradisyonal na modelo, bawat layer ay gumagamit ng "Full Attention"—kung saan bawat token ay tumitingin sa lahat ng token sa buong usapan, parang lalong tumutumba ang notebook. Ginawa ng MiMo-V2.5-Pro ang pagbabago sa arkitektura: sa 70 na layer, 60 lamang ang tumitingin sa pinakabagong 128 na token (SWA, Sliding Window Attention), at lamang ang 10 na layer na "档案管理员" ang tumitingin sa lahat.
Ang resulta ay ang sukat ng KVCache ay direkta na bawasan sa 1/7 ng Full Attention, at ang dami ng pagkalkula ay parehong 1/7.
Ito ang unang pundasyon ng pagbaba ng gastos. Sa isang halimbawa, dating inaasahan na matandaan ng bawat empleyado ang lahat ng mga tala ng pagpupulong, kaya naging sobra ang isipan nila at mababa ang kanilang efisensiya. Ang bagong patakaran ay nagbawas ng load sa isipan ng 60 empleyado sa 1/7, at pinanatili lamang ang 10 na mga tagapag-alaga ng arkibo na responsable sa lahat ng kasaysayan—hindi bumaba ang kakayahan ng kumpanya na tandaan, ngunit tumataas ang efisensiya ng 7 beses.
Proyekto 2: Gawing gamit ang espasyo na napagbawasan ng SWA
Ang pagpapababa ng laptop sa 1/7 sa arkitektura ay ang unang hakbang, ngunit upang isakatuparan ang "teoretikal na 1/7" bilang "totoong 1/7", may isang hadlang pa.
Ang tradisyonal na sistema ng KVCache ay nag-aalok ng memorya sa GPU nang pantay-pantay sa lahat ng layer batay sa "pinakamataas na posibleng paggamit". Ibig sabihin: kahit na ang 60 layers ng SWA ay kailangan lang ng maliit na notebook, ang sistema ay nag-aalok ng "malaking notebook ng arkibista" sa lahat ng layer—ang espasyo na naliligtas ng SWA ay pinapaligiran nang walang kabuluhan, kaya hindi talaga naliligtas.
Ang paraan ng team ni Luo Fuli ay ang paghahati ng KVCache sa dalawang hiwalay na pool. Ang 10 na layer ng Full Attention ay gumagamit ng "malaking pool" at may allocation batay sa buong haba; samantalang ang 60 na layer ng SWA ay gumagamit ng "maliit na pool" at may allocation lamang batay sa window ng 128 na token.
Halimbawa, dating ibinibigay ng kumpanya sa bawat empleyado ang "kabinet na kayang maglalaman ng 100 taon ng mga dokumento"—ngunit ang 60 na empleyado ay kailangan lang ng "maliit na kabinet na kayang maglalaman ng isang linggo ng mga dokumento", at 99% ng espasyo sa mga malalaking kabinet ay walang laman. Ang bagong paraan ay ang paghahati ng mga kabinet batay sa tunay na pangangailangan. Bilang resulta, mas maraming 5 beses ang mga empleyado na maaaring magtrabaho sa buong tanggapan—parehong 5 beses ang bilang ng mga nagkakasabay na user na maaaring pasuportahan ng isang GPU.
Ang hakbang na ito ay tila simpleng, ngunit kung walang ito, ang mga benepisyo ng nakaraang SWA arkitektura ay parang walang saysay.
Proyek 3: Siguraduhin na makahinga ang "repeat reading ng mga lumang user"
Nakapress ang notebook sa 1/7 + talagang kayang gamitin ang space, ang susunod ay lutasin ang isang lumang problema: ang hit rate ng prefix cache.
Maraming mga user na may magkakaparehong simula sa kanilang pag-uusap—parehong system prompt, parehong codebase, at parehong mahabang dokumento. Ang sistema ay nag-iimbak ng mga resultang nakuha nito, at kapag magkakasabay muli, diretso itong muling gagamitin. Ang mekanismo na ito ay tinatawag na prefix caching.
Ngunit may isang problema sa SWA mode: ang pagkakatulad ng dalawang request token ay hindi nangangahulugan na ang KV ay nasa loob pa. Maaaring na-calculate na ang prefix, ngunit ang bahagi sa labas ng SWA window ay nalinis na. Kung ang sistema ay patuloy na gumagamit ng lumang patakaran na "kung pareho ang token, gamitin muli", maaaring basahin nito ang hindi wasto o nabago na data, at mababagsak agad ang epekto ng model.
Inilunsad ng team ni Luo Fuli ang pag-update ng patakaran sa "window safety length"—tanging ang bahagi na kayang makabawi mo ang ipinagkakait.
Halimbawa, mayroong isang liboang librong aklat sa isang aklatan, at nais mong makakuha ng buong serye na tatlong volumen ng "The Three-Body Problem". Sa dating sistema, sasabihin nito sa iyo na "nandito ang libro," ngunit kapag pumunta ka doon, makikita mo na ang cover at unang volumen lang ang nasa shelf—ang dalawang iba pang volumen ay naka-borrow na. Ang ganitong "pseudohit" ay nagdudulot ng walang kwentang paglalakad at kailangan mong i-request muli. Sa bagong sistema, ang patakaran ay binago upang pangako lamang ang mga bahagi na maaari mong makakuha nang buo—una ay ibibigay sa iyo ang unang volumen, at pagkatapos ay i-arrange ang dalawang natitirang volumen.
Mukhang mas mahigpit at bumababa ang accuracy rate, ngunit sa katotohanan, kabaligtaran: dahil pinapaliit ng SWA ang sukat ng KVCache sa 1/7, mas maraming laman ang maaaring iimbak sa parehong espasyo sa memorya, kaya tumataas nang malaki ang totoong accuracy rate.
Binigay ni Luo Fuli ang mga numerong natuklasan sa online na pagsubok: sa pangunahing harness framework, ang average cache hit rate ng server ay 93%, at maaaring umabot sa higit sa 95% para sa mga user na may mataas na kadalian at mahabang panahon.
Ang kahulugan ng numero na ito: 95% ng mga hiling na "repeat read" ay hindi gumagamit ng GPU sa lahat, kundi direktang kinukuha mula sa cache. Ito ang pisikal na batayan ng 99% discount.
Proyek 4: I-install ang "cache" sa built-in SSD ng GPU
Nataas ang accuracy rate, ang susunod na tanong ay: Saan ito nakakabit ang cache?
Ang VRAM (HBM memory sa GPU) ay mahal at limitado—ang isang H100 na may walong GPU ay may 640GB lamang ng VRAM, ngunit ang KVCache na kailangang i-store ng MiMo ay maaaring umabot sa mga tens of TB. Kaya kailangang magkaroon ng paghahati: ang pinakabagong gamit ay isasama sa VRAM (L1), ang kaunting mas lumang data sa CPU memory (L2), at ang mga hindi aktibong data sa distributed cache (L3).
Parin lang sa pagpapatakbo ng pera. Ang pera sa wallet ay katulad ng VRAM—maaaring gamitin agad ngunit limitado ang kapasidad. Ang balanse sa bank card ay katulad ng CPU memory—kailangan ng 30 segundo para i-withdraw ngunit maraming puwedeng iimbak. Ang time deposit ay katulad ng L3 distributed cache—kailangan ng 2 minuto para i-withdraw ngunit mas mura.
Ang karaniwang praktika sa industriya ay magbuo ng hiwalay na storage cluster para sa L3, gamit ang espesyal na mga machine at espesyal na room, at magbabayad ng renta araw-araw.
Hindi pareho ang paraan ng team ng Xiaomi sa pagmememorya. Ibinuo nila ang isang sariling distributed cache na tinatawag na GCache, na diretso na inilalagay sa SSD na kasama ng GPU machine—pinagsama sa parehong machine kasama ang mga training at inference task.
Para sa malaking dami ng data, ang iba ay nag-rent ng isang warehouse; natuklasan ni Xiaomi na ang garage ng GPU machines ay walang laman, at direktang isinave doon ang data. Nabawasan ang monthly rent.
Ang karagdagang gastos sa pag-iimbak ay 0.
Mas malakas ang epekto nito kaysa sa tila. Sa karaniwang "account ng computing power ng AI company," ang gastos sa pag-iimbak ay isang fixed na gastos—mas malaki ang iyong model at mas marami ang mga user, mas mahaba ang tsek sa gastos sa pag-iimbak. Ang paraan ng GCache ay agad na tinanggal ang gastos na ito. Kasama ang maliit na laki ng SWA + 93-95% na hit rate, ang TTL (time-to-live) ng KVCache sa L3 ay naitaas mula sa ilang minuto hanggang sa ilang oras o kahit ilang araw—mas mahaba ang TTL, mas malawak ang window para sa paghahanap ng historical context, mas mataas ang cache hit rate, at mas matatag ang 99% discount.
Proyek 5: Ipatrol ang mga hiling na nakakamit ang cache sa pinakamaikling daan
Ang cache ay maaaring i-store, i-check, at mura pa; ang huling hakbang ay: paano i-route ang tamang request sa tamang machine.
Nilikha ng Xiaomi ang sarili nilang sistema ng pagpaplano na tinatawag na LLM-Router, at ginawa ang tatlong bagay:
Una ay pagkakasundo ayon sa pagkakatulad. Ang mga hiling na may parehong prefix ay pinapadala sa iisang machine upang maksimisahin ang paggamit muli ng cache.
Ikalawa ay ang pagbabahagi ayon sa haba. Ihihiwalay ang maikling kahilingan (0-64K), katamtamang kahilingan (64K-256K), at mahabang kahilingan (256K-1M) sa iba’t ibang mga channel ng pagproseso upang maiwasan ang pagpapabagal ng mga maikling kahilingan ng mga mahabang kahilingan.
Ikatlo ay ang pagpapabuti ng TTFT. Sa queue para sa paghihintay ng inference, unahin ang pag-schedule ng mga hiling na may maliit na aktwal na computation—ibig sabihin, ang mga hiling na madalas ay sumasakop sa cache—upang maiwasan ang pagkakablock nila ng mga hiling na may "bagong input" na nangangailangan ng malaking computation.
Halimbawa, sa karaniwang jadwal ng airpot, ang lahat ng pasahero na papunta sa parehong destinasyon ay pinagsasama sa iisang terminal at nagbabahagi ng proseso ng pagkuha ng bagahe—ito ay affinity scheduling. Ang mga may carry-on luggage at ang mga may tatlong malalaking bagahe ay gumagamit ng dalawang magkakaibang checkpoint para sa security check, kaya hindi pinipigilan ng mabagal ang mabilis—ito ay length-based bucketing. Kapag pagsisimulan na ang pagpapasok sa eroplano, unang pinapapasok ang mga may carry-on lang, dahil mas mabilis silang papaalis, kaya mas maaga makakalabas ang eroplano—ito ay TTFT optimization.
Ang praktikal na pagsubok ng estratehiyang ito ay nagpataas ng L2 cache hit rate ng 25%, nagpataas ng input throughput ng isang machine ng 30%, at nagbawas ng P90 latency ng mga habang kahilingan ng 30%.
Ang iisang GPU ay nakakaserve sa mas maraming gumagamit. Narito ang kalahati ng lohika ng pagbaba ng presyo—mas mataas ang epektibong output ng unit ng computing power, mas mababa ang gastos bawat user.
Proyek 6: Gawing mas mabilis ang pagketina ng model
Ang limang unang bagay ay nagpapabuti sa aspeto ng "pagbasa"—pinapababa ang gastos ng pag-uulit ng historical context ng user sa halos 0. Ang ikaanim na bagay ay nagpapabuti sa aspeto ng "pagsusulat"—ang proseso kung saan ang model ay nagpapalabas ng susunod na token.
Ang tradisyonal na modelo ay nagpapagawa ng 1 token lamang sa isang pagkakataon. Ang MiMo ay may natatanging suporta sa 3 antas ng MTP (Multi-Token Prediction)—nagpapagawa ng mga sumusunod na 3 token nang sabay-sabay, at kung tama ang pagbibilang sa gitna, direktang isasagawa ang paglilipas sa gitnang kalkulasyon.
Halimbawa, ang tradisyonal na pagketik ay isang titik-isang titik—kung gusto mong ketikin ang "今天天气", kailangan mong pindutin ang 4 na beses. Ang MTP ay may auto-complete na nagtataya kung ano ang susunod na 1-2 titik mo—kung tama ang pagtataya nito, hindi na kailangan mong pindutin ang dalawang beses.
Ang MTP ng MiMo ay nasubok sa agentic scenario: 2.3x na pagpapabilis sa unang 128 na token, 1.5x na pagpapabilis sa 128-256 na token.
Ang kahalagahan nito ay ang 99% na discount ay espesipikong nakatuon sa Input (Cache Hit), ngunit habang naglilingkod ang modelo sa mga user, ang input at output ay nangyayari sa iisang request—kung hindi nabawasan ang output, ang kabuuang gastos sa request ay nabawasan lamang ng kalahati. Pinapababa ng MTP ang kalahating bahagi ng output, kaya isang saradong modelo ng kita ang nabubuo sa buong pagbaba ng presyo.
Isama ang anim na bagay sa isang chain ng pagbaba ng gastos:
SWA architecture → KVCache 1/7 → Double pool truly releases capacity → One GPU can accommodate 5x more concurrent requests → Prefix cache hit rate of 93–95% → 95% of requests require almost no computation → GCache brings storage costs to zero → Scheduling prioritizes cached requests → MTP also saves generation → GPU time per request drops by an order of magnitude → Unit cost drops by 95%+ → Pricing drops 99%, yet gross margin remains positive.
Kawalan ng anumang bahagi ay magpapabagsak sa buong serye. Ang 99% na pagbaba ng presyo ay hindi isang marketing number, kundi ang akumulatibong epekto ng pagkakasunod-sunod ng anim na teknikal na pundasyon + totoong online na pagsubok.
Tingnan ang mga unang interpretasyon ng industriya, bawat isa ay may bahaging katotohanan. Totoo ang price war sa pagitan ng mga Chinese large model company sa loob ng dalawang taon; totoo na bawasan ng kalahati ang kita ni Xiaomi habang patuloy na umiinom sa AI; totoo rin na dinapa ni DeepSeek ang presyo ng industriya sa lupa.
Ngunit ang pagpapalabas ni Luo Fuli ng teknikal na blog at ang detalyadong pagpapaliwanag ng teknikal na detalye ay isang malinaw na pagtutol sa mga pagsasabing may price war, upang “maging teknikal ang teknikal na isyu at marketing ang marketing na isyu.”
Isinulat niya sa blog na ang pagiging epektibo sa pagpapatakbo ng mga modelo ng MiMo-V2.5 ay hindi nagmula sa isang pambansang pagbubuo sa isang bahagi lamang, kundi ang resulta ng maraming dimensyon na koordinadong pagpapabuti. Ang Hybrid SWA ay nagbibigay ng kapakinabangan sa parehong prefill at decode, ngunit ang hindi sapat na pinagpapabuting implementasyon ng KVCache ay maaaring magtaas ng gastos sa bawat yugto. Sa paligid ng layuning ito, ang MiMo team ay sistematikong muli nang binago ang KVCache management, hierarchical caching, at prefix caching tree, nilutas ang mga pangunahing problema ng SWA KVCache, pinabuti ang scheduling strategy at ang Prefill/Decode pipeline, at sinubok sa totoong online na mga sitwasyon, upang talagang isabuhay ang teoretikal na mga benepisyo sa produksyon. Sa ganitong paraan, ang Hybrid SWA ay nagsimulang magpakita ng kanyang arkitekturang kakayahan sa pagiging malakas at epektibo sa pagpapatakbo ng mahabang teksto. Kasama pa ang pagkakaisa ng MoE configuration at iba’t ibang pagpapabuti sa multi-modal inference, napalaki nang malaki ang performance ng online inference service.
Ito ay isang sistematisadong diskarte para sa AI engineering, at isang epektibong paraan sa pagbawas ng gastos na dapat isaalang-alang ng industriya.
Hindi kailangan ng blog para sa pakikidigma sa presyo, kailangan ng pagpapatupad ng inhinyeriya.