⚡ Tóm tắt nhanh
Moonshot (Kimi) vừa tung ra Kimi K3-256K: năng lực ngang bằng bản K3 đầy đủ, cắt luôn đầu vào video, và đóng trần cửa sổ ngữ cảnh ở 256K. Nghe như một "bản cắt giảm", nhưng sau khi cộng đồng dev ngồi tính xong một bài toán, kết luận lại đồng tình đến mức bất thường — đây mới là nước đi thực dụng. Lý do rất đơn giản: trong coding, nguồn chi phí lớn nhất chưa từng nằm ở input hay output. Nó nằm ở chính đống ngữ cảnh dài.
Với đại đa số tác vụ coding, khoản chi phí chủ đạo không phải input hay output, mà là ngữ cảnh. Kéo ngữ cảnh từ mức 5 vạn lên cấp triệu, lượng token tiêu thụ trung bình tăng thẳng một bậc độ lớn — và trừ khi cache cực rẻ, đây chính xác là "sát nhân token". Việc Kimi ngắt luôn ngữ cảnh dài ngay ở tầng cấu hình mô hình, thực chất là thay bạn tắt cái công tắc đắt tiền nhất.
💸 Vì sao ngữ cảnh dài lại đắt đến vậy
Một sự thật đã bị kiểm chứng đi kiểm chứng lại: trong tác vụ coding, miễn là giá cache chưa hạ, toàn bộ chi phí chủ đạo của một phiên nằm ở đống token ngữ cảnh. Cửa sổ càng nới rộng, mỗi lượt request bạn đều phải kéo theo một quả núi token càng lúc càng lớn.
Nhưng có một điều kiện kèm theo — chỉ khi cache hit đủ rẻ, ngữ cảnh dài mới "đắt có lý". Hiện tại trên thị trường thực sự hạ được giá cache xuống chỉ có DeepSeek và MiMo, nên cũng chỉ hai nhà này mới tính là "dùng được" ở cấp triệu token. Còn lại, cách tính tiền cho ngữ cảnh dài vô lý đến mức khác thường, và lựa chọn tỉnh táo bao giờ cũng là ngữ cảnh ngắn.
Tính nhẩm cho dễ hình dung: 1M ngữ cảnh trung bình rơi vào khoảng 500K, so với mốc 50K thì chi phí chênh nhau đúng 10 lần.
Quen thu gom quanh mốc 100K, trung bình ngữ cảnh còn khoảng 50K; quen đẩy lên 990K rồi mới để hệ thống tự nén, trung bình sẽ là 500K. Cùng là "mô hình ngữ cảnh dài", cái sau đắt hơn cái trước 10 lần. Kể cả chỉ trong đúng phạm vi 256K này, một phiên kéo đến 200K, chi phí đã bằng 4 lần mốc 50K.
Tất cả những điều trên chỉ không đúng khi giá cache hit thật sự rẻ. Đáng tiếc đa số mô hình mainstream giá cache cũng chẳng thấp, nên chi phí chủ đạo bao giờ cũng nằm ở ngữ cảnh, và dài ngữ cảnh gần như chắc chắn đẩy giá lên. Chủ động giới hạn ngữ cảnh, để harness (lớp phần mềm Agent) tự động kiểm soát kích thước, là cách giảm chi phí rõ rệt nhất.
🧠 Nhiều người chẳng có khái niệm "quản lý ngữ cảnh"
Vấn đề sâu hơn nằm ở thói quen. Rất nhiều người không hề có ý thức "chủ động quản lý ngữ cảnh", hoàn toàn dựa vào cơ chế tự nén của harness (lớp Agent) — và thường chọn mô hình đắt nhất, một phiên chat kéo đến hết, để fill đầy 1M rồi mới trigger nén.
Dùng kiểu đó thì "vài lượt đã cháy hạn mức" gần như chắc chắn. Cảnh bị chê "ít dùng, vài lượt đã hết" trên group Feishu của Kimi, rất có thể là hệ quả trực tiếp của chính kiểu dùng này. Trong group, thông báo chính thức có nhắc "90% tình huống sử dụng không vượt 256K ngữ cảnh" — ngược lại xem, vẫn còn khoảng 10% người lấy K3 đốt ngữ cảnh dài.
Hay hơn nữa là câu trong tài liệu K3: "nên mở phiên mới rồi mới chuyển sang K3". Vốn là một lời nhắc tử tế, nhưng rất nhiều người chẳng buồn đọc: họ quẳng thẳng một phiên đã chất đến 200K+ sang K3, rồi đẩy tới giới hạn 1M rồi mới để nó tự nén — kiểu này, gói nào cũng tụt hạn mức nhanh. Câu nhắc đó thực chất là Kimi đang đắp đập ngăn khủng hoảng truyền thông từ trước.
Trước đó, GPT 5.6 Sol trong Codex đã đưa Context Window mặc định từ 272K lên 372K, bị phàn nàn ngay "token không bền". Tibo còn phải đăng bài giải thích Auto Compact giữa hai mức thực ra không khác nhau nhiều, nhưng cuối cùng vẫn không trụ, âm thầm kéo mức mặc định về lại. Đẩy ngữ cảnh mặc định lên max, là một thiết kế tốn công mà chẳng ai cảm ơn.
🔍 "Cache hit của tôi 98%" thực ra là tín hiệu đỏ
Trên cộng đồng thỉnh thoảng có người khoe tỷ lệ cache hit lên tới 98%, 99%, rồi mặc định mình đang dùng rất tiết kiệm. Trực giác này rất có thể đi ngược chiều.
Ở tầng harness, tỷ lệ cache hit giữa các bên chênh nhau không đáng kể. Tỷ lệ hit cao bất thường, thường chỉ ra rằng bạn đang dùng ngữ cảnh dài rất nặng — mà ngữ cảnh dài, lại đúng là phần đắt nhất. Nên "tỷ lệ hit cao" đặt sang một góc nhìn khác, tương đương với "tôi đang dùng nhiều nhất ở đúng chỗ đắt nhất".
Nói cho cùng, không phải tình huống nào cũng cần ngữ cảnh dài. Biết chủ động kiểm soát ngữ cảnh, thì những mô hình đắt tiền mới tạm dùng được; nếu bạn thuộc kiểu "một phiên kéo đến hết, đợi ngữ cảnh đầy 1M mới tự nén", thì ngoài DeepSeek và MiMo ra, tất cả mô hình còn lại đều có thể vượt khỏi túi tiền của bạn.
🏷️ Bản 256K có rẻ hơn không? Khả năng cao là không
Nhiều người đang đoán xem ID mô hình mới này có được tính giá rẻ hơn không. Rất có thể là không — vẫn đúng mức giá cũ. Hệ số giá mà bên phát hành nói tới, chủ yếu đến từ chi phí input của ngữ cảnh dài và cache hit, chứ không phải do mô hình tự giảm giá.
Theo trung bình của cả hai bên, mức chênh sẽ rơi vào khoảng 3 lần. Chỉ là đại đa số phiên không ai kéo tới tận 1M, nên phía phát hành đưa một con số bảo thủ là "ước tính 2 lần".
Trong giới hạn 256K, độ dài ngữ cảnh trung bình khoảng 150K; trong giới hạn 1M, trung bình vào khoảng 600K — chỉ riêng chi phí cache đã mở ra 4 lần. Một prompt trung bình khoảng 8 lượt tin nhắn, mỗi lượt giả sử input 4K, output 600 token, chi phí input/output thực tế chiếm tỷ trọng không đáng kể.
Nên cải thiện tỷ lệ giá trị/chi phí đến từ chính hành động "cắt luôn ngữ cảnh dài ở tầng cấu hình mô hình", chứ không phải từ việc giảm giá.
Cũng vì thế, Kimi mới tách ra hẳn một phiên bản riêng, ngắt luôn ngữ cảnh dài ở tầng cấu hình, đó mới thực sự nâng được giá trị trên mỗi đồng của tác vụ người dùng.
📊 Thực tế: tiêu thụ chỉ bằng khoảng một phần ba bản đầy đủ
Có vài dòng thực đo và trivia đáng ghi lại trong phần bình luận:
- Trivia: Codex và Cursor đều nối với mô hình 1M, nhưng ngữ cảnh thực tế dùng được chỉ nằm ở mức 2–3 trăm K.
- Bản cắt lỗ bao nhiêu: có người thử trên cùng tác vụ, bản 256K này tiêu tốn hạn mức bằng khoảng 1/3 bản đầy đủ — vì chính ngữ cảnh lớn cũng làm tăng token tiêu thụ; theo cùng tiêu chuẩn hoàn thành, mức tiêu thụ cho cùng tác vụ bằng khoảng 40% trước đó.
- Tác vụ dài: một task dài chạy trong kimi cli khoảng một–hai tiếng, hạn mức tuần tiêu thụ 5,53%; trước đó thường ở mức 10% trở lên mỗi giờ.
- Có ảnh hưởng chất lượng không: có — sau review cần sửa lại chút; bản đầy đủ gần như không cần sửa.
- Video và 1M ngốn compute: cắt luôn đầu vào video và ngữ cảnh 1M, nhu cầu compute giảm tối thiểu một nửa.
Với người dùng gói 199, hạn mức vốn đã căng, dùng bản cắt giảm thì thở được; và quan trọng — bản K3 MAX 1M vẫn dùng được bình thường, không như ChatGPT, muốn dùng 1M thì bắt buộc phải bật tính tiền qua API.
Tức là ngoài một tầng giá rẻ, họ lại thêm cho bạn một lựa chọn nữa (tiện thể giảm luôn chi phí tính toán cho chính họ) — chỉ có lợi, chẳng có hại.
🎯 Tóm lại
Với đại đa số người, ngữ cảnh dài chính là một sát nhân token — ngoài DeepSeek hay MiMo kiểu mô hình cache cực rẻ, phần còn lại đều đang rút ruột số dư của bạn trong im lặng.
Kimi K3-256K dùng một giới hạn ở tầng cấu hình, thay người dùng giữ đúng tư thế chi tiêu. Với một đội ngũ mà compute luôn căng, nước đi này coi như đàng hoàng. Cái đắt tiền chưa bao giờ là mô hình — mà là cái "vô hạn" mà bạn cứ tưởng mình dùng nổi.
Bài viết tổng hợp từ thảo luận và thực đo công khai của cộng đồng dev quanh đợt ra mắt Kimi K3-256K; mọi con số và quan điểm đều rút từ phản hồi cộng đồng, chỉ mang tính tham khảo; chi tiết tính phí cụ thể vui lòng lấy thông báo chính thức của Moonshot làm chuẩn.