Moonshot API là giao diện mô hình do nền tảng mở Moonshot AI cung cấp, cũng là nền tảng dành cho nhà phát triển đứng sau Kimi. API tính phí theo lượng token dùng, không có gói đăng ký. Nhiều đội ngũ mắc lỗi ở hai chỗ khi lập ngân sách: một là vẫn gọi dòng moonshot-v1 đã ngừng cung cấp, hai là gộp đầu vào, ghi bộ nhớ đệm, đầu ra và thử lại thành một đơn giá trung bình. Bài viết bóc tách cấu trúc tính phí theo tài liệu công khai tháng 10 năm 2026; giá cụ thể căn cứ theo giá mô hình trên trang và tài liệu chính thức.

Lưu ý: Moonshot và Kimi là nhãn hiệu của chủ sở hữu tương ứng. Bài viết chỉ nhằm mục đích kỹ thuật, không ngụ ý có quan hệ liên kết hoặc đại lý với chủ sở hữu. Danh sách mô hình, độ dài ngữ cảnh và quy tắc tính phí có thể điều chỉnh; trước khi mua, hãy kiểm tra lại trang chính thức.

1. Phân biệt "mô hình hiện hành" và "mô hình đã ngừng" trước

Tính đến tháng 10 năm 2026, các mô hình chủ lực được tài liệu nền tảng mở liệt kê là kimi-k3, kimi-k2.6, kimi-k2.7-code và kimi-k2.7-code-highspeed. Dòng moonshot-v1 cũ đã rút lui: moonshot-v1-8k, -32k, -128k, -auto và các phiên bản xem trước thị giác tương ứng đều ngừng cung cấp ngày 31 tháng 8 năm 2026; cùng ngày còn có kimi-k2.5. Các phiên bản xem trước kimi-k2 sớm hơn và kimi-latest cũng đã ngừng dịch vụ.

Mô hình Ngữ cảnh Cấu trúc tính phí Trạng thái và lưu ý
kimi-k3 1.048.576 Đầu vào, trúng bộ nhớ đệm, ghi bộ nhớ đệm, đầu ra Mô hình hàng đầu hiện tại, tài liệu chính thức khuyến nghị làm đích di chuyển
kimi-k2.6 262.144 Đầu vào, trúng bộ nhớ đệm, đầu ra Dùng phổ thông và đa phương thức, hay dùng ở tình huống nhạy chi phí
kimi-k2.7-code 262.144 Đầu vào, trúng bộ nhớ đệm, đầu ra Tạo mã, hỏi đáp kho mã và Agent
kimi-k2.7-code-highspeed 262.144 Đầu vào, trúng bộ nhớ đệm, đầu ra Tác vụ mã yêu cầu độ trễ thấp
moonshot-v1-8k/32k/128k Theo tên mô hình Bản cũ tính theo bậc độ dài Đã ngừng cung cấp ngày 31 tháng 8 năm 2026

Không thể sao chép nguyên tên mô hình trong hướng dẫn cũ. "8k" trong moonshot-v1-8k chính là bậc ngữ cảnh; gọi thất bại không phải do Key mà do mô hình không còn tồn tại. Khi di chuyển, đổi tên mô hình trước, sau đó đối chiếu ngữ cảnh và các khoản tính phí, đừng chỉ thay chuỗi.

2. Đơn vị tính phí: một yêu cầu chia thành bốn khoản

Hóa đơn hiện tại thường gồm bốn loại token: đầu vào không trúng bộ nhớ đệm, đầu vào trúng bộ nhớ đệm, ghi bộ nhớ đệm và đầu ra. Ghi bộ nhớ đệm của K3 tính riêng theo hai mức TTL 5 phút và 1 giờ; trang giá dòng K2 không liệt kê riêng khoản ghi bộ nhớ đệm. Viết một yêu cầu thành công thức:

Chi phí một yêu cầu =
  Token đầu vào không trúng × đơn giá không trúng
+ Token đầu vào trúng bộ nhớ đệm × đơn giá trúng
+ Token ghi bộ nhớ đệm × đơn giá TTL tương ứng (chỉ K3)
+ Token đầu ra × đơn giá đầu ra

Tài liệu chính thức đưa một quy đổi hữu ích: văn bản tiếng Trung tiêu chuẩn khoảng 1,5 đến 2 chữ Hán tương ứng 1 token. Nhân trực tiếp số chữ với đơn giá sẽ đánh giá thấp lượng đầu vào; khi tính chính thức nên dùng giao diện ước lượng POST /v1/tokenizers/estimate-token-count, hoặc đọc trực tiếp usage trong phản hồi.

Trường mức dùng của Chat Completions là usage.prompt_tokens, usage.completion_tokens; chi tiết bộ nhớ đệm nằm ở usage.prompt_tokens_details.cached_tokens và cache_write_tokens. input_tokens của Messages API không gồm phần bộ nhớ đệm; tổng đầu vào phải cộng input_tokens, cache_read_input_tokens, cache_creation_input_tokens. Gọi truyền phát phải đặt stream_options.include_usage=true.

3. Bộ nhớ đệm tính phí thế nào, vì sao không trúng

Bộ nhớ đệm ngữ cảnh khớp theo tiền tố, không khớp theo toàn bộ cuộc hội thoại. Bất kỳ thay đổi nào trong tiền tố đều khiến nội dung sau vị trí đó không tái sử dụng được. Các hành vi phá tiền tố phổ biến: chèn dấu thời gian hoặc ID ngẫu nhiên vào system prompt, sắp xếp lại định nghĩa công cụ mỗi lần, ghép động đoạn cơ sở tri thức, đổi bậc TTL. Bộ nhớ đệm còn cách ly theo tổ chức; khác tổ chức không chia sẻ.

Ghi bộ nhớ đệm của K3 tính phí ở lần ghi đầu tiên, TTL cố định 5 phút hoặc 1 giờ, sau khi ghi không đổi bậc giữa chừng; khi trúng sẽ gia hạn miễn phí theo TTL gốc, không thu lại phí ghi. Hai bậc bộ nhớ đệm không thông nhau. Nếu phần đuôi tiền tố không đủ một khối bộ nhớ đệm hoàn chỉnh, phần này thường được xử lý như không trúng.

Bộ nhớ đệm không phải công tắc "bật là tiết kiệm", mà là kỹ thuật tiền tố. Đặt system prompt, định nghĩa công cụ, ví dụ cố định và phần chung của cơ sở tri thức lên trước, biến đổi để cuối, rồi dùng cached_tokens kiểm chứng tỷ lệ trúng.

4. Chi phí ngữ cảnh dài: đắt ở truyền lặp

K3 hỗ trợ ngữ cảnh 1.048.576 token, dòng K2 là 262.144 token. K3 tính phí theo lượng dùng thống nhất, không còn chia bậc độ dài 8k, 32k, 128k như moonshot-v1 cũ, nên không thể dùng bảng giá bậc cũ để suy ra K3.

Ngữ cảnh dài tự nó không phải vấn đề; vấn đề là cùng một tài liệu bị truyền lại mỗi lượt. Một lần hỏi đáp tài liệu 200.000 token, hỏi tiếp mười lượt và mỗi lượt mang toàn văn, chi phí đầu vào sẽ tích lũy nhanh theo số lượt; nhật ký công cụ, nội dung trang web và kết quả mã cũng nằm trong lịch sử và tiếp tục tính phí. Cách làm phổ biến hơn: truy xuất đoạn liên quan trước rồi cho mô hình đọc; hội thoại nhiều lượt dùng tóm tắt cuốn chiếu; phần ổn định làm tiền tố bộ nhớ đệm; chỉ dùng ngữ cảnh dài cho nguyên văn bắt buộc giữ.

Ngữ cảnh dài còn khuếch đại độ trễ và tỷ lệ thất bại. Yêu cầu dài không truyền phát dễ gặp quá thời gian cổng; thử lại còn mang thêm lượng đầu vào mới. Tác vụ dài nên ưu tiên đầu ra truyền phát và đặt thời gian đọc hợp lý.

5. Thử lại và yêu cầu thất bại tính thế nào

Mã lỗi chính thức chia 429 thành ba loại: rate_limit_reached_error là chạm trần đồng thời, RPM, TPM hoặc TPD cấp tổ chức; exceeded_current_quota_error là số dư hoặc hạn mức không đủ; engine_overloaded_error là dung lượng máy chủ quá tải. Chỉ vấn đề số dư mới giải quyết được bằng nạp tiền; quá tải dung lượng nạp tiền cũng không xóa được ngay. 500, 503 thường khuyến nghị thử lại sau; quá thời gian cổng của yêu cầu dài phù hợp chuyển sang truyền phát hơn là gửi lại nguyên trạng.

Yêu cầu thất bại có tính phí không, tài liệu chính thức không nêu rõ "thất bại miễn phí". Cách ổn định là đừng giả định thử lại không tốn phí, dùng nhật ký yêu cầu và usage đối chiếu, đồng thời thống kê riêng số lần thử lại. Chiến lược thử lại có thể triển khai theo thứ tự:

  1. Phân loại theo mã lỗi trước; nợ phí, sai tham số và kiểm duyệt nội dung thất bại không thử lại.
  2. Chỉ thử lại có giới hạn với 429 giới hạn tốc độ, 500, 503 và ngắt mạng.
  3. Dùng lùi cấp số nhân kèm nhiễu ngẫu nhiên, tuân theo Retry-After.
  4. Đặt giới hạn số lần và tổng thời gian cho thử lại, tránh chiếm dụng đồng thời mãi.
  5. Gọi công cụ phải có khóa idempotent hoặc bảng khử trùng, tránh đặt hàng lặp, gửi tin lặp.
  6. Ghi request_id, tên mô hình, lượng token dùng và số lần thử lại để đối chiếu.

6. Ước lượng ngân sách: từ token đến trần hàng tháng

Đừng suy ngân sách từ "mỗi triệu token bao nhiêu tiền" mà suy ngược từ tác vụ thật. Chọn 20 đến 50 tác vụ đại diện, bao phủ ba mức đơn giản, trung bình, phức tạp, ghi rõ tiêu chí nghiệm thu; dùng giao diện ước lượng đo đầu vào, đọc usage của lần gọi thật, dùng "tổng chi phí hoàn thành một tác vụ đạt chuẩn" để so sánh mô hình.

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "Trích xuất hợp đồng này thành JSON:..."}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

Sau khi ước lượng đầu vào một lần, còn phải cộng bốn phần: tin nhắn lịch sử, kết quả công cụ, tỷ lệ không trúng bộ nhớ đệm, lệnh gọi thêm do thử lại. Xử lý hàng loạt ngoại tuyến có thể đánh giá Batch API; tài liệu chính thức nêu giá thấp hơn khoảng bốn mươi phần trăm so với gọi đồng bộ, nhưng hiện chỉ hỗ trợ kimi-k2.7-code và kimi-k2.6, kimi-k3 chưa hỗ trợ.

Kiểm soát ngân sách nên chia ba lớp: đặt ngân sách ngày và tháng theo dự án; bảng điều khiển khi đạt trần sẽ từ chối yêu cầu của dự án đó, nhưng thực thi có thể trễ khoảng mười phút; tách theo Key hoặc thành viên, tránh một nghiệp vụ dùng hết hạn mức toàn tổ chức; đối chiếu hàng tuần theo mô hình và tình huống, tìm lệnh gọi tăng nhanh nhất. Cảnh báo số dư chỉ chống gián đoạn đột ngột, không thay thế ngân sách.

7. Thứ tự giảm chi phí và thói quen đối chiếu

Đừng đảo thứ tự giảm chi phí. Làm bộ nhớ đệm và quản trị đầu vào trước, rồi giới hạn đầu ra, cuối cùng mới cân nhắc đổi mô hình; nếu không chỉ là làm câu trả lời sai rẻ hơn.

  1. Cố định system prompt, định nghĩa công cụ và tiền tố cơ sở tri thức, kiểm chứng cached_tokens.
  2. Dùng truy xuất và tóm tắt giảm nguyên văn truyền mỗi lần, tóm tắt cuốn chiếu tin nhắn lịch sử.
  3. Đặt max_completion_tokens, yêu cầu JSON hoặc trường cố định, giảm đầu ra dài mở.
  4. Định tuyến mô hình theo tác vụ: tác vụ phổ thông dùng kimi-k2.6, tác vụ mã dùng bản mã K2.7, tài liệu siêu dài mới lên K3.
  5. Yêu cầu dài chuyển sang truyền phát, giảm thử lại do quá thời gian và đứt kết nối.
  6. Tác vụ ngoại tuyến đi Batch API, tác vụ thời gian thực giữ giao diện đồng bộ.
  7. Đối chiếu hàng tháng theo ba chiều dự án, mô hình, tình huống; ghi riêng tỷ lệ trúng bộ nhớ đệm, số lần thử lại và độ dài đầu ra trung bình.

Bảng đối chiếu tối thiểu phải có: thời gian gọi, dự án, mô hình, token đầu vào, token trúng bộ nhớ đệm, token ghi bộ nhớ đệm, token đầu ra, số lần thử lại, request_id. Thiếu các trường này, khi hóa đơn lệch chỉ có thể đoán.

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

moonshot-v1-8k còn gọi được không?

Không. Toàn bộ dòng moonshot-v1 đã ngừng cung cấp ngày 31 tháng 8 năm 2026; tài liệu chính thức khuyến nghị di chuyển sang kimi-k3. Khi di chuyển không chỉ đổi tên mô hình mà còn phải đối chiếu lại độ dài ngữ cảnh, các khoản tính phí và tham số đầu ra.

Vì sao trúng bộ nhớ đệm không có hiệu lực?

Trước hết kiểm tra tiền tố có bị dấu thời gian, ID ngẫu nhiên, sắp xếp động hoặc xáo trộn công cụ phá không; sau đó xác nhận khoảng cách yêu cầu không vượt TTL; cuối cùng xác nhận ghi và đọc bộ nhớ đệm cùng tổ chức, cùng bậc TTL. Dùng cached_tokens để đánh giá, đừng dựa vào cảm giác.

Ngữ cảnh dài có chắc chắn đắt hơn không?

Không nhất thiết, nhưng truyền lặp tài liệu dài thường đắt. Chi phí phụ thuộc số lần đầu vào bị lặp, tỷ lệ trúng bộ nhớ đệm và độ dài đầu ra. Hãy dùng truy xuất thu hẹp phạm vi trước, rồi quyết định có dùng ngữ cảnh hàng triệu token không.

Yêu cầu thất bại có bị tính phí không?

Tài liệu chính thức không nêu rõ thất bại miễn phí. Đừng giả định thử lại không tốn phí; hãy đối chiếu qua nhật ký yêu cầu và usage, đồng thời đưa số lần thử lại vào chi phí mỗi tác vụ.

Xem giá mới nhất ở đâu?

Căn cứ theo giá mô hình trên trang và tài liệu chính thức Moonshot/Kimi. Giá, danh sách mô hình và quy tắc bộ nhớ đệm đều có thể điều chỉnh; đừng dùng ảnh chụp cũ.

Bước tiếp theo

Trước hết tạo Key kiểm thử tại ZSQH AI Gateway, dùng kimi-k2.6 và kimi-k3 chạy mỗi mô hình một lô tác vụ thật, ghi đầu vào, đầu ra, trúng bộ nhớ đệm và thử lại, rồi quyết định mô hình chính và ngân sách hàng tháng. Giá cụ thể và mô hình khả dụng căn cứ theo giá mô hình.

Bài viết liên quan: