Xiaomi MiMo giảm giá 99% không phải là chiến dịch marketing! Luo Fulie phản bác những người dự đoán tiêu cực bằng bài đăng trên X

null

Ngữ | Xiàng Xiānzhì

Luo Fulili đã đăng một dòng X, muốn chấm dứt làn sóng giảm giá của Xiaomi MiMo.

Ngày 26 tháng 5, tài khoản chính thức của Xiaomi MiMo trên X đã phát ra một thông báo: API của dòng MiMo-V2.5 sẽ giảm giá vĩnh viễn, mức giảm cao nhất 99%. Tất cả các gói giá dựa trên độ dài nội dung đều được định giá cố định, gói Token nâng cấp từ 5-8 lần.

Thông báo này đã gây xôn xao trong cộng đồng AI trong suốt một tuần. Phản ứng của giới ngành chia thành vài phe. Phe lớn nhất cho rằng đây là "một đợt chiến tranh giá nữa" — trong hai năm qua từ Zhipu, DeepSeek, ByteDoubao đến Alibaba Tongyi, các mô hình lớn nội địa đều giảm giá, ai cũng phải cạnh tranh.

Phe khác thì bi quan hơn: Xiaomi vừa công bố lợi nhuận năm nay bị cắt làm đôi, giờ lại đổ 600 tỷ vào AI, API giảm tới 90% — rõ ràng là "lỗ để giành thị trường". Cũng có ý kiến cho rằng đây là ảnh hưởng tiếp tục của DeepSeek — phía sau đã kéo giá cả toàn ngành xuống sàn, ai không theo kịp sẽ bị loại khỏi cuộc chơi.

Vì vậy, với vai trò người phụ trách MiMo, Luo Fulili tối qua đã đăng một bài blog kỹ thuật dài 5000 chữ, công khai các khoản chi phí kỹ thuật của việc giảm giá cho mọi người.

“Xem này, đây là năng lực kỹ thuật thực sự, không phải là chiêu marketing.”

Để hiểu rõ Luo Fulili đang nói gì, trước tiên cần biết rõ mức giảm 99% này thực chất là gì.

Nó không phải giảm giá toàn bộ mô hình. Giảm 99% chỉ dành riêng cho một loại 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 đối thoại dài". Các đầu vào mới (No Cache Hit) giảm ít hơn nhiều, còn phần đầu ra của mô hình (Output) giảm ít nhất.

Nếu bạn xem mô hình như một quán cà phê, chuyện này dễ hiểu.

Bạn gọi một ly latte nửa đường, quán cà phê có hai cách làm: mỗi lần xay hạt, đổ đường si rô, pha sữa từ đầu, nguyên liệu và công sức đều tính một lần; nhưng mô hình biết rằng tuần này bạn mỗi ngày đều uống cùng một ly latte nửa đường, thế là làm sẵn một bình lớn bỏ vào tủ lạnh, lần sau chỉ cần múc ra một ly. MiMo lần này làm theo cách thứ hai — chuyển phần người dùng lặp lại đọc từ "tính toán mới" thành "lấy ra ngay", nên phần này chi phí thực tế gần như bằng 0, tự nhiên có thể giảm 99%.

Để làm được "lấy ra ngay", bài blog kỹ thuật đã đề cập đến sáu bước kỹ thuật, mỗi bước đều không thể thiếu. Dưới đây lần lượt xem từng bước.

Bước 1: Nén "trí nhớ" của mô hình xuống còn 1/7

Khi trò chuyện với bạn, mô hình phải tính toán một "trạng thái trung gian" cho từng token, rồi lưu lại để dùng cho bước tiếp theo. Thứ này gọi là KVCache — có thể hiểu là "ghi chú trí nhớ ngắn hạn" của mô hình. Mỗi câu nói, mô hình sẽ ghi lại tóm tắt câu đó trong sổ ghi chú, lần sau mở ra đọc mà không cần nghe lại toàn bộ nội dung đã nói.

Các mô hình truyền thống đều làm "Chú ý toàn phần" ở mỗi lớp — nghĩa là mỗi token đều phải xem toàn bộ đoạn hội thoại gồm tất cả token, sổ ghi chú ngày càng dày. 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 "quản lý hồ sơ" mới xem toàn bộ.

Kết quả là kích thước KVCache đã giảm xuống còn 1/7 so với "Chú ý toàn phần", lượng tính toán cũng giảm tương tự.

Đây là nền tảng giảm chi phí đầu tiên. Ví dụ, trước đây mỗi nhân viên trong công ty đều phải nhớ tất cả các ghi chú cuộc họp, kết quả là não không đủ bộ nhớ, hiệu quả thấp. Quy định mới giảm tải cho 60 nhân viên, chỉ còn 10 người quản lý toàn bộ lịch sử — năng lực ghi nhớ của công ty không giảm, mà hiệu suất tăng gấp 7 lần.

Bước 2: Đảm bảo không gian SWA tiết kiệm thực sự có thể dùng

Việc nén sổ ghi chú xuống còn 1/7 là bước đầu, nhưng để biến "1/7 lý thuyết" thành "thực tế 1/7" còn có một thử thách.

Hệ thống KVCache truyền thống phân bổ bộ nhớ cho tất cả các lớp theo "dung lượng tối đa có thể dùng". Nghĩa là: dù 60 lớp SWA chỉ cần nhỏ gọn, hệ thống vẫn cấp phát như thể tất cả đều dùng "bộ hồ sơ lớn" — phần không dùng của SWA bị bỏ phí, không tiết kiệm được gì.

Đội ngũ Luo Fulili đã chia KVCache thành hai bộ nhớ riêng biệt. 10 lớp "Chú ý toàn phần" dùng "bộ lớn" theo độ dài toàn bộ; 60 lớp SWA dùng "bộ nhỏ" chỉ 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 "tủ hồ sơ chứa tài liệu 100 năm" — nhưng thực tế 60 nhân viên chỉ cần "tủ nhỏ chứa tài liệu một tuần". Các tủ lớn đó phần lớn là trống. Phương pháp mới là phân chia theo nhu cầu thực tế. Kết quả là văn phòng có thể chứa hơn 5 lần số nhân viên cùng lúc làm việc — cùng một GPU có thể phục vụ gấp 5 lần người dùng đồng thời.

Bước này tưởng đơn giản, nhưng nếu thiếu sẽ khiến ưu thế của kiến trúc SWA bị mất hết.

Bước 3: Đảm bảo "người dùng lặp lại đọc" thực sự trúng cache

Nén sổ xuống còn 1/7 + không gian thực dùng được, bước tiếp theo là giải quyết vấn đề cũ: tỷ lệ trúng cache của phần đệm đầu.

Nhiều người dùng có các cuộc hội thoại bắt đầu giống nhau — cùng một system prompt, cùng một thư viện mã, cùng một tài liệu dài. Hệ thống sẽ tính toán kết quả này rồi lưu lại, lần sau gặp lại sẽ dùng lại luôn. Cơ chế này gọi là cache tiền tố.

Nhưng trong chế độ SWA có một vấn đề: hai yêu cầu token giống nhau, chưa chắc KV còn giữ. Có thể phần tiền tố đã tính rồi, nhưng phần ngoài cửa sổ SWA đã bị loại bỏ từ lâu. Nếu hệ thống cứ theo quy tắc cũ "token giống nhau là trúng cache", sẽ đọc phải dữ liệu không hợp lệ hoặc đã bị ghi đè, làm mô hình hoạt động giảm sút rõ rệt.

Luo Fulili đã nâng cấp quy tắc thành "đúng theo độ dài an toàn của cửa sổ" — chỉ cam kết "phần bạn có thể lấy đủ" mà thôi.

Ví dụ, thư viện có 1 triệu cuốn sách, bạn muốn mượn bộ "Tam Thể" gồm 3 cuốn. Quy tắc cũ sẽ nói "các cuốn này có", nhưng bạn đến thì chỉ còn bìa và phần đầu của cuốn thứ nhất, hai phần còn lại đã bị mượn mất. "Trúng cache giả" như vậy khiến bạn phải quay lại mượn lần nữa. Quy tắc mới chỉ cam kết bạn có thể mượn đủ phần đó — trước tiên cho bạn mượn cuốn đầu, rồi sẽ đưa các cuốn còn lại sau.

Nghe có vẻ nghiêm ngặt hơn, tỷ lệ trúng giảm, nhưng thực tế lại ngược lại: vì SWA giúp KVCache giảm còn 1/7, cùng dung lượng lưu trữ, có thể chứa nhiều nội dung hơn, tỷ lệ trúng thực tế tăng đáng kể.

Trong blog của Luo Fulili có số liệu thực tế: trong các hệ thống phổ biến, tỷ lệ trúng cache của server trung bình đạt 93%, các người dùng thường xuyên dài hạn có thể lên tới trên 95%.

Ý nghĩa của con số này là: 95% các yêu cầu "đọc lặp lại" không cần tính toán GPU, chỉ cần lấy từ cache. Đây chính là nền tảng vật lý của giảm giá 99%.

Bước 4: Đưa "cache" vào SSD tích hợp của GPU

Tỷ lệ trúng cao hơn, vấn đề tiếp theo là: cache đặt ở đâu.

Bộ nhớ GPU (HBM) rất đắt và hạn chế — một máy H100 tám card chỉ có 640GB bộ nhớ, nhưng KVCache của MiMo có thể lên tới hàng chục TB. Vì vậy cần phân tầng: dữ liệu dùng gần nhất để trong bộ nhớ GPU (L1), dữ liệu cũ hơn để trong RAM CPU (L2), dữ liệu lạnh hơn thì lưu vào cache phân tán (L3).

Thông thường, các công ty xây dựng hệ thống lưu trữ riêng cho L3, dùng máy chủ riêng, phòng máy riêng, trả tiền thuê hàng tháng.

Đội lưu trữ của Xiaomi làm khác: họ tự phát triển hệ thống GCache, phân phối cache trên SSD tích hợp sẵn trong GPU — cùng chia sẻ với các tác vụ huấn luyện, suy luận trên cùng một máy.

Nói đơn giản: người khác thuê kho chứa dữ liệu lớn, còn Xiaomi phát hiện ra rằng trong máy GPU có kho chứa trống, họ bỏ dữ liệu vào đó luôn. Tiết kiệm tiền thuê.

Trong bài blog, họ viết: "Chi phí lưu trữ bổ sung là 0."

Điều này cực kỳ có sức ảnh hưởng. Trong các tính toán của ngành AI, chi phí lưu trữ là khoản cố định — mô hình càng lớn, người dùng càng nhiều, hóa đơn lưu trữ càng dài. GCache cắt bỏ khoản này hoàn toàn. Kết hợp với SWA nhỏ gọn + tỷ lệ trúng 93-95%, thời gian sống của KVCache trong L3 (TTL) từ vài phút kéo dài thành vài giờ hoặc vài ngày — TTL càng dài, khả năng trúng nội dung lịch sử càng cao, giảm giá 99% càng vững chắc.

Bước 5: Đưa yêu cầu trúng cache đi đường ngắn nhất

Cache đã có, có thể tra cứu, lại rẻ, bước cuối cùng là: làm sao để yêu cầu đúng được định tuyến tới đúng máy.

Xiaomi đã phát triển hệ thống điều phối riêng gọi là LLM-Router, làm ba việc:

Thứ nhất: Phân phối theo tính liên kết. Các yêu cầu có cùng tiền tố sẽ được chuyển tới cùng một máy, tối đa hóa khả năng dùng lại cache.

Thứ hai: Phân nhóm theo độ dài. Yêu cầu ngắn (0-64K), trung bình (64K-256K), dài (256K-1M) sẽ được xử lý qua các kênh riêng, tránh yêu cầu ngắn bị chậm bởi yêu cầu dài.

Thứ ba: Tối ưu TTFT. Trong hàng đợi chờ xử lý, ưu tiên các yêu cầu có lượng tính toán nhỏ (tức là nhiều lần trúng cache) — tránh bị chặn bởi các yêu cầu "đầu vào mới" cần tính lại toàn bộ.

Ví dụ, trong sân bay, hành khách đi cùng chuyến sẽ tập trung ở cùng phòng chờ, chia sẻ quy trình lấy hành lý — đó là phân phối theo tính liên kết. Người mang hành lý xách tay hoặc ký gửi lớn sẽ đi qua các cổng kiểm tra riêng, nhanh hơn, đó là phân nhóm theo độ dài. Khi lên máy bay, ưu tiên cho người chỉ mang hành lý xách tay, giúp chuyến bay cất cánh sớm — đó là tối ưu TTFT.

Chiến lược này thực tế đã nâng tỷ lệ trúng cache L2 lên 25%, tăng throughput của mỗi máy lên 30%, giảm P90 độ trễ của yêu cầu dài 30%.

Nói cách khác: cùng một GPU có thể phục vụ nhiều người dùng hơn. Một phần của giảm giá này chính là ở đây — hiệu quả sản xuất của mỗi đơn vị tính toán cao hơn, chi phí cho mỗi người dùng thấp hơn.

Bước 6: Làm cho quá trình "đánh máy" của mô hình nhanh hơn

Năm bước trên đều tối ưu phần "đọc" — giảm chi phí người dùng lặp lại đọc lịch sử về gần như bằng 0. Bước thứ sáu là tối ưu phần "viết" — tức là quá trình mô hình sinh token tiếp theo.

Truyền thống, mô hình chỉ sinh ra từng token một. MiMo hỗ trợ gốc 3 lớp MTP (Multi-Token Prediction) — dự đoán cùng lúc 3 token tiếp theo, nếu đoán đúng, bỏ qua bước tính trung gian.

Ví dụ, việc đánh máy truyền thống là gõ từng chữ một — muốn viết "Hôm nay trời đẹp", phải nhấn 4 lần. MTP như có tính năng tự động hoàn thành, đoán xem 1-2 chữ tiếp theo là gì — nếu đoán đúng, bạn không cần nhấn nữa.

Trong thử nghiệm thực tế, MTP của MiMo trong các kịch bản agentic: decode 128 token đầu tiên nhanh gấp 2.3 lần, từ 128-256 token nhanh gấp 1.5 lần.

Ý nghĩa của điều này là, giảm giá 99% chủ yếu tập trung vào Input (Cache Hit), nhưng khi phục vụ người dùng, input và output đều nằm trong cùng một yêu cầu — nếu output không giảm, tổng chi phí chỉ giảm một nửa. MTP giúp giảm luôn phần output, vòng lặp giảm giá hoàn chỉnh mới hình thành lợi nhuận.

Tổng hợp sáu bước thành chuỗi giảm chi phí:

Kiến trúc SWA → KVCache còn 1/7 → giải phóng thực sự dung lượng bằng hai bộ nhớ → cùng một GPU phục vụ 5+ lần số người dùng → tỷ lệ trúng cache 93-95% → 95% yêu cầu gần như không cần tính → GCache giảm chi phí lưu trữ về 0 → điều phối ưu tiên yêu cầu trúng cache → MTP giảm thời gian sinh token → thời gian GPU cho mỗi yêu cầu giảm một cấp độ — chi phí đơn vị giảm hơn 95% → giảm giá 99%, lợi nhuận vẫn dương.

Bất kỳ bước nào thiếu, chuỗi này sẽ đứt quãng ở một điểm. Giảm giá 99% không phải là marketing, mà là kết quả của sáu trụ cột kỹ thuật cộng hưởng + xác thực thực tế trên hệ thống.

Nhìn lại các phân tích ban đầu của giới ngành, mỗi kiểu đều có phần đúng. Trong hai năm qua, chiến tranh giá của các công ty mô hình lớn Trung Quốc là có thật; Xiaomi cắt lợi nhuận một nửa rồi vẫn đổ tiền vào AI là có thật; DeepSeek kéo giá cả toàn ngành xuống sàn cũng là có thật.

Nhưng bài blog kỹ thuật công khai này, cùng với các phân tích chi tiết, rõ ràng là muốn phản bác các luận điểm về chiến tranh giá, để "vấn đề kỹ thuật thuộc về kỹ thuật, marketing thuộc về marketing."

Trong blog, cô viết rằng, các mô hình MiMo-V2.5 không đạt được hiệu quả suy luận cao chỉ từ một bước đột phá đơn lẻ, mà là kết quả của tối ưu đa chiều phối hợp. Hybrid SWA giúp prefill và decode cùng có lợi, nhưng nếu KVCache chưa tối ưu toàn diện, sẽ làm tăng chi phí ở nhiều khâu. Nhóm của Luo Fulili đã tái cấu trúc hệ thống quản lý KVCache, cache phân tầng, cây cache tiền tố, giải quyết các vấn đề cốt lõi của KVCache trong SWA, tối ưu chiến lược điều phối và các liên kết Pre-fill / Decode, đã kiểm nghiệm thực tế trong các tình huống sản xuất, cuối cùng đã biến lợi thế lý thuyết thành hiệu quả thực tế. Đến lúc này, Hybrid SWA mới phát huy được ưu điểm trong xử lý các đoạn văn dài vừa mạnh mẽ vừa hiệu quả. Kết hợp cấu hình MoE và các tối ưu đa dạng cho đa mô hình, hiệu suất dịch vụ suy luận trực tuyến được nâng cao đáng kể.

Đây là một phương pháp hệ thống trong kỹ thuật AI, cũng là một cách giảm chi phí đáng để ngành học tham khảo, học hỏi.

Chiến tranh giá không cần viết blog, chỉ cần thực thi kỹ thuật mới là đủ.