Bài viết | Tượng Tiên Chí
Luo Fuli đã đăng một bài viết trên X nhằm kết thúc cuộc tranh cãi về việc giảm giá của Xiaomi MiMo.
Ngày 26 tháng 5, tài khoản chính thức MiMo của Xiaomi đăng một thông báo trên X: Các API dòng MiMo-V2.5 được giảm giá vĩnh viễn, mức giảm tối đa lên đến 99%. Tất cả độ dài context đều được định giá thống nhất, gói token được nâng cấp 5-8 lần.
Thông báo này đã lan truyền khắp cộng đồng AI trong nước suốt cả một tuần. Phản ứng đầu tiên của ngành chia thành nhiều phe. Phe lớn nhất cho rằng đây là "một vòng chiến giá mới" – trong hai năm qua, từ Zhipu, DeepSeek, ByteDance DouBao đến Alibaba Tongyi, các mô hình lớn trong nước lần lượt giảm giá, ai cũng đang cạnh tranh khốc liệt.
Một quan điểm bi quan khác cho rằng: Xiaomi vừa thông báo lợi nhuận năm nay giảm một nửa, vậy mà vẫn tiếp tục đầu tư 60 tỷ nhân dân tệ vào AI và cắt giảm 90% API — đây là hành động điển hình “chịu lỗ để tranh thị phần”. Một số người còn cho rằng đây là hiệu ứng tiếp nối từ DeepSeek — công ty này đã kéo mức định giá của toàn ngành xuống đáy, ai không theo sẽ bị loại bỏ.
Vì vậy, với tư cách là người phụ trách MiMo, Luo Fuli đã trực tiếp công bố một bài viết kỹ thuật dài 5.000 từ vào tối qua, công khai toàn bộ chi phí kỹ thuật giảm giá cho tất cả mọi người.
Nhìn này, đây là năng lực kỹ thuật thực sự, không phải là thủ thuật tiếp thị.
Để hiểu được羅福莉 đang nói gì, trước tiên phải hiểu rõ 99% này đã giảm cái gì.
Đây không phải là giảm giá toàn bộ mô hình. Mức giảm 99% chỉ áp dụng cho một mức giá gọi là Input (Cache Hit)—tức là phần "người dùng lặp lại đọc lịch sử ngữ cảnh trong cuộc hội thoại dài". Mức giảm cho các đầu vào mới thông thường (No Cache Hit) nhỏ hơn nhiều, và mức giảm cho đầu ra mô hình (Output) là nhỏ nhất.
Nếu bạn coi mô hình như một quán cà phê, điều này sẽ dễ hiểu hơn.
Bạn gọi một ly cà phê latte đường nửa, quán cà phê có hai cách làm: mỗi lần đều phải xay hạt cà phê mới, đổ xi-rô và sữa, nguyên vật liệu và nhân công đều phải trả tiền một lần; nhưng mô hình biết rằng tuần này bạn đều uống cùng một ly latte đường nửa mỗi ngày, nên nó làm sẵn một ấm lớn, để trong ngăn đá, lần sau chỉ cần múc ra từng cốc. Lần này MiMo làm theo cách thứ hai — chuyển phần dữ liệu người dùng đọc lặp lại từ "tính toán ngay" sang "lấy ngay", do đó chi phí thực tế của phần này gần như bằng 0, nên tự nhiên có thể đưa ra mức chiết khấu 99%.
Để thực hiện được "lấy ngay", bài viết kỹ thuật đã đề cập đến sáu dự án kỹ thuật, mỗi dự án đều không thể thiếu. Dưới đây sẽ từng bước phân tích từng dự án.
Dự án 1: Giảm bộ nhớ của mô hình xuống 1/7
Khi mô hình đang trò chuyện với bạn, mỗi token đều phải tính một "trạng thái trung gian" và lưu lại để sử dụng cho bước tiếp theo. Thứ này gọi là KVCache — có thể hiểu như một "sổ ghi nhớ ngắn hạn" của mô hình. Mỗi khi nói một câu, mô hình sẽ ghi lại tóm tắt câu đó vào sổ, lần sau chỉ cần tra lại sổ ghi chép mà không cần nghe lại toàn bộ những gì bạn đã nói từ đầu.
Mô hình truyền thống ở mỗi lớp đều thực hiện "Full Attention" — tức là mỗi token đều phải xem toàn bộ các token trong đoạn hội thoại, khiến cuốn sổ ngày càng dày lên. MiMo-V2.5-Pro đã thay đổi kiến trúc: trong 70 lớp, 60 lớp chỉ xem 128 token gần nhất (SWA, Sliding Window Attention), chỉ có 10 lớp "người quản lý hồ sơ" xem toàn bộ.
Kết quả là kích thước KVCache được giảm trực tiếp xuống 1/7 so với Full Attention, và lượng tính toán cũng là 1/7.
Đây là nền tảng đầu tiên để giảm chi phí. Ví dụ, trước đây mỗi nhân viên trong công ty đều phải ghi nhớ tất cả biên bản cuộc họp, dẫn đến quá tải trí nhớ và hiệu suất thấp. Quy định mới đã giảm gánh nặng trí nhớ của 60 nhân viên xuống còn 1/7, chỉ còn 10 nhân viên quản lý hồ sơ chịu trách nhiệm lưu trữ toàn bộ lịch sử — khả năng ghi nhớ tổng thể của công ty không giảm, nhưng hiệu suất tăng lên 7 lần.
Dự án 2: Làm cho không gian tiết kiệm được từ SWA thực sự có thể sử dụng được
Việc ép laptop xuống 1/7 về mặt kiến trúc là bước đầu tiên, nhưng để biến “1/7 lý thuyết” thành “1/7 thực tế” vẫn còn một rào cản.
Hệ thống KVCache truyền thống cấp bộ nhớ GPU đồng đều cho tất cả các lớp dựa trên "lượng sử dụng tối đa có thể". Nghĩa là: ngay cả khi 60 lớp SWA chỉ cần một quyển vở nhỏ, hệ thống vẫn cấp cho tất cả các lớp một quyển vở lớn như "người quản lý hồ sơ" — không gian tiết kiệm được bởi SWA bị giữ lại vô ích, tương đương với việc không tiết kiệm được gì.
Đội ngũ Luo Fuli chia KVCache thành hai bể riêng biệt. 10 lớp Full Attention sử dụng "bể lớn", phân bổ theo độ dài đầy đủ; 60 lớp SWA sử dụng "bể nhỏ", chỉ phân bổ theo cửa sổ 128 token.
Ví dụ, trước đây công ty cấp cho mỗi nhân viên một chiếc tủ lưu trữ có thể chứa tài liệu trong 100 năm — nhưng thực tế 60 nhân viên chỉ cần những chiếc tủ nhỏ đủ chứa tài liệu trong một tuần, và 99% không gian trong những chiếc tủ lớn đó là trống rỗng. Cách tiếp cận mới là phân chia tủ theo nhu cầu thực tế. Kết quả là toàn bộ văn phòng có thể đón thêm hơn 5 lần số lượng đồng nghiệp làm việc — cùng một GPU có thể phục vụ số lượng người dùng đồng thời tăng gấp 5 lần.
Bước này trông có vẻ đơn giản, nhưng nếu không có nó, những lợi thế của kiến trúc SWA trước đó sẽ trở nên vô nghĩa.
Dự án 3: Đảm bảo rằng "người dùng cũ đọc lại" thực sự trúng bộ nhớ đệm
Áp dụng笔记本 trên 1/7 + không gian thật sự sử dụng được, bước tiếp theo cần giải quyết một vấn đề cũ: tỷ lệ hit của bộ nhớ đệm tiền tố.
Nhiều cuộc hội thoại của người dùng bắt đầu giống nhau—cùng một đoạn system prompt, cùng một thư viện mã, cùng một tài liệu dài. Hệ thống sẽ lưu trữ các kết quả đã tính toán trước đó và tái sử dụng trực tiếp khi khớp lại lần sau. Cơ chế này được gọi là tiền tố bộ nhớ đệm.
Tuy nhiên, trong chế độ SWA có một vấn đề: hai yêu cầu có cùng token không có nghĩa là KV vẫn còn tồn tại. Có thể phần tiền tố đã được tính toán, nhưng phần nằm ngoài cửa sổ SWA đã bị loại bỏ từ lâu. Nếu hệ thống vẫn tuân theo quy tắc cũ "cùng token thì dùng lại", bạn sẽ đọc được dữ liệu không hợp lệ hoặc đã bị ghi đè, khiến hiệu suất mô hình sụp đổ ngay lập tức.
Đội ngũ Luo Fuli đã nâng cấp quy tắc lên "độ dài an toàn của cửa sổ" — chỉ cam kết "phần mà bạn có thể vay đầy đủ".
Hãy ví dụ, một thư viện có 1 triệu cuốn sách, và bạn muốn mượn bộ ba cuốn "Three-Body Problem" đầy đủ. Kiến trúc cũ sẽ thông báo cho bạn: "Cuốn sách này có sẵn", bạn chạy đến thì phát hiện trên kệ chỉ còn bìa và tập một, hai tập còn lại đã bị mượn hết. Tình trạng “trúng giả” này khiến bạn phải đi vô ích và phải mượn lại. Quy tắc của hệ thống mới đã thay đổi: chỉ cam kết cung cấp cho bạn phần mà bạn có thể mượn đầy đủ — trước tiên cấp cho bạn tập một, sau đó sẽ điều phối hai tập còn lại cho bạn.
Nghe có vẻ nghiêm ngặt hơn và tỷ lệ trúng giảm, nhưng thực tế lại ngược lại: vì SWA làm giảm kích thước KVCache xuống 1/7, cùng một không gian lưu trữ có thể chứa được nhiều hơn nhiều lần, do đó tỷ lệ trúng thực tế tăng lên đáng kể.
Trong blog của Luo Fuli, các con số thực tế trực tuyến được cung cấp: tỷ lệ hit cache trên máy chủ trong các framework harness phổ biến trung bình đạt 93%, người dùng có tần suất cao và chu kỳ dài có thể đạt trên 95%.
Ý nghĩa của con số này: 95% yêu cầu "đọc lặp lại" hoàn toàn không cần sử dụng GPU, mà lấy trực tiếp từ bộ nhớ đệm. Đây là nền tảng vật lý cho mức chiết khấu 99%.
Đề án 4: Đưa “bộ nhớ đệm” vào SSD tích hợp trên GPU
Tỷ lệ命中 đã tăng lên, vấn đề tiếp theo là: những bộ nhớ đệm này được lưu ở đâu.
Bộ nhớ VRAM (HBM trên GPU) rất đắt và hạn chế — một máy H100 tám card chỉ có 640GB VRAM, nhưng KVCache mà MiMo cần lưu trữ có thể lên tới hàng chục TB. Do đó, cần phân tầng: dữ liệu mới nhất được lưu trong VRAM (L1), dữ liệu hơi cũ hơn được lưu trong bộ nhớ CPU (L2), và dữ liệu ít dùng được lưu trong bộ nhớ đệm phân tán (L3).
Cũng giống như việc quản lý tiền bạc của bạn. Tiền mặt trong ví là bộ nhớ hiển thị — dùng ngay lập tức nhưng dung lượng hạn chế. Số dư tài khoản ngân hàng là bộ nhớ CPU — mỗi lần rút mất 30 giây nhưng có thể lưu trữ rất nhiều. Tiền gửi kỳ hạn là bộ nhớ đệm phân tán L3 — mỗi lần rút mất 2 phút nhưng chi phí rẻ hơn nhiều.
Thông lệ trong ngành là xây dựng một cụm lưu trữ riêng cho L3, sử dụng máy chủ chuyên dụng và phòng máy riêng, trả tiền thuê hàng tháng.
Nhóm lưu trữ của Xiaomi có cách làm khác biệt. Họ tự phát triển một bộ nhớ đệm phân tán gọi là GCache, được triển khai trực tiếp trên SSD tích hợp sẵn trên máy GPU—chạy chung với các tác vụ huấn luyện và suy luận trên cùng một máy.
Người khác thuê một kho hàng riêng để lưu trữ lượng lớn dữ liệu; Xiaomi phát hiện ra gara máy GPU đang trống rỗng, nên trực tiếp lưu dữ liệu vào đó. Tiết kiệm được tiền thuê hàng tháng.
Chi phí lưu trữ bổ sung là 0.
Sức ảnh hưởng của việc này lớn hơn những gì trông thấy. Trong “bảng chi phí tính toán của các công ty AI” thông thường, chi phí lưu trữ là một khoản chi cố định — mô hình càng lớn, số lượng người dùng càng nhiều, hóa đơn lưu trữ càng dài. Cách tiếp cận của GCache đã loại bỏ hoàn toàn khoản chi này. Kết hợp với kích thước nhỏ của SWA và tỷ lệ hit 93-95%, thời gian tồn tại (TTL) của KVCache trên L3 đã được kéo dài từ vài phút lên vài giờ, thậm chí vài ngày — TTL càng dài, cửa sổ có thể hit cho context lịch sử càng rộng, tỷ lệ hit bộ nhớ đệm càng cao, mức chiết khấu 99% càng trở nên vững chắc.
Project 5: Route cached requests along the shortest path
Bộ nhớ đệm có thể lưu, tra cứu và rẻ tiền, bước cuối cùng là: làm thế nào để các yêu cầu đúng được định tuyến đến đúng máy chủ.
Xiaomi đã phát triển một hệ thống lập lịch riêng gọi là LLM-Router, thực hiện ba việc:
Một là lập lịch trình thân thiện. Các yêu cầu có tiền tố giống nhau được định tuyến đến cùng một máy chủ để tối đa hóa việc tái sử dụng bộ nhớ đệm.
Thứ hai là chia theo độ dài gói yêu cầu. Đưa các yêu cầu ngắn (0-64K), yêu cầu trung bình (64K-256K) và yêu cầu dài (256K-1M) vào các kênh xử lý khác nhau để tránh tình trạng yêu cầu ngắn bị yêu cầu dài làm chậm lại.
Thứ ba là tối ưu TTFT. Trong hàng đợi chờ xử lý suy luận, ưu tiên lập lịch các yêu cầu có khối lượng tính toán thực tế nhỏ (tức là các yêu cầu có tỷ lệ truy cập bộ nhớ đệm cao) – để tránh bị các yêu cầu tính toán nặng do đầu vào hoàn toàn mới gây ra làm tắc nghẽn.
Ví dụ, trong quy trình điều phối sân bay thông thường, tất cả hành khách bay đến cùng một điểm đến được tập trung tại cùng một phòng chờ, chia sẻ quy trình nhận hành lý — đây là lịch trình thân thiện. Những người mang hành lý xách tay và những người mang ba hành lý ký gửi đi qua hai lối kiểm tra an ninh khác nhau, người nhanh không bị người chậm kéo chậm lại — đây là phân nhóm theo độ dài. Khi lên máy bay, ưu tiên cho những người chỉ mang hành lý xách tay, vì họ lên máy bay nhanh, giúp máy bay cất cánh sớm hơn — đây là tối ưu hóa TTFT.
Chiến lược lập lịch này đã thực tế tăng tỷ lệ hit bộ nhớ đệm L2 lên 25%, tăng thông lượng đầu vào trên một máy chủ lên 30%, và giảm độ trễ P90 của các yêu cầu dài xuống 30%.
Cùng một GPU có thể phục vụ nhiều người dùng hơn. Nửa còn lại của lý do giảm giá nằm ở đây—sản lượng hiệu quả trên đơn vị tính toán cao hơn, chi phí trên mỗi người dùng thấp hơn.
Dự án 6: Làm cho mô hình "gõ phím" nhanh hơn
Năm việc trước đều tối ưu phía "đọc" — giảm chi phí để người dùng lặp lại việc đọc ngữ cảnh lịch sử xuống gần như 0. Việc thứ sáu là tối ưu phía "viết" — tức là quá trình mô hình tạo ra token tiếp theo.
Các mô hình truyền thống chỉ có thể tạo ra 1 token mỗi lần. MiMo hỗ trợ native 3 lớp MTP (Multi-Token Prediction) — dự đoán 3 token tiếp theo cùng một lúc, và nếu dự đoán đúng ở giữa, bỏ qua các phép tính trung gian.
Hãy ví dụ, việc gõ chữ truyền thống là gõ từng chữ một—nếu bạn muốn gõ "hôm nay trời đẹp", bạn phải nhấn 4 lần phím. MTP giống như có tính năng tự động hoàn thành đoán trước 1-2 chữ tiếp theo của bạn—nếu nó đoán đúng, bạn sẽ không cần phải nhấn thêm hai lần đó.
MTP của MiMo khi thử nghiệm trong kịch bản agentic: tăng tốc 2,3 lần cho 128 token đầu tiên, tăng tốc 1,5 lần cho 128-256 token.
Ý nghĩa của việc này là mức chiết khấu 99% chỉ áp dụng cho Input (Cache Hit), nhưng khi mô hình thực sự phục vụ người dùng, input và output xảy ra trong cùng một yêu cầu — nếu output không tiết kiệm được, thì tổng chi phí yêu cầu chỉ giảm được một nửa. MTP giúp giảm một nửa chi phí của output, từ đó hoàn thiện mô hình lợi nhuận giảm giá toàn diện.
Xâu sáu việc thành một chuỗi giảm chi phí:
Kiến trúc SWA → KVCache 1/7 → Hai hồ chứa thực sự giải phóng dung lượng → Một GPU có thể chứa hơn 5 lần số phiên đồng thời → Tỷ lệ hit bộ nhớ đệm tiền tố 93-95% → 95% yêu cầu gần như không cần tính toán → GCache giúp chi phí lưu trữ bằng không → Lập lịch ưu tiên xử lý các yêu cầu hit → MTP giúp tiết kiệm cả quá trình sinh → Thời gian GPU trên mỗi yêu cầu giảm một cấp độ → Chi phí đơn vị giảm hơn 95% → Giá giảm 99%, lợi nhuận gộp vẫn dương.
Một khâu nào đó bị thiếu, chuỗi này sẽ đứt tại một mắt xích. Giảm giá 99% không phải là con số tiếp thị, mà là hiệu ứng tích lũy sau khi kết hợp sáu trụ cột kỹ thuật và xác minh trực tuyến thực tế.
Nhìn lại những cách hiểu ban đầu của ngành, mỗi cách đều có một phần đúng. Hai năm qua, cuộc chiến giá giữa các công ty mô hình lớn của Trung Quốc là có thật; Xiaomi lợi nhuận giảm một nửa vẫn đầu tư mạnh vào AI là có thật; DeepSeek kéo mức định giá ngành xuống đáy cũng là có thật.
Nhưng lần này, Luo Fuli công khai bài viết kỹ thuật và chi tiết phân tích kỹ thuật, rõ ràng là nhằm phản bác những lời đồn về chiến tranh giá, để “vấn đề kỹ thuật trả về kỹ thuật, vấn đề tiếp thị trả về tiếp thị.”
Trong bài viết trên blog, cô viết rằng hiệu suất suy luận của mô hình MiMo-V2.5 không đến từ một điểm đột phá đơn lẻ ở bất kỳ giai đoạn nào, mà là kết quả của tối ưu hóa đồng bộ trên nhiều chiều. Hybrid SWA mang lại lợi ích cho cả prefill và decode, nhưng việc triển khai KVCache chưa được tối ưu hóa lại có thể làm tăng chi phí ở mọi giai đoạn. Nhằm đạt được mục tiêu này, đội ngũ MiMo đã tái cấu trúc hệ thống quản lý KVCache, bộ nhớ đệm phân cấp và cây bộ nhớ đệm tiền tố, giải quyết các vấn đề cốt lõi của SWA KVCache, tối ưu hóa chiến lược lập lịch và đường dẫn prefill/decode, đồng thời kiểm nghiệm qua các kịch bản thực tế trực tuyến, cuối cùng biến lợi thế hiệu suất lý thuyết thành hiện thực trong môi trường sản xuất. Đến lúc này, Hybrid SWA mới phát huy đầy đủ lợi thế kiến trúc về cả cường độ và hiệu suất trong suy luận văn bản dài. Kết hợp thêm các tối ưu hóa cho cấu hình MoE và suy luận đa phương tiện, hiệu suất dịch vụ suy luận trực tuyến đã được nâng cao đáng kể.
Đây là một chiến lược hệ thống trong kỹ thuật AI và cũng là phương pháp giảm chi phí đáng để ngành cùng tham khảo và học hỏi.
Không cần viết blog để chiến tranh giá, nhưng cần để hiện thực hóa kỹ thuật.