Kimi API tính phí theo mức dùng, không có gói đăng ký. Khi so giá mà chỉ nhìn "mỗi triệu token bao nhiêu tiền" thì rất dễ chọn sai: thứ thực sự quyết định hóa đơn là mẫu mô hình, độ dài ngữ cảnh, tỷ lệ trúng bộ nhớ đệm và độ dài đầu ra. Dòng K2 cung cấp ngữ cảnh 262.144 token, K3 lên tới 1.048.576; năng lực ngữ cảnh dài mạnh cũng đồng nghĩa phía đầu vào dễ tích lũy chi phí hơn.

Bài viết bóc tách cấu trúc tính phí của dòng K2, nguồn gốc chi phí ngữ cảnh dài, phương pháp ước tính có thể tái lập và thứ tự giảm chi phí, không ghi cứng đơn giá. Giá cụ thể căn cứ tài liệu chính thức và bảng giá mô hình trên trang.

Lưu ý: Moonshot và Kimi là nhãn hiệu của chủ sở hữu tương ứng. Mẫu mô hình, độ dài ngữ cảnh và quy tắc tính phí có thể điều chỉnh; bài viết lấy tình hình phổ biến tính đến tháng 10 năm 2026 làm ví dụ, vui lòng kiểm tra lại trang chính thức trước khi mua.

1. Dòng K2 phân vai thế nào

Mẫu mô hình Định vị Ngữ cảnh Tác vụ phù hợp Điểm cần chú ý về chi phí
kimi-k2.6 Đa dụng 262.144 Trò chuyện, trích xuất, chăm sóc khách hàng, xử lý tài liệu Tỷ lệ trúng bộ nhớ đệm
kimi-k2.7-code Mã nguồn 262.144 Sinh mã, hỏi đáp kho mã, Agent Đầu vào dài, nhiều kết quả công cụ
kimi-k2.7-code-highspeed Bản mã nguồn tốc độ cao 262.144 Hoàn thành độ trễ thấp, lập trình tương tác Cân bằng đơn giá và thông lượng
kimi-k3 Thế hệ mới 1.048.576 Tài liệu siêu dài, tác vụ nhiều bước phức tạp Ngữ cảnh dài và ghi bộ nhớ đệm

Các mẫu sẽ được cập nhật; dòng K2 có thể bổ sung phiên bản mới về sau. Khi mua, căn cứ danh sách mô hình chính thức và bảng giá mô hình trên trang, đừng coi tên mẫu trong bài là cam kết vĩnh viễn.

Tác vụ đa dụng không nhất thiết mặc định dùng ngữ cảnh lớn nhất. Nhét toàn bộ tư liệu vào ngữ cảnh 1M sẽ khiến chi phí đầu vào tích lũy nhanh theo số lượt; trước hết dùng truy xuất để thu hẹp phạm vi, rồi cho mô hình đọc đoạn chính thường tiết kiệm hơn. Tác vụ mã nguồn thì ngược lại: cấu trúc kho mã và kết quả công cụ thường phải giữ lại, trọng tâm là tiền tố ổn định và tăng tỷ lệ trúng bộ nhớ đệm.

2. Hóa đơn gồm ba phần

Dòng K2 tính phí theo ba khoản: đầu vào trúng bộ nhớ đệm, đầu vào trượt bộ nhớ đệm và đầu ra. K3 còn tính riêng phí ghi bộ nhớ đệm theo hai mức TTL 5 phút và 1 giờ, nên không thể lấy một đơn giá trung bình nhân tổng token.

Khoản tính phí Khi nào phát sinh Ảnh hưởng chi phí Cách kiểm soát
Đầu vào trượt bộ nhớ đệm Prompt, tài liệu, kết quả công cụ xuất hiện lần đầu Tăng tuyến tính theo ngữ cảnh Truy xuất, tóm tắt, cắt tỉa lịch sử
Đầu vào trúng bộ nhớ đệm System prompt lặp lại, tiền tố cố định Thường thấp hơn rõ rệt so với trượt Tiền tố ổn định, thứ tự công cụ cố định
Token đầu ra Nội dung và suy nghĩ mô hình sinh ra Đầu ra dài làm hóa đơn phình Giới hạn max_completion_tokens
Ghi bộ nhớ đệm (K3) Ghi tiền tố vào bộ nhớ đệm Tính theo mức TTL Chỉ đệm nội dung ổn định, dùng lặp lại

Tách một yêu cầu ra, công thức chi phí là:

Chi phí một yêu cầu =
  Token đầu vào trượt đệm × đơn giá trượt
+ Token đầu vào trúng đệm × đơn giá trúng
+ Token đầu ra × đơn giá đầu ra

K3 còn phải cộng khoản ghi bộ nhớ đệm. Trường usage trong phản hồi cung cấp prompt_tokens, completion_tokens và prompt_tokens_details; trong đó trúng bộ nhớ đệm và ghi bộ nhớ đệm đều nằm trong prompt_tokens, phần không đệm lấy tổng trừ hai khoản này.

3. Vì sao ngữ cảnh dài dễ đắt

Tình huống Cấu trúc token điển hình Chi phí chính Hướng tối ưu
Hỏi đáp tài liệu dài Đầu vào lớn, đầu ra trung bình Tài liệu truyền lại nhiều lần Truy xuất kèm bộ nhớ đệm
Agent kho mã Đầu vào và đầu ra đều lớn Kết quả công cụ và lịch sử Tóm tắt, cắt tỉa, bộ nhớ đệm
Chăm sóc khách hàng nhiều lượt Đầu vào tích lũy theo số lượt Tin nhắn lịch sử lặp lại Tóm tắt cuốn chiếu
Trích xuất hàng loạt Đầu vào trung bình, đầu ra ngắn Tài liệu bị đọc lặp Xử lý hàng loạt kèm mô hình nhỏ

Khác biệt thường đến từ năm điểm:

  1. Đầu vào tích lũy theo số lượt: mỗi lượt lại gửi lại toàn văn, hóa đơn gần như tăng gấp đôi theo số lượt.
  2. Tỷ lệ trúng bộ nhớ đệm: tiền tố cố định dùng lại được; dấu thời gian, ID ngẫu nhiên, sắp xếp động mỗi lần đều làm đệm mất hiệu lực.
  3. Kết quả công cụ: một lần tìm kiếm hoặc chạy mã trả về cả đoạn nhật ký, lượt sau lại mang nguyên văn theo, chi phí cộng dồn.
  4. Độ dài đầu ra: yêu cầu "phân tích chi tiết" mở dễ sinh đầu ra dài, mà đầu ra thường đắt hơn đầu vào trúng bộ nhớ đệm.
  5. Ghép sai mẫu mô hình: phân loại đơn giản dùng mô hình lớn, hoặc tác vụ phức tạp dùng mẫu không phù hợp rồi thử lại nhiều lần, đều làm chi phí phình ra.

4. Thực hiện một phép đo có thể tái lập

  1. Chọn 20–50 tác vụ thật, bao phủ ba mức đơn giản, trung bình, phức tạp; ghi rõ tiêu chí nghiệm thu.
  2. Dùng giao diện ước tính token để định lượng đầu vào trước, đừng đoán theo số chữ.
  3. Cùng một lô tác vụ chạy lần lượt kimi-k2.6 và mẫu mã nguồn, ghi chất lượng, độ trễ và số lần làm lại.
  4. Đọc đầu vào, đầu ra, trúng bộ nhớ đệm và ghi bộ nhớ đệm từ usage trong phản hồi.
  5. So sánh theo chi phí "mỗi tác vụ đạt chuẩn hoàn thành", không phải giá niêm yết mỗi triệu token.
  6. Tính cả thử lại, yêu cầu thất bại và ghi bộ nhớ đệm vào chi phí một tác vụ.
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "Trích xuất hợp đồng này thành JSON: ……"}],
    max_completion_tokens=1024,
)

u = resp.usage
print("Đầu vào", u.prompt_tokens, "Đầu ra", u.completion_tokens)
print("Chi tiết bộ nhớ đệm", getattr(u, "prompt_tokens_details", None))

Gọi truyền phát cần thêm stream_options={"include_usage": True}; mức dùng đầy đủ chỉ trả về ở khối cuối. Số tiền phải nhân với đơn giá thực tế trong hợp đồng hoặc trang giá, đừng dùng lại ảnh chụp từ vài tháng trước.

5. Thứ tự giảm chi phí

  1. Làm bộ nhớ đệm trước: cố định system prompt, định nghĩa công cụ và tiền tố cơ sở tri thức, dùng cached_tokens xác nhận có trúng thật không.
  2. Giảm đầu vào: truy xuất chỉ trả về đoạn liên quan, tóm tắt tin nhắn lịch sử, đừng nhét cả kho vào ngữ cảnh.
  3. Giới hạn đầu ra: đặt max_completion_tokens hợp lý, yêu cầu JSON hoặc trường cố định, giảm lời thừa.
  4. Định tuyến mẫu mô hình: tác vụ đa dụng dùng kimi-k2.6, tác vụ mã nguồn dùng bản K2.7 code, tư liệu siêu dài mới cân nhắc K3.
  5. Yêu cầu dài chuyển sang truyền phát: truyền phát không đổi đơn giá trực tiếp, nhưng giảm thử lại do quá thời gian và ngắt kết nối.
  6. Giám sát và cảnh báo: xem mức dùng theo dự án, mẫu mô hình, tình huống; đặt hạn mức ngân sách, đánh giá lại bảng xếp hạng tiêu thụ hàng tuần.

Đừng đảo thứ tự. Làm bộ nhớ đệm và quản trị đầu vào trước, rồi mới cân nhắc đổi sang mẫu rẻ hơn; nếu không chỉ là làm cho câu trả lời sai rẻ hơn.

6. Quản lý ngân sách và hóa đơn thế nào

  • Một dự án một khóa, đặt ngân sách ngày theo dự án, tránh một nghiệp vụ dùng hết toàn bộ hạn mức.
  • Đối chiếu hàng tháng theo ba chiều "dự án, mẫu mô hình, tình huống", tìm các lần gọi tăng nhanh nhất.
  • Ghi riêng tỷ lệ trúng bộ nhớ đệm, số lần thử lại và độ dài đầu ra trung bình, nếu không không chứng minh được hiệu quả tối ưu.
  • Đội cần thanh toán bằng nhân dân tệ và hóa đơn có thể dùng cổng AI trong nước để thống nhất hóa đơn đa mô hình; giá và quy tắc hóa đơn cụ thể căn cứ theo bảng giá mô hình.

Câu hỏi thường gặp

K2 và K3 cái nào kinh tế hơn?

Tùy tác vụ. Dòng K2 có ngữ cảnh 262.144, bao phủ đa số tình huống tài liệu và mã nguồn; K3 có ngữ cảnh lớn hơn, phù hợp tư liệu siêu dài. Hãy so sánh theo tổng chi phí "hoàn thành một tác vụ đạt chuẩn", đừng chỉ nhìn đơn giá.

Bộ nhớ đệm tiết kiệm bao nhiêu?

Tùy tỷ lệ dùng lại tiền tố và tỷ lệ trúng. Đầu vào trúng bộ nhớ đệm thường thấp hơn rõ rệt so với trượt; trúng còn kéo dài thời hạn hiệu lực của bộ nhớ đệm; nhưng nếu tiền tố mỗi lần đều đổi hoặc quá ngắn thì sẽ không trúng.

Truyền phát có rẻ hơn không?

Không thay đổi đơn giá trực tiếp. Giá trị của nó là giảm chi phí ẩn từ quá thời gian, đứt kết nối và thử lại ở yêu cầu dài.

Vì sao hóa đơn cao hơn ước tính?

Các khoản dễ bỏ sót gồm tin nhắn lịch sử, kết quả công cụ, toàn văn tài liệu, thử lại, đầu ra dài và trượt bộ nhớ đệm. Dùng nhật ký yêu cầu đối chiếu theo usage mới định vị được chênh lệch.

Đội trong nước thanh toán bằng nhân dân tệ thế nào?

Có thể gọi Kimi qua cổng AI cung cấp nạp bằng nhân dân tệ và hóa đơn, thống nhất hóa đơn đa mô hình. Mẫu mô hình khả dụng, giá và quy tắc hóa đơn cụ thể căn cứ theo bảng giá mô hình.

Bước tiếp theo

Trước hết tạo khóa kiểm thử tại ZSQH AI Gateway, dùng kimi-k2.6 và mẫu mã nguồn chạy mỗi loại một lô tác vụ thật, ghi lại token, trúng bộ nhớ đệm và chất lượng, rồi mới quyết định mẫu chính. Mô hình khả dụng và giá căn cứ theo bảng giá mô hình.

Đọc thêm: