Yazı | Şiang Xianshi
Lofti, Xiaomi MiMo'nun fiyat indirimi tartışmasını kapatmak için bir X gönderdi.
26 Mayıs'ta Xiaomi MiMo resmi hesabı, X üzerinde bir duyuru yayımladı: MiMo-V2.5 serisi API'leri kalıcı olarak indirime sokuldu, en yüksek indirim %99. Tüm context uzunlukları tek bir fiyata belirlendi, Token paketleri 5-8 kat artırıldı.
Bu duyuru, yerel AI topluluğunda tam bir hafta boyunca dolaştı. Endüstri ilk tepkisini birkaç gruba ayırdı. En büyük grup, bunu "yeniden bir fiyat savaşı" olarak tanımladı—bu iki yıl içinde Zhipu, DeepSeek, ByteDance DouBao ve Alibaba Tongyi gibi yerli büyük modeller sırayla fiyatlarını düşürdü, kimse rekabetin dışında kalmadı.
Diğer taraftan karamsar bir bakış: Xiaomi, bu yılki kârının yarıya düştüğünü duyurduktan hemen sonra AI alanında 60 milyar dolar harcıyor ve API’yi %90 oranında kesiyor—tipik bir “zararla pazar alma” stratejisi. Bir başka görüş ise DeepSeek etkisinin devam ettiğini söylüyor—DeepSeek, tüm endüstrinin fiyatlandırma temelini zemine indirdi ve bunu takip etmeyenler dışarıda kalır.
Bu nedenle MiMo'nun sorumluusu olarak, Luo Fuli, dün gece 5000 kelimelik bir teknik blog yayınladı ve indirimle ilgili mühendislik maliyetlerini herkese açığa çıkardı.
Bakın, bu gerçek mühendislik becerisidir, pazarlama yöntemi değildir.
Rof莉'nin ne dediğini anlayabilmek için bu %99'un tam olarak neyi düşürdüğünü anlamalısınız.
Bu tam model indirimi değildir. %99 indirim, "kullanıcının uzun diyaloglarda geçmiş bağlamı tekrar okuması" kısmını oluşturan Input (Cache Hit) adlı fiyatlandırma katmanına özel uygulanmaktadır. Normal yeni girişler (No Cache Hit) için indirim çok daha azdır, model çıktısı (Output) için ise indirim en düşüktür.
Modeli bir kafe olarak düşünürseniz, bu durum daha iyi anlaşılabilir.
Yarım şekerli latte sipariş edersiniz, kafe iki farklı yöntemle hazırlar: her seferinde yeni kahve çekirdeklerini öğütür, şurup ekler ve süt döker; her seferinde malzeme ve emek maliyeti oluşur. Ancak model bu hafta her gün aynı yarım şekerli latte içtiğinizi bilir ve bunun yerine büyük bir tencerede hazırlayıp buzdolabında saklar, sonraki seferlerde bir bardaklık miktarı alır. MiMo bu sefer ikinci yöntemi seçti—kullanıcıların tekrar okuduğu kısımları "anında hesapla" yerine "anında al" olarak değiştirdi; bu nedenle bu kısmın gerçek maliyeti neredeyse 0'dır ve doğal olarak %99 indirim verebilir.
"Şimdi al" yapmak için teknik blogda altı mühendislik çalışması anlatıldı, her biri eksik olamaz. Aşağıda bunları tek tek inceleyelim.
Proje 1: Modelin "hafızasını" 1/7'ye sıkıştırın
Model, sizinle konuşurken her token için bir "ara durum" hesaplar ve bir sonraki adımda kullanmak üzere saklar. Bu, KVCache olarak adlandırılır — modelin "kısa süreli hafıza defteri" olarak anlaşılabilir. Her cümlede, model defterine bu cümlenin özetiyle not alır ve bir sonraki seferde tüm geçmiş konuşmaları yeniden dinlemek yerine doğrudan deftere bakar.
Geleneksel modelde her katman "Tam Dikkat" yapar—yani her token, tüm diyalogun tüm tokenlarını görür, defter gittikçe kalınlaşır. MiMo-V2.5-Pro, mimarisini değiştirdi: 70 katmandan 60'ı yalnızca son 128 token'u görür (SWA, Kayan Pencere Dikkati), sadece 10 katman "arşiv görevlisi" olarak tümünü görür.
Sonuç olarak, KVCache boyutu Tam Dikkat'in 1/7'sine indirildi ve hesaplama miktarı aynı şekilde 1/7'si oldu.
Bu, maliyet azaltmanın ilk temelidir. Örneğin, önceki durumda şirketin her çalışanı tüm toplantı tutanaklarını hatırlamak zorundaydı ve bunun sonucunda herkesin zihni yetersiz kalıyor ve verimlilik düşük oluyordu. Yeni düzenlemeye göre 60 çalışanın zihinsel yükü 1/7 oranında azaltıldı ve tüm geçmiş kayıtlar yalnızca 10 arşiv görevlisi tarafından yönetiliyor—şirketin genel bellek kapasitesi azalmadı, ancak verimlilik yedi kat arttı.
Proje 2: SWA'nın serbest bıraktığı alanı gerçekten kullanabilir hale getirmek
Dizayn olarak dizüstü bilgisayarı 1/7'e düşürmek ilk adımdır, ancak "teorik 1/7"yi gerçek 1/7'ye dönüştürmek için bir engel daha vardır.
Geleneksel KVCache sistemi, tüm katmanlara "maksimum olası kullanım" göre aynı miktarda GPU belleği ayırır. Yani 60 katman SWA sadece küçük bir deftere ihtiyaç duysa bile, sistem tüm katmanlara "arşiv görevlisinin büyük defteri" kadar bellek ayırır—SWA'nın tasarruf ettiği alan boşta kalır, yani tasarruf yapılmamış olur.
Rofuli ekibi, KVCache'yi iki ayrı havuza ayırdı. Tam Dikkat'in 10 katmanı "büyük havuz"u, tam uzunlukta dağıtılarak kullanır; SWA'nın 60 katmanı ise "küçük havuz"u, yalnızca 128 token'lık bir pencereye göre dağıtılarak kullanır.
Örneğin, şirket daha önce her çalışanına "100 yıl boyunca dosya saklayabilecek bir dosya dolabı" veriyordu—ancak 60 çalışanın sadece "bir haftalık dosyaları saklayabilecek küçük dolap" ihtiyacı vardı ve bu büyük dolapların %99'u boş kalıyordu. Yeni yöntem, gerçek ihtiyaçlara göre dolapları bölüştürmektedir. Sonuç olarak, ofiste aynı anda çalışabilecek çalışan sayısı 5 kat artmıştır—aynı bir GPU, aynı anda hizmet verebilecek kullanıcı sayısını 5 kat artırmıştır.
Bu adım basit görünüyor, ancak bunu yapmadan önceki SWA mimarisinin avantajları tamamen boşuna tasarlanmış olur.
Mühendislik 3: "Eski kullanıcıların tekrar okuması" gerçekten önbelleğe ulaşsın
Laptop 1/7'e baskı yaptı + alan gerçekten kullanabilir, bir sonraki adım eski bir sorunu çözmek: önek önbelleğinin vurma oranı.
Çok sayıda kullanıcının konuşmaları aynı başlangıçla başlar—aynı sistem promptu, aynı kod deposu, aynı uzun belge. Sistem, bu sonuçları saklar ve bir sonraki eşleşmede doğrudan yeniden kullanır. Bu mekanizma önek önbelleği olarak adlandırılır.
Ancak SWA modunda bir sorun ortaya çıkıyor: İki istek token’ı aynı olsa da, KV hâlâ aktif olmayabilir. Önek hesaplanmış olabilir, ancak SWA penceresinin dışındaki kısımlar zaten atılmıştır. Sistem, "token aynıysa eşleşir" eski kuralına göre yeniden kullanırsa, geçersiz veya üzerine yazılmış veriler okunur ve model performansı tamamen bozulur.
Rofuli ekibi kuralı "pencere güvenlik uzunluğu"na yükseltti — yalnızca "tam olarak kiralayabileceğiniz kısmı" taahhüt etti.
Bir örnek verelim: Bir kütüphane 1 milyon kitap içeriyor ve üç ciltten oluşan "Three-Body Problem" serisini tamamen ödünç almak istiyorsunuz. Eski sistem, "Bu kitap mevcut" diyecektir; ancak oraya gittiğinizde rafta sadece kapak ve birinci cilt kalır, diğer iki cilt ödünç alınmıştır. Bu "yalanlı eşleşme", sizi gereksiz yere yola çıkarır ve tekrar ödünç almanızı gerektirir. Yeni sistem ise sadece tamamen ödünç alabileceğiniz kısmı vaat eder—önce birinci cilt verilir, ardından diğer iki cilt getirilir.
Daha katı gibi görünüyor ve vurma oranı düşer gibi geliyor. Ancak gerçek tamamen tersine: SWA, KVCache boyutunu 1/7'ye düşürerek aynı depolama alanına çok daha fazla içerik sığdırır ve gerçek vurma oranı büyük ölçüde artar.
Ro Fuli blogunda çevrimiçi test verileri verildi: Ana harness çerçevesinde sunucu önbelleği vuruş oranı ortalama %93, yüksek frekanslı uzun dönemli kullanıcılar için %95'in üzerinde.
95% tekrar okuma istekleri, GPU hesaplamasına gerek olmadan doğrudan önbellekten alınır. Bu, %99 indirimizin fiziksel temelidir.
Mühendislik 4: Önbelleği GPU'nun dahili SSD'sine yerleştirin
Doğruluk oranı yükseldi, bir sonraki soru: Bu önbellekler nerede saklanıyor.
VRAM (GPU'daki HBM bellek) pahalı ve sınırlı—bir H100 sekiz GPU makinesi sadece 640 GB VRAM'a sahip, ancak MiMo'nun saklaması gereken KVCache boyutu onlarca TB seviyesinde olabilir. Bu nedenle katmanlı bir yapı gerekli: en son kullanılan veriler VRAM'a (L1), biraz daha eski veriler CPU belleğine (L2), soğuk veriler ise dağıtılmış önbelleğe (L3) yerleştirilmelidir.
Para yönetimiyle aynı şey. Cüzdanınızda ki nakit, geçici bellektir — hemen kullanılabilir ama az yer kaplar. Banka kartı bakiyesi, CPU belleğidir — bir kez çekmek 30 saniye sürer ama çok daha fazla yer kaplar. Vadeli hesap, L3 dağıtılmış önbellektir — bir kez çekmek 2 dakika sürer ama çok daha ucuza mal olur.
Endüstrideki yaygın uygulama, L3 için ayrı bir depolama kümesi kurmak, özel makine ve özel veri merkezi kullanmak ve aylık kira ödemektir.
Xiaomi depolama ekibi farklı bir yaklaşım izliyor. GPU makinesinin dahili SSD'sine doğrudan dağıtılan, eğitim ve çıkarım görevleriyle aynı makinede paylaşılan kendi geliştirdikleri GCache adlı dağıtık önbellek sistemini kullanıyorlar.
Diğerleri büyük miktarda veri depolamak için özel olarak bir depo kiraladı; Xiaomi, GPU makinesinin garajının boş olduğunu fark etti ve verileri doğrudan oraya kaydetti. Aylık kira tasarrufu sağlandı.
Ek depolama maliyeti 0'dır.
Bu durumun etkisi göründüğünden daha büyük. Geleneksel "AI şirketleri hesap maliyetleri"nde depolama maliyeti sabit bir gider kalemidir—modeliniz ne kadar büyükse ve kullanıcılarınız ne kadar fazlaysa, depolama faturanız o kadar uzar. GCache bu yaklaşım, bu kalemi tamamen ortadan kaldırıyor. SWA'nın küçük boyutu ve %93-95 hedefleme oranı ile birlikte, KVCache'in L3'te kalma süresi (TTL), dakikalar yerine saatler hatta günler boyunca uzuyor—TTL ne kadar uzunsa, geçmiş bağlamın hedeflenme penceresi o kadar geniş olur, önbellek hedefleme oranı o kadar yüksektir ve %99 indirimi o kadar sağlam kalır.
Mühendislik 5: Önbelleğe alınmış isteklerin en kısa yolu izlemesini sağlayın
Önbellek hem depolayabilir, hem sorgulanabilir ve ucuzdur; son adım ise: doğru isteklerin doğru makineye yönlendirilmesidir.
Xiaomi, kendi zamanlama sistemini LLM-Router olarak geliştirdi ve üç şey yaptı:
Birincisi, uyumlu yönlendirme. Aynı öne sahip istekler aynı makineye yönlendirilir, önbellek yeniden kullanımını maksimize eder.
İkinci olarak, uzunluk bazlı bölme. Kısa istekleri (0-64K), orta istekleri (64K-256K) ve uzun istekleri (256K-1M) farklı işlem kanallarına ayırarak, kısa isteklerin uzun istekler tarafından yavaşlatılmasını önleyin.
Üçüncüsü TTFT optimizasyonu. Tahmin için sıraya alınan sırada, gerçek hesaplama yükü küçük olan istekleri (yani önbelleğe çokça hit eden istekleri) öncelikli olarak yönlendirin — bunların, tamamen yeni girdilere dayalı ağır hesaplama istekleri tarafından engellenmesini önleyin.
Örneğin, düzenli havaalanı planlamasında, aynı varış noktasına giden tüm yolcular aynı bekleme salonunda toplanır ve bagaj alma sürecini paylaşır—bu yakınlık planlamasıdır. El bagajı olanlar ve üç büyük bagajı olanlar farklı güvenlik kontrollerinden geçer, hızlı olanlar yavaş olanlar tarafından yavaşlatılmaz—bu uzunluk bölmeleridir. Yalnızca el bagajı olan yolculara öncelik verilir, çünkü daha hızlı biner ve uçak daha erken kalkar—bu TTFT optimizasyonudur.
Bu zamanlama stratejisi, L2 önbellek vuruş oranını %25, tek makine girdi verimliliğini %30 ve uzun istek P90 gecikmesini %30 azalttı.
Aynı GPU, daha fazla kullanıcıya hizmet verebilir. Fiyat düşüşünün diğer yarısı burada: birim hesaplama gücü daha yüksek verimlilik sağlıyor ve birim kullanıcı maliyeti daha düşük.
Mühendislik 6: Modelin "yazma" hızını da artırın
İlk beş şey, kullanıcıların geçmiş bağlamı tekrar okuma maliyetini neredeyse sıfıra indirmek için "okuma" tarafını optimize ediyor. Altıncı şey, modelin bir sonraki token'i üretme süreci olan "yazma" tarafını optimize etmek.
Geleneksel modeller bir seferde yalnızca 1 token üretir. MiMo, 3 katmanlı MTP (Çoklu Token Tahmini)’yi doğrudan destekler — bir seferde sonraki 3 tokeni tahmin eder ve ortadaki tahminler doğruysa, ortadaki hesaplamalar atlanır.
Bir örnek verelim, geleneksel bir klavyede bir harf bir harf yazıyorsunuz—“bugün hava” yazmak istiyorsanız 4 kez tuşa basmalısınız. MTP ise bir otomatik tamamlama gibi çalışır ve bir sonraki 1-2 harfinizi tahmin eder—eğer doğru tahmin ederse, o iki tuşa basmanıza gerek kalmaz.
MiMo'nun MTP'si, agentic senaryolarında: ilk 128 token için 2,3 kat hızlanma, 128-256 token için 1,5 kat hızlanma sağlıyor.
Bu olayın önemi, %99 indirim yalnızca Input (Cache Hit) üzerine odaklanırken, modelin gerçek kullanıcıları hizmet verirken input ve output aynı istekte gerçekleşir—output tasarruf edilmezse, toplam istek maliyeti sadece yarısı kadar azalır. MTP, outputun bu yarısını da düşürerek tüm indirim modelinin döngüsünü tamamlar.
Altı şeyi bir maliyet azalma zincirine bağlayın:
SWA mimarisi → KVCache 1/7 → çift havuz gerçek kapasite serbest bırakır → aynı GPU'da 5+ kat daha fazla eşzamanlı işlem → önek önbellek vuruş oranı %93-95 → %95 istek neredeyse hesaplamaya gerek duymaz → GCache depolama maliyetini sıfıra indirir → zamanlama vuruş isteklerini öncelikli yönlendirir → MTP üretimi de tasarruf sağlar → birim istek GPU süresi bir basamak düşer → birim maliyet %95+ azalır → fiyat %99 düşer, brüt kar marjı hâlâ pozitiftir.
Herhangi bir aşamanın eksik olması, zincirin bir yerde kırılmasına neden olur. %99 indirim, pazarlama sayısı değil, altı mühendislik sütununun birikecek etkisi ve gerçek çevrimiçi doğrulama sonrası ortaya çıkan sonuçtur.
İlk başta endüstrideki çeşitli yorumlara bakıldığında, her biri kısmen doğruydu. Son iki yıldır Çin’in büyük model şirketleri arasındaki fiyat savaşları gerçek; Xiaomi’nin kârı yarıya inmesine rağmen AI’ya yatırım yapması gerçek; DeepSeek’in sektörün fiyatlandırmasını zemine indirmesi de gerçek.
Ancak Ro Fuli, bu kez açık bir teknik blog yazısı yayınladı ve detaylı teknik ayrıntıları ortaya koydu; bu da fiyat savaşı iddialarına karşı bir cevap vermek ve “teknik sorunlar teknik, pazarlama sorunları pazarlama olsun” demek istiyor.
Blogunda, MiMo-V2.5 serisi modellerin çıkarım verimliliğinin tek bir noktada gerçekleşen bir atlamayla değil, çok boyutlu eş zamanlı optimizasyonun sonucu olduğunu yazdı. Hybrid SWA, prefill ve decode süreçlerine aynı anda fayda sağlıyor, ancak yeterince optimize edilmemiş KVCache uygulamaları her aşamada maliyetleri artırıyor. Bu hedefe yönelik olarak MiMo ekibi, KVCache yönetimi, hiyerarşik önbellekleme ve önek önbellek ağacı üzerinde sistematik bir yeniden yapılandırma gerçekleştirdi, SWA KVCache’in temel sorunlarını çözdü, zamanlama stratejisini ve prefill/decode zincirini optimize etti ve canlı ortamdaki gerçek senaryolarla test ederek teorik verimlilik avantajını üretim ortamında somutlaştırdı. Böylece Hybrid SWA, uzun metin çıkarımında hem güçlü hem de verimli bir mimari avantajı sergilemeye başladı. MoE yapılandırması ve çoklu modality çıkarımının çeşitli optimizasyonları ile birlikte, canlı çıkarım servislerinin performansı büyük ölçüde artırıldı.
Bu, bir AI mühendisliği sistemi ve endüstride ortak olarak referans alınabilecek maliyet azaltma yöntemi.
Fiyat savaşları için blog yazmaya gerek yok, mühendislik teslimi için gerekir.