DEV Community: Sebastian Petrus

Cách sử dụng Kimi K3 để lập trình với Kimi Code

Sebastian Petrus — Fri, 17 Jul 2026 08:04:24 +0000

Moonshot AI xây dựng Kimi K3 cho các tác vụ lập trình không thể hoàn thành chỉ bằng một lời nhắc: đọc kho lưu trữ lớn, chỉnh sửa tệp, chạy công cụ, thực thi kiểm thử, phân tích nhật ký và ảnh chụp màn hình, rồi lặp lại đến khi hoàn tất. Để làm việc này, bạn chạy K3 trong Kimi Code — tác nhân lập trình terminal và IDE của Moonshot. Bài viết này hướng dẫn cách thiết lập quy trình, giao việc hiệu quả, kiểm chứng đầu ra và hiểu các giới hạn thực tế của K3.

Dùng thử Apidog ngay hôm nay

TL;DR: Chạy Kimi K3 để lập trình

Kimi K3 là mẫu flagship của Moonshot AI, ra mắt ngày 16 tháng 7 năm 2026, có cửa sổ ngữ cảnh 1 triệu token và được điều chỉnh cho công việc quy mô kho lưu trữ. Bạn sử dụng nó qua Kimi Code bằng cách chọn mô hình với /model, sau đó giao một nhiệm vụ cụ thể.

K3 phù hợp với các tác vụ cần:

Điều hướng codebase lớn.
Đọc/ghi tệp và chạy lệnh shell.
Gỡ lỗi dựa trên log, stack trace và kết quả kiểm thử.
Lặp lại sau phản hồi thời gian chạy hoặc ảnh chụp màn hình.
Duy trì ngữ cảnh dài trong các phiên kỹ thuật nhiều bước.

K3 có lợi thế chi phí cho các vòng lặp dùng nhiều bộ nhớ đệm, với tỷ lệ cache hit được báo cáo trên 90%. Tuy nhiên, tốc độ khoảng 62 token/giây không phải nhanh nhất, và Moonshot thừa nhận K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol về năng lực thô.

Nếu K3 xây dựng API cho bạn, hãy dùng Apidog để gửi request thật, kiểm tra status code, schema phản hồi và hành vi xác thực. Để xem thông tin nền về mô hình, bắt đầu với Kimi K3 là gì.

Kimi Code là gì?

Kimi Code là tác nhân lập trình của Moonshot. Nó chạy trong terminal, có thể tích hợp IDE, đọc và ghi tệp, thực thi shell command, chạy kiểm thử và quản lý một phiên kỹ thuật hoàn chỉnh thay vì chỉ trả lời câu hỏi về mã.

Quy trình cơ bản:

Mở Kimi Code trong thư mục dự án.
Mô tả nhiệm vụ với tiêu chí hoàn thành rõ ràng.
Để tác nhân đọc codebase và lập kế hoạch.
Cho phép nó chỉnh sửa, chạy kiểm thử và đọc phản hồi.
Kiểm tra diff trước khi merge hoặc triển khai.

Mô hình K3 xử lý văn bản và gọi công cụ; Kimi Code cung cấp môi trường làm việc như filesystem, shell, đầu ra kiểm thử và ảnh chụp màn hình. Kết hợp này biến một mô hình sinh mã thành tác nhân có thể xử lý một ticket kỹ thuật nhiều bước.

Kimi Code không chỉ hỗ trợ K3; dòng Kimi K2 trước đây cũng dùng cùng tác nhân này. Xem hướng dẫn CLI của Kimi Code để cài đặt từ đầu, hoặc cách sử dụng Kimi CLI để tham khảo thêm về dòng lệnh.

Chạy Kimi K3 trong Kimi Code

Cú pháp cài đặt và cờ lệnh có thể thay đổi khi Moonshot cập nhật công cụ. Hãy dùng quy trình dưới đây như một checklist, sau đó xác nhận câu lệnh hiện tại trong tài liệu chính thức của Kimi hoặc hướng dẫn CLI của Kimi Code.

1. Cài đặt tác nhân và xác thực

Bạn cần tài khoản Kimi và API key từ nền tảng nhà phát triển Kimi. Không hard-code khóa vào file cấu hình có thể bị commit. Thay vào đó, dùng biến môi trường:

# Chỉ mang tính minh họa. Kiểm tra tài liệu Kimi để có cú pháp hiện tại.
export KIMI_API_KEY="your-key-here"

# Khởi chạy tác nhân trong thư mục hiện tại
kimi-code

Khuyến nghị thực tế:

Lưu API key trong secret manager hoặc file .env đã được thêm vào .gitignore.
Không gửi API key vào prompt.
Chỉ cấp quyền cần thiết cho thư mục dự án đang xử lý.

2. Khởi chạy trong thư mục gốc của dự án

Mở terminal tại repository cần làm việc:

cd path/to/your-project
kimi-code

Thư mục hiện tại là workspace của tác nhân. Nếu bạn khởi chạy sai cấp thư mục, Kimi Code có thể không nhìn thấy các tệp cấu hình, package workspace hoặc module liên quan.

3. Chọn Kimi K3

Trong phiên Kimi Code, chọn K3:

/model kimi-k3

Bạn có thể dùng cùng cơ chế này để chuyển sang các mô hình khác, chẳng hạn Kimi K2.7 Code, khi cần so sánh chất lượng hoặc tốc độ trên cùng một nhiệm vụ.

4. Chọn mức nỗ lực suy luận phù hợp

K3 hỗ trợ cấu hình nỗ lực suy luận, bao gồm mức “tối đa”.

Dùng mức cao hơn cho:

Gỡ lỗi lỗi khó tái tạo.
Refactor nhiều module.
Phân tích dependency phức tạp.
Sửa lỗi cần đọc log, test và code ở nhiều lớp.

Dùng mức thấp hơn cho:

Đổi tên biến hoặc hàm.
Chỉnh sửa tài liệu.
Thay đổi nhỏ, có phạm vi rõ ràng.
Tạo test case đơn giản.

Sau khi chọn mô hình và workspace, bạn có thể giao nhiệm vụ. Nếu muốn thử K3 mà không cần cài Kimi Code hoặc cần lựa chọn miễn phí, xem cách sử dụng Kimi K3 miễn phí.

Quy trình lập trình tác nhân thực tế

Dù bạn sửa bug hay xây tính năng, quy trình nên luôn có ba phần:

Mô tả nhiệm vụ cụ thể.
Cho tác nhân thu thập ngữ cảnh và thực thi.
Yêu cầu bằng chứng khách quan: test, build, log hoặc HTTP response.

Giao nhiệm vụ có thể kiểm thử

Tránh prompt chung chung như:

Cải thiện mô-đun xác thực.

Thay vào đó, cung cấp lỗi, phạm vi và tiêu chí hoàn thành:

Endpoint /login trả về HTTP 500 khi trường password rỗng.

Hãy:
1. Tái tạo lỗi.
2. Xác định nguyên nhân gốc.
3. Sửa lỗi theo quy ước hiện có của dự án.
4. Thêm test cho trường hợp password rỗng.
5. Chạy toàn bộ test liên quan.
6. Tóm tắt các tệp đã thay đổi và kết quả test.

Một prompt tốt nên trả lời được các câu hỏi:

Lỗi hoặc yêu cầu chính xác là gì?
Phạm vi code nào có thể bị ảnh hưởng?
Điều kiện hoàn thành là gì?
Những kiểm thử nào phải chạy?
Có ràng buộc nào về API, tương thích ngược hoặc bảo mật không?

Ngữ cảnh 1M token của K3 giúp việc làm việc với toàn bộ repository trở nên thực tế hơn. Tác nhân có thể theo dõi luồng gọi từ route handler qua service layer mà không yêu cầu bạn chỉ định thủ công từng tệp.

Cho phép tác nhân dùng công cụ và đọc phản hồi

Trong Kimi Code, K3 có thể chạy shell command, tìm kiếm codebase, build dự án, khởi động dịch vụ và chạy test. Vòng lặp tiêu chuẩn là:

Đọc các tệp liên quan.
Hình thành giả thuyết về nguyên nhân lỗi.
Chỉnh sửa mã.
Chạy test hoặc khởi động ứng dụng.
Đọc lỗi, log hoặc stack trace.
Điều chỉnh giải pháp.
Lặp lại đến khi kiểm tra thành công.

Ví dụ prompt cho lỗi backend:

Kiểm tra lỗi timeout khi POST /orders với payload lớn.

Yêu cầu:
- Tái tạo lỗi bằng test hoặc request cục bộ.
- Theo dõi request từ route đến service và database layer.
- Không thay đổi public API nếu không cần thiết.
- Thêm regression test.
- Chạy test module liên quan.
- Báo cáo nguyên nhân gốc, thay đổi và kết quả xác minh.

Điểm quan trọng: đừng yêu cầu mô hình “đúng ngay lần đầu”. Hãy yêu cầu nó quan sát, kiểm tra và sửa lại như một kỹ sư đang làm việc trong repository.

Lặp lại dựa trên ảnh chụp màn hình và đầu ra thời gian chạy

Phản hồi không chỉ là text.

Với frontend, bạn có thể yêu cầu tác nhân:

Cập nhật form đăng nhập để hiển thị lỗi validation dưới từng trường.

Tiêu chí:
- Không thay đổi layout trên màn hình desktop.
- Password rỗng phải hiển thị thông báo rõ ràng.
- Chụp ảnh màn hình sau khi render.
- Điều chỉnh CSS nếu thông báo bị tràn hoặc lệch.

Vòng lặp UI thường là:

Chỉnh sửa HTML/CSS/JS.
Render giao diện.
Chụp ảnh màn hình.
Kiểm tra hiển thị.
Điều chỉnh và lặp lại.

Với backend, phản hồi tương ứng là:

Test report.
Application log.
Stack trace.
HTTP response.
Database error.
Metrics hoặc trace cục bộ.

Giữ vòng lặp đáng tin cậy bằng kiểm thử

Test là tiêu chí “xong” rõ ràng nhất cho một tác nhân.

Trước khi giao tác vụ, hãy xác định:

Test hiện có nào cần chạy.
Test mới nào phải được thêm.
Những hành vi không được regression.
Lệnh build hoặc lint nào là bắt buộc.

Ví dụ:

Trước khi hoàn tất:
- Chạy unit test của auth module.
- Chạy lint cho các tệp đã sửa.
- Thêm test regression cho password rỗng.
- Không bỏ qua test hoặc xóa assertion để làm test xanh.

Nếu không có test, vòng lặp tự động có thể đi lệch hướng và gây lỗi ở module khác mà không phát hiện.

Kimi K3 so với Claude Code và Cursor

Dưới đây là so sánh thực tế giữa ba cách chạy tác nhân trên codebase vào giữa năm 2026.

Tiêu chí	Kimi Code (Kimi K3)	Claude Code (Fable 5)	Cursor
Yếu tố hình thức	Tác nhân lập trình terminal và IDE	Tác nhân lập trình terminal	Trình chỉnh sửa mã AI-native
Mô hình mặc định	Kimi K3, chuyển qua `/model`	Claude Fable 5 và các mô hình Claude khác	Tự mang mô hình hoặc dùng mô hình tích hợp
Cửa sổ ngữ cảnh	1M token	Lớn, tùy mô hình	Tùy mô hình
Điều hướng repository	Mạnh, hướng tới tác vụ quy mô lớn và dài hạn	Mạnh, có quyền truy cập tệp và shell theo tác nhân	Lập chỉ mục và truy xuất mạnh trong editor
Sử dụng công cụ	Tool calling, shell, test, ảnh chụp màn hình	Tool calling, shell, MCP	Công cụ editor, terminal, MCP
Đòn bẩy chi phí	Có lợi cho vòng lặp cache-heavy với cache hit 90%+	Tính phí theo token Claude	Đăng ký cộng chi phí sử dụng mô hình
Trọng số mở	Dự kiến khoảng 27 tháng 7 năm 2026	Đóng	Editor độc quyền, mô hình đa dạng
Phù hợp nhất	Tác vụ agent dài, repository lớn, tối ưu chi phí	Suy luận và độ tin cậy hàng đầu	Developer muốn agent hoạt động trong editor

Một số lựa chọn thực tế:

Nếu ưu tiên độ tin cậy thô cho tác vụ khó, Fable 5 trong Claude Code là lựa chọn Moonshot cũng thừa nhận vượt K3.
Nếu muốn agent tích hợp sâu trong editor, Cursor hoặc Cline thường phù hợp hơn.
Nếu cần chạy mô hình mở trong các môi trường này, xem hướng dẫn GLM-5.2 trong Claude Code, Cline và Cursor.
Nếu cần xử lý repository lớn với vòng lặp dài và quan tâm đến chi phí, K3 có lợi thế nhờ context 1M token và cơ chế cache.

Điểm mạnh và hạn chế thực tế

K3 giỏi về điều gì?

Ngữ cảnh quy mô repository.

Cửa sổ 1M token giúp tác nhân giữ nhiều phần của codebase trong cùng một phiên, đặc biệt hữu ích với monorepo hoặc thay đổi xuyên nhiều package.

Sử dụng công cụ và tự chủ dài hạn.

K3 được điều chỉnh để duy trì phiên kỹ thuật kéo dài, chạy terminal command, đọc output và tự điều chỉnh theo phản hồi.

Chi phí trong vòng lặp nặng bộ nhớ đệm.

Lập trình tác nhân thường gửi lại cùng ngữ cảnh ở mỗi bước: cấu trúc tệp, system instruction và lịch sử nhiệm vụ. Giá input cache hit của K3 là 0,30 USD cho mỗi triệu token, so với 3,00 USD khi cache miss — chênh lệch 10 lần. Mooncake inference của Moonshot được báo cáo đạt cache hit trên 90% trong tác vụ lập trình. Xem phân tích giá Kimi K3 để biết thêm số liệu.

Những hạn chế của K3

Không phải mô hình dẫn đầu tuyệt đối.

Moonshot cho biết K3 vẫn kém các mô hình độc quyền mạnh nhất như Claude Fable 5 và GPT-5.6 Sol. Theo các benchmark Moonshot công bố:

Terminal Bench 2.1: K3 đạt 88.3, GPT-5.6 Sol đạt 88.8.
DeepSWE: K3 đạt 67.5, Fable 5 đạt 70.0, GPT-5.6 Sol đạt 73.0.

Kết quả cạnh tranh, nhưng K3 không đứng đầu. Xem phân tích benchmark Kimi K3 để xem chi tiết.

Không phải lựa chọn nhanh nhất.

Theo Artificial Analysis, K3 tạo khoảng 62 token/giây, thấp hơn trung bình trong phân khúc giá của nó. Nếu cần phản hồi tương tác nhanh, hãy benchmark thêm mô hình khác trên chính tác vụ của bạn.

Khả năng “mở” vẫn phụ thuộc lịch phát hành.

Trọng số đầy đủ dự kiến vào khoảng ngày 27 tháng 7 năm 2026, không phải ngày ra mắt. Nếu chiến lược của bạn phụ thuộc vào self-hosting, đây là mốc cần theo dõi.

Để so sánh trực tiếp, xem:

Các trường hợp sử dụng thực tế

K3 phù hợp nhất khi nhiệm vụ có nhiều bước, cần đọc nhiều ngữ cảnh và có tín hiệu xác minh rõ ràng.

Refactor lớn trong monorepo

Ví dụ:

Tách module billing khỏi package monolith hiện tại.

Yêu cầu:
- Xác định toàn bộ import và dependency liên quan.
- Không thay đổi API công khai.
- Cập nhật test, build config và tài liệu nội bộ nếu cần.
- Chạy build và test cho tất cả package bị ảnh hưởng.
- Liệt kê các thay đổi có rủi ro cần review thủ công.

Gỡ lỗi kéo dài

Có memory leak khi worker xử lý queue chạy liên tục hơn 30 phút.

Hãy:
- Tìm code khởi tạo worker và lifecycle cleanup.
- Kiểm tra timer, event listener, connection và cache.
- Tái tạo bằng test hoặc script tối thiểu nếu khả thi.
- Đề xuất và triển khai bản vá nhỏ nhất.
- Đưa ra bằng chứng từ test, log hoặc profiling output.

Xây dựng API có kiểm chứng

K3 có thể tạo handler, route, validation và test. Nhưng sau khi test code chạy xanh, bạn vẫn nên xác minh API như một client thực.

Xác minh API mà K3 xây dựng

Unit test xác nhận mã có chạy. Tuy nhiên, chúng không luôn đảm bảo endpoint hoạt động đúng theo kỳ vọng của client:

Status code có đúng không?
Response body có đúng schema không?
Header có đầy đủ không?
Token không hợp lệ có bị từ chối không?
Payload sai có trả lỗi validation nhất quán không?

Đây là lúc Apidog hữu ích. Sau khi K3 tạo hoặc chỉnh sửa API, hãy gửi request thực đến endpoint và thêm assertion cho status code, header và JSON body.

Ví dụ checklist kiểm thử endpoint /login:

POST /login

Kiểm tra:
- Password rỗng trả về lỗi validation, không phải HTTP 500.
- Sai mật khẩu trả về status code phù hợp.
- Response không chứa dữ liệu nhạy cảm.
- Token hợp lệ được trả về theo schema đã định nghĩa.
- Header Content-Type đúng.

Nếu tác nhân tạo OpenAPI spec, hãy import spec vào Apidog để tạo request collection và kiểm thử theo contract thay vì kiểm tra thủ công.

Khi làm việc với môi trường chia sẻ:

Lưu secret trong biến môi trường của Apidog.
Không hard-code token vào collection.
Không commit API key vào repository.
Tách biến môi trường local, staging và production.

Apidog cũng cung cấp giao diện MCP, giúp kết nối công cụ API vào ngữ cảnh tác nhân. Xem hướng dẫn gỡ lỗi trực quan bằng client MCP của Apidog và Apidog trong VS Code để giữ vòng lặp kiểm thử gần với code mà K3 viết. Bạn có thể tải Apidog để kiểm tra đầu ra API ngay khi được tạo.

Bạn sẽ nhận được gì?

Kimi K3 trong Kimi Code là lựa chọn thực tế cho các repository lớn, vòng lặp tự động dài và tác vụ cần lặp lại theo test, log hoặc ảnh chụp màn hình. Context 1M token và mô hình chi phí dựa trên cache giúp nó phù hợp với công việc nhiều bước mà các mô hình tính token khác có thể trở nên đắt đỏ.

Để bắt đầu hiệu quả:

Khởi chạy Kimi Code tại thư mục gốc của repository.
Chọn K3 bằng /model kimi-k3.
Giao một nhiệm vụ có thể kiểm thử.
Yêu cầu tác nhân chạy test, build hoặc request thật.
Review diff trước khi merge.
Xác minh API bằng Apidog trước khi triển khai.

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

Làm cách nào để sử dụng Kimi K3 để lập trình?

Chạy K3 trong Kimi Code, tác nhân lập trình terminal và IDE của Moonshot. Cài đặt tác nhân, mở nó trong thư mục dự án, chọn mô hình bằng:

/model kimi-k3

Sau đó giao một nhiệm vụ cụ thể, có thể kiểm thử. Để tác nhân đọc tệp, chạy công cụ, thực thi test và lặp lại dựa trên kết quả. Xem hướng dẫn CLI của Kimi Code để cài đặt.

Kimi K3 có tốt cho lập trình tác nhân không?

Có. K3 được điều chỉnh cho việc điều hướng repository lớn, dùng công cụ, gỡ lỗi và lặp lại dựa trên test, log và phản hồi thời gian chạy trong context 1M token. Nó cạnh tranh trên benchmark lập trình, dù vẫn kém Fable 5 và GPT-5.6 Sol ở một số chỉ số.

Kimi K3 có hỗ trợ gọi công cụ cho quy trình tác nhân không?

Có. K3 API hỗ trợ tool calling, ràng buộc lựa chọn công cụ, JSON mode, structured output, tìm kiếm internet, tải công cụ động và nỗ lực suy luận có thể cấu hình. Những khả năng này cho phép tác nhân chạy test, thực thi shell command và điều phối vòng lặp kỹ thuật trong Kimi Code. Xem hướng dẫn API Kimi K3 để biết chi tiết.

Tôi có thể kiểm thử API mà Kimi K3 viết không?

Có, và nên làm như vậy. Test của tác nhân chỉ xác nhận code chạy; chúng không luôn xác nhận endpoint trả đúng status code, schema phản hồi và hành vi xác thực như client thực mong đợi. Hãy gửi request thật trong Apidog, thêm assertion và import OpenAPI spec do tác nhân tạo để xác thực theo contract.

Kimi K3 vs GPT-5.6 Sol: AI Nguồn Mở Thách Thức Đỉnh Cao Công Nghệ

Sebastian Petrus — Fri, 17 Jul 2026 07:22:17 +0000

Moonshot AI đã phát hành Kimi K3 vào ngày 16 tháng 7 năm 2026 và định vị đây là mô hình mở đầu tiên trong phân khúc 3 nghìn tỷ tham số. Câu hỏi thực tế cho đội ngũ kỹ thuật là: liệu trọng số mở, ngữ cảnh dài và chi phí thấp hơn có đủ để cạnh tranh với mô hình đóng hàng đầu? Trong bài đăng ra mắt Kimi K3, Moonshot thừa nhận K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol về chất lượng tổng thể. Vì vậy, đây không phải bài toán “mô hình nào thắng tuyệt đối”, mà là chọn giữa chất lượng tiên phong của Sol và quyền kiểm soát, ngữ cảnh, chi phí của K3.

Dùng thử Apidog ngay hôm nay

GPT-5.6 Sol là phiên bản tiên phong của OpenAI trong dòng GPT-5.6, cùng Terra và Luna. Kimi K3 là lựa chọn mô hình mở mạnh trong phân khúc, xếp thứ tư trên Chỉ số Thông minh của Artificial Analysis. Cả hai cung cấp API tương thích với OpenAI, nên bạn có thể chạy cùng một prompt trên kimi-k3 và gpt-5.6-sol trong Apidog, sau đó so sánh chất lượng, độ trễ và mức dùng token.

TL;DR: cách chọn nhanh

Chọn GPT-5.6 Sol nếu ưu tiên hàng đầu là suy luận, coding agent và chất lượng tối đa trong hệ sinh thái OpenAI được quản lý.
Chọn Kimi K3 nếu cần trọng số mở, tự lưu trữ, ngữ cảnh 1 triệu token hoặc kiểm soát chi phí đầu vào.
Đừng chỉ dựa vào benchmark của nhà cung cấp. Hiện chưa có kết quả độc lập, khách quan so sánh trực tiếp K3 và Sol.
Hãy chạy A/B test bằng workload thật. Vì cả hai dùng API tương thích OpenAI, chi phí chuyển đổi khi thử nghiệm song song rất thấp.

Gặp gỡ hai mô hình

Kimi K3

Kimi K3 là mô hình Mixture-of-Experts (MoE) của Moonshot AI, với tổng cộng 2,8 nghìn tỷ tham số. Kiến trúc sử dụng Kimi Delta Attention, Attention Residuals và Stable LatentMoE; mỗi token kích hoạt 16 trong số 896 chuyên gia.

Moonshot chưa công bố số tham số hoạt động. Đây là chỉ số thường ảnh hưởng trực tiếp đến chi phí và tốc độ suy luận, vì vậy không nên xem con số 2,8T là lượng tính toán cho mỗi token.

Các đặc điểm cần biết khi tích hợp:

Model ID: kimi-k3
Đầu vào: văn bản và hình ảnh
Đầu ra: văn bản
Cửa sổ ngữ cảnh: 1.000.000 token
Trọng số dự kiến mở vào khoảng ngày 27 tháng 7 năm 2026
API tương thích OpenAI

Xem thêm: Kimi K3 là gì?

GPT-5.6 Sol

GPT-5.6 Sol là mô hình tiên phong đóng của OpenAI trong thế hệ GPT-5.6. Bạn có thể gọi model qua API hoặc sản phẩm OpenAI, nhưng không thể tải trọng số về để kiểm tra, tinh chỉnh hoặc tự triển khai.

OpenAI định vị Sol là model mạnh nhất trong dòng GPT-5.6. Terra và Luna phục vụ các điểm cân bằng khác nhau về chi phí và độ trễ.

Model ID: gpt-5.6-sol — cần xác nhận trong tài liệu OpenAI trước khi triển khai.
Truy cập: API và sản phẩm OpenAI.
Trọng số: không công khai.
Vận hành: được OpenAI quản lý.

Tham khảo: GPT-5.6 Sol so với Terra so với Luna và tài liệu model của OpenAI.

So sánh nhanh

Khía cạnh	Kimi K3	GPT-5.6 Sol
Nhà phát triển	Moonshot AI	OpenAI
Ra mắt	16 tháng 7 năm 2026	Dòng GPT-5.6, 2026
Cách truy cập	Trọng số mở, dự kiến khoảng 27 tháng 7 năm 2026	Đóng, qua API và sản phẩm
Kiến trúc	MoE, 2,8T tổng tham số, 16/896 chuyên gia hoạt động	Chưa công bố
Chất lượng hàng đầu	Dẫn đầu nhóm mô hình mở; Chỉ số Thông minh AA 57, xếp #4/189	Được Moonshot định vị cao hơn K3
Cửa sổ ngữ cảnh	1.000.000 token	Lớn; kiểm tra tài liệu OpenAI
Đầu vào	Văn bản và hình ảnh	Đa phương thức; kiểm tra tài liệu OpenAI
Tốc độ đầu ra	Khoảng 62 token/giây theo Artificial Analysis	Phụ thuộc cấp độ và tải
Giá đầu vào	$0,30/M cache-hit, $3,00/M cache-miss	Kiểm tra giá hiện tại của OpenAI
Giá đầu ra	$15,00/M token	Kiểm tra giá hiện tại của OpenAI
Tự lưu trữ	Có, khi trọng số được phát hành	Không
Hệ sinh thái	Kimi, Kimi Code, Kimi Work, API tương thích OpenAI	SDK, công cụ và tích hợp OpenAI

Hai lưu ý quan trọng:

Điểm Chỉ số Thông minh 57 đưa K3 lên hạng 4 trong 189 model do Artificial Analysis theo dõi. Đây là kết quả đáng chú ý cho mô hình mở, nhưng không chứng minh K3 vượt Sol tổng thể.
Các số liệu đối đầu hiện có đến từ Moonshot. Hãy xem đây là chỉ dấu ban đầu, không phải kết luận độc lập. Theo dõi các cập nhật tại điểm chuẩn Kimi K3.

Chất lượng suy luận và coding

Sol phù hợp hơn khi workload nằm sát giới hạn khả năng của model hiện tại:

Lập kế hoạch agent nhiều bước.
Tái cấu trúc codebase lớn.
Xử lý nhiệm vụ lập trình tác nhân khó.
Suy luận cần độ ổn định cao qua nhiều vòng gọi tool.

Moonshot cũng định vị Sol cao hơn K3 về năng lực tổng thể. Nếu sản phẩm của bạn bán “chất lượng tốt nhất có thể”, Sol là lựa chọn ít rủi ro hơn.

Tuy nhiên, K3 không phải lựa chọn yếu. Với các tác vụ sản xuất phổ biến như:

Tóm tắt tài liệu.
Phân loại nội dung.
Trả lời RAG.
Soạn thảo nội dung.
Trợ lý lập trình hằng ngày.

…khoảng cách giữa model hạng tư và model dẫn đầu có thể không dễ nhận biết trong bài kiểm tra mù. Đây là lúc tính mở, ngữ cảnh và chi phí trở thành tiêu chí quyết định.

Moonshot công bố bảng benchmark sau, chạy với cấu hình suy luận tối đa:

Điểm chuẩn	Kimi K3	GPT-5.6 Sol
Terminal-Bench 2.1	88,3	88,8
DeepSWE	67,5	73,0
BrowseComp	91,2	90,4
Automation Bench	30,8	29,7
SpreadsheetBench 2	34,8	32,4

K3 thắng 3 trên 5 benchmark trong bảng này: BrowseComp, Automation Bench và SpreadsheetBench 2. Sol dẫn trước nhẹ ở Terminal-Bench 2.1 và rõ rệt hơn ở DeepSWE, với 73,0 so với 67,5.

Điều cần rút ra: lợi thế của Sol có xu hướng xuất hiện ở các bài toán agentic coding khó nhất. Điều này phù hợp với nhận định của Moonshot rằng K3 vẫn kém Sol về năng lực tổng thể.

Artificial Analysis cũng gắn cờ K3 có xu hướng dài dòng: model tạo khoảng 130 triệu token đầu ra trong quá trình chạy Chỉ số Thông minh, trong khi mức trung bình là 63 triệu. Với giá đầu ra $15/M token, hãy chủ động giới hạn độ dài câu trả lời:

Trả lời tối đa 8 gạch đầu dòng.
Không lặp lại yêu cầu.
Nếu thiếu dữ liệu, chỉ nêu câu hỏi cần làm rõ.
Giới hạn phần giải thích dưới 300 từ.

Để xem thêm góc nhìn về coding, đọc Kimi K3 để lập trình và Kimi K3 so với Claude Opus 4.8.

Tính mở và tự lưu trữ

Đây là lợi thế rõ rệt nhất của Kimi K3.

Khi trọng số được mở, bạn có thể:

Chạy model trong hạ tầng riêng.
Giữ prompt và dữ liệu nhạy cảm trong mạng nội bộ.
Tinh chỉnh theo dữ liệu hoặc miền chuyên biệt.
Ghim một phiên bản model để tránh thay đổi hành vi ngoài ý muốn.
Loại bỏ phí API theo token ở quy mô lớn.

K3 phù hợp khi bạn làm việc trong môi trường:

Có yêu cầu lưu trú dữ liệu.
Bị hạn chế gửi dữ liệu sang API bên ngoài.
Cần triển khai air-gapped.
Cần kiểm soát phiên bản model dài hạn.

Ngược lại, GPT-5.6 Sol là dịch vụ đóng và được lưu trữ. Bạn đổi quyền kiểm soát lấy sự tiện lợi: OpenAI quản lý hạ tầng, độ tin cậy và công cụ, nhưng bạn không thể kiểm tra hoặc sửa trọng số model.

Lưu ý thực tế: tự vận hành một model 3 nghìn tỷ tham số đòi hỏi GPU, hạ tầng suy luận và năng lực vận hành đáng kể. “Trọng số mở” không đồng nghĩa “triển khai rẻ hoặc đơn giản”.

Ngữ cảnh dài và phân tích tài liệu

Kimi K3 có cửa sổ ngữ cảnh 1 triệu token, tương đương khoảng 1.500 trang trong một request. Điều này có thể giảm nhu cầu phân đoạn dữ liệu trong các trường hợp như:

Phân tích codebase lớn.
Rà soát hợp đồng dài.
Tổng hợp bộ tài liệu nội bộ.
Theo dõi lịch sử tác nhân dài.
Đọc log hoặc dữ liệu vận hành nhiều phần.

GPT-5.6 Sol cũng hỗ trợ cửa sổ ngữ cảnh lớn, nhưng hãy kiểm tra tài liệu OpenAI để biết giới hạn hiện tại thay vì dựa vào số liệu cũ.

Dù model có ngữ cảnh lớn, hãy luôn đo chất lượng retrieval và recall trên tài liệu thật của bạn. Một cửa sổ 1M token là dung lượng xử lý, không phải bảo đảm model sẽ ghi nhớ hoàn hảo mọi chi tiết.

Giá cả và kiểm soát chi phí

Kimi K3 có giá:

Loại token	Giá
Đầu vào cache-hit	$0,30/M token
Đầu vào cache-miss	$3,00/M token
Đầu ra	$15,00/M token

Lợi thế lớn nằm ở cache-hit. Nếu ứng dụng thường xuyên tái sử dụng system prompt lớn, tài liệu nền ổn định hoặc context cố định, chi phí đầu vào có thể giảm đáng kể.

Ví dụ, dùng một system prompt chung cho mọi request:

Bạn là trợ lý hỗ trợ nội bộ.
Chỉ trả lời dựa trên tài liệu được cung cấp.
Nếu không có bằng chứng trong tài liệu, trả lời: "Không đủ dữ liệu".
Trả lời bằng tiếng Việt, ngắn gọn và có nguồn trích dẫn.

Để tận dụng cache tốt hơn:

Đặt phần prompt tĩnh ở đầu request.
Giữ nguyên thứ tự và nội dung của phần tĩnh.
Chỉ thêm câu hỏi người dùng và dữ liệu thay đổi ở cuối.
Theo dõi token input/output thực tế theo endpoint.

Xem thêm phân tích giá Kimi K3.

Giá GPT-5.6 Sol do OpenAI công bố và có thể thay đổi theo thời gian. So sánh giá bằng tỷ lệ token thật của workload, không chỉ bằng đơn giá đầu vào. Nếu Sol vượt ngân sách, Terra hoặc Luna có thể là lựa chọn phù hợp hơn. Tham khảo hướng dẫn định giá GPT-5.6.

Hệ sinh thái, công cụ và tốc độ

Sol có lợi thế khi đội ngũ của bạn đã dùng OpenAI SDK, function calling hoặc structured output. Việc chuyển sang Sol thường chỉ cần đổi model ID.

K3 giảm chi phí chuyển đổi nhờ API tương thích OpenAI. Trong nhiều ứng dụng, bạn chỉ cần thay base URL và model ID.

Ví dụ request tương thích OpenAI cho Kimi K3:

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Tóm tắt tài liệu này thành 5 ý chính."
      }
    ]
  }'

Ví dụ request cho GPT-5.6 Sol:

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [
      {
        "role": "user",
        "content": "Tóm tắt tài liệu này thành 5 ý chính."
      }
    ]
  }'

Xác nhận endpoint, model ID và tham số hỗ trợ trong tài liệu chính thức của từng nhà cung cấp trước khi đưa vào production.

Về tốc độ, Artificial Analysis đo K3 ở khoảng 62 token/giây, với thời gian đến token đầu tiên gần 2 giây. Thông lượng của Sol phụ thuộc cấp độ dịch vụ và tải hệ thống.

Đừng benchmark bằng một request đơn lẻ. Hãy đo:

Time to first token.
Tổng thời gian phản hồi.
Token/giây.
Tỷ lệ lỗi.
P95/P99 latency.
Chi phí trung bình cho mỗi tác vụ hoàn thành.

Tham khảo thêm cách sử dụng API GPT-5.6.

Ma trận quyết định

Nếu ưu tiên của bạn là…	Nghiêng về	Lý do
Chất lượng suy luận tối đa	GPT-5.6 Sol	Moonshot định vị Sol cao hơn K3
Trọng số mở và khả năng kiểm tra	Kimi K3	Trọng số dự kiến mở
Tự lưu trữ hoặc triển khai cách ly	Kimi K3	Sol chỉ có dạng dịch vụ đóng
Kiểm soát dữ liệu và quyền riêng tư	Kimi K3	Có thể chạy trong hạ tầng riêng
Ngữ cảnh rất dài	Kimi K3	Công bố cửa sổ 1M token
SDK và công cụ trưởng thành	GPT-5.6 Sol	Hệ sinh thái OpenAI rộng
Đầu vào rẻ khi tái sử dụng prompt	Kimi K3	Cache-hit $0,30/M token
Không muốn vận hành hạ tầng	GPT-5.6 Sol	Dịch vụ được quản lý
Tinh chỉnh theo miền riêng	Kimi K3	Trọng số mở hỗ trợ khả năng này
Agentic coding khó	GPT-5.6 Sol	Lợi thế chất lượng ở tác vụ khó

Các trường hợp sử dụng thực tế

Trợ lý tài liệu nội bộ trong fintech

Nếu chính sách tuân thủ cấm gửi dữ liệu khách hàng ra API bên ngoài, Sol không phù hợp. Kimi K3 là lựa chọn logic khi trọng số mở, vì nhóm có thể triển khai sau tường lửa, giữ dữ liệu nội bộ và tận dụng ngữ cảnh dài cho hồ sơ hoặc tài liệu phức tạp.

Copilot lập trình cho startup

Nếu giá trị sản phẩm nằm ở khả năng xử lý tái cấu trúc khó, giải quyết bug phức tạp hoặc điều phối agent nhiều bước, Sol là lựa chọn an toàn hơn. Đội ngũ có thể chấp nhận chi phí cao hơn để đổi lấy chất lượng suy luận và hệ sinh thái OpenAI.

Thử nghiệm Kimi K3 và GPT-5.6 Sol trong Apidog

Đừng chọn model chỉ dựa trên benchmark công khai. Hãy chạy workload thật của bạn trên cả hai.

Trong Apidog, tạo hai request POST:

Một request đến API Moonshot với model kimi-k3.
Một request đến API OpenAI với model gpt-5.6-sol.
Dùng cùng system prompt, user prompt và dữ liệu đầu vào.
Lưu API key bằng biến môi trường.
So sánh response, token usage, latency và chi phí.

Ví dụ biến môi trường:

MOONSHOT_API_KEY=your_moonshot_key
OPENAI_API_KEY=your_openai_key

Ví dụ body dùng chung:

{
  "model": "{{model_id}}",
  "temperature": 0,
  "messages": [
    {
      "role": "system",
      "content": "Bạn là trợ lý kỹ thuật. Trả lời ngắn gọn, chính xác và nêu rõ giả định."
    },
    {
      "role": "user",
      "content": "{{prompt}}"
    }
  ]
}

Để đánh giá công bằng, hãy chuẩn bị bộ test gồm:

Prompt RAG có nguồn.
Tác vụ tóm tắt tài liệu dài.
Tác vụ phân loại có schema cố định.
Bài toán coding từ repository thật.
Tác vụ gọi tool hoặc lập kế hoạch nhiều bước.
Prompt cần kiểm soát độ dài đầu ra.

Tải Apidog để thiết lập môi trường test. Nếu bạn làm việc trong editor, Apidog trong VS Code giúp giữ vòng lặp API test cạnh mã nguồn.

Kết luận

Kimi K3 và GPT-5.6 Sol tối ưu cho hai hệ giá trị khác nhau.

GPT-5.6 Sol phù hợp khi bạn cần chất lượng tiên phong, khả năng suy luận cao và dịch vụ được quản lý.
Kimi K3 phù hợp khi bạn cần trọng số mở, tự lưu trữ, dữ liệu nội bộ, ngữ cảnh 1 triệu token hoặc tối ưu chi phí bằng cache-hit.

Nếu không chắc, đừng cam kết sớm. Vì cả hai hỗ trợ API tương thích OpenAI, hãy gửi cùng một prompt, đo chất lượng và chi phí trên dữ liệu thực tế, rồi để số liệu quyết định.

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

Kimi K3 có tốt hơn GPT-5.6 Sol không?

Không phải về chất lượng hàng đầu tổng thể. Moonshot cho biết K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol về năng lực tổng thể. K3 mạnh hơn về tính mở, ngữ cảnh 1M token và khả năng kiểm soát chi phí.

Có benchmark trực tiếp giữa K3 và Sol không?

Có, nhưng hiện chỉ có bảng do Moonshot tự công bố. K3 thắng BrowseComp, Automation Bench và SpreadsheetBench 2; Sol thắng Terminal-Bench 2.1 và DeepSWE. Hãy xem đây là số liệu định hướng cho đến khi có thử nghiệm độc lập.

Tôi có thể tự lưu trữ Kimi K3 không?

Có, khi trọng số được mở vào khoảng ngày 27 tháng 7 năm 2026. Khi đó, bạn có thể chạy K3 trên hạ tầng riêng, tinh chỉnh theo miền và giữ dữ liệu nội bộ. GPT-5.6 Sol chỉ có dạng model đóng được lưu trữ.

Kimi K3 có giá bao nhiêu?

K3 có giá $0,30/M token đầu vào cache-hit, $3,00/M token đầu vào cache-miss và $15,00/M token đầu ra. Cache-hit đặc biệt hữu ích cho workload tái sử dụng prompt hoặc context cố định. Với GPT-5.6 Sol, hãy kiểm tra bảng giá hiện tại của OpenAI.

Điểm chuẩn Kimi K3: Số liệu Moonshot so với Kiểm tra độc lập

Sebastian Petrus — Fri, 17 Jul 2026 05:19:54 +0000

Khi một mô hình mới ra mắt, thường có hai nhóm số liệu không hoàn toàn khớp nhau: số liệu do phòng thí nghiệm công bố và kết quả từ kiểm thử viên độc lập. Kimi K3, được Moonshot AI phát hành vào ngày 16 tháng 7 năm 2026, là ví dụ rõ ràng cho cách đọc hai nhóm dữ liệu này. Theo nguồn độc lập, mô hình có năng lực tốt nhưng không nhanh; theo Moonshot, K3 đạt “cấp độ tiên tiến” trên bộ đánh giá của họ nhưng vẫn kém các hệ thống độc quyền hàng đầu. Bài viết này tách từng tuyên bố để bạn biết số liệu nào đã được xác minh, số liệu nào là do nhà cung cấp công bố và phần nào vẫn cần tự kiểm thử.

Dùng thử Apidog ngay hôm nay

TL;DR: Kimi K3 thực sự được đánh giá như thế nào

Trên Chỉ số Thông minh của Artificial Analysis, Kimi K3 đạt 57 điểm, xếp hạng #4 trong 189 mô hình. Đây là kết quả độc lập và là chỉ dấu đáng tin cậy nhất về năng lực tổng quát.

Tuy nhiên, tốc độ xuất liệu của K3 vào khoảng 62 token/giây, thấp hơn mức trung vị 72,7 token/giây trong phân khúc giá. Điều đó khiến K3 phù hợp hơn với tác vụ lập luận, xử lý theo lô hoặc phân tích hơn là luồng tương tác yêu cầu phản hồi nhanh.

Moonshot công bố K3 có “hiệu suất cấp độ tiên tiến trên bộ đánh giá của chúng tôi”, nhưng cũng thừa nhận K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol ở năng lực tổng thể. Các điểm chuẩn tác nhân như BrowseComp, Automation Bench và SpreadsheetBench 2 có kết quả mạnh, nhưng đây là số liệu do nhà cung cấp tự chạy và chưa được tái kiểm chứng độc lập.

💡 Điểm chuẩn quan trọng nhất là điểm bạn tự chạy trên khối lượng công việc của mình. Hãy dùng một client tương thích OpenAI như Apidog để trỏ tới điểm cuối kimi-k3, sau đó đo độ trễ, chi phí và chất lượng đầu ra trên các prompt thực tế. Kết quả đó có giá trị hơn bất kỳ bảng xếp hạng công khai nào khi quyết định có đưa K3 vào hệ thống hay không.

Ba tuyên bố, được tách bạch

Các buổi ra mắt mô hình thường trộn ba loại tuyên bố vào cùng một thông điệp tiếp thị. Tách chúng ra giúp bạn đánh giá chính xác hơn. Nếu cần thông tin về kiến trúc và giá, xem bài viết Kimi K3 là gì; phần này tập trung vào dữ liệu đánh giá.

Tuyên bố 1: điểm neo độc lập từ Artificial Analysis

Artificial Analysis là bên thứ ba: họ mua quyền truy cập API, chạy bộ đánh giá cố định và công bố kết quả mà không có sự can thiệp từ phòng thí nghiệm. Vì vậy, đây là nhóm số liệu có trọng lượng cao nhất.

Các số liệu độc lập chính của Kimi K3:

Chỉ số Thông minh: 57 — chỉ số tổng hợp cho lập luận, kiến thức và mã hóa.
Xếp hạng: #4 trong 189 mô hình — chỉ có ba mô hình đạt điểm cao hơn tại thời điểm viết bài.
Tốc độ xuất liệu: khoảng 62 token/giây — thấp hơn trung vị phân khúc là 72,7 token/giây.
Thời gian đến token đầu tiên: khoảng 2 giây — có độ trễ khởi đầu trước khi mô hình bắt đầu sinh nội dung.

Các con số này cho thấy K3 mạnh về năng lực tổng quát nhưng không tối ưu về tốc độ.

Điều đó ảnh hưởng trực tiếp đến cách triển khai:

Với xử lý theo lô qua đêm, tốc độ thấp hơn thường không phải vấn đề lớn.
Với chatbot, copilot hoặc trợ lý lập trình tương tác, 62 token/giây có thể tạo cảm giác chậm khi phản hồi dài.
Với API cần SLA độ trễ chặt, hãy kiểm thử bằng prompt và độ dài đầu ra thực tế thay vì chỉ dựa vào tốc độ trung bình.

Tuyên bố 2: những gì Moonshot công bố

Bài đăng ra mắt của Moonshot là tài liệu từ nhà cung cấp. Họ mô tả K3 có “hiệu suất cấp độ tiên tiến trên bộ đánh giá của chúng tôi, liên tục vượt trội các mô hình khác đã được thử nghiệm”.

Cụm từ quan trọng là “bộ đánh giá của chúng tôi”. Việc một nhà cung cấp chọn benchmark phù hợp không đồng nghĩa với gian lận, nhưng đó vẫn là một lợi thế sân nhà. Hãy xem các kết quả này là tín hiệu định hướng, không phải kết luận cuối cùng.

Một tuyên bố phụ từ các báo cáo ra mắt cho biết K3 đứng đầu 4 trong 8 benchmark tự động hóa thực tế, gồm Automation Bench, SpreadsheetBench 2 và BrowseComp, đồng thời xếp sau Claude Fable 5 ở nhiều benchmark khác. Vì chưa có bên độc lập tái kiểm chứng, hãy phân loại dữ liệu này là:

Thú vị, có số liệu công khai, nhưng chưa được xác nhận độc lập.

Tuyên bố 3: giới hạn mà Moonshot thừa nhận

Câu đáng chú ý nhất trong bài đăng ra mắt là Moonshot thừa nhận hiệu suất tổng thể của K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol.

Đây là thông tin cần dùng để đặt kỳ vọng triển khai:

Với các tác vụ khó nhất, Moonshot tự xác nhận các mô hình độc quyền hàng đầu vẫn có lợi thế về năng lực thô.
Giá trị của K3 không phải là “đánh bại mọi mô hình”, mà là đưa chất lượng cận tiên phong vào một mô hình mở với chi phí thấp hơn.
Nếu workload của bạn yêu cầu năng lực cực đại, hãy benchmark K3 cùng các mô hình độc quyền trước khi chuyển đổi.

Xem thêm các bài so sánh trực tiếp:

Số liệu độc lập và số liệu nhà cung cấp

Tuyên bố	Ai công bố	Điều được đo	Mức độ đáng tin cậy
Chỉ số Thông minh 57, xếp hạng #4/189	Artificial Analysis	Năng lực tổng quát	Cao: bên thứ ba, bộ đánh giá cố định
Đầu ra khoảng 62 token/giây, trung vị phân khúc 72,7	Artificial Analysis	Thông lượng sinh nội dung	Cao: được đo và có thể tái kiểm chứng
Thời gian đến token đầu tiên khoảng 2 giây	Artificial Analysis	Khả năng phản hồi	Cao: số liệu đo lường trực tiếp
“Hiệu suất cấp độ tiên phong trên bộ đánh giá của chúng tôi”	Moonshot	Benchmark do nhà cung cấp chọn	Có tính định hướng
Dẫn đầu BrowseComp, Automation Bench, SpreadsheetBench 2; thứ 2 Terminal-Bench 2.1; thứ 3 DeepSWE	Moonshot	Hiệu năng tác vụ tác nhân	Trung bình: có số liệu nhưng chưa được tái kiểm chứng
Kém Claude Fable 5 và GPT-5.6 Sol nói chung	Moonshot	Giới hạn so với mô hình độc quyền	Cao: nhà cung cấp tự thừa nhận giới hạn
Điểm mã hóa tái kiểm chứng và SWE-bench Verified cổ điển	Chưa có	Năng lực mã hóa cụ thể	Chưa được công bố độc lập

Mẫu hình quan trọng là:

Dữ liệu độc lập xác nhận năng lực tổng quát và tốc độ.
Dữ liệu cấp tác vụ có tồn tại nhưng chủ yếu do Moonshot tự chạy.
Khoảng trống giữa hai nhóm này là nơi benchmark nội bộ của bạn có giá trị nhất.

Bảng sau là kết quả Moonshot công bố ở cấu hình lập luận tối đa:

Điểm chuẩn	Kimi K3	Claude Fable 5	GPT-5.6 Sol	Claude Opus 4.8
Terminal-Bench 2.1	88,3	84,6	88,8	84,6
DeepSWE	67,5	70,0	73,0	59,0
BrowseComp	91,2	88,0	90,4	84,3
Automation Bench	30,8	29,1	29,7	27,2
SpreadsheetBench 2	34,8	34,7	32,4	31,6

K3 vượt Claude Fable 5 và Claude Opus 4.8 trên bốn trong năm benchmark này, đồng thời vượt GPT-5.6 Sol trên BrowseComp, Automation Bench và SpreadsheetBench 2.

Tuy vậy, ở DeepSWE — benchmark mã hóa tác nhân khó nhất trong bảng — K3 đứng sau cả Sol và Fable 5. Điều này phù hợp với nhận định của Moonshot rằng K3 vẫn kém các mô hình độc quyền hàng đầu về năng lực tổng thể.

Những gì vẫn còn thiếu

Một đánh giá trung thực cần nêu rõ phần chưa biết. Với Kimi K3, các khoảng trống chính gồm:

Điểm mã hóa độc lập

Moonshot đã công bố Terminal-Bench 2.1 và DeepSWE, nhưng Artificial Analysis chỉ đưa mã hóa vào chỉ số tổng hợp. Hiện chưa có điểm SWE-bench Verified độc lập cho K3. Nếu gặp phần trăm SWE-bench cụ thể, hãy kiểm tra xem đó là kết quả Moonshot tự chạy hay ước tính.
Kết quả tự động hóa được tái kiểm chứng

Một bên thứ ba vẫn cần chạy lại Automation Bench, SpreadsheetBench 2 và BrowseComp với phương pháp công khai. Benchmark tác nhân nhạy cảm với scaffolding, định dạng prompt và cơ chế retry, nên kết quả giữa các tổ chức có thể khác nhau đáng kể.
Chất lượng ngữ cảnh dài ở 1 triệu token

Cửa sổ ngữ cảnh 1 triệu token không tự động đảm bảo khả năng truy xuất chính xác trên toàn bộ ngữ cảnh. Nếu ứng dụng của bạn xử lý tài liệu dài, hãy kiểm tra trực tiếp ở độ dài 32K, 128K, 500K hoặc mức bạn thực sự sử dụng.

Moonshot cũng cam kết phát hành toàn bộ trọng số mở sau khi ra mắt. Khi đó, benchmark cộng đồng có thể xác nhận hoặc làm thay đổi nhận định ban đầu.

Không có số liệu không có nghĩa là số liệu xấu — chỉ có nghĩa là chưa có ai công bố dữ liệu độc lập.

Cách đọc benchmark của nhà cung cấp

Dùng checklist sau trước khi đưa một số liệu benchmark vào quyết định kỹ thuật:

Ai thực hiện benchmark?

Bên thứ ba đáng tin hơn tự báo cáo. Nếu phòng thí nghiệm tự chạy, hãy giả định việc chọn cấu hình có thể có lợi cho họ.
Tên benchmark và phiên bản có rõ ràng không?

“SWE-bench Verified” có thể được tái tạo. “Bộ công cụ mã hóa nội bộ” thì không.
Có chỉ số nào bị bỏ qua không?

Biểu đồ chỉ hiển thị ba chiến thắng không nói lên kết quả ở các benchmark còn lại.
Nhà cung cấp có nêu giới hạn không?

Việc Moonshot nêu rõ K3 kém Fable 5 và Sol đáng tin hơn một tuyên bố chiến thắng tuyệt đối.
Tuyên bố có khớp với nguồn độc lập không?

Khi dữ liệu nhà cung cấp và nguồn trung lập mâu thuẫn, ưu tiên nguồn trung lập.

Áp dụng checklist này cho K3:

Chỉ số độc lập xác nhận K3 có năng lực tổng quát mạnh.
Moonshot thừa nhận giới hạn của mô hình.
Các tuyên bố về tự động hóa chưa vượt qua bước kiểm tra độc lập.

Tham khảo thêm:

Thử nghiệm thực tế: đánh giá K3 cho tác vụ của bạn

Bảng xếp hạng công khai trả lời câu hỏi chung: mô hình này mạnh đến đâu trên trung bình?

Quyết định triển khai cần trả lời câu hỏi cụ thể hơn: mô hình này thực hiện workload của bạn tốt đến đâu?

Dùng quy trình sau để benchmark K3:

Tạo golden set gồm 20–50 prompt thực tế

Thu thập ticket thật, thay đổi mã thật, câu hỏi hỗ trợ thật hoặc tài liệu thật. Nếu có thể, lưu đầu ra kỳ vọng hoặc tiêu chí chấm điểm.
Cố định cấu hình

Ghim model ID kimi-k3, temperature, system prompt và max_tokens. Chỉ thay đổi một biến cho mỗi lần thử nghiệm.
Đo bốn nhóm chỉ số cho mỗi prompt
- Chất lượng: đầu ra có giải quyết được tác vụ không?
- Độ trễ: thời gian đến token đầu tiên và tổng thời gian hoàn thành.
- Chi phí: token đầu vào + token đầu ra nhân với giá.
- Tính nhất quán: chạy nhiều lần để phát hiện biến động.
So sánh với mô hình hiện tại

Chạy cùng golden set với mô hình bạn đang dùng. Chỉ chuyển đổi khi K3 tốt hơn ở chỉ số thực sự quan trọng với sản phẩm.

Ví dụ, bạn có thể gửi cùng một yêu cầu tương thích OpenAI tới nhiều endpoint:

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "temperature": 0,
    "max_tokens": 1200,
    "messages": [
      {
        "role": "system",
        "content": "Bạn là trợ lý lập trình. Chỉ trả về thay đổi cần thiết."
      },
      {
        "role": "user",
        "content": "Tối ưu hàm xử lý danh sách sau..."
      }
    ]
  }'

Lưu lại các trường sau cho từng lần chạy:

{
  "model": "kimi-k3",
  "prompt_id": "bugfix-014",
  "ttft_ms": 2000,
  "total_latency_ms": 8400,
  "input_tokens": 920,
  "output_tokens": 740,
  "quality_score": 4,
  "passed": true
}

Apidog giúp bạn tổ chức quy trình này bằng cách lưu golden set thành collection có thể tái sử dụng, ghim tham số yêu cầu, theo dõi phản hồi streaming và đọc số token để tính chi phí. Bạn có thể chạy lại toàn bộ collection với model khác chỉ bằng cách đổi endpoint.

Nếu bạn làm việc trong IDE, hãy gửi các yêu cầu tương tự từ bên trong VS Code. Khi sẵn sàng, hãy tải xuống Apidog và tạo request mới trỏ tới endpoint của Moonshot.

Chọn chỉ số theo dạng tác vụ

Trợ lý lập trình

Độ trễ là chỉ số chi phối. Với khoảng 62 token/giây, completion dài sẽ có thời gian hiển thị đáng kể. Hãy benchmark bằng độ dài completion trung bình thực tế của bạn và so sánh với một mô hình nhanh hơn.
Trích xuất dữ liệu theo lô

Thông lượng thường ít quan trọng hơn chất lượng và chi phí mỗi token. Đây là trường hợp K3 có thể phù hợp nếu năng lực lập luận giúp giảm lỗi trích xuất.
Phân tích tài liệu dài

Kiểm tra tại độ dài ngữ cảnh thực tế. Đừng chỉ kiểm tra ở 32K nếu production của bạn dùng 500K token. Cửa sổ 1M là giới hạn hỗ trợ, không phải bảo đảm về chất lượng.
Tự động hóa tác nhân

Đây là khu vực có tuyên bố “4 trên 8” chưa được xác minh. Hãy xây dựng một agent loop tối giản với task thực tế, chạy nhiều lần và đo tỷ lệ hoàn thành thay vì dựa vào quảng cáo.

Bạn cũng có thể gọi K3 qua một bộ tổng hợp nếu không muốn quản lý khóa trực tiếp. Danh sách OpenRouter cho moonshotai/kimi-k3 cung cấp cùng mô hình qua tuyến tương thích OpenAI.

Vị trí thực sự của K3

Bỏ qua sự ồn ào của ngày ra mắt, Kimi K3 là một mô hình tổng quát mạnh với giới hạn rõ ràng:

Đánh giá độc lập xác nhận năng lực cao: #4 trong 189 mô hình.
Tốc độ là điểm yếu thực tế: khoảng 62 token/giây, ảnh hưởng rõ tới workload tương tác.
Các chiến thắng benchmark tác nhân do Moonshot công bố là tín hiệu tích cực, nhưng chưa phải bằng chứng độc lập.
Moonshot tự thừa nhận K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol ở năng lực tổng thể.

Hãy coi bản phát hành là điểm bắt đầu của bằng chứng, không phải kết luận cuối cùng. Đo K3 trên workload của bạn, với prompt, độ trễ, cấu hình và tiêu chí chất lượng thực tế. Sau đó, để dữ liệu nội bộ quyết định.

Để cân nhắc giá trị theo chi phí, xem thêm bài phân tích giá của Kimi K3.

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

Điểm benchmark của Kimi K3 là bao nhiêu?

Trên Chỉ số Thông minh độc lập của Artificial Analysis, Kimi K3 đạt 57 điểm và xếp #4 trong 189 mô hình. Moonshot cũng công bố điểm Terminal-Bench 2.1 và DeepSWE, nhưng chưa có bên độc lập tái kiểm chứng đầy đủ các benchmark mã hóa của K3. Vì vậy, Chỉ số Thông minh hiện là số liệu trung lập tốt nhất.

Kimi K3 có nhanh hơn các mô hình khác không?

Không. Tốc độ xuất liệu đo được vào khoảng 62 token/giây, thấp hơn mức trung vị 72,7 token/giây của phân khúc giá. Thời gian đến token đầu tiên khoảng 2 giây. K3 phù hợp hơn với xử lý theo lô và phân tích so với tác vụ tương tác nhạy cảm với độ trễ.

Kimi K3 có đánh bại Claude Fable 5 hoặc GPT-5.6 Sol không?

Không phải trên năng lực tổng thể, theo chính Moonshot. K3 có kết quả tốt trên một số benchmark tự động hóa do Moonshot công bố, nhưng các kết quả đó chưa được xác nhận độc lập. Với các tác vụ tiên phong khó nhất, Fable 5 và Sol vẫn dẫn trước theo mô tả của Moonshot.

Tôi nên đánh giá Kimi K3 cho use case của mình như thế nào?

Tạo golden set gồm 20–50 prompt thực tế, cố định model ID và tham số, sau đó đo chất lượng, độ trễ, chi phí và tính nhất quán. Chạy cùng bộ prompt trên kimi-k3 và mô hình hiện tại để có so sánh công bằng. Các công cụ như Apidog có thể lưu các request này thành collection tái sử dụng và giúp bạn chạy lại benchmark nhất quán.

Cách sử dụng Kimi K3 miễn phí

Sebastian Petrus — Fri, 17 Jul 2026 05:11:38 +0000

Moonshot AI đã ra mắt Kimi K3 vào ngày 16 tháng 7 năm 2026. Đây được mô tả là mô hình mã nguồn mở 3T-class đầu tiên: kiến trúc mixture-of-experts (MoE) với 2,8 nghìn tỷ tham số và cửa sổ ngữ cảnh 1 triệu token. Câu hỏi thực tế hơn là: có thể dùng Kimi K3 miễn phí không? Có, nhưng mỗi lựa chọn đều có giới hạn về hạn mức, độ ổn định hoặc chi phí hạ tầng.

Dùng thử Apidog ngay hôm nay

Hướng dẫn này liệt kê các cách tiếp cận miễn phí hoặc gần miễn phí, cách kiểm tra giới hạn thực tế và cách gọi API mà không lãng phí hạn mức. Nếu bạn từng làm theo hướng dẫn sử dụng Kimi K2.7 Code miễn phí, quy trình phân phối của Moonshot sẽ khá quen thuộc.

TL;DR

Cách nhanh nhất là dùng gói miễn phí trên ứng dụng Kimi hoặc Kimi.com. Đăng nhập, trò chuyện và dùng Kimi Code/Kimi Work trong hạn mức hiện tại của tài khoản.
OpenRouter cung cấp moonshotai/kimi-k3 qua API tương thích OpenAI. Kiểm tra xem tại thời điểm gọi có lộ trình miễn phí hoặc khuyến mãi hay không.
Tự lưu trữ chưa khả thi vào ngày ra mắt. Moonshot cho biết trọng số đầy đủ dự kiến phát hành ngày 27 tháng 7 năm 2026. Mô hình MoE 2,8T vẫn cần hạ tầng GPU rất mạnh.
API Kimi có thể có tín dụng dùng thử hoặc ưu đãi cho tài khoản mới. Kiểm tra trực tiếp trong dashboard thay vì dựa vào số dư được đăng trên blog.
Khi đã có API key, hãy dùng Apidog để kiểm tra request, lưu biến môi trường và tái sử dụng payload thay vì thử đi thử lại trong ứng dụng Kimi.

Lưu ý: Theo bài đăng ra mắt của Moonshot, K3 vẫn đứng sau Claude Fable 5 và GPT-5.6 Sol trong các benchmark của họ. Trên Artificial Analysis, mô hình đạt Chỉ số Thông minh 57 và đứng thứ tư trong 189 mô hình được theo dõi. Hãy đánh giá K3 bằng workload thực tế của bạn thay vì chỉ dựa vào thông số.

“Miễn phí” thực sự nghĩa là gì?

Với mô hình ngôn ngữ lớn, “miễn phí” hiếm khi đồng nghĩa với không giới hạn. Thường sẽ thuộc một trong bốn dạng sau:

Giới hạn tỷ lệ: Có hạn mức theo giờ, ngày, số tin nhắn hoặc token. Khi chạm giới hạn, bạn phải chờ hoặc chuyển sang trả phí.
Định tuyến được trợ cấp: Nhà tổng hợp như OpenRouter có thể cung cấp route khuyến mãi hoặc giá rất thấp. Route này có thể biến mất hoặc thay đổi giới hạn.
Dùng phần cứng của bạn: Không mất phí theo token, nhưng bạn trả tiền GPU, điện, lưu trữ và vận hành.
Tín dụng dùng thử: Được cấp số dư ban đầu để đánh giá API. Số dư này có thể hết hạn hoặc bị giới hạn.

Ngoài chi phí, hãy xem xét chính sách dữ liệu. Nếu bạn gửi mã độc quyền hoặc dữ liệu khách hàng, hãy đọc điều khoản lưu giữ dữ liệu trước khi dùng gói tiêu dùng miễn phí. Để hiểu thêm về kiến trúc và định vị mô hình, xem bài Kimi K3 là gì.

Phương pháp 1: Dùng ứng dụng Kimi hoặc Kimi.com

Đây là lựa chọn nên thử đầu tiên nếu bạn chỉ muốn kiểm tra khả năng của K3 mà chưa cần tích hợp API.

Cách bắt đầu

Cài đặt hoặc cập nhật ứng dụng Kimi trên iOS, Android hoặc HarmonyOS.
Hoặc truy cập kimi.com.
Đăng nhập bằng tài khoản Kimi.
Kiểm tra mô hình đang được sử dụng và chỉ báo hạn mức trong ứng dụng trước khi chạy các tác vụ dài.

Bạn nhận được gì?

Gói miễn phí bao gồm trò chuyện tổng quát và các giao diện chuyên biệt:

Kimi Code: Làm việc với mã trong terminal. Dùng lệnh /model bên trong công cụ để chọn mô hình. Quy trình tương tự như trong hướng dẫn Kimi CLI.
Kimi Work: Ứng dụng năng suất cho desktop, yêu cầu phiên bản 3.1.0 trở lên và hỗ trợ Windows cùng máy Mac Apple silicon.

Cách tránh hết hạn mức quá nhanh

Dùng prompt ngắn trước, chỉ mở rộng ngữ cảnh khi cần.
Chia công việc lớn thành các tác vụ nhỏ.
Không liên tục gửi toàn bộ repository hoặc log dài vào mỗi lượt.
Kiểm tra chỉ báo sử dụng trực tiếp trong ứng dụng vì Moonshot không công bố một hạn mức token miễn phí cố định.

Phù hợp nhất cho: thử mô hình, chat hàng ngày và hỗ trợ code nhẹ.

Phương pháp 2: Gọi `moonshotai/kimi-k3` qua OpenRouter

Nếu cần gọi K3 từ ứng dụng hoặc workflow, OpenRouter là con đường API ngắn nhất. Mô hình được cung cấp qua slug:

moonshotai/kimi-k3

API tương thích định dạng OpenAI, nên bạn chủ yếu cần thay base URL và API key.

Request tối thiểu với cURL

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Refactor this function for readability."
      }
    ]
  }'

Ví dụ JavaScript

const response = await fetch(
  "https://openrouter.ai/api/v1/chat/completions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "moonshotai/kimi-k3",
      messages: [
        {
          role: "user",
          content: "Refactor this function for readability.",
        },
      ],
    }),
  }
);

const data = await response.json();
console.log(data.choices?.[0]?.message?.content);

Cách kiểm tra khả năng dùng miễn phí

Mở trang model trên OpenRouter.
Kiểm tra các provider route, giá và nhãn khuyến mãi hiện tại.
Đọc rate limit trước khi đưa route vào workflow.
Chuẩn bị fallback model hoặc route trả phí nếu request quan trọng.

Route miễn phí trên nền tảng tổng hợp có thể bị điều tiết, xếp hàng hoặc rút lại mà không báo trước. Không nên dùng route miễn phí làm hạ tầng production duy nhất.

Để xem thêm về xác thực, endpoint và request của bên thứ nhất, đọc hướng dẫn API Kimi K3.

Phương pháp 3: Tự lưu trữ sau khi phát hành trọng số

Kimi K3 được giới thiệu là mô hình mã nguồn mở 3T-class, nhưng cần phân biệt rõ giữa thông báo ra mắt và thời điểm phát hành trọng số.

Theo Moonshot, trọng số đầy đủ dự kiến được phát hành ngày 27 tháng 7 năm 2026. Điều đó có nghĩa là tự lưu trữ chưa phải lựa chọn có thể thực hiện ngay tại ngày ra mắt.

Cần theo dõi ở đâu?

Khi phát hành chính thức, hãy theo dõi:

Trang Moonshot AI trên Hugging Face
Blog chính thức của Kimi

Không tải “trọng số K3” từ nguồn không chính thức trước thông báo phát hành. Các file như vậy không thể được xác minh là trọng số chính thức.

Thực tế phần cứng

K3 là mô hình MoE 2,8T tham số. Dù chỉ kích hoạt 16 trong 896 chuyên gia cho mỗi token, hệ thống vẫn cần đủ bộ nhớ để chứa toàn bộ tập tham số.

Với hầu hết cá nhân, chạy đầy đủ độ chính xác tại nhà là không thực tế. Lựa chọn khả thi hơn sau khi phát hành thường là:

Chờ bản lượng tử hóa từ cộng đồng.
Đánh giá đánh đổi chất lượng so với dung lượng VRAM/RAM.
Chạy thử bằng GPU thuê trước khi đầu tư hạ tầng dài hạn.
Chỉ tự host nếu yêu cầu quyền riêng tư hoặc kiểm soát dữ liệu đủ quan trọng.

Nếu bạn đã từng chạy các model Kimi trước đó, xem hướng dẫn chạy Kimi K2.5 cục bộ để hiểu các công cụ và đánh đổi thường gặp.

Điểm chính: tự host loại bỏ phí theo token, nhưng thay bằng chi phí GPU, setup và vận hành. Nó chỉ “miễn phí” nếu bạn đã có phần cứng phù hợp.

Phương pháp 4: Tín dụng dùng thử hoặc khuyến mãi API Kimi

API Kimi của bên thứ nhất là dịch vụ trả phí. Các mức giá được nêu gồm:

Loại token	Giá
Token đầu vào có cache hit	0,30 USD / 1 triệu token
Token đầu vào không có cache hit	3,00 USD / 1 triệu token
Token đầu ra	15,00 USD / 1 triệu token

Đây không phải gói miễn phí. Tuy nhiên, tài khoản mới có thể nhận tín dụng khởi đầu hoặc ưu đãi ra mắt tùy từng thời điểm.

Cách kiểm tra tín dụng hiện có

Đăng nhập dashboard nhà phát triển Kimi.
Tạo hoặc mở API key.
Kiểm tra số dư tài khoản.
Kiểm tra khu vực promotion, billing hoặc trial credits.
Xác nhận ngày hết hạn trước khi tích hợp vào workflow.

Đừng lập kế hoạch ngân sách dựa trên một con số đọc từ bài blog. Chỉ số dư hiển thị trong dashboard của bạn tại thời điểm hiện tại mới đáng tin cậy.

Tín dụng dùng thử phù hợp để đánh giá endpoint chính thức, đo độ trễ và kiểm tra hành vi production. Nó không phù hợp cho workload dài hạn. Xem thêm bài phân tích giá Kimi K3.

So sánh các lựa chọn

Phương pháp	Chi phí thực tế	Nỗ lực thiết lập	Tính ổn định	Phù hợp nhất cho
Ứng dụng Kimi / Kimi.com	Miễn phí, có rate limit	Chỉ cần đăng nhập	Ổn định trong hạn mức	Dùng thử, chat, code nhẹ
OpenRouter `moonshotai/kimi-k3`	Route miễn phí hoặc chi phí thấp	Thấp, đổi base URL	Route miễn phí có thể bị điều tiết hoặc biến mất	Prototype API
Tự lưu trữ	Không phí theo token, phần cứng đắt	Cao	Bạn tự vận hành	Quyền riêng tư, team có GPU
Tín dụng dùng thử API Kimi	Miễn phí đến khi hết tín dụng	Thấp, tạo API key	Có giới hạn và có thể hết hạn	Đánh giá endpoint chính thức

Quy luật chung rất đơn giản:

Con đường dễ nhất thường chạm giới hạn nhanh nhất.
Con đường kiểm soát cao nhất thường đòi hỏi phần cứng hoặc thời gian nhiều nhất.
Không có lựa chọn nào đồng thời miễn phí, không giới hạn và phù hợp production.

Kiểm tra API Kimi K3 bằng Apidog

Khi có API key từ OpenRouter hoặc Kimi, đừng dùng chat UI để thử từng biến thể request. Hãy tạo request có thể tái sử dụng trong một API client để tiết kiệm hạn mức.

Trong Apidog, bạn có thể:

Tạo request POST.
Đặt endpoint OpenRouter:

   https://openrouter.ai/api/v1/chat/completions

Thêm header:

   Authorization: Bearer {{OPENROUTER_API_KEY}}
   Content-Type: application/json

Lưu API key dưới dạng biến môi trường thay vì ghi trực tiếp vào request.
Đặt body JSON:

   {
     "model": "moonshotai/kimi-k3",
     "messages": [
       {
         "role": "user",
         "content": "Explain this API response and suggest error handling."
       }
     ]
   }

Gửi request, kiểm tra response và lưu request thành template để dùng lại.
Khi request hoạt động, chuyển nó thành tài liệu chia sẻ hoặc test case.

Với API Kimi của bên thứ nhất, giữ nguyên cấu trúc request theo tài liệu endpoint của Kimi và thay model ID tương ứng, chẳng hạn kimi-k3.

Cùng workflow này cũng có thể dùng qua tiện ích mở rộng Apidog trong VS Code. Bạn có thể tải Apidog để lưu request, quản lý biến môi trường và kiểm tra API mà không lãng phí hạn mức vào thao tác thủ công.

Kết luận

Nếu chỉ muốn thử Kimi K3, hãy bắt đầu bằng ứng dụng Kimi hoặc Kimi.com. Nếu đang xây dựng ứng dụng, hãy kiểm tra route moonshotai/kimi-k3 trên OpenRouter và dùng API client để chuẩn hóa request. Nếu quyền riêng tư là yêu cầu bắt buộc, hãy theo dõi thời điểm phát hành trọng số và chuẩn bị kế hoạch GPU trước khi tự host.

Tóm lại:

Dùng ứng dụng Kimi cho thử nghiệm nhanh.
Dùng OpenRouter cho prototype qua API.
Kiểm tra trial credits của Kimi nếu cần đánh giá API chính thức.
Chờ trọng số chính thức nếu muốn tự host.
Dùng Apidog để mỗi token miễn phí được dùng cho việc kiểm thử thực tế thay vì lặp lại thao tác cấu hình.

FAQ

Kimi K3 có miễn phí sử dụng không?

Có. Ứng dụng Kimi và Kimi.com có gói miễn phí cho trò chuyện, Kimi Code và Kimi Work, nhưng bị giới hạn bởi rate limit có thể thay đổi. API Kimi của bên thứ nhất là trả phí, dù tài khoản mới có thể có tín dụng dùng thử.

Tôi có thể tải trọng số Kimi K3 và tự chạy ngay không?

Không phải tại thời điểm ra mắt. Moonshot cho biết trọng số đầy đủ dự kiến phát hành vào ngày 27 tháng 7 năm 2026. Sau đó, hãy theo dõi trang Moonshot trên Hugging Face và blog Kimi chính thức. Do đây là mô hình MoE 2,8T, hầu hết cá nhân sẽ cần chờ bản lượng tử hóa từ cộng đồng.

API Kimi K3 giá bao nhiêu khi hết hạn mức miễn phí?

Giá được nêu là 0,30 USD cho 1 triệu token đầu vào có cache hit, 3,00 USD cho 1 triệu token đầu vào không có cache hit và 15,00 USD cho 1 triệu token đầu ra. Cache prompt có thể giảm chi phí thực tế.

Kimi K3 so với các model độc quyền hàng đầu như thế nào?

K3 mạnh, nhưng không được Moonshot định vị là model dẫn đầu tuyệt đối. Theo bài đăng ra mắt, nó vẫn đứng sau Claude Fable 5 và GPT-5.6 Sol trong benchmark của họ. Hãy benchmark bằng dữ liệu và tác vụ thực tế của dự án.

Khác gì so với việc dùng Kimi K2.7 miễn phí?

Các cửa truy cập miễn phí phần lớn tương tự. Nếu bạn đã làm theo hướng dẫn dùng Kimi K2.7 Code miễn phí, hãy thay model ID thành kimi-k3 và tiếp tục lưu ý về rate limit, độ ổn định của route và chi phí API.

Giá Kimi K3: Chi phí API và Bài toán Cache-Hit

Sebastian Petrus — Fri, 17 Jul 2026 03:19:08 +0000

Kimi K3 ra mắt vào ngày 16 tháng 7 năm 2026, và bảng giá có vẻ đơn giản cho đến khi bạn nhận thấy nó có hai mức giá đầu vào khác nhau. Moonshot AI niêm yết $0,30 cho mỗi triệu token đối với đầu vào trúng bộ nhớ đệm (cache hit), $3,00 cho mỗi triệu token đối với đầu vào trượt bộ nhớ đệm (cache miss), và $15,00 cho mỗi triệu token đầu ra. Tuy nhiên, con số quyết định hóa đơn hàng tháng không chỉ là giá niêm yết mà là tỷ lệ đầu vào hỗn hợp bạn thực sự trả. Với tác vụ lập trình, tỷ lệ này có thể gần mức $0,30 hơn nhiều so với $3,00. Bài viết này hướng dẫn cách tính chi phí hiệu quả, phân tích một tác vụ cụ thể và so sánh Kimi K3 với Claude Opus 4.8, GPT-5.6 Sol và DeepSeek V4.

Dùng thử Apidog ngay hôm nay

TÓM TẮT

Kimi K3 có giá:

$0,30 / 1M token cho đầu vào trúng bộ nhớ đệm
$3,00 / 1M token cho đầu vào trượt bộ nhớ đệm
$15,00 / 1M token cho đầu ra

Moonshot cung cấp mô hình qua kiến trúc suy luận phân tán Mooncake và báo cáo tỷ lệ trúng bộ nhớ đệm trên 90% cho các tác vụ lập trình. Nếu tỷ lệ này phù hợp với workload của bạn, chi phí đầu vào thực tế sẽ gần mức $0,30 hơn mức $3,00.

Điểm cần tối ưu không phải là đầu vào đã được cache, mà là đầu ra. Tận dụng cache, giữ tiền tố prompt ổn định và giới hạn phản hồi để kiểm soát chi phí. Bạn có thể kiểm tra token usage trên từng phản hồi bằng Apidog khi thử nghiệm mô hình.

Giá niêm yết trong một bảng

Moonshot công bố mức giá sau cho model kimi-k3:

Loại token	Giá trên 1 triệu token
Đầu vào trúng bộ nhớ đệm	$0,30
Đầu vào trượt bộ nhớ đệm	$3,00
Đầu ra	$15,00

Chênh lệch giá là yếu tố quan trọng:

Đầu vào trượt cache đắt gấp 10 lần đầu vào trúng cache.
Đầu ra đắt gấp 5 lần đầu vào trượt cache.
Đầu ra đắt gấp 50 lần đầu vào trúng cache.

Nếu giả định mọi token đầu vào đều bị trượt cache, bạn sẽ đánh giá quá cao chi phí đầu vào. Ngược lại, nếu xem đầu ra là chi phí nhỏ, bạn sẽ bỏ qua phần thường chi phối hóa đơn.

Để xem tổng quan về model và vị trí của nó trong bối cảnh hiện tại, hãy đọc bài giải thích Kimi K3. Nếu cần cấu hình request, base URL và SDK, xem hướng dẫn API Kimi K3.

Vì sao giá cache hit thay đổi phép tính

Prompt caching là khác biệt giữa giá bạn nhìn thấy và giá bạn thực sự trả.

Khi gửi request, nhà cung cấp lưu tiền tố prompt đã được token hóa. Nếu request tiếp theo tái sử dụng cùng tiền tố đó, model có thể đọc từ cache thay vì xử lý lại toàn bộ ngữ cảnh. Các token tái sử dụng sẽ được tính theo giá cache hit thay vì cache miss.

Moonshot cho biết Kimi K3 sử dụng kiến trúc suy luận phân tán Mooncake, tách riêng giai đoạn prefill và decode để tái sử dụng tiền tố cache hiệu quả hơn. Công ty báo cáo tỷ lệ cache hit trên 90% với tác vụ lập trình.

Công thức tính giá đầu vào hỗn hợp

Gọi:

h là tỷ lệ cache hit
1 - h là tỷ lệ cache miss
P_hit = $0,30 / 1M token
P_miss = $3,00 / 1M token

Khi đó:

Giá đầu vào hỗn hợp =
  (h × P_hit) + ((1 - h) × P_miss)

Với tỷ lệ cache hit 90%:

0,90 × $0,30 = $0,27
0,10 × $3,00 = $0,30
----------------------
Giá đầu vào hỗn hợp = $0,57 / 1M token

Như vậy, thay vì lập ngân sách theo mức $3,00 / 1M token đầu vào, bạn có thể bắt đầu với mức ước tính khoảng $0,57 / 1M token nếu workload thực tế đạt 90% cache hit.

Với tỷ lệ cache hit 95%:

0,95 × $0,30 = $0,285
0,05 × $3,00 = $0,150
-----------------------
Giá đầu vào hỗn hợp = $0,435 / 1M token

Con số 90% là số liệu Moonshot báo cáo cho tác vụ lập trình. Tỷ lệ thực tế của bạn phụ thuộc vào độ ổn định của prompt prefix. Chat có prompt thay đổi liên tục thường cache kém hơn agent liên tục làm việc với cùng kho mã nguồn.

Ví dụ: chi phí của một tác vụ lập trình tự động

Giả sử bạn chạy một phiên lập trình tự động trên một repository cỡ trung bình.

Trong toàn bộ phiên:

Model đọc 2.000.000 token đầu vào
Model sinh 200.000 token đầu ra
Context được gửi lại qua nhiều lượt, nên tổng token đầu vào cao

Trường hợp 1: Không có cache hit

Đầu vào:
2.000.000 × $3,00 / 1.000.000 = $6,00

Đầu ra:
200.000 × $15,00 / 1.000.000 = $3,00

Tổng chi phí = $9,00

Trường hợp 2: Cache hit 90%

Đầu vào cache hit:
1.800.000 × $0,30 / 1.000.000 = $0,54

Đầu vào cache miss:
200.000 × $3,00 / 1.000.000 = $0,60

Tổng đầu vào = $1,14

Đầu ra:
200.000 × $15,00 / 1.000.000 = $3,00

Tổng chi phí = $4,14

Kết quả:

Hạng mục	Không cache	Cache hit 90%
Chi phí đầu vào	$6,00	$1,14
Chi phí đầu ra	$3,00	$3,00
Tổng chi phí	$9,00	$4,14

Caching giảm tổng chi phí từ $9,00 xuống $4,14, tương đương khoảng 54%.

Lưu ý: cache chỉ giảm chi phí đầu vào. Token đầu ra vẫn có giá $15,00 / 1M token trong cả hai trường hợp.

Đầu vào rẻ, đầu ra là phần cao cấp

Với Kimi K3, đầu ra là phần cần kiểm soát chặt nhất:

Đầu ra $15,00 / 1M token đắt gấp 50 lần đầu vào cache hit.
Đầu ra đắt gấp 5 lần đầu vào cache miss.
Tối ưu đầu ra thường tạo tác động lớn hơn việc cắt giảm context đã được cache.

Việc nên làm

Yêu cầu phản hồi ngắn gọn, ví dụ: chỉ trả về diff, patch hoặc checklist.
Đặt max_tokens khi API hoặc SDK hỗ trợ.
Giữ system prompt, tool schema và context prefix ổn định theo byte.
Gộp các lệnh gọi liên quan vào cùng một phiên có prefix đã “ấm”.
Dùng cùng format prompt giữa các lượt thay vì thay đổi thứ tự hoặc chỉnh sửa nhỏ không cần thiết.

Ví dụ, thay vì yêu cầu:

Phân tích toàn bộ lỗi, giải thích nguyên nhân chi tiết,
đề xuất các phương án, rồi viết code hoàn chỉnh.

Bạn có thể tách thành yêu cầu kiểm soát đầu ra tốt hơn:

Chỉ trả về unified diff để sửa lỗi.
Không giải thích. Tối đa 500 token.

Việc ít hiệu quả hơn bạn nghĩ

Cắt giảm context đầu vào chỉ để tiết kiệm token thường không phải chiến lược tốt khi context đó đang được cache. Việc loại bỏ thông tin hữu ích có thể:

Làm model thiếu ngữ cảnh.
Tăng số lượt hỏi-đáp để làm rõ yêu cầu.
Khiến phản hồi dài hơn và đắt hơn.
Làm giảm chất lượng diff hoặc code được sinh ra.

Với mô hình có cấu trúc giá như Kimi K3, hãy cấp input đủ tốt, sau đó kiểm soát đầu ra bằng prompt và giới hạn token.

So sánh giá: Kimi K3 đứng ở đâu

Mô hình	Đầu vào trên 1M token	Đầu ra trên 1M token	Ghi chú
Kimi K3	$0,30 cache hit / $3,00 cache miss	$15,00	Context 1M, trọng số mở gần 27 tháng 7
Claude Opus 4.8	$5,00	$25,00	Mức cao cấp; cần kiểm tra giá hiện tại
GPT-5.6 Sol	Khoảng $5,00	Khoảng $30,00	Mức flagship; có các mức GPT-5.6 rẻ hơn
DeepSeek V4	Mức giá trị	Mức giá trị	Xác nhận tỷ giá hiện tại

So với Claude Opus 4.8

Theo giá Claude Opus 4.8, đầu vào là $5,00 / 1M token và đầu ra là $25,00 / 1M token.

Với tác vụ mẫu 2M token đầu vào và 200K token đầu ra:

Claude Opus 4.8:
2M đầu vào × $5,00 / 1M = $10,00
200K đầu ra × $25,00 / 1M = $5,00
Tổng = $15,00

Trong khi đó, Kimi K3 với 90% cache hit có tổng chi phí khoảng $4,14.

So sánh này mang tính định hướng vì Anthropic cũng có prompt caching, có thể làm giảm chi phí thực tế của Opus. Tuy nhiên, theo giá niêm yết, Kimi K3 vẫn rẻ hơn ở cả đầu vào lẫn đầu ra.

So với GPT-5.6 Sol

Theo giá GPT-5.6, GPT-5.6 Sol có giá khoảng $5 đầu vào và $30 đầu ra.

Kimi K3 rẻ hơn GPT-5.6 Sol ở mức giá này. Tuy nhiên, GPT-5.6 có các tier Terra và Luna rẻ hơn, nên lựa chọn phụ thuộc vào khả năng bạn cần và mức giá hiện tại.

So với DeepSeek V4

Theo giá DeepSeek V4, DeepSeek V4 là một lựa chọn định vị ở phân khúc giá trị.

DeepSeek có thể có giá đầu ra thô thấp hơn Kimi K3. Ngược lại, Kimi K3 có context 1M và chiết khấu sâu cho đầu vào cache hit. Nếu workload của bạn nặng về input và tái sử dụng prefix tốt, Kimi K3 có thể thu hẹp hoặc đảo ngược khoảng cách chi phí.

Kiểm tra token usage với Apidog

Phép tính cache chỉ hữu ích khi bạn đo được dữ liệu thực tế của mình. Mỗi phản hồi từ Kimi K3 trả về đối tượng usage, bao gồm token đầu vào, token đầu ra và phần token trúng cache.

Bạn có thể dùng Apidog để gửi request đại diện và kiểm tra phản hồi.

Kimi K3 tương thích OpenAI SDK, vì vậy cấu hình request tương tự API kiểu OpenAI:

Base URL của Kimi K3
Bearer token
Model ID: kimi-k3

Ví dụ request:

curl "$KIMI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "system",
        "content": "Bạn là trợ lý lập trình. Chỉ trả về unified diff."
      },
      {
        "role": "user",
        "content": "Sửa lỗi null pointer trong hàm parseConfig."
      }
    ],
    "max_tokens": 800
  }'

Cách đo tỷ lệ cache hit của bạn

Gửi một request đại diện lần đầu.
Gửi lại request đó với system prompt và context prefix không thay đổi.
So sánh trường usage trong hai phản hồi.
Ghi lại token cache hit, cache miss và output token.
Dùng tỷ lệ cache hit thực tế trong công thức chi phí hỗn hợp.

Bạn cũng có thể lưu cùng một request cho kimi-k3 và model hiện tại, sau đó A/B test phản hồi và token usage cạnh nhau. Nếu làm việc trong editor, hãy xem hướng dẫn chạy Apidog bên trong VS Code. Bạn có thể tải xuống Apidog để bắt đầu thử nghiệm.

Phán quyết trung thực

Kimi K3 rẻ ở đầu vào và đắt ở đầu ra.

Mức $0,30 cho cache hit, kết hợp với tỷ lệ trúng cache trên 90% mà Moonshot báo cáo cho tác vụ lập trình, khiến chi phí đầu vào hiệu quả có thể tiến gần mức sàn. Phần cần quản lý chặt hơn là output ở mức $15,00 / 1M token.

So với các đối thủ:

Rẻ hơn Claude Opus 4.8 theo giá niêm yết.
Rẻ hơn GPT-5.6 Sol theo mức giá được nêu.
Có thể cạnh tranh với DeepSeek V4, tùy tỷ trọng input và hiệu quả caching.
Có context 1M và lợi thế lớn khi workload tái sử dụng cùng prompt prefix.

Moonshot xếp Kimi K3 sau Claude Fable 5 và GPT-5.6 Sol về khả năng, đồng thời model chạy chậm hơn một chút so với mức trung bình trong phân khúc giá. Tuy nhiên, nếu workload của bạn phù hợp với caching, Kimi K3 là lựa chọn đáng cân nhắc về chi phí.

Quy trình thực tế nên là:

Giữ system prompt và context prefix ổn định.
Đo cache hit rate trên traffic đại diện.
Giới hạn max_tokens.
Yêu cầu đầu ra đúng định dạng cần dùng.
So sánh chi phí theo token usage thực tế, không chỉ theo bảng giá.

Để xác định tỷ lệ đầu vào hỗn hợp trước khi triển khai, hãy tải xuống Apidog, gửi vài request đại diện đến kimi-k3 và kiểm tra phân tách token cache hit trực tiếp trong usage object.

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

API Kimi K3 có giá bao nhiêu?

Kimi K3 có giá $0,30 cho mỗi triệu token đầu vào trúng bộ nhớ đệm, $3,00 cho mỗi triệu token đầu vào trượt bộ nhớ đệm và $15,00 cho mỗi triệu token đầu ra trên API trực tiếp của Moonshot.

Các bên thứ ba như OpenRouter có thể hiển thị mức giá cố định $3,00 đầu vào và $15,00 đầu ra mà không tách riêng giá cache hit. Xem hướng dẫn API Kimi K3 để thiết lập request.

Tỷ lệ cache hit là gì và tại sao nó quan trọng?

Cache hit là phần token đầu vào được tái sử dụng từ prompt prefix đã lưu. Những token này có giá $0,30 thay vì $3,00 mỗi triệu token.

Moonshot báo cáo cache hit trên 90% cho tác vụ lập trình. Với tỷ lệ này, giá đầu vào hỗn hợp rơi vào khoảng $0,57 / 1M token.

Kimi K3 có rẻ hơn Claude Opus 4.8 không?

Có, dựa trên giá niêm yết. Đầu ra của Kimi K3 là $15,00 / 1M token, trong khi Claude Opus 4.8 là $25,00 / 1M token. Đầu vào của Kimi K3 cũng thấp hơn.

Trong tác vụ mẫu với 2M token đầu vào và 200K token đầu ra, Kimi K3 với cache hit 90% có giá khoảng $4,14, trong khi Opus theo giá niêm yết khoảng $15,00.

Anthropic có prompt caching riêng, nên hãy coi đây là so sánh định hướng. Xem giá Claude Opus 4.8 và so sánh Kimi K3 với Claude Opus 4.8.

Giá Kimi K3 so với GPT-5.6 và DeepSeek V4 như thế nào?

Kimi K3 rẻ hơn GPT-5.6 Sol, model flagship có giá khoảng $5 đầu vào và $30 đầu ra. Tuy nhiên, GPT-5.6 có các tier Terra và Luna rẻ hơn.

DeepSeek V4 là một lựa chọn giá trị khác và có thể có giá đầu ra thô thấp hơn Kimi K3. Hãy kiểm tra trực tiếp giá GPT-5.6 và giá DeepSeek V4 trước khi quyết định.

Làm thế nào để giảm hóa đơn Kimi K3?

Tập trung vào đầu ra:

Đặt max_tokens.
Yêu cầu phản hồi ngắn gọn.
Chỉ yêu cầu format cần thiết, chẳng hạn unified diff hoặc JSON.
Giữ system prompt và context prefix ổn định theo byte.
Gộp các request liên quan để tận dụng prefix đã cache.

Cắt giảm input đã cache thường ít hiệu quả vì token cache hit đã rất rẻ. Loại bỏ context hữu ích thậm chí có thể khiến output dài hơn và tốn kém hơn.

Làm thế nào để xác minh tỷ lệ cache hit thực tế?

Kiểm tra usage object trả về trên từng phản hồi Kimi K3. Đối tượng này báo cáo token đầu vào, đầu ra và token trúng cache.

Gửi cùng một request qua Apidog hai lần, sau đó so sánh số token cache hit giữa hai phản hồi. Tỷ lệ quan sát được là số bạn nên dùng trong công thức chi phí hỗn hợp của mình.

Cách sử dụng API Kimi K3

Sebastian Petrus — Fri, 17 Jul 2026 02:12:37 +0000

Moonshot AI đã ra mắt Kimi K3 vào ngày 16 tháng 7 năm 2026 và gọi đây là mô hình có khả năng nhất của họ cho đến nay: mô hình 3T-class mã nguồn mở đầu tiên trên thế giới, với thiết kế Mixture-of-Experts (MoE) 2.8T tham số và cửa sổ ngữ cảnh 1.048.576 token. Điều đáng quan tâm với nhà phát triển không chỉ là kích thước, mà là API: Kimi K3 sử dụng định dạng tương thích OpenAI SDK. Nếu bạn đã gọi GPT hoặc endpoint tương thích OpenAI, bạn chỉ cần trỏ client sang kimi-k3 để nhận phản hồi streaming trong vài phút. Hướng dẫn này trình bày cách lấy khóa API, gọi API bằng Python, JavaScript và cURL, xử lý streaming, tool calls, JSON mode, reasoning_effort, context caching và gỡ lỗi yêu cầu thô bằng Apidog.

Dùng thử Apidog ngay hôm nay

Tóm tắt

ID mô hình API là kimi-k3. Trên OpenRouter, slug là moonshotai/kimi-k3.
Endpoint tương thích OpenAI SDK: cấu hình base_url, api_key và model="kimi-k3". Xác nhận URL cơ sở trong console tại platform.kimi.ai; Kimi trước đây đã sử dụng https://api.moonshot.ai/v1.
Cửa sổ ngữ cảnh là 1M token. Giá: $0.30 cho mỗi triệu token đầu vào cache-hit, $3.00 cho mỗi triệu token đầu vào cache-miss và $15.00 cho mỗi triệu token đầu ra.
Streaming, tool calls, JSON mode, structured output và reasoning_effort (max hiện có sẵn) hoạt động theo định dạng chat completions tiêu chuẩn.
Với tác vụ lập trình thông thường hoặc ngân sách hạn chế, dòng K2.7 có thể phù hợp hơn.
Dùng Apidog để kiểm tra streaming, gỡ lỗi tool calls, lưu khóa API dưới dạng biến môi trường và so sánh A/B kimi-k3 với kimi-k2-7-code.

Bạn nên gọi mô hình Kimi nào?

Hãy chọn mô hình theo loại workload trước khi viết code. Kimi K3 là mô hình tiên tiến nhất trong dòng sản phẩm: một MoE lớn hướng đến lập trình phức tạp, tác vụ agentic dài hạn và công việc kiến thức trên ngữ cảnh dài. Tuy nhiên, chi phí token đầu ra của nó cao nhất trong dòng sản phẩm. Bài đăng ra mắt của Moonshot cũng nêu rằng K3 xếp sau Claude Fable 5 và GPT-5.6 Sol trong các so sánh nội bộ của họ.

Nếu workload của bạn là trợ lý mã hóa lưu lượng cao, trình tạo kiểm thử CI hoặc tác vụ cần gọi API ở quy mô lớn, dòng K2.7 Code cũ hơn thường tối ưu chi phí hơn. Bắt đầu với hướng dẫn API Kimi K2.7 Code và bài viết Kimi K2.7 Code là gì.

Dùng kimi-k3 khi bạn cần:

Suy luận sâu hơn.
Ngữ cảnh đầy đủ 1M token.
Điều phối công cụ cho tác nhân.

Chuyển sang K2.7 khi tác vụ thông thường và có khối lượng lớn. Để so sánh trực tiếp, xem Kimi K3 vs Kimi K2.7 Code. Nếu cần hiểu thêm về kiến trúc, xem Kimi K3 là gì.

Lấy khóa API trên nền tảng Kimi

Truy cập platform.kimi.ai và đăng nhập. Console là nơi tạo khóa API, theo dõi mức sử dụng và xác nhận URL cơ sở cho tài khoản.

Mở phần API keys trong console và tạo khóa mới.
Sao chép khóa ngay khi được hiển thị và lưu ở nơi an toàn. Bạn sẽ không thể xem lại toàn bộ giá trị này.
Thêm tín dụng hoặc xác nhận gói thanh toán để lệnh gọi kimi-k3 không bị từ chối do số dư không đủ.
Ghi lại URL cơ sở trong console. Kimi trước đây đã sử dụng https://api.moonshot.ai/v1, nhưng console là nguồn thông tin chính xác cho tài khoản của bạn.

Xuất khóa thành biến môi trường thay vì ghi trực tiếp vào mã nguồn:

export KIMI_API_KEY="sk-your-key-here"
export KIMI_BASE_URL="https://api.moonshot.ai/v1"

Cách này giúp tránh lộ khóa trong Git history, log hoặc ảnh chụp màn hình. Khi kiểm tra bằng Apidog, hãy lưu cùng khóa đó trong environment thay vì dán vào request body.

Để xem chi tiết chi phí cache-hit và cache-miss, đọc hướng dẫn định giá Kimi K3.

Bắt đầu nhanh: lệnh gọi `kimi-k3` đầu tiên

Kimi API tuân theo hợp đồng OpenAI chat completions. Với OpenAI SDK, bạn chỉ cần thay đổi base_url, api_key và model.

Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["KIMI_API_KEY"],
    # Xác nhận URL cơ sở chính xác trong console tại platform.kimi.ai.
    base_url=os.environ["KIMI_BASE_URL"],
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You are a precise coding assistant."},
        {
            "role": "user",
            "content": "Explain what a token bucket rate limiter does in one paragraph.",
        },
    ],
)

print(response.choices[0].message.content)

JavaScript / TypeScript

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.KIMI_API_KEY,
  // Xác nhận URL cơ sở trong console tại platform.kimi.ai.
  baseURL: process.env.KIMI_BASE_URL,
});

const response = await client.chat.completions.create({
  model: "kimi-k3",
  messages: [
    { role: "system", content: "You are a precise coding assistant." },
    {
      role: "user",
      content: "Explain what a token bucket rate limiter does in one paragraph.",
    },
  ],
});

console.log(response.choices[0].message.content);

cURL

curl "$KIMI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Explain what a token bucket rate limiter does in one paragraph."
      }
    ]
  }'

Nếu nhận lỗi:

401: kiểm tra KIMI_API_KEY, biến môi trường hoặc quyền truy cập của khóa.
404: kiểm tra KIMI_BASE_URL và đường dẫn /chat/completions; thường đây là lỗi URL cơ sở, không phải lỗi model.

Tài liệu OpenAI Python SDK có thêm tùy chọn client. Các tùy chọn tương thích với định dạng OpenAI đều có thể áp dụng ở đây.

Phản hồi streaming

Với chat UI hoặc agent chạy lâu, hãy bật streaming để nhận token ngay khi chúng được tạo thay vì chờ toàn bộ phản hồi.

Python

stream = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "user", "content": "Write a 6-line poem about flaky tests."}
    ],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta
    if delta.content:
        print(delta.content, end="", flush=True)

Luồng này sử dụng server-sent events (SSE). Mỗi khung thường có tiền tố data: chứa JSON, và luồng kết thúc bằng:

data: [DONE]

SDK giúp bạn không phải tự parse SSE, nhưng khi stream lỗi giữa chừng, xem khung SSE thô sẽ hữu ích để xác định lỗi ở client, proxy hay endpoint.

JavaScript

const stream = await client.chat.completions.create({
  model: "kimi-k3",
  messages: [
    { role: "user", content: "Write a 6-line poem about flaky tests." },
  ],
  stream: true,
});

for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
}

Gọi công cụ (function calling)

Kimi K3 hỗ trợ tool calls, ràng buộc lựa chọn công cụ và tải công cụ động. Bạn khai báo công cụ bằng JSON Schema, mô hình trả về tên hàm cùng đối số JSON, còn ứng dụng của bạn thực thi hành động thực tế.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "City name, e.g. Singapore",
                    },
                },
                "required": ["city"],
            },
        },
    }
]

messages = [
    {"role": "user", "content": "What's the weather in Singapore right now?"}
]

first = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    tools=tools,
    tool_choice="auto",
)

tool_call = first.choices[0].message.tool_calls[0]

print(tool_call.function.name)       # get_weather
print(tool_call.function.arguments)  # {"city": "Singapore"}

Mô hình không chạy hàm get_weather. Bạn cần thực hiện lệnh gọi API hoặc logic nghiệp vụ trong ứng dụng, rồi gửi kết quả trở lại model.

import json

# Thêm message của assistant yêu cầu tool call.
messages.append(first.choices[0].message)

# Thêm kết quả do ứng dụng của bạn thực thi.
messages.append({
    "role": "tool",
    "tool_call_id": tool_call.id,
    "content": json.dumps({
        "city": "Singapore",
        "temp_c": 31,
        "sky": "humid",
    }),
})

final = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    tools=tools,
)

print(final.choices[0].message.content)

Các chế độ tool_choice hữu ích:

# Ép model phải gọi một tool.
tool_choice = "required"

# Ép model gọi đúng một hàm.
tool_choice = {
    "type": "function",
    "function": {"name": "get_weather"},
}

Với agent đa lượt, hãy giữ toàn bộ lịch sử tin nhắn, bao gồm các lượt tool call và phản hồi tool. Nếu cắt bỏ các lượt nội bộ của assistant, chất lượng sinh có thể không ổn định.

Chế độ JSON và đầu ra có cấu trúc

Khi ứng dụng cần dữ liệu có thể parse bằng máy, yêu cầu JSON trực tiếp thay vì parse văn bản tự do.

JSON object

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "system",
            "content": "Return only valid JSON. No prose, no markdown.",
        },
        {
            "role": "user",
            "content": "Extract name and role from: 'Ada Lovelace, mathematician'.",
        },
    ],
    response_format={"type": "json_object"},
)

print(response.choices[0].message.content)
# {"name": "Ada Lovelace", "role": "mathematician"}

JSON Schema

Nếu SDK và tài khoản của bạn hỗ trợ json_schema, khai báo schema để ràng buộc cấu trúc đầu ra:

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Extract name and role from: 'Ada Lovelace, mathematician'.",
        }
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "person",
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "role": {"type": "string"},
                },
                "required": ["name", "role"],
            },
        },
    },
)

Xác nhận hỗ trợ json_schema trong console trước khi dùng ở production. Nếu không chắc chắn, dùng json_object và validate dữ liệu ở phía ứng dụng là phương án dự phòng an toàn.

Kimi cũng cung cấp partial mode và tìm kiếm internet, hữu ích khi cần điền trước phản hồi hoặc dựa vào dữ liệu mới.

Nỗ lực suy luận có thể cấu hình

Kimi K3 có tham số reasoning_effort để kiểm soát mức độ suy nghĩ trước khi trả lời. Hiện tại, cấp độ sẵn có là max, cũng là giá trị mặc định. Suy luận sâu hơn có thể tăng token đầu ra và độ trễ, nên chỉ dùng cho tác vụ thực sự cần thiết.

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Plan a migration from REST to GraphQL for a 40-endpoint API.",
        }
    ],
    reasoning_effort="max",
)

Nếu phiên bản OpenAI SDK chưa hỗ trợ trường này, truyền qua extra_body:

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Plan a migration from REST to GraphQL.",
        }
    ],
    extra_body={"reasoning_effort": "max"},
)

extra_body phù hợp cho các trường dành riêng cho nhà cung cấp mà SDK gốc chưa mô hình hóa.

Kiểm tra và gỡ lỗi `kimi-k3` trong Apidog

SDK che giấu chi tiết HTTP và SSE, điều này tiện lợi cho đến khi tool call trả về dữ liệu sai định dạng hoặc streaming bị ngắt. Khi đó, hãy kiểm tra request thô bằng Apidog: gửi đúng request kimi-k3, xem SSE theo từng khung và giữ API key ngoài request body.

Nếu bạn muốn kiểm tra API không phụ thuộc vào terminal, xem hướng dẫn kiểm thử API không dùng Postman.

Thiết lập request trong Apidog theo các bước sau:

Tạo một HTTP request mới.
Đặt phương thức là POST.
Đặt URL thành:

   {{KIMI_BASE_URL}}/chat/completions

Trong environment, thêm:
- KIMI_API_KEY
- KIMI_BASE_URL
Thêm headers:

   Authorization: Bearer {{KIMI_API_KEY}}
   Content-Type: application/json

Dùng request body cơ bản:

   {
     "model": "kimi-k3",
     "messages": [
       {
         "role": "user",
         "content": "Explain what a token bucket rate limiter does in one paragraph."
       }
     ]
   }

Gửi request và kiểm tra:
- Nội dung phản hồi.
- Usage token.
- Thông tin cache-hit và cache-miss nếu được trả về.
- HTTP status và response headers.

Để kiểm tra streaming, thêm:

{
  "stream": true
}

hoặc gộp vào request body hiện có:

{
  "model": "kimi-k3",
  "stream": true,
  "messages": [
    {
      "role": "user",
      "content": "Write a 6-line poem about flaky tests."
    }
  ]
}

Kiểm tra các khung data: để xác định stream có bị dừng trước [DONE] hay không.

Để gỡ lỗi tool calls:

Gửi request có trường tools.
Kiểm tra mảng tool_calls trong phản hồi assistant.
Xác minh function.name có đúng với tool đã khai báo.
Parse và validate function.arguments trước khi chạy logic nghiệp vụ.
Nếu arguments không hợp lệ, cải thiện description, parameters và danh sách required trong JSON Schema.

Bạn cũng nên chạy A/B test giữa K3 và K2.7:

Sao chép request trong Apidog.
Chỉ đổi trường model từ kimi-k3 sang kimi-k2-7-code.
Gửi cùng prompt.
So sánh độ trễ, chất lượng đầu ra và chi phí.

Apidog có thể nhập trực tiếp request tương thích OpenAI từ lệnh cURL, giúp biến request thủ công thành test case có thể chạy lại. Nếu agent của bạn giao tiếp qua MCP, xem hướng dẫn gỡ lỗi trực quan với client Apidog MCP. Bạn có thể tải xuống Apidog để thực hiện quy trình này với API key của mình.

Các trường hợp sử dụng thực tế

kimi-k3 phù hợp với các workload sau:

Agent mã hóa quy mô repository: Ngữ cảnh 1M token và tool orchestration giúp model đọc cơ sở mã lớn, chạy kiểm thử, đọc log và lặp lại. Giữ bản tóm tắt repository ở phần đầu prompt để tăng cache hit.
Công việc kiến thức với tài liệu dài: Đưa toàn bộ đặc tả, hợp đồng hoặc tài liệu nghiên cứu vào ngữ cảnh và yêu cầu trích xuất bằng json_schema. Đặt tài liệu dùng chung ở đầu prompt để tái sử dụng cache.
Lập kế hoạch di chuyển và tái cấu trúc: Dùng reasoning_effort="max" trong bước lập kế hoạch, sau đó chuyển sang model rẻ hơn cho các thay đổi cơ học.
Trả lời nghiên cứu có căn cứ: Kết hợp tìm kiếm internet và tool calls để lấy dữ liệu mới, phù hợp với trợ lý không thể chỉ dựa vào kiến thức huấn luyện cũ.

Quy trình nên là:

Xây dựng request bằng SDK.
Xác minh request và phản hồi thô trong Apidog.
Đo chi phí, độ trễ và chất lượng với prompt thực tế.
Chỉ tích hợp vào production sau khi đã có test case lặp lại được.

Tổng kết

Để gọi Kimi K3, bạn chỉ cần cấu hình ba giá trị trong client tương thích OpenAI:

URL cơ sở từ Kimi console.
API key.
model="kimi-k3".

Sau đó, bạn có thể dùng streaming, tool calls, JSON mode, structured output và reasoning_effort theo hợp đồng chat completions quen thuộc.

Hai điểm quan trọng cần theo dõi:

Context caching: Giữ system prompt và ngữ cảnh dùng chung ổn định ở đầu request để biến chi phí đầu vào cache-miss $3.00 thành cache-hit $0.30 trên mỗi triệu token.
Chi phí so với năng lực: K3 phù hợp cho suy luận sâu và ngữ cảnh dài; với tác vụ mã hóa thông thường, lưu lượng cao, K2.7 thường kinh tế hơn.

Xây dựng request trong mã, kiểm chứng bằng Apidog và đo lường trên workload thực tế trước khi triển khai.

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

ID mô hình API cho Kimi K3 là gì?

Đó là kimi-k3 trên nền tảng Kimi. Nếu gọi qua OpenRouter, slug là moonshotai/kimi-k3. Xem danh sách model tại openrouter.ai/moonshotai/kimi-k3.

Tôi sử dụng URL cơ sở nào?

Xác nhận trong console tại platform.kimi.ai. Kimi trước đây đã sử dụng https://api.moonshot.ai/v1, nhưng bạn nên lưu URL này dưới dạng biến KIMI_BASE_URL thay vì hard-code.

Kimi K3 có tương thích OpenAI SDK không?

Có. API tuân theo định dạng OpenAI chat completions, nên OpenAI SDK cho Python và JavaScript hoạt động sau khi đổi base_url và model. Các trường riêng của nhà cung cấp có thể truyền qua extra_body.

API Kimi K3 có giá bao nhiêu?

$0.30 cho mỗi triệu token đầu vào cache-hit, $3.00 cho mỗi triệu token đầu vào cache-miss và $15.00 cho mỗi triệu token đầu ra. Xem hướng dẫn định giá Kimi K3 để biết chi tiết.

Context caching thực sự làm gì?

Khi token ở phần đầu request trùng với request trước đó, endpoint có thể tái sử dụng trạng thái đã tính toán thay vì tính lại. Điều này giảm chi phí phần đầu vào đó từ $3.00 xuống $0.30 cho mỗi triệu token. Hãy giữ system prompt và ngữ cảnh chia sẻ ở đầu prompt, ổn định giữa các lần gọi.

Tôi có thể kiểm soát mức độ mô hình suy nghĩ không?

Có, bằng reasoning_effort. Cấp độ hiện có là max, cũng là mặc định. Nỗ lực cao hơn có thể dùng nhiều token đầu ra hơn và tăng độ trễ.

Tôi nên dùng Kimi K3 hay Kimi K2.7 Code?

Dùng kimi-k3 khi cần suy luận sâu, ngữ cảnh 1M token hoặc agentic tool orchestration. Với tác vụ mã hóa thông thường, lưu lượng cao, K2.7 thường rẻ hơn. Xem Kimi K3 vs Kimi K2.7 Code và hướng dẫn API Kimi K2.7 Code.

Làm cách nào để gỡ lỗi streaming hoặc tool call lỗi?

Gửi request thô trong Apidog với "stream": true để đọc từng khung SSE, hoặc kiểm tra mảng tool_calls để xem model có trả về JSON sai định dạng không. Lưu API key trong environment để tránh đưa bí mật vào request body.

Kimi K3 là gì? Siêu phẩm 2.8T Open của Moonshot

Sebastian Petrus — Fri, 17 Jul 2026 02:08:36 +0000

Moonshot AI đã ra mắt Kimi K3 vào ngày 16 tháng 7 năm 2026 và gọi đây là “mô hình mã nguồn mở hạng 3T đầu tiên trên thế giới”. Về kỹ thuật, K3 là mô hình Mixture-of-Experts (MoE) có 2,8 nghìn tỷ tham số, cửa sổ ngữ cảnh 1 triệu token, cơ chế attention mới và mức giá nhắm đến đội ngũ phát triển phần mềm. Mô hình được triển khai ngay ngày ra mắt trên Kimi.com, Kimi Work, Kimi Code và Kimi API; Moonshot cam kết phát hành toàn bộ trọng số trước ngày 27 tháng 7 năm 2026. Bài viết này tập trung vào cách đánh giá, tích hợp và kiểm thử Kimi K3 trước khi đưa vào production.

Dùng thử Apidog ngay hôm nay

TL;DR: Kimi K3 là gì?

Kimi K3 là mô hình ngôn ngữ lớn chủ lực của Moonshot AI, phát hành ngày 16 tháng 7 năm 2026.

Các thông số chính:

Kiến trúc: Mixture-of-Experts, tổng cộng 2,8 nghìn tỷ tham số
Chuyên gia hoạt động: 16 trên 896 chuyên gia cho mỗi token
Cửa sổ ngữ cảnh: 1.048.576 token (1M)
ID model API: kimi-k3
API: tương thích OpenAI SDK
Giá input cache-hit: 0,30 USD / 1 triệu token
Giá input cache-miss: 3,00 USD / 1 triệu token
Giá output: 15,00 USD / 1 triệu token
Artificial Analysis Intelligence Index: 57 điểm, xếp thứ 4 trong 189 model
Thời điểm dự kiến mở trọng số: khoảng ngày 27 tháng 7 năm 2026

Moonshot cho biết K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol. Vì vậy, hãy xem K3 là một model trọng số mở mạnh, gần nhóm “biên giới” công nghệ, thay vì model tốt nhất tuyệt đối.

Vì sao Kimi K3 đáng chú ý với developer?

Điểm đáng chú ý không chỉ là benchmark. Với đội ngũ xây dựng sản phẩm AI, K3 có ba yếu tố cần kiểm tra:

Chất lượng gần nhóm model dẫn đầu
Giá input cache-hit thấp hơn 10 lần cache-miss
Lộ trình phát hành trọng số để tự lưu trữ

Nếu Moonshot phát hành trọng số đúng cam kết, K3 có thể trở thành một lựa chọn đáng cân nhắc khi bạn cần so sánh:

Chi phí API so với chi phí cụm GPU
Quyền kiểm soát hạ tầng so với API độc quyền
Context window dài so với chi phí gửi lại prompt lặp lại
Chất lượng agentic so với độ trễ phản hồi

Về tích hợp, câu hỏi quan trọng nhất là: bạn có thể giữ nguyên client theo chuẩn OpenAI và chỉ đổi model sang kimi-k3 hay không?

Câu trả lời là có, vì Moonshot cung cấp API tương thích OpenAI SDK. Điều này giúp bạn tái sử dụng phần lớn code hiện có cho:

Chat completion
Streaming
Tool calling
Structured output
Agent framework

Bạn cũng có thể kiểm thử endpoint tương thích OpenAI bằng Apidog, bao gồm streaming SSE, request có tool và payload tool_calls, trước khi đưa model vào luồng production.

Để đi sâu theo từng chủ đề, xem thêm:

Danh tính: model mạnh nhất của Moonshot

Moonshot AI định vị K3 là “mô hình mạnh mẽ nhất của chúng tôi”, kế nhiệm dòng Kimi K2.

Nếu bạn đã dùng:

thì K3 là thế hệ tiếp theo, được xây dựng lại từ lớp attention trở lên.

Tuyên bố “mô hình mã nguồn mở hạng 3T đầu tiên trên thế giới” cần được hiểu đúng:

“Mã nguồn mở”: không có ngay tại thời điểm phát hành. Khi ra mắt, K3 chỉ truy cập được qua sản phẩm được lưu trữ và API trả phí. Moonshot cam kết phát hành toàn bộ trọng số trước ngày 27 tháng 7 năm 2026.
“Hạng 3T”: đề cập đến tổng số 2,8 nghìn tỷ tham số. Tuy nhiên, model chỉ kích hoạt một phần chuyên gia cho mỗi token, giúp giảm chi phí inference.

Nếu bạn cần tự host, không nên lập kế hoạch dựa trên giả định rằng trọng số đã có sẵn ngay ngày đầu. Hãy coi đây là một mốc phát hành được lên lịch.

Kiến trúc Kimi K3: những điểm cần biết

K3 không chỉ là K2 với số tham số lớn hơn. Moonshot nêu ra một số thay đổi kiến trúc ảnh hưởng trực tiếp đến context dài, routing MoE và hiệu quả inference.

Kimi Delta Attention (KDA)

KDA là cơ chế linear attention lai. Theo Moonshot, cơ chế này giúp kiểm soát mức tăng bộ nhớ và chi phí tính toán khi context dài hơn.

Ý nghĩa thực tế: context window 1M token trở nên khả dụng hơn cho các workload như:

Phân tích codebase lớn
Trợ lý nghiên cứu dùng tài liệu dài
Agent cần giữ trạng thái lớn
Phân tích log hoặc transcript nhiều giờ

Attention Residuals (AttnRes)

AttnRes được Moonshot mô tả là thay thế trực tiếp cho residual connection tiêu chuẩn.

Mục tiêu là cho phép model truy xuất có chọn lọc biểu diễn từ các lớp trước ở những lớp sâu hơn. Hiểu đơn giản: kiến trúc này nhằm giảm việc mất ngữ cảnh khi thông tin đi qua nhiều lớp của network.

Stable LatentMoE

Đây là lớp routing Mixture-of-Experts của K3:

896 chuyên gia tổng cộng
16 chuyên gia hoạt động trên mỗi token
Dùng Quantile Balancing để giữ routing ổn định trong quá trình huấn luyện

Sparse activation là lý do K3 có thể mang tổng số tham số rất lớn nhưng không phải kích hoạt toàn bộ model ở mỗi bước inference.

Moonshot cũng đề cập các thành phần bổ trợ:

Per-Head Muon
Sigmoid Tanh Unit (SiTU)
Gated MLA
Trọng số MXFP4
Kích hoạt MXFP8

Thông số kỹ thuật Kimi K3

Thông số	Kimi K3
Nhà phát triển	Moonshot AI
Ngày phát hành	16 tháng 7 năm 2026
Tổng tham số	2,8 nghìn tỷ (Mixture-of-Experts)
Chuyên gia hoạt động	16 trong số 896 trên mỗi token
Cửa sổ ngữ cảnh	1.048.576 token (1M)
ID model API	`kimi-k3`
OpenRouter slug	`moonshotai/kimi-k3`
Tương thích API	Tương thích OpenAI SDK
Input cache-hit	0,30 USD / 1 triệu token
Input cache-miss	3,00 USD / 1 triệu token
Output	15,00 USD / 1 triệu token
Tốc độ output	~62 token/giây
Thời gian đến token đầu tiên	~1,99 giây
Intelligence Index	57, xếp thứ 4 trong 189
Trọng số mở	Dự kiến khoảng 27 tháng 7 năm 2026

Để ước tính chi phí theo lưu lượng token của ứng dụng, xem hướng dẫn định giá Kimi K3.

Context 1M token: tối ưu chi phí bằng cache-hit

Context window 1.048.576 token cho phép bạn đưa vào một prompt:

Toàn bộ codebase
Tài liệu nghiên cứu dài
Cây thư mục lớn
Prompt hệ thống phức tạp
Transcript dài nhiều giờ

Tuy nhiên, điểm đáng chú ý hơn là chênh lệch giá input:

Loại input	Giá / 1 triệu token
Cache-hit	0,30 USD
Cache-miss	3,00 USD

Đây là chênh lệch 10 lần.

Moonshot cho biết hệ thống inference Mooncake có thể đạt cache-hit trên 90% cho tác vụ lập trình. Điều này đặc biệt có lợi nếu ứng dụng của bạn liên tục gửi lại cùng một phần context, ví dụ:

Prompt hệ thống lớn dùng chung
Metadata repository
Hướng dẫn cố định cho agent
Cây thư mục dự án
Context code được tái sử dụng qua nhiều vòng lặp agent

Cách đánh giá lợi ích cache trong workload của bạn

Trước khi chọn model, hãy đo ba chỉ số:

Tổng số input token trên mỗi request
Phần input lặp lại giữa các request
Tỷ lệ cache-hit thực tế trong workload

Nếu agent gửi lại 500.000 token repository context ở mỗi bước, chi phí sẽ khác biệt đáng kể giữa cache-hit và cache-miss.

Đánh đổi: tốc độ output

Artificial Analysis đo K3 ở khoảng:

62 token output/giây
1,99 giây đến token đầu tiên

Tốc độ output này thấp hơn mức trung bình 72,7 token/giây của phân khúc giá tương ứng. Vì vậy, K3 phù hợp hơn với workload cần suy luận sâu, context dài và agentic workflow hơn là giao diện cần phản hồi tức thời.

Nếu latency là ưu tiên hàng đầu, hãy benchmark trực tiếp với model nhanh hơn trước khi cam kết.

Định vị thực tế: mạnh, mở, nhưng không dẫn đầu tuyệt đối

Moonshot thừa nhận trong blog ra mắt Kimi K3 rằng K3 vẫn kém các model độc quyền mạnh nhất là Claude Fable 5 và GPT-5.6 Sol.

Theo Artificial Analysis, K3 đạt 57 điểm trên Intelligence Index và xếp thứ 4 trong 189 model. Chỉ số này tổng hợp chín bài đánh giá về:

Agentic tasks
Coding
Scientific reasoning
General reasoning

Cách định vị phù hợp cho K3 là:

Model trọng số mở mạnh gần nhóm frontier
Lựa chọn đáng cân nhắc cho self-hosting sau khi phát hành trọng số
Lựa chọn có chi phí input hiệu quả khi tận dụng cache
Không phải model tốt nhất tuyệt đối cho các tác vụ suy luận khó nhất

Để so sánh trực tiếp với các model đóng, xem:

Bạn có thể dùng Kimi K3 ở đâu?

Nền tảng	Bạn nhận được gì
Kimi.com	Ứng dụng chat web, K3 là model mặc định
Kimi Work	Sản phẩm không gian làm việc nhóm
Kimi Code	Agent lập trình chạy trong terminal
Kimi API	Truy cập lập trình qua model ID `kimi-k3`
Ứng dụng di động	iOS, Android và HarmonyOS
Desktop	Kimi Work phiên bản 3.1.0 trở lên
OpenRouter	Truy cập qua `moonshotai/kimi-k3`

Nếu làm việc trong terminal, bạn có thể bắt đầu với Kimi Code. Xem hướng dẫn Kimi Code CLI để tham khảo quy trình thiết lập từ thời K2.

Các tài nguyên liên quan:

Khả năng API của Kimi K3

Kimi K3 hỗ trợ các tính năng cần thiết cho ứng dụng agentic và workflow có cấu trúc:

Context caching
Tool calling
Ràng buộc lựa chọn tool
JSON mode
Structured output
Partial mode để kiểm soát completion
Internet search
Dynamic tool loading
Cấu hình reasoning effort, bao gồm mức “maximum”

Vì API tương thích OpenAI SDK, bạn có thể bắt đầu bằng cách giữ nguyên cấu trúc client hiện có và chỉ thay endpoint cùng model ID.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_KIMI_API_KEY",
    base_url="YOUR_KIMI_OPENAI_COMPATIBLE_BASE_URL"
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Phân tích các rủi ro chính trong thay đổi này."
        }
    ]
)

print(response.choices[0].message.content)

Trước khi hard-code URL cơ sở, hãy xác nhận endpoint chính xác trong platform.kimi.ai, vì Moonshot đã chuyển sang tên miền mới khi ra mắt.

Để tích hợp tool calling, giữ nguyên schema OpenAI-style hiện có và kiểm tra payload trả về từ tool_calls trong môi trường test trước.

Xem hướng dẫn API Kimi K3 để biết chi tiết request và response.

Kiểm thử `kimi-k3` trước khi triển khai

Đừng đưa K3 trực tiếp vào agent loop chỉ dựa trên benchmark. Trước tiên, hãy xác minh các hành vi API quan trọng:

Streaming hoạt động đúng với parser của bạn
tool_calls có đúng schema bạn mong đợi
JSON output có ổn định với dữ liệu thật
Context caching hoạt động đúng trên request lặp lại
Latency phù hợp với SLO của ứng dụng
Reasoning effort tối đa có ảnh hưởng thế nào đến chi phí và thời gian phản hồi

Bạn có thể dùng Apidog để kiểm thử endpoint theo quy trình sau:

Tạo request chat completion tương thích OpenAI.
Lưu API key dưới dạng biến môi trường, không đặt trực tiếp trong collection chia sẻ.
Đặt model là kimi-k3.
Gửi request với stream: true.
Kiểm tra các sự kiện Server-Sent Events khi token được trả về.
Gửi request có tools để xem payload tool_calls.
Xác thực arguments của tool theo JSON schema trước khi nối vào agent runtime.

Ví dụ payload streaming:

{
  "model": "kimi-k3",
  "stream": true,
  "messages": [
    {
      "role": "user",
      "content": "Tóm tắt thay đổi trong repository này."
    }
  ]
}

Ví dụ request có tool:

{
  "model": "kimi-k3",
  "messages": [
    {
      "role": "user",
      "content": "Kiểm tra trạng thái triển khai mới nhất."
    }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_deployment_status",
        "description": "Lấy trạng thái triển khai theo môi trường.",
        "parameters": {
          "type": "object",
          "properties": {
            "environment": {
              "type": "string",
              "enum": ["development", "staging", "production"]
            }
          },
          "required": ["environment"]
        }
      }
    }
  ]
}

Mục tiêu của bước này không phải prompt engineering. Đây là kiểm thử hợp đồng API: xác minh chính xác dữ liệu model trả về trước khi code agent được chạy trong production.

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

Kimi K3 là gì?

Kimi K3 là model ngôn ngữ lớn chủ lực của Moonshot AI, ra mắt ngày 16 tháng 7 năm 2026. Đây là model MoE 2,8 nghìn tỷ tham số, context window 1M token và được phục vụ qua API model ID kimi-k3.

Kimi K3 có bao nhiêu tham số?

K3 có tổng cộng 2,8 nghìn tỷ tham số. Model kích hoạt 16 trong số 896 chuyên gia trên mỗi token.

Moonshot chưa công bố số tham số hoạt động chính xác. Vì vậy, không nên trích dẫn một con số “active parameters” cụ thể như dữ kiện.

API Kimi K3 có giá bao nhiêu?

Input cache-hit: 0,30 USD / 1 triệu token
Input cache-miss: 3,00 USD / 1 triệu token
Output: 15,00 USD / 1 triệu token

Xem phân tích giá Kimi K3 để lập mô hình chi phí theo lượng token của ứng dụng.

Kimi K3 có phải mã nguồn mở không?

Không phải ngay ngày ra mắt. Moonshot cam kết phát hành toàn bộ trọng số trước ngày 27 tháng 7 năm 2026.

Trước thời điểm đó, bạn truy cập K3 qua các sản phẩm được lưu trữ và API trả phí. Sau khi trọng số được phát hành, bạn có thể cân nhắc tự host.

Kimi K3 có tốt hơn Claude Fable 5 hoặc GPT-5.6 Sol không?

Không. Moonshot nói rõ rằng K3 vẫn kém các model độc quyền mạnh nhất là Claude Fable 5 và GPT-5.6 Sol.

Tuy nhiên, K3 đạt 57 điểm trên Artificial Analysis Intelligence Index và xếp thứ 4 trong 189 model, nên vẫn là một lựa chọn mạnh trong nhóm model gần frontier.

Tôi có thể dùng Kimi K3 với OpenAI SDK không?

Có. API Moonshot tương thích OpenAI SDK.

Bạn cần:

Xác nhận base URL trên platform.kimi.ai
Cấu hình client trỏ đến endpoint tương thích OpenAI
Đặt model là kimi-k3
Kiểm thử chat completion, streaming và tool calling

Bạn có thể xác minh request/response trước bằng Apidog.

Kimi K3 nhanh đến mức nào?

Artificial Analysis đo khoảng 62 token output/giây, thấp hơn mức trung bình phân khúc là 72,7 token/giây. Thời gian đến token đầu tiên gần 1,99 giây.

K3 ưu tiên độ sâu suy luận hơn tốc độ phản hồi. Nếu latency là ràng buộc chính, hãy benchmark với model nhanh hơn trên workload thực tế.

Kimi K3 khác Kimi K2.7 Code thế nào?

K3 là model chủ lực thế hệ tiếp theo của dòng K2, với cơ chế attention được xây dựng lại và hiệu quả mở rộng tốt hơn khoảng 2,5 lần so với K2 theo Moonshot.

K2.7 Code vẫn là model mạnh dành riêng cho coding. Xem Kimi K3 vs Kimi K2.7 Code để so sánh trực tiếp.

Cách sử dụng Scripts trước yêu cầu và sau phản hồi trong Apidog

Sebastian Petrus — Thu, 16 Jul 2026 09:25:31 +0000

Một số yêu cầu cần được xử lý trước khi rời khỏi máy của bạn, và một số cần được xử lý ngay khi nhận được phản hồi. Một API thanh toán muốn có chữ ký HMAC được tính toán từ một dấu thời gian và khóa bí mật của bạn. Một điểm cuối đăng nhập trả về một mã thông báo mà mọi cuộc gọi sau đó đều cần. Một quy trình thanh toán phải xác nhận rằng phản hồi thực sự trả về mã 200 và ID đơn hàng chính xác. Bạn có thể tự làm tất cả những điều này, nhưng sẽ rất tốn thời gian và dễ bị lỗi khi chia sẻ yêu cầu với đồng đội.

Dùng thử Apidog ngay hôm nay

Script giải quyết vấn đề này. Trong Apidog, bạn có thể đính kèm các đoạn JavaScript nhỏ vào một yêu cầu để chúng tự động chạy: một nhóm trước khi yêu cầu được gửi và một nhóm khác sau khi phản hồi quay về. Nếu đã từng viết script Postman, bạn vẫn có thể dùng API đối tượng pm quen thuộc vì engine của Apidog tương thích với API này.

Bài viết này triển khai một luồng thực tế:

Ký yêu cầu bằng HMAC trong Pre Processors.
Trích xuất mã thông báo trong Post Processors.
Xác nhận mã trạng thái và dữ liệu phản hồi.
Tái sử dụng logic bằng Public Scripts.
Chạy kịch bản trong CI với Apidog CLI.

Hành vi scripting được mô tả trong tài liệu scripting của Apidog, nhưng tên tab và một số chi tiết khác với Postman cần được lưu ý.

Script tiền xử lý và hậu xử lý thực sự làm gì?

Apidog chạy script theo hai giai đoạn.

Pre Processors: chuẩn bị yêu cầu trước khi gửi

Pre Processors chạy trước khi yêu cầu được gửi đến máy chủ. Dùng chúng để:

Tạo dấu thời gian.
Tính chữ ký HMAC.
Sinh ID đơn hàng hoặc request ID.
Đọc biến và chuyển thành header.
Chuẩn bị dữ liệu body hoặc query parameter.

Ở thời điểm này, phản hồi chưa tồn tại. Vì vậy, bạn không thể kiểm tra pm.response trong Pre Processor.

Post Processors: kiểm tra và tái sử dụng phản hồi

Post Processors chạy sau khi nhận phản hồi. Dùng chúng để:

Kiểm tra mã trạng thái.
Xác nhận cấu trúc JSON.
Trích xuất token xác thực.
Lưu ID tài nguyên vừa tạo.
Lưu cursor phân trang cho yêu cầu tiếp theo.

Ví dụ, pm.response với các thuộc tính như code, status, headers, responseTime, responseSize, text() và json() chỉ hoạt động trong Post Processors.

Hai giai đoạn trao đổi dữ liệu thông qua biến:

Pre Processor → thiết lập biến → request sử dụng biến → Post Processor đọc hoặc cập nhật biến

Nếu chuyển từ Postman, hãy chú ý tên tab:

Postman	Apidog
Pre-request Script	Pre Processors
Tests	Post Processors

Hành vi tương tự, nhưng vị trí trên giao diện khác nhau.

Thiết lập: mở yêu cầu và tìm các tab script

Tải Apidog nếu bạn chưa cài đặt. Công cụ chạy trên macOS, Windows và Linux.

Sau đó:

Mở một API request trong Apidog.
Tìm tab Pre Processors hoặc Post Processors.
Chọn add a Custom Script.
Viết JavaScript sử dụng đối tượng pm.

Trước khi bắt đầu, cần hiểu thứ tự ưu tiên của biến trong Apidog:

Biến cục bộ (Local Variables) > Biến môi trường (Environment Variables) > Biến toàn cục chia sẻ trong dự án (Global Variables Shared within Project) > Biến toàn cục chia sẻ trong nhóm (Global Variables Shared within Team).

Nếu một biến không có giá trị như mong đợi, hãy kiểm tra xem biến có cùng tên ở cấp ưu tiên cao hơn hay không.

Với cấu hình ổn định, dùng chung cho dự án, bạn có thể lưu trong các tham số toàn cục của Apidog.

Ví dụ Pre Processor: ký yêu cầu bằng HMAC

Giả sử bạn gọi một API thanh toán yêu cầu chữ ký HMAC-SHA256 cho từng request.

Mẫu phổ biến là:

payload = timestamp + "\n" + raw_request_body
signature = HMAC_SHA256(payload, secret)

Nhiều nhà cung cấp API dùng mẫu tương tự để xác thực webhook. Tài liệu chữ ký webhook của Stripe mô tả rõ cách máy chủ xác minh timestamp, payload và secret.

Bước 1: Tạo biến môi trường

Tạo biến môi trường:

payments_api_secret = your-secret-key

Không hard-code khóa bí mật trực tiếp trong script.

Bước 2: Thêm HMAC script vào Pre Processors

Mở Pre Processors → add a Custom Script, sau đó thêm:

// Pre Processor: ký yêu cầu trước khi nó được gửi
const CryptoJS = require('crypto-js');

// Dấu thời gian Unix hiện tại, tính bằng giây
const timestamp = Math.floor(Date.now() / 1000).toString();

// Đọc khóa bí mật từ biến môi trường
const secret = pm.environment.get('payments_api_secret');

// Xây dựng payload: timestamp + xuống dòng + body thô
const body = pm.request.body ? pm.request.body.toString() : '';
const payload = timestamp + '\n' + body;

// Tính HMAC-SHA256 và mã hóa hexadecimal
const signature = CryptoJS
  .HmacSHA256(payload, secret)
  .toString(CryptoJS.enc.Hex);

// Lưu giá trị để request sử dụng
pm.environment.set('x_timestamp', timestamp);
pm.environment.set('x_signature', signature);

pm.console.log('Đã ký yêu cầu vào ' + timestamp);

Bước 3: Dùng biến trong request headers

Mở tab Headers và thêm:

X-Timestamp: {{x_timestamp}}
X-Signature: {{x_signature}}

Khi gửi request, thứ tự chạy sẽ là:

Pre Processor tạo timestamp.
Pre Processor tính signature.
Apidog lưu các giá trị vào environment.
Apidog thay {{x_timestamp}} và {{x_signature}} vào headers.
Request được gửi đến máy chủ.

Lưu ý: Apidog hỗ trợ import toàn bộ module:

const CryptoJS = require('crypto-js');

Không dùng đường dẫn submodule như:

require('crypto-js/sha256');

Các thao tác biến chỉ cập nhật giá trị hiện tại, không phải giá trị ban đầu được nhập trong trình chỉnh sửa môi trường. Đây là hành vi phù hợp với timestamp và chữ ký ngắn hạn.

Nếu cần chuyển đổi từ script Postman, xem thêm bài viết về script tiền yêu cầu của Postman.

Ví dụ Post Processor: trích xuất token và xác nhận phản hồi

Giả sử endpoint đăng nhập trả về:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "user": { "id": 4812, "email": "dana@example.com" },
  "expires_in": 3600
}

Mục tiêu là:

Xác nhận HTTP status là 200.
Kiểm tra token tồn tại và là chuỗi.
Kiểm tra user.id là số.
Lưu token để dùng trong các request tiếp theo.

Mở Post Processors → add a Custom Script và thêm:

// Post Processor: xác minh phản hồi, sau đó trích xuất mã thông báo
pm.test('Trạng thái là 200', function () {
  pm.response.to.have.status(200);
});

const jsonData = pm.response.json();

pm.test('Phản hồi trả về một mã thông báo', function () {
  pm.expect(jsonData.token).to.be.a('string').and.not.empty;
});

pm.test('ID người dùng có mặt', function () {
  pm.expect(jsonData.user.id).to.be.a('number');
});

// Lưu token để các request khác sử dụng
pm.environment.set('auth_token', jsonData.token);

pm.console.log('Đã lưu mã thông báo cho người dùng ' + jsonData.user.email);

Sau đó, trong các endpoint cần xác thực, thêm header:

Authorization: Bearer {{auth_token}}

Kết quả: bạn không cần sao chép token thủ công từ phản hồi đăng nhập sang từng request khác.

Các khối pm.test() biến thao tác gửi request thủ công thành một bài kiểm thử có thể lặp lại. Apidog hỗ trợ các matcher kiểu Chai thông qua pm.expect().

Để tìm hiểu thêm về assertion, xem hướng dẫn xác nhận API trong Apidog. Nếu cần tạo dữ liệu giả, bạn có thể kết hợp với Faker.js trong Apidog.

Lưu ý trong Post Processors

pm.iterationData là chỉ đọc. Bạn có thể đọc dữ liệu kiểm thử nhưng không thể ghi lại vào đó.
pm.cookies trả về cookie trong phản hồi từ máy chủ, không phải cookie đã gửi đi cùng request.

Tái sử dụng logic với Public Scripts

Nếu cần dùng cùng một logic HMAC cho nhiều endpoint, không nên sao chép script vào từng request. Khi thuật toán hoặc payload thay đổi, bạn sẽ phải sửa ở nhiều nơi.

Thay vào đó, dùng Public Scripts.

Cách tạo Public Script

Mở Settings > Public Scripts.
Tạo script dùng chung.
Đính kèm script vào Pre Processors hoặc Post Processors của request.

Thứ tự chạy rất quan trọng:

Public Scripts chạy trước Custom Scripts trong cùng danh sách.
Nếu có nhiều Public Scripts, chúng chạy từ trên xuống dưới theo thứ tự hiển thị.

Chia sẻ hàm giữa Public Script và Custom Script

Nếu Custom Script cần gọi một hàm từ Public Script, hàm đó phải là biến toàn cục.

Trong Public Script:

// Biến sign() thành hàm toàn cục bằng cách không dùng var, let hoặc const
sign = function (payload, secret) {
  const CryptoJS = require('crypto-js');

  return CryptoJS
    .HmacSHA256(payload, secret)
    .toString(CryptoJS.enc.Hex);
};

Trong Custom Script đặt bên dưới Public Script:

const timestamp = Math.floor(Date.now() / 1000).toString();
const secret = pm.environment.get('payments_api_secret');

pm.environment.set('x_timestamp', timestamp);
pm.environment.set('x_signature', sign(timestamp, secret));

Nếu khai báo hàm với const, let, var hoặc đặt Custom Script trước Public Script, bạn có thể gặp lỗi hàm không xác định.

Thư viện, gói bên ngoài và gỡ lỗi

Apidog có sẵn một số thư viện để dùng trực tiếp qua require().

crypto-js (v3.1.9-1) để băm và HMAC.
jsrsasign (v10.3.0) cho JWT và RSA, yêu cầu Apidog 1.4.5 trở lên.
chai (v4.2.0) cho assertion matcher.
lodash
moment
uuid
xml2js
cheerio
postman-collection
atob
btoa
csv-parse/lib/sync
tv4
ajv

Ngoài ra còn có các thư viện tích hợp của Node như:

path, assert, buffer, util, url, querystring, stream, events

Tải gói ngoài bằng `$$.liveRequire()`

Nếu package không có sẵn, dùng $$.liveRequire():

$$.liveRequire('nanoid', (nanoid) => {
  const id = nanoid.nanoid();

  pm.environment.set('request_id', id);
});

Cách này yêu cầu kết nối internet vì Apidog tải package khi script chạy.

Gỡ lỗi bằng console

Dùng một trong hai cách:

pm.console.log('Giá trị biến:', pm.environment.get('auth_token'));

Hoặc:

console.log('Chữ ký đã tạo:', signature);

Cả pm.console.log() và console.log() đều in ra console của Apidog. Đây là cách nhanh nhất để kiểm tra payload, signature, token hoặc dữ liệu phản hồi.

Hai giới hạn cần lưu ý

pm.sendRequest() dùng callback thay vì Promise. Không dùng await:

pm.sendRequest('https://example.com/api', function (error, response) {
  if (error) {
    console.log(error);
    return;
  }

  console.log(response.json());
});

Ngoài ra, pm.nextRequest() của Postman không được hỗ trợ.

Khi cần điều phối workflow có nhánh, điều kiện hoặc nhiều bước, hãy dùng Kịch bản kiểm thử (Test Scenarios). Bạn có thể sắp xếp request trực quan với các bước Condition và If-Else.

Tự động hóa workflow với Apidog CLI

Script không chỉ chạy khi bạn nhấn nút Send. Khi đóng gói request và assertion trong một Test Scenario đã lưu, bạn có thể chạy toàn bộ kịch bản bằng Apidog CLI, bao gồm cả Pre Processors và Post Processors.

Cài đặt CLI:

npm install -g apidog-cli

Đăng nhập bằng access token:

apidog login --with-token <YOUR_ACCESS_TOKEN>

Chạy một test scenario:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli

Ý nghĩa các cờ:

Cờ	Ý nghĩa
`-t`	ID của Test Scenario
`-e`	ID môi trường
`-r`	Reporter: `cli`, `html` hoặc `junit`

Bạn có thể dùng nhiều reporter, phân tách bằng dấu phẩy.

Tạo access token trong cài đặt tài khoản Apidog, xuất thành biến APIDOG_ACCESS_TOKEN, rồi chạy command này trong CI.

Lưu ý: script phụ thuộc vào tài nguyên chỉ có trên máy local, chẳng hạn tệp cục bộ hoặc package chỉ từng được tải thủ công, có thể chạy trong desktop app nhưng thất bại trong CLI. Để script chạy nhất quán, ưu tiên thư viện tích hợp sẵn hoặc $$.liveRequire().

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

Script Apidog có tương thích với script Postman hiện có không?

Phần lớn là có. Apidog sử dụng cùng API đối tượng pm, nên các lệnh sau hoạt động theo cách quen thuộc:

pm.environment.set();
pm.response.json();
pm.test();
pm.expect();

Khác biệt chính là tên tab:

Apidog: Pre Processors và Post Processors
Postman: Pre-request Script và Tests

Một số API như pm.nextRequest() không được hỗ trợ.

Vì sao `pm.response` là `undefined` trong Pre Processor?

Vì phản hồi chưa tồn tại. Pre Processors chạy trước khi request được gửi.

Mọi code đọc status, body hoặc header từ pm.response phải nằm trong Post Processors. Nếu cần dữ liệu ở giai đoạn trước, lấy từ pm.request, biến môi trường hoặc thư viện phù hợp. Xem thêm cách lấy request params trong pre/post request scripts.

Làm cách nào để chia sẻ script cho nhiều request?

Dùng Public Scripts tại Settings > Public Scripts.

Viết logic một lần, sau đó đính kèm vào Pre Processors hoặc Post Processors của từng request. Public Script chạy trước Custom Script trong cùng danh sách.

Nếu Custom Script cần gọi hàm từ Public Script, khai báo hàm ở phạm vi toàn cục:

myFunction = function () {
  // logic dùng chung
};

Tôi có thể dùng package npm không có sẵn trong Apidog không?

Có. Dùng:

$$.liveRequire('tên-gói', (pkg) => {
  // sử dụng pkg
});

Lệnh này tải package khi chạy nên cần internet.

Với package tích hợp sẵn như crypto-js, moment hoặc uuid, chỉ cần dùng require():

const CryptoJS = require('crypto-js');

Bạn phải import toàn bộ module, không dùng đường dẫn submodule.

Xem log từ script ở đâu?

Dùng:

pm.console.log('debug message');

Hoặc:

console.log('debug message');

Sau khi gửi request, xem kết quả trong console của Apidog.

Tóm lại

Pre Processors và Post Processors giúp request tự chuẩn bị và tự xác minh:

Ký request trước khi gửi.
Trích xuất token sau khi nhận phản hồi.
Xác nhận status code và cấu trúc dữ liệu.
Lưu biến để tái sử dụng trong các request tiếp theo.
Đưa logic dùng chung vào Public Scripts.
Chạy toàn bộ kịch bản trong CI bằng Apidog CLI.

Mở Apidog, chọn một request và thêm Custom Script đầu tiên để tự động hóa luồng API của bạn.

AI Đang Viết Code. Vậy Ai Quản Lý API?

Sebastian Petrus — Thu, 16 Jul 2026 06:43:10 +0000

Các tác nhân mã hóa AI đang thay đổi cách phần mềm được xây dựng. Chỉ trong vài phút, Claude Code, Cursor, Codex, GitHub Copilot, Windsurf, Trae, Cline và các công cụ tương tự có thể tạo route, handler, logic nghiệp vụ, truy vấn cơ sở dữ liệu, xác thực, kiểm thử và tích hợp frontend.

Dùng thử Apidog ngay hôm nay

Tốc độ này rất hữu ích, nhưng cũng đặt ra một câu hỏi vận hành quan trọng:

AI có thể viết mã. Nhưng ai quản lý API?

API không chỉ là mã. API là hợp đồng giữa frontend, backend, ứng dụng di động, dịch vụ bên thứ ba và đôi khi là khách hàng bên ngoài. Nếu AI thay đổi API nhưng tài liệu, schema, mock, môi trường, kiểm thử và quy trình review không được cập nhật cùng lúc, tốc độ phát triển sẽ nhanh hơn nhưng hệ thống lại khó vận hành hơn.

Đây là lúc Apidog CLI trở nên hữu ích. Công cụ này đưa các tác vụ quản lý API vào terminal để nhà phát triển, tác nhân AI và pipeline CI/CD có thể làm việc với tài liệu, mock, kiểm thử, môi trường, báo cáo, nhập/xuất và cộng tác nhánh.

Tóm tắt

Tác nhân AI có thể tạo mã API nhanh, nhưng vẫn cần một vòng đời API có cấu trúc:

Thiết kế hoặc cập nhật hợp đồng API.
Đồng bộ tài liệu, schema và mock.
Chạy kiểm thử API theo hành vi thực tế.
Xác thực thay đổi trong pull request và CI/CD.
Review API như một hợp đồng sản phẩm, không chỉ là diff mã nguồn.

Apidog CLI có thể đóng vai trò lớp quản lý API giữa mã do AI tạo và phần mềm sẵn sàng cho production.

Tạo mã không phải là quản lý API

Tác nhân AI có thể tạo nhanh:

Route Express
Handler FastAPI
Controller Spring Boot
Truy vấn cơ sở dữ liệu
Trình xác thực request
Đối tượng response
Lệnh gọi API từ frontend
Kiểm thử đơn vị và tích hợp
Mô tả theo phong cách OpenAPI

Tuy nhiên, một API có thể vận hành ổn định cần nhiều hơn việc tạo file. Nhóm cần quản lý:

Path và HTTP method
Tham số request, query và header
Schema request/response
Quy tắc xác thực và phân quyền
Định dạng lỗi
Biến và môi trường
Mock server
Tài liệu API
Test case, kịch bản và test suite
Báo cáo kiểm thử
Xác thực CI/CD
Review, versioning và cộng tác nhánh

Khi một lập trình viên thêm endpoint, họ thường biết cần cập nhật tài liệu và kiểm thử. Khi tác nhân AI thêm mười endpoint trong một phiên, các bước đó rất dễ bị bỏ qua.

Rủi ro của API do AI tạo

1. Endpoint không có tài liệu

AI có thể thêm endpoint sau:

POST /api/orders/refund

Route có thể hoạt động, nhưng nếu tài liệu không cập nhật, các nhóm khác sẽ không biết:

Request body nào là bắt buộc
Trường nào là tùy chọn
Mã trạng thái nào có thể trả về
Định dạng lỗi là gì
Endpoint có yêu cầu xác thực không
Frontend hoặc mobile có thể tích hợp như thế nào

Endpoint tồn tại, nhưng hợp đồng API lại không hiển thị.

2. Schema không nhất quán

Một endpoint có thể trả về:

{
  "userId": "u_123",
  "fullName": "Alex Chen",
  "emailAddress": "alex@example.com"
}

Trong khi endpoint khác trả về:

{
  "id": "u_123",
  "name": "Alex Chen",
  "email": "alex@example.com"
}

Cả hai đều có thể hợp lệ trong phạm vi cục bộ. Nhưng sự khác biệt này làm tăng chi phí:

Frontend phải ánh xạ nhiều kiểu dữ liệu
SDK cần thêm logic chuyển đổi
Kiểm thử dễ hỏng
Tài liệu trở nên khó đọc
Người dùng API mất niềm tin

Tính nhất quán không tự xảy ra; nó cần hợp đồng và quy trình làm việc dùng chung.

3. Mock lỗi thời

Mock rất quan trọng khi frontend và backend phát triển song song. Nếu AI thay đổi backend mà mock không được cập nhật, frontend có thể được xây dựng dựa trên giả định cũ.

Ví dụ:

Mock trả về status: "success"
API thực tế trả về state: "completed"
Frontend chạy tốt với mock nhưng lỗi khi tích hợp môi trường thật

4. Kiểm thử không phản ánh hợp đồng API

Kiểm thử do AI tạo có thể chỉ xác minh một luồng thành công trong mã. Kiểm thử API nên bao phủ cả hành vi hợp đồng:

Trường bắt buộc
Input không hợp lệ
Xác thực
Phân quyền
Mã trạng thái
Schema response
Response lỗi
Kịch bản nhiều bước
Hành vi theo từng môi trường

5. Điểm mù CI/CD

Một pull request do AI hỗ trợ có thể bao gồm endpoint mới, payload thay đổi, trường response bị xóa hoặc định dạng lỗi mới. Nếu API chỉ được kiểm tra thủ công, thay đổi có thể được merge trước khi bất kỳ ai xác thực API như một hợp đồng sản phẩm.

Câu hỏi đúng cho nhóm kỹ thuật

Câu hỏi không còn là:

AI có thể viết mã không?

Nó có thể.

Câu hỏi quan trọng hơn là:

Nhóm của bạn có thể quản lý các thay đổi API mà AI tạo ra không?

Trước khi merge một thay đổi API, hãy kiểm tra:

Hợp đồng API có rõ ràng không?
Tài liệu đã được cập nhật chưa?
Mock có còn khớp không?
Kiểm thử API có vượt qua không?
Môi trường đã được cấu hình chưa?
CI/CD có xác thực thay đổi này không?
Nhóm có thể review thay đổi không?
Tác nhân AI trong tương lai có đủ ngữ cảnh để tiếp tục làm việc không?

Apidog CLI cho phát triển AI-native

Apidog CLI đưa các quy trình cộng tác cốt lõi của Apidog vào terminal, tác nhân AI và pipeline CI/CD.

Bạn có thể sử dụng CLI để làm việc với:

Tài liệu API
Schema dữ liệu
API mock
Môi trường và biến
API test case
Kịch bản và test suite
Báo cáo kiểm thử
Nhập/xuất
Cộng tác nhánh

Thay vì chỉ giao cho tác nhân một yêu cầu như:

Tạo endpoint hoàn tiền.

Hãy giao một nhiệm vụ hoàn chỉnh hơn:

Xây dựng endpoint hoàn tiền, cập nhật hợp đồng API, đồng bộ tài liệu và mock, sau đó chạy kiểm thử API.

Xem đầy đủ các khả năng trong tài liệu Lệnh & Tùy chọn của Apidog CLI hoặc bắt đầu với hướng dẫn cài đặt và chạy Apidog CLI.

Nếu dự án được lưu trữ tại Apidog Europe, chỉ định API base URL của EU:

--api-base-url https://api.eu.apidog.com

Quy trình làm việc API khi dùng tác nhân AI

Bước 1: Giao nhiệm vụ tính năng cho AI

Ví dụ:

Thêm endpoint để tạo yêu cầu hoàn tiền.

Tác nhân có thể tạo logic backend, validation và các file liên quan. Tuy nhiên, đó chỉ là bước triển khai.

Bước 2: Thiết kế hoặc cập nhật hợp đồng API

Trước khi endpoint trở thành một phần của sản phẩm, xác định rõ:

Path
Method
Request body
Query parameter
Header
Response body
Response lỗi
Quy tắc xác thực

Nếu muốn quản lý bước này qua terminal, hãy xem Cách thiết kế API trong CLI.

Bước 3: Cập nhật tài liệu

Mỗi endpoint mới cần trả lời rõ:

Endpoint này làm gì?
Gọi endpoint như thế nào?
Cần gửi những trường nào?
Response có ý nghĩa gì?
Cần xử lý lỗi nào?

Xem hướng dẫn: Cách tài liệu hóa API trong CLI.

Bước 4: Đồng bộ mock với hợp đồng

Mock giúp frontend, backend, QA và tác nhân AI cùng làm việc dựa trên hành vi API thống nhất.

Khi hợp đồng thay đổi, hãy cập nhật mock trong cùng pull request. Tìm hiểu thêm tại Cách tạo API Mock trong CLI.

Bước 5: Chạy kiểm thử API từ terminal

Đừng chỉ kiểm thử mã nguồn. Hãy kiểm thử endpoint theo hành vi thực tế:

Status code có đúng không?
Schema response có khớp không?
Input không hợp lệ có bị từ chối không?
Authentication và authorization có hoạt động không?
Kịch bản nhiều bước có chạy thành công không?

Apidog CLI hỗ trợ chạy test case, kịch bản và test suite từ dòng lệnh, phù hợp cho:

Phát triển cục bộ
Quy trình làm việc của tác nhân AI
Kiểm tra pull request
Pipeline CI/CD
Xác thực trước phát hành

Bắt đầu tại Hướng dẫn đầy đủ về Apidog CLI.

Bước 6: Chạy quy trình không cần giao diện

Tác nhân AI và CI/CD cần lệnh có thể lặp lại, không phải thao tác nhấp qua UI. Một quy trình API không cần giao diện có thể chạy trong:

Terminal
Build pipeline
Container
Môi trường phát triển từ xa
Phiên mã hóa AI
Tác vụ tự động theo lịch

Xem thêm: Công cụ quản lý API không cần giao diện.

Dùng Apidog CLI với tác nhân mã hóa AI

Apidog CLI cung cấp một đường dẫn dòng lệnh để các tác nhân AI tham gia vào vòng đời API, không chỉ chỉnh sửa file nguồn.

Công cụ mã hóa AI	Hướng dẫn
Claude Code	Cách sử dụng Apidog CLI trong Claude Code
Cursor	Cách sử dụng Apidog CLI trong Cursor
Codex	Cách sử dụng Apidog CLI trong Codex
GitHub Copilot	Cách sử dụng Apidog CLI trong GitHub Copilot
Windsurf	Cách sử dụng Apidog CLI trong Windsurf
Trae	Cách sử dụng Apidog CLI trong Trae
Cline	Cách sử dụng Apidog CLI trong Cline
Antigravity	Cách sử dụng Apidog CLI trong Antigravity
OpenClaw	Cách sử dụng Apidog CLI trong OpenClaw
Hermes Agent	Cách sử dụng Apidog CLI trong Hermes Agent

Nguyên tắc chung là:

Tác nhân AI không chỉ nên tạo mã. Nó nên giúp duy trì quy trình API lành mạnh.

Đưa kiểm tra API vào CI/CD

Mã do AI tạo không nên đi thẳng từ trình soạn thảo đến production. Nó cần trải qua cùng quy trình xác thực như mã do con người viết.

Trong CI/CD, bạn có thể dùng Apidog CLI để:

Chạy kịch bản kiểm thử API sau pull request
Xác thực endpoint quan trọng trước triển khai
Tạo báo cáo kiểm thử API
Kiểm tra hành vi theo môi trường
Gắn kiểm thử API với quy trình phát hành

Tham khảo tài liệu tích hợp CI/CD của Apidog.

Checklist thực tế khi AI thay đổi API

Áp dụng checklist này cho mọi pull request có thay đổi API:

Kiểm tra hợp đồng

Path, method, request schema, response schema và error response phải rõ ràng.
Cập nhật tài liệu

Không merge endpoint mới nếu người dùng API chưa biết cách gọi nó.
Đồng bộ mock

Mock phải phản ánh hợp đồng hiện tại, không phải JSON mẫu cũ.
Chạy kiểm thử API

Kiểm tra happy path, validation, authentication, authorization và error case.
Tự động hóa bằng CLI

Biến các bước lặp lại thành lệnh để developer, AI agent và CI đều có thể chạy.
Bắt buộc kiểm tra trong CI/CD

Những endpoint quan trọng cần được xác thực trước khi phát hành.
Review hành vi API, không chỉ review mã

Hỏi rõ thay đổi có breaking không, tài liệu đã cập nhật chưa và người dùng có bị ảnh hưởng không.

Tại sao quản lý API quan trọng hơn khi có AI

AI tăng lượng mã mà nhóm có thể tạo. Đồng thời, nó cũng tăng số endpoint, schema, tích hợp và thay đổi API mà nhóm cần hiểu, review, kiểm thử và tài liệu hóa.

Khi tốc độ phát triển tăng, khả năng phối hợp càng quan trọng. Nếu không có một quy trình API trung tâm, nhiều endpoint, nhiều branch, nhiều mock và nhiều thay đổi backend sẽ nhanh chóng trở thành nhiễu loạn.

Apidog CLI giúp công việc API duy trì khả năng hiển thị, kiểm thử và lặp lại trong terminal, tác nhân AI và CI/CD.

Tư duy sản phẩm đằng sau Apidog CLI

Apidog CLI phản ánh sự dịch chuyển từ quy trình thao tác thủ công qua UI sang quy trình ưu tiên tự động hóa và được điều khiển bởi tác nhân.

Một nền tảng API hiện đại không chỉ là nơi con người nhấp nút. Nó cũng cần cung cấp workflow mà script, terminal, tác nhân AI và CI/CD có thể gọi.

Đọc thêm về bối cảnh sản phẩm tại Hành trình phát triển của Apidog CLI.

Tương lai: AI agent cần công cụ API, không chỉ trình soạn thảo mã

Khi tác nhân AI ngày càng giỏi viết mã, chúng cần quyền truy cập tốt hơn vào các hệ thống xung quanh mã:

Nền tảng API
Công cụ kiểm thử
Hệ thống tài liệu
Mock server
Quy trình CI/CD
Pipeline triển khai
Công cụ giám sát

Các nhóm hiệu quả nhất sẽ không chỉ yêu cầu AI viết nhiều mã hơn. Họ sẽ kết nối AI với các quy trình giúp phần mềm đáng tin cậy hơn.

Với API, điều đó có nghĩa là tác nhân cần làm việc được với hợp đồng, tài liệu, mock, kiểm thử và báo cáo.

Kết luận

AI có thể viết mã, nhưng mã chỉ là một phần của phát triển phần mềm.

API vẫn cần hợp đồng rõ ràng, tài liệu, mock, kiểm thử, môi trường, báo cáo và quy trình cộng tác. Nếu thiếu các thành phần này, mã do AI tạo có thể tăng sự nhầm lẫn nhanh hơn giá trị mà nó mang lại.

Apidog CLI đưa quản lý API vào dòng lệnh, nơi developer, tác nhân AI và hệ thống CI/CD đều có thể sử dụng.

AI có thể viết mã. Apidog CLI giúp nhóm của bạn quản lý các API đằng sau nó.

Câu hỏi thường gặp về Apidog CLI

Apidog CLI là gì?

Apidog CLI là công cụ dòng lệnh cho phép developer và tác nhân AI sử dụng các khả năng của Apidog bên ngoài ứng dụng, bao gồm tài liệu API, schema, mock, môi trường, biến, test case, kịch bản, test suite, báo cáo, nhập/xuất và cộng tác nhánh.

Tại sao quản lý API quan trọng khi AI viết mã?

AI có thể tạo API nhanh, nhưng nhóm vẫn cần hợp đồng rõ ràng, tài liệu cập nhật, mock chính xác, kiểm thử đáng tin cậy và xác thực CI/CD. Nếu không, endpoint có thể không nhất quán, không có tài liệu hoặc không được kiểm thử đầy đủ.

Apidog CLI có hoạt động với tác nhân mã hóa AI không?

Có. Apidog CLI được thiết kế cho workflow dòng lệnh và tác nhân AI, bao gồm Claude Code, Cursor, Codex, GitHub Copilot, Windsurf, Trae, Cline, Antigravity, OpenClaw và Hermes Agent.

Tôi có thể chạy kiểm thử API bằng Apidog CLI không?

Có. Apidog CLI hỗ trợ chạy API test case, kịch bản, test suite và báo cáo từ dòng lệnh, phù hợp với phát triển cục bộ, workflow của AI agent và CI/CD.

Apidog CLI có hỗ trợ tài liệu API không?

Có. Apidog CLI hỗ trợ quy trình tài liệu API qua dòng lệnh, giúp nhóm giữ tài liệu phù hợp với các thay đổi trong quá trình phát triển.

Apidog CLI có thể tạo hoặc quản lý API mock không?

Có. Apidog CLI hỗ trợ workflow mock để frontend, backend, QA và AI agent làm việc dựa trên hành vi API nhất quán.

Apidog CLI có hữu ích cho CI/CD không?

Có. Vì chạy từ dòng lệnh, Apidog CLI có thể được dùng trong CI/CD để chạy kiểm thử API, tạo báo cáo và tự động xác thực hành vi API.

Làm cách nào để dùng Apidog CLI với Apidog Europe?

Nếu dự án của bạn được lưu trữ tại Apidog Europe, chỉ định API base URL của EU khi chạy lệnh:


bash
--api-base-url https://api.eu.apidog.com

Cách sinh mã client từ API Spec trong Apidog

Sebastian Petrus — Thu, 16 Jul 2026 06:24:44 +0000

Bạn đã định nghĩa một endpoint và muốn gọi nó từ ứng dụng của mình. Phần tẻ nhạt là chuyển đổi đặc tả thành mã hoạt động: URL chính xác, tiêu đề, mã thông báo xác thực, chuỗi truy vấn — tất cả được kết nối vào một lệnh gọi requests hoặc fetch. Sao chép sai một ký tự và bạn có thể mất hai mươi phút để tìm lý do máy chủ trả về mã 401.

Dùng thử Apidog ngay hôm nay

Bạn không cần viết tay những đoạn mã trùng lặp đó. Nếu API được thiết kế trong Apidog, nền tảng sẽ đọc đặc tả endpoint và cung cấp đoạn mã yêu cầu sẵn sàng để dán bằng ngôn ngữ bạn đang dùng: cURL để kiểm tra nhanh trong terminal, Python requests cho script, JavaScript fetch hoặc Axios cho frontend.

Bài viết này hướng dẫn cách:

Tạo mã yêu cầu từ một endpoint thực tế.
Gửi yêu cầu trước để đưa giá trị thực tế vào đoạn mã.
Cập nhật mã khi đặc tả API thay đổi.
Kiểm tra endpoint trong CI bằng Apidog CLI.

Nếu muốn xem thêm các lựa chọn khác, hãy tham khảo bài tổng hợp về các công cụ tạo mã API.

Ý tưởng này dựa trên nguyên tắc đặc tả là nguồn chân lý duy nhất — cũng là nguyên tắc đằng sau OpenAPI Specification. Định nghĩa đúng một lần, rồi tạo mã yêu cầu từ cùng định nghĩa đó.

Trình tạo mã client thực sự làm gì?

Apidog biến định nghĩa endpoint thành đoạn mã yêu cầu theo ngôn ngữ và thư viện HTTP bạn chọn.

Ví dụ, với endpoint GET /orders, khi chọn Python và thư viện Requests, Apidog tạo mã gọi đúng đường dẫn cùng các tiêu đề và tham số được khai báo trong đặc tả.

Đây là trình tạo yêu cầu cho từng endpoint, không phải trình tạo SDK đầy đủ hoặc package client có phiên bản. Bạn có thể dùng nó để tạo:

Một lệnh cURL để chạy trong terminal.
Một khối Python requests.
Một đoạn JavaScript fetch hoặc Axios.
Mã tương ứng cho nhiều ngôn ngữ và thư viện HTTP khác.

Nếu bạn cần SDK được gõ kiểu đầy đủ, model dữ liệu hoặc tiện ích phân trang tích hợp sẵn, tính năng này không nhằm thay thế các công cụ tạo SDK chuyên dụng.

Quy trình này phù hợp với phát triển API thiết kế trước:

Định nghĩa hợp đồng API.
Tạo mã yêu cầu trực tiếp từ hợp đồng.
Đảm bảo mọi consumer bắt đầu từ cùng một định nghĩa.

Hai cách để mở trình tạo mã

Apidog có hai điểm truy cập vào trình tạo mã client.

Cách 1: Từ tab Tài liệu

Dùng cách này khi bạn đang đọc tài liệu endpoint:

Mở tab Tài liệu của API.
Chọn endpoint cần dùng.
Nhấp Tạo mã Client ở phía bên phải.
Chọn ngôn ngữ và thư viện HTTP.

Cách 2: Từ tab Chạy

Dùng cách này khi bạn đã cấu hình hoặc kiểm thử yêu cầu:

Mở endpoint trong tab Chạy.
Nhấp biểu tượng mã </>.
Chọn ngôn ngữ và biến thể thư viện.

Cả hai cách đều mở cùng một bảng điều khiển tạo mã.

Tạo lệnh gọi Python cho `GET /orders`

Ví dụ dưới đây dùng endpoint GET /orders để liệt kê đơn hàng, có lọc theo trạng thái và phân trang.

Bước 1: Mở endpoint và chọn ngôn ngữ

Mở endpoint trong tab Tài liệu, sau đó nhấp Tạo mã Client.

Apidog hỗ trợ nhiều ngôn ngữ và biến thể:

Shell: cURL, cURL-Windows, Httpie, wget, PowerShell
JavaScript: Fetch, Axios, jQuery, XHR, Native, Request, Unirest
Python: http.client, Requests
Java: Unirest, OkHttp
Go: Native
PHP: cURL, Guzzle, pecl_http, HTTP_Request2
Khác: Swift (URLSession), C (libcurl), C#, Objective-C, Ruby, OCaml, Dart, R và HTTP thô

Trong ví dụ này, chọn Python và Requests. Apidog sẽ tạo đoạn mã tương tự:

import requests

url = "https://api.example.com/orders"

querystring = {"status": "shipped", "page": "1"}

headers = {"Accept": "application/json"}

response = requests.get(url, headers=headers, params=querystring)

print(response.json())

Bạn có thể sao chép đoạn mã này vào script và chạy ngay, miễn là endpoint không yêu cầu thông tin xác thực bổ sung.

Bước 2: Hiểu mã được tạo từ đặc tả

Mã tạo trực tiếp từ đặc tả API chỉ chứa thông tin có trong đặc tả:

URL và HTTP method.
Header được khai báo.
Tham số truy vấn hoặc đường dẫn.
Giá trị ví dụ nếu đặc tả có định nghĩa.
Cấu trúc body yêu cầu nếu có.

Mã này không tự động chứa mã thông báo xác thực thực tế hoặc giá trị tham số bạn đã nhập khi chạy request.

Ví dụ, đoạn mã từ đặc tả có thể không bao gồm:

Authorization: Bearer <your-token>

Điều này phù hợp nếu endpoint không cần xác thực hoặc bạn muốn tự quản lý token trong mã nguồn. Nhưng với endpoint được bảo vệ như GET /orders, bạn thường cần tạo mã từ một yêu cầu đã gửi thực tế.

Bước 3: Gửi yêu cầu để lấy giá trị thực tế

Để tạo mã có cả tham số và header xác thực thực tế:

Mở endpoint trong tab Chạy.
Điền tham số yêu cầu.
Thêm token xác thực.
Nhấp Gửi.
Mở tab Yêu cầu Thực tế.
Cuộn xuống phần mã client và chọn ngôn ngữ cần dùng.

Nếu làm việc theo hướng thiết kế trước, các tham số từ đặc tả sẽ được điền tự động trong tab Chạy. Nếu đang thiết lập yêu cầu thủ công, hãy nhập chúng trực tiếp.

Sau khi gửi yêu cầu, đoạn Python được tạo có thể trông như sau:

import requests

url = "https://api.example.com/orders"

querystring = {"status": "shipped", "page": "1"}

headers = {
    "Accept": "application/json",
    "Authorization": "Bearer sk_live_51H8xY2..."
}

response = requests.get(url, headers=headers, params=querystring)

print(response.json())

Khác biệt chính là:

Nguồn tạo mã	Nội dung
Từ đặc tả	Cấu trúc endpoint và giá trị ví dụ
Từ Yêu cầu Thực tế	Giá trị tham số và header đã thực sự gửi

Không commit token hoặc khóa API từ đoạn mã được tạo vào Git. Hãy xử lý chúng như bí mật, tương tự khuyến nghị trong tài liệu Stripe về API keys.

Xử lý request body cho POST và PUT

GET /orders không có request body. Tuy nhiên, với POST /orders hoặc PUT /orders/{id}, bạn cần tạo body trước khi sinh mã client.

Trong tab Chạy, Apidog hỗ trợ tạo body JSON hoặc XML từ hai nguồn:

Ví dụ request đã được định nghĩa trong đặc tả.
Tùy chọn Tự động tạo dựa trên schema.

Menu Tự động tạo có hai chế độ:

Ví dụ: chọn thủ công một body mẫu đã được định nghĩa.
Tạo mỗi lần: tạo lại dữ liệu cho mỗi lần sử dụng dựa trên quy tắc mock và schema.

Bạn cũng có thể cấu hình ưu tiên tại Tùy chọn Tự động tạo:

Sử dụng Giá trị Ví dụ trước
Sử dụng Giá trị Mặc định trước
Sử dụng Giá trị Mock
Chỉ tạo Tên trường
Sử dụng Ví dụ Yêu cầu

Chọn Sử dụng Giá trị Ví dụ trước khi đặc tả đã có dữ liệu ví dụ chất lượng. Chọn Sử dụng Giá trị Mock khi cần dữ liệu mẫu hợp lệ cho từng trường.

Các tùy chọn Tự động tạo cho request body yêu cầu Apidog 2.7.0 trở lên. Nếu không thấy chúng, hãy cập nhật ứng dụng.

Một schema có mô tả tốt, kiểu dữ liệu rõ ràng và ví dụ phù hợp sẽ giúp tạo body chính xác hơn. Bạn có thể cải thiện chất lượng đặc tả bằng cách tự động tạo tài liệu API từ OpenAPI.

Khi cần giá trị thay đổi theo từng yêu cầu, chẳng hạn timestamp hoặc ID ngẫu nhiên:

Nhấp biểu tượng đũa thần cạnh trường tham số.
Hoặc dùng Chèn Giá trị Động trong body JSON/XML.
Gửi yêu cầu.
Lấy mã hoàn chỉnh từ tab Yêu cầu Thực tế.

Khi nào dùng đoạn mã yêu cầu thay vì mã trong mô hình nghiệp vụ?

Chọn lượng mã cần sao chép dựa trên nơi đoạn mã sẽ được sử dụng.

Dùng đoạn mã đơn lẻ cho tác vụ một lần

Chọn cURL, fetch đơn giản hoặc requests.get khi bạn cần:

Gỡ lỗi endpoint trả về 403.
Chia sẻ request có thể tái tạo trong ticket.
Kiểm tra nhanh từ terminal.
Thêm ví dụ vào tài liệu nội bộ.
Xác minh nhanh header, query string hoặc body.

Ví dụ cURL phù hợp để tái hiện một lỗi ngay lập tức:

curl --request GET \
  --url 'https://api.example.com/orders?status=shipped&page=1' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <TOKEN>'

Dùng mã có cấu trúc trong ứng dụng

Khi endpoint được gọi từ logic ứng dụng, hãy đóng gói mã được tạo vào service hoặc module.

Ví dụ với Python:

import os
import requests

API_BASE_URL = "https://api.example.com"
API_TOKEN = os.environ["API_TOKEN"]

def get_orders(status: str, page: int = 1) -> dict:
    response = requests.get(
        f"{API_BASE_URL}/orders",
        headers={
            "Accept": "application/json",
            "Authorization": f"Bearer {API_TOKEN}",
        },
        params={
            "status": status,
            "page": page,
        },
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

Cách này phù hợp hơn khi GET /orders được dùng ở nhiều nơi vì bạn có thể:

Tập trung xử lý xác thực.
Thêm timeout và xử lý lỗi.
Tái sử dụng logic.
Không lặp token trong từng request.

Nếu nhiều endpoint dùng chung xác thực hoặc tham số, hãy cấu hình chúng tập trung. Hướng dẫn về cách đặt tham số toàn cục trong Apidog cho thấy cách định nghĩa header và biến dùng chung một lần để các request kế thừa cấu hình đó.

Giữ mã được tạo chính xác với quy trình thiết kế trước

Mã được tạo chỉ chính xác khi đặc tả phía sau nó còn chính xác.

Ví dụ, nếu bạn thêm tham số truy vấn region vào GET /orders nhưng vẫn dùng đoạn mã cũ, request có thể thiếu tham số cần thiết mà không có cảnh báo rõ ràng.

Hãy áp dụng quy trình sau:

Cập nhật đặc tả endpoint.
Kiểm tra endpoint trong tab Chạy.
Gửi request với dữ liệu thực tế.
Tạo lại đoạn mã client.
Cập nhật service hoặc tài liệu đang dùng đoạn mã cũ.
Chạy test để xác minh hợp đồng.

Chế độ thiết kế trước của Apidog giúp giữ định nghĩa API làm nguồn chính thức, để mã yêu cầu luôn phản ánh hợp đồng hiện tại.

Với các đoạn JavaScript được tạo, hãy tham khảo tài liệu MDN về Fetch API nếu cần điều chỉnh cú pháp hoặc xử lý response.

Tự động hóa quy trình với Apidog CLI

Tạo mã client là thao tác trong GUI: bạn mở bảng mã và sao chép đoạn mã cần dùng. Không có lệnh CLI riêng chỉ để xuất mã client.

Tuy nhiên, Apidog CLI giúp tự động hóa hai phần quan trọng:

Giữ đặc tả API được cập nhật.
Chạy test để xác minh endpoint vẫn hoạt động đúng hợp đồng.

Cài đặt CLI bằng Node.js v16 trở lên:

npm install -g apidog-cli

Xác thực bằng access token:

apidog login --with-token <YOUR_ACCESS_TOKEN>

Chạy kịch bản kiểm tra đã lưu:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Trong đó:

-t: ID kịch bản kiểm tra.
-e: ID môi trường.
-r: định dạng báo cáo, gồm cli, html hoặc junit.

Tích hợp lệnh này vào CI để mỗi lần push đều xác minh endpoint vẫn đáp ứng đặc tả trước khi đội ngũ tạo lại mã client. Xem thêm hướng dẫn Apidog CLI với GitHub Actions.

CLI không trực tiếp viết mã client, nhưng nó bảo vệ hợp đồng mà mã client dựa vào.

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

Mã được tạo có bao gồm API key và token không?

Không theo mặc định. Mã tạo trực tiếp từ đặc tả không chứa giá trị tham số thực tế hoặc thông tin xác thực đang dùng.

Để lấy đoạn mã có token và tham số thật:

Cấu hình request trong tab Chạy.
Gửi request.
Mở tab Yêu cầu Thực tế.
Sao chép mã client từ request đã gửi.

Không đưa token trong đoạn mã đó vào repository công khai hoặc commit trực tiếp vào Git.

Apidog có thể tạo mã cho ngôn ngữ và thư viện nào?

Apidog hỗ trợ nhiều lựa chọn, bao gồm:

Shell: cURL, Httpie, wget, PowerShell.
JavaScript: Fetch, Axios, jQuery, XHR và các biến thể khác.
Python: http.client, Requests.
Java: Unirest, OkHttp.
Go, PHP, Swift, C, C#, Ruby, Dart, R và các ngôn ngữ khác.

Bạn chọn ngôn ngữ và thư viện cụ thể trong bảng tạo mã.

Tại sao tôi không thấy tùy chọn Tự động tạo cho request body?

Các tùy chọn này yêu cầu Apidog 2.7.0 trở lên.

Sau khi cập nhật, bạn sẽ thấy chúng trong tab Chạy khi tạo body JSON hoặc XML. Menu Tự động tạo cung cấp các chế độ Ví dụ và Tạo mỗi lần, cùng các tùy chọn ưu tiên cho giá trị được tạo.

Tính năng tạo mã client có phải là tính năng trả phí không?

Tài liệu Apidog không phân định rõ giữa miễn phí/trả phí hoặc cloud/tự lưu trữ đối với tính năng tạo mã client.

Yêu cầu phiên bản được nêu rõ là tùy chọn body Tự động tạo cần Apidog 2.7.0 trở lên. Bạn có thể tải xuống Apidog và thử trình tạo mã.

Làm thế nào để đảm bảo lệnh gọi được tạo thực sự hoạt động?

Sau khi tạo mã:

Lưu một kịch bản kiểm tra cho endpoint.
Chạy kịch bản trong Apidog.
Chạy lại bằng CLI trong CI.
Chỉ cập nhật mã client sau khi test xác nhận endpoint hoạt động đúng.

Xem hướng dẫn về cách viết kịch bản kiểm tra với Apidog để thiết lập test cho endpoint.

Tóm tắt

Tạo mã client trong Apidog giúp biến đặc tả endpoint thành request sẵn sàng dán bằng ngôn ngữ và thư viện bạn đang dùng.

Quy trình thực tế:

Định nghĩa endpoint trong đặc tả.
Mở Tạo mã Client để lấy cấu trúc request.
Gửi request trong tab Chạy nếu cần token và giá trị thực tế.
Sao chép mã từ tab Yêu cầu Thực tế.
Không commit secret vào mã nguồn.
Tạo lại mã khi đặc tả thay đổi.
Dùng test và CLI để xác minh endpoint trong CI.

Tải xuống Apidog, định nghĩa endpoint GET /orders và tạo một lệnh gọi client hoạt động chỉ trong vài cú nhấp chuột.

Hướng dẫn kiểm thử API mTLS bằng Apidog

Sebastian Petrus — Thu, 16 Jul 2026 06:14:23 +0000

Bạn gọi một API đối tác với payload đúng định dạng và token hợp lệ nhưng vẫn nhận lỗi TLS handshake failure. Nguyên nhân có thể là endpoint yêu cầu client chứng minh danh tính bằng chứng chỉ trước khi bất kỳ yêu cầu HTTP nào được gửi đi. Đây là TLS song phương (mutual TLS hoặc mTLS), và việc cấu hình sai chứng chỉ có thể chặn toàn bộ quá trình tích hợp.

Dùng thử Apidog ngay hôm nay

Hướng dẫn này trình bày cách cấu hình chứng chỉ client và chứng chỉ CA trong Apidog để kiểm thử API bảo vệ bằng mTLS. Bạn sẽ liên kết chứng chỉ client với một host, thêm CA cho chứng chỉ tự ký hoặc root nội bộ, rồi gửi yêu cầu HTTPS đã được Apidog tự động ký. Nếu bạn mới làm việc với chứng chỉ, hãy đọc thêm về xác minh chứng chỉ SSL. Để hiểu giao thức nền tảng, xem tài liệu TLS của MDN.

TLS song phương là gì và tại sao API yêu cầu nó?

Với HTTPS thông thường, việc xác minh diễn ra một chiều:

Máy chủ gửi chứng chỉ của nó.
Client xác minh chứng chỉ đó.
Kết nối mã hóa được thiết lập.
Client gửi token hoặc API key trong yêu cầu để xác thực ở tầng ứng dụng.

Với mTLS, máy chủ cũng yêu cầu client gửi chứng chỉ:

Máy chủ trình bày chứng chỉ TLS.
Client xác minh chứng chỉ máy chủ.
Client trình bày chứng chỉ client.
Máy chủ xác minh chứng chỉ client.
Chỉ khi cả hai bên được tin cậy, yêu cầu HTTP mới được gửi.

Nếu chứng chỉ client không được ký bởi CA mà máy chủ tin cậy, quá trình bắt tay thất bại. Khi đó sẽ không có header, body hay token nào được truyền đi.

mTLS thường xuất hiện trong các trường hợp sau:

Ngân hàng và thanh toán: API ngân hàng mở hoặc hệ thống xử lý thẻ thường yêu cầu chứng chỉ client bên cạnh OAuth. Tài liệu Stripe mô tả mô hình thông tin xác thực nhiều lớp cho endpoint tài chính nhạy cảm.
Giao tiếp nội bộ giữa các dịch vụ: Môi trường zero-trust yêu cầu dịch vụ xác minh danh tính bằng chứng chỉ thay vì chỉ dựa vào mạng nội bộ.
API đối tác B2B: Đối tác có thể cấp chứng chỉ client trong quá trình onboarding để giới hạn quyền truy cập cho các máy hoặc hệ thống đã đăng ký.

Nếu API sử dụng cả OAuth và mTLS, hai cơ chế này không thay thế nhau. RFC 8705 mô tả cách liên kết token OAuth với chứng chỉ client.

Chứng chỉ client xác thực ở tầng TLS/network.

Token, API key, OAuth và Basic Auth xác thực ở tầng HTTP/application.

Trong Apidog:

Tab Certificates dùng để cấu hình mTLS.
Tab Authorization dùng cho API key, Bearer token, OAuth và Basic Auth.

Bạn có thể cần cấu hình cả hai.

Apidog liên kết chứng chỉ với host như thế nào?

Apidog cấu hình chứng chỉ ở phạm vi toàn cục, không phải trên từng request. Bạn thêm chứng chỉ một lần, liên kết nó với host, và Apidog tự động sử dụng chứng chỉ đó cho mọi yêu cầu HTTPS khớp với host.

Có hai loại chứng chỉ cần phân biệt:

Loại	Mục đích
Client Certificate	Chứng minh danh tính client với máy chủ trong quy trình mTLS.
CA Certificate	Cho phép Apidog tin cậy máy chủ sử dụng CA nội bộ hoặc chứng chỉ tự ký.

Ví dụ:

API đối tác yêu cầu mTLS → thêm client certificate.
Server staging dùng private root CA → thêm CA certificate.
API nội bộ dùng cả mTLS và private CA → cần cả hai.

Việc khớp dựa trên host. Nếu host cấu hình không khớp URL yêu cầu, Apidog sẽ không gửi chứng chỉ client.

Thiết lập chứng chỉ client cho API mTLS

Giả sử đối tác cấp cho bạn:

Host: partner-api.acmebank.com
Endpoint: GET /v1/settlements
Một chứng chỉ client và private key
OAuth token để xác thực yêu cầu

Bước 1: Mở phần Certificates

Trong Apidog:

Chọn biểu tượng cài đặt ở góc trên bên phải.
Mở tab Certificates.
Tìm phần Client Certificates.

Các chứng chỉ tại đây sẽ được áp dụng tự động dựa trên host, thay vì gắn vào một request riêng lẻ.

Bước 2: Thêm client certificate

Trong phần Client Certificates, chọn Add Certificate.

Ở trường Host, chỉ nhập tên miền:

partner-api.acmebank.com

Không nhập giao thức:

https://partner-api.acmebank.com

Nếu đối tác sử dụng cùng chứng chỉ cho nhiều subdomain, bạn có thể dùng wildcard:

*.acmebank.com

Ví dụ này có thể áp dụng cùng chứng chỉ cho:

partner-api.acmebank.com
sandbox-api.acmebank.com
settlements-api.acmebank.com

Cổng mặc định là 443. Chỉ điền cổng nếu endpoint mTLS dùng cổng khác, chẳng hạn:

Bước 3: Chọn định dạng chứng chỉ

Apidog hỗ trợ hai dạng phổ biến.

Cách 1: CRT và private key riêng biệt

Chọn:

File chứng chỉ, ví dụ .crt
File private key, ví dụ .key

Ví dụ:

client.crt
client.key

Cách 2: File PFX

Nếu đối tác cấp một file chứa cả chứng chỉ và private key, chọn file .pfx.

client-certificate.pfx

Nếu private key hoặc PFX có passphrase, nhập passphrase vào trường tương ứng. Nếu không có, để trống.

Bước 4: Lưu chứng chỉ

Chọn Add để lưu.

Sau khi lưu, chứng chỉ được liên kết với:

partner-api.acmebank.com

Từ thời điểm này, Apidog sẽ tự động dùng chứng chỉ khi bạn gọi HTTPS đến host đó.

Bước 5: Gửi yêu cầu mTLS

Tạo request:

GET https://partner-api.acmebank.com/v1/settlements
Authorization: Bearer <your_oauth_token>

Apidog thực hiện các bước sau:

Khớp host với cấu hình certificate.
Gửi client certificate trong TLS handshake.
Hoàn tất xác thực mTLS.
Gửi Bearer token trong HTTP request.

Ví dụ phản hồi thành công:

{
  "settlements": [
    {
      "id": "stl_88213",
      "amount": 41200,
      "currency": "USD",
      "status": "cleared",
      "settled_at": "2026-07-14T09:31:00Z"
    }
  ],
  "next_cursor": null
}

Chứng chỉ xác thực máy hoặc hệ thống gọi API; token xác thực phiên, ứng dụng hoặc người dùng ở tầng HTTP.

Thêm chứng chỉ CA cho root nội bộ hoặc chứng chỉ tự ký

Client certificate chỉ xử lý việc máy chủ xác minh bạn. Bạn cũng cần xử lý chiều ngược lại: client phải tin cậy chứng chỉ của máy chủ.

Nếu server dùng chứng chỉ được ký bởi CA nội bộ hoặc chứng chỉ tự ký, request có thể thất bại với lỗi:

SSL Error: Self signed certificate

Lỗi này xảy ra trước khi mTLS hoàn tất.

Cách thêm CA certificate

Trong tab Certificates:

Bật CA Certificates.
Chọn file CA ở định dạng PEM.
Lưu cấu hình.

Một file PEM có thể chứa nhiều chứng chỉ, bao gồm root CA và intermediate CA:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQG...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEFTCCAv2gAwIBAgIQeM8V5x8B3QksZ4 b2VqkJTANBgkqhkiG9w0BAQ...
-----END CERTIFICATE-----

Sau khi thêm CA:

Apidog có thể tin cậy server được ký bởi CA này.
Client certificate cho phép server tin cậy bạn.
Kết nối mTLS nội bộ có thể hoạt động từ đầu đến cuối.

Mẹo cấu hình mTLS trong Apidog

Dùng wildcard cho nhiều subdomain

Nếu một chứng chỉ áp dụng cho nhiều endpoint của đối tác, dùng:

*.acmebank.com

Thay vì thêm riêng từng host:

partner-api.acmebank.com
sandbox-api.acmebank.com
settlements-api.acmebank.com

Kiểm tra cổng không chuẩn

Nếu API dùng cổng như 8443 hoặc 9443, hãy cấu hình đúng cổng trong certificate settings.

Ví dụ URL:

https://partner-api.acmebank.com:8443/v1/settlements

Nếu bạn không cấu hình cổng phù hợp, host có thể không khớp và Apidog sẽ không gửi chứng chỉ.

Chứng chỉ không thể chỉnh sửa trực tiếp

Nếu cần thay chứng chỉ đã gia hạn hoặc sửa host:

Xóa chứng chỉ cũ.
Thêm lại chứng chỉ mới.

Đưa bước này vào quy trình xoay vòng chứng chỉ để tránh gián đoạn kiểm thử.

Chỉ giữ một chứng chỉ cho mỗi host

Không nên đăng ký nhiều client certificate cho cùng một tên miền. Điều này tạo ra sự mơ hồ về chứng chỉ cần gửi trong handshake.

Mỗi host nên có một certificate binding rõ ràng.

Tách biệt Certificates và Authorization

Đây là lỗi cấu hình phổ biến nhất:

Cấu hình	Vị trí trong Apidog
Client certificate, CA certificate, mTLS	Certificates
API key, Bearer token, OAuth, Basic Auth	Authorization

Authorization có thể được cấu hình ở:

Từng request
Folder
Collection

Các request có thể kế thừa authorization từ folder hoặc collection cha.

Để tìm hiểu thêm về token-based authentication, xem hướng dẫn xác thực gateway API. Nếu bạn làm việc trong môi trường Windows, xem thêm bài cấu hình xác thực Kerberos trong Apidog.

mTLS chỉ hoạt động với HTTPS

Apidog không gửi client certificate cho URL HTTP thuần túy:

http://partner-api.acmebank.com

URL phải dùng HTTPS:

https://partner-api.acmebank.com

Nếu endpoint bắt đầu bằng http://, TLS handshake sẽ không chạy và chứng chỉ sẽ không được gửi.

Tự động hóa kiểm thử mTLS bằng Apidog CLI

Sau khi request chạy được trong giao diện Apidog, bạn có thể chạy scenario trong CI/CD bằng Apidog CLI.

Cài đặt CLI:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Chạy scenario đã lưu với một environment:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Apidog CLI hỗ trợ truyền trực tiếp cấu hình chứng chỉ:

--ssl-client-cert: đường dẫn đến chứng chỉ PEM
--ssl-client-key: đường dẫn đến private key
--ssl-client-passphrase: passphrase của private key
--ssl-extra-ca-certs: CA bổ sung cần tin cậy
--ssl-client-cert-list: file cấu hình ánh xạ chứng chỉ theo mẫu URL

Ví dụ với nhiều reporter:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t <scenario_id> \
  -e <env_id> \
  -r html,cli

Bạn có thể đưa lệnh này vào pipeline để kiểm thử API mTLS trên mỗi lần push. Xem hướng dẫn chạy Apidog CLI trong CI/CD để tích hợp vào pipeline.

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

Tôi cần client certificate, CA certificate hay cả hai?

Tùy vào endpoint:

Cần client certificate khi server yêu cầu mTLS.
Cần CA certificate khi server dùng CA chưa được máy bạn tin cậy, chẳng hạn private root CA.
Cần cả hai khi API nội bộ vừa dùng mTLS vừa sử dụng chứng chỉ server được ký bởi private CA.

API công khai sử dụng CA công khai thường chỉ cần client certificate.

Tại sao Apidog không gửi client certificate?

Kiểm tra các điểm sau:

Host trong cấu hình phải khớp chính xác URL request.
Không thêm https:// vào trường Host.
Cổng phải khớp nếu endpoint không dùng 443.
URL request phải bắt đầu bằng https://.

Ví dụ host đúng:

partner-api.acmebank.com

Ví dụ host sai:

https://partner-api.acmebank.com

API key và Bearer token được cấu hình ở đâu?

Cấu hình chúng trong tab Authorization, không phải Certificates.

Xem thêm hướng dẫn về sơ đồ bảo mật để phân biệt các loại xác thực và cách kế thừa Authorization trong collection.

Một chứng chỉ có thể dùng cho nhiều subdomain không?

Có. Dùng wildcard trong trường Host:

*.example.com

Cấu hình này áp dụng chứng chỉ cho mọi subdomain của example.com.

Làm cách nào để cập nhật chứng chỉ?

Chứng chỉ không chỉnh sửa trực tiếp được. Hãy xóa certificate hiện có và thêm lại certificate mới hoặc certificate đã gia hạn.

Khi quản lý nhiều môi trường, bạn cũng có thể dùng tham số toàn cục trong Apidog để giữ URL, token và giá trị môi trường nhất quán giữa các request.

Tổng kết

Để kiểm thử API mTLS trong Apidog:

Liên kết client certificate với đúng host.
Thêm CA certificate nếu server dùng private root hoặc chứng chỉ tự ký.
Gửi request HTTPS để Apidog tự động chọn và đính kèm chứng chỉ.
Cấu hình OAuth, API key hoặc Bearer token riêng trong Authorization.

Giữ tách biệt giữa TLS certificate và HTTP authorization sẽ giúp bạn xác định lỗi handshake nhanh hơn và cấu hình mTLS ổn định hơn.

Tải Apidog, thêm chứng chỉ của đối tác và gửi request mTLS đầu tiên của bạn. Dùng thử miễn phí, không cần thẻ tín dụng.

Cách kiểm thử API upload file (multipart/form-data) trong Apidog

Sebastian Petrus — Thu, 16 Jul 2026 06:05:07 +0000

Bạn đã xây dựng một endpoint nhận tệp: người dùng tải ảnh đại diện lên POST /avatars, hoặc ứng dụng đẩy PDF đã ký lên POST /documents. Bây giờ, bạn cần kiểm tra nó qua HTTP: chọn một tệp thực, đính kèm vào trường biểu mẫu, gửi yêu cầu và xác minh phản hồi.

Thử Apidog ngay hôm nay

Tải tệp dùng multipart/form-data, không phải JSON. Vì vậy, bạn không thể chỉ dán nội dung vào body rồi nhấn gửi. Bạn cần một công cụ có thể đính kèm trường tệp và một quy trình kiểm thử có thể tìm thấy tệp khi chạy lại trong Runner hoặc CLI. Apidog hỗ trợ cả hai.

Bài viết này tập trung vào quy trình triển khai:

Gửi một tệp đơn lẻ.
Gửi tệp kèm JSON.
Xác nhận phản hồi.
Chạy lại bài kiểm thử trong Runner hoặc CLI khi tệp không còn ở máy cục bộ.

Nếu cần tìm hiểu cấu trúc multipart trước, xem bài tải tệp trong API. Tài liệu MDN về FormData cũng hữu ích khi bạn làm việc ở phía trình duyệt.

multipart/form-data là gì và tại sao tác vụ tải tệp cần nó

Body của một yêu cầu API có thể là form-data, x-www-form-urlencoded, JSON, XML, raw hoặc binary. Trong phần lớn trường hợp, bạn sẽ dùng JSON. Tải tệp là ngoại lệ.

Khi chọn form-data, Apidog tạo body với tiêu đề:

Content-Type: multipart/form-data

Body được chia thành nhiều phần. Mỗi phần có tên và dữ liệu riêng:

Một phần có thể là chuỗi như title.
Một phần có thể là byte thô của ảnh hoặc PDF.
Các phần này được gửi trong cùng một HTTP request.

Người họ hàng gần của nó là x-www-form-urlencoded. Dù đều có dạng khóa-giá trị, định dạng này chỉ phù hợp cho các trường văn bản ngắn, không chứa tệp.

Quy tắc chọn nhanh:

Trường hợp	Body nên dùng
Chỉ có dữ liệu JSON	`JSON`
Form đơn giản, không có tệp	`x-www-form-urlencoded`
Có ảnh, PDF, video hoặc tệp bất kỳ	`form-data`

Trong form-data, mỗi tham số có kiểu riêng như string, integer hoặc file. Điểm quan trọng là: khi đặt kiểu thành file, Apidog sẽ đính kèm nội dung tệp thay vì gửi đường dẫn dưới dạng văn bản.

Gửi một tệp tải lên duy nhất và xác nhận phản hồi

Giả sử bạn đang kiểm thử:

POST /avatars

Endpoint nhận trường avatar chứa ảnh và trả JSON với URL ảnh đã lưu.

1. Chọn Body là form-data

Trong Apidog:

Đặt method là POST.
Nhập URL endpoint, ví dụ https://api.example.com/avatars.
Mở tab Body.
Chọn form-data.

Apidog sẽ tự đặt Content-Type: multipart/form-data.

2. Thêm trường tệp

Thêm một hàng tham số:

Key	Type	Value
`avatar`	`file`	Chọn tệp

Đổi kiểu của trường avatar từ string sang file. Ô giá trị sẽ chuyển thành trình chọn tệp.

3. Chọn tệp cục bộ

Nhấp Upload trên hàng avatar, sau đó chọn tệp, ví dụ:

jane-profile.png

Apidog lưu đường dẫn cục bộ đến tệp, không lưu byte của tệp trên đám mây.

4. Gửi request

Nhấn Send. Apidog sẽ:

Đọc tệp từ đường dẫn cục bộ.
Tạo multipart body.
Gửi request đến endpoint.

Một phản hồi thành công có thể như sau:

{
  "id": "usr_8842",
  "avatarUrl": "https://cdn.example.com/avatars/usr_8842.png",
  "sizeBytes": 48210,
  "contentType": "image/png"
}

5. Thêm assertions

Status 200 không đủ để chứng minh endpoint hoạt động đúng. Hãy thêm post-request assertions để xác minh dữ liệu quan trọng:

status code == 200
$.avatarUrl exists
$.contentType == "image/png"

Các assertion này kiểm tra:

Request trả về HTTP 200.
JSON có trường avatarUrl.
Máy chủ nhận đúng loại MIME của tệp.

Xem thêm hướng dẫn xác nhận API để biết các toán tử và cách dùng JSONPath.

Tương đương với curl:

curl -X POST https://api.example.com/avatars \
  -F "avatar=@jane-profile.png"

Cờ -F tạo multipart request, còn @ yêu cầu curl đọc nội dung từ tệp. Trường file trong Apidog thực hiện cùng chức năng đó qua giao diện.

Gửi một tệp và JSON cùng nhau

Các endpoint thực tế thường cần cả tệp lẫn metadata. Ví dụ:

POST /documents

Endpoint có thể nhận:

Tệp PDF.
Tiêu đề.
Danh mục.
Danh sách thẻ.

Trường dữ liệu đơn giản

Với dữ liệu vô hướng, thêm các hàng form-data bên cạnh trường tệp:

Key	Type	Ví dụ
`file`	`file`	`q3-invoice.pdf`
`title`	`string`	`Q3 Invoice`
`category`	`string`	`billing`

Tất cả được gửi trong một multipart request.

Metadata có cấu trúc

Nếu metadata là object lồng nhau hoặc mảng, gửi JSON dưới dạng một trường string:

Key	Type	Value
`file`	`file`	`q3-invoice.pdf`
`metadata`	`string`	JSON bên dưới

{
  "title": "Q3 Invoice",
  "category": "billing",
  "tags": ["invoice", "2026", "paid"]
}

Máy chủ sẽ:

Đọc PDF từ phần file.
Phân tích JSON từ phần metadata.

Đây là mẫu multipart phổ biến. Ví dụ, tài liệu tải tệp của Stripe minh họa một endpoint nhận phần tệp cùng các trường dữ liệu khác.

Nếu đang chuyển từ Postman, xem hướng dẫn tải tệp và dữ liệu JSON trong Postman.

Đính kèm nhiều tệp

Không cần chế độ đa tệp riêng. Chỉ cần thêm nhiều trường kiểu file:

Key	Type
`file`	`file`
`thumbnail`	`file`

Mỗi trường có nút Upload riêng.

Biến request thành kịch bản kiểm thử có thể lặp lại

Một lần gửi request chỉ chứng minh endpoint hoạt động tại thời điểm đó. Để phát hiện lỗi hồi quy, hãy lưu request trong test scenario.

Ví dụ một luồng kiểm thử:

Gọi POST /avatars.
Lấy id từ response.
Gọi GET /users/{id}.
Xác minh avatarUrl đã được lưu.

Bạn có thể lưu bước tải tệp như một bước trong scenario, sau đó truyền id sang bước tiếp theo. Hướng dẫn cách viết kịch bản kiểm thử với Apidog trình bày cách nối các bước và truyền giá trị giữa chúng.

Sau khi tạo scenario, bạn có thể:

Chạy trên staging sau mỗi lần triển khai.
Thêm nhánh với logic điều kiện trong các kịch bản kiểm thử API.
Chạy định kỳ bằng các bài kiểm thử API theo lịch trình.

Tuy nhiên, có một vấn đề quan trọng: máy của bạn có tệp, nhưng Runner hoặc CLI có thể không có.

Cái bẫy: tác vụ tải tệp chạy ở nơi khác

Apidog lưu đường dẫn tệp, không lưu tệp. Trên máy cục bộ, điều này thường không gây vấn đề vì đường dẫn vẫn hợp lệ.

Ví dụ, bạn chọn:

/Users/jane/pics/jane-profile.png

Đường dẫn này chỉ tồn tại trên máy của bạn. Khi cùng request chạy ở máy khác, nó có thể không tìm thấy tệp.

Bạn thường gặp vấn đề này trong hai trường hợp.

Hợp tác nhóm

Đồng đội có thể mở request của bạn và thấy đường dẫn:

/Users/jane/pics/jane-profile.png

Nhưng họ không thể gửi request nếu tệp không tồn tại trên máy của họ.

Cách xử lý: mỗi người cần có bản sao tệp và đặt đường dẫn phù hợp trên máy của mình, hoặc dùng biến môi trường cho đường dẫn.

Chạy bằng Runner hoặc CLI

Kịch bản có thể chạy thành công cục bộ nhưng thất bại trên Runner hoặc CI vì Runner không có tệp tại đường dẫn cục bộ của bạn.

Nguyên tắc xử lý là:

Tệp phải tồn tại trên máy thực hiện request, và trường tệp phải trỏ đến đường dẫn hợp lệ trên máy đó.

Thiết lập tệp cho Runner

Runner đọc tệp từ thư mục máy chủ đã được mount vào volume bằng cờ -v.

Quy trình:

Mount thư mục chứa fixture khi triển khai Runner.
Sao chép tệp tải lên vào thư mục đó.
Mở bước tải tệp trong scenario.
Nhấp Batch Edit.
Thay thế đường dẫn tệp bằng đường dẫn trong môi trường Runner.

Ví dụ:

/opt/runner/jane-profile.png

Thiết lập tệp cho CLI

Với CLI, nguyên tắc tương tự:

Đặt tệp trên máy chạy CLI hoặc CI runner.
Dùng Batch Edit để cập nhật đường dẫn.
Hoặc tốt hơn, dùng biến môi trường.

Ví dụ:

/opt/apidog/runner/jane-profile.png

Dùng biến thay vì mã hóa cứng đường dẫn

Không nên hard-code đường dẫn trong bước kiểm thử. Thay vào đó, dùng biến, ví dụ:

{{avatar_file_path}}

Sau đó đặt giá trị biến theo môi trường:

Môi trường	`avatar_file_path`
Local	`/Users/jane/pics/jane-profile.png`
Runner	`/opt/runner/jane-profile.png`
CI	`/opt/apidog/runner/jane-profile.png`

Nhờ đó, scenario không cần thay đổi khi chạy ở môi trường khác.

Runner chỉ truy cập được tệp trong thư mục đã được mount bằng -v khi triển khai. Nếu tệp nằm ngoài vùng mount, không có đường dẫn nào có thể đọc được nó.

Xem tài liệu Apidog về các yêu cầu tải tệp để biết chi tiết về mount volume và Batch Edit.

Tự động hóa quy trình với Apidog CLI

Sau khi lưu scenario, bạn có thể chạy nó ở chế độ headless trong CI.

Cài đặt CLI:

npm install -g apidog-cli

Xác thực bằng access token:

apidog login --with-token <YOUR_ACCESS_TOKEN>

Chạy scenario theo ID và môi trường:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Trong đó:

-t: ID của test scenario.
-e: ID của environment.
-r: reporter, có thể là cli, html hoặc junit.

Bạn có thể chỉ định nhiều reporter, phân tách bằng dấu phẩy.

CLI chạy scenario từ cloud project và trả kết quả pass/fail qua exit code, vì vậy nó phù hợp để kiểm soát pipeline CI.

Xem thêm hướng dẫn cài đặt Apidog CLI.

Lưu ý quan trọng: CLI vẫn cần tệp tồn tại trên máy đang chạy. Trước khi chạy:

Chuẩn bị tệp trên CI runner.
Đặt đúng đường dẫn bằng Batch Edit hoặc biến môi trường.
Sau đó mới chạy scenario.

Nếu bỏ qua bước này, request tải tệp sẽ thất bại dù các bước khác trong scenario vẫn đúng. Để chạy theo nhiều bộ dữ liệu, xem kiểm thử dựa trên dữ liệu với Apidog CLI.

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

Tại sao đồng đội của tôi không thể gửi request tải tệp?

Apidog lưu đường dẫn tệp cục bộ, không lưu tệp trên đám mây. Đường dẫn của bạn trỏ đến ổ đĩa của bạn, không phải máy của đồng đội.

Hãy yêu cầu họ:

Tải hoặc sao chép tệp về máy.
Chọn lại tệp trong trường file.
Hoặc cấu hình biến đường dẫn riêng cho môi trường của họ.

Cơ chế tương tự cũng áp dụng cho các bài kiểm thử theo lịch trình và Runner.

Làm cách nào để gửi JSON cùng với tệp trong một request?

Giữ body là form-data:

Thêm trường tệp với kiểu file.
Thêm trường metadata với kiểu string.
Dán JSON vào giá trị của trường metadata.

Máy chủ sẽ nhận tệp và chuỗi JSON trong hai phần riêng của multipart request.

Tôi nên dùng đường dẫn nào cho tệp trong Runner?

Dùng đường dẫn bên trong thư mục đã mount vào Runner bằng cờ -v.

Ví dụ:

/opt/runner/yourfile.jpg

Sao chép tệp vào thư mục đó, sau đó dùng Batch Edit để đặt giá trị trường tệp.

Với CLI, một đường dẫn tương tự có thể là:

/opt/apidog/runner/yourfile.jpg

Apidog có giới hạn kích thước hoặc loại tệp không?

Việc tạo request trong Apidog tập trung vào cách gửi multipart và đọc tệp từ máy cục bộ. Giới hạn kích thước và loại tệp thực tế do API của bạn quyết định.

Hãy kiểm tra validation ở phía máy chủ và thêm assertion cho các trường hợp:

Tệp vượt kích thước cho phép.
MIME type không hợp lệ.
Phần mở rộng không được hỗ trợ.
Tệp bị từ chối.

Nên dùng form-data hay x-www-form-urlencoded để tải tệp?

Dùng form-data.

Nó ánh xạ tới multipart/form-data và được thiết kế để mang tệp. x-www-form-urlencoded chỉ phù hợp cho các form đơn giản gồm trường văn bản ngắn.

Tóm tắt

Kiểm thử tải tệp có hai phần chính:

Xây dựng multipart request đúng cách.
Đảm bảo tệp tồn tại ở bất kỳ môi trường nào chạy bài kiểm thử.

Trong Apidog, quy trình cơ bản là:

Chọn Body là form-data.
Đặt kiểu trường thành file.
Chọn tệp bằng Upload.
Gửi JSON bổ sung dưới dạng trường string nếu cần.
Gửi request và thêm assertions.
Khi chạy bằng Runner hoặc CLI, chuẩn bị tệp trên máy đích.
Dùng Batch Edit hoặc biến để đặt đường dẫn theo từng môi trường.

Muốn thử với endpoint của bạn? Tải Apidog, tạo request form-data, trỏ đến endpoint tải tệp và kiểm tra phản hồi.

DEV Community: Sebastian Petrus

Cách sử dụng Kimi K3 để lập trình với Kimi Code

TL;DR: Chạy Kimi K3 để lập trình

Kimi Code là gì?

Chạy Kimi K3 trong Kimi Code

1. Cài đặt tác nhân và xác thực

2. Khởi chạy trong thư mục gốc của dự án

3. Chọn Kimi K3

4. Chọn mức nỗ lực suy luận phù hợp

Quy trình lập trình tác nhân thực tế

Giao nhiệm vụ có thể kiểm thử

Cho phép tác nhân dùng công cụ và đọc phản hồi

Lặp lại dựa trên ảnh chụp màn hình và đầu ra thời gian chạy

Giữ vòng lặp đáng tin cậy bằng kiểm thử

Kimi K3 so với Claude Code và Cursor

Điểm mạnh và hạn chế thực tế

K3 giỏi về điều gì?

Những hạn chế của K3

Các trường hợp sử dụng thực tế

Refactor lớn trong monorepo

Gỡ lỗi kéo dài

Xây dựng API có kiểm chứng

Xác minh API mà K3 xây dựng

Bạn sẽ nhận được gì?

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

Làm cách nào để sử dụng Kimi K3 để lập trình?

Kimi K3 có tốt cho lập trình tác nhân không?

Kimi K3 có hỗ trợ gọi công cụ cho quy trình tác nhân không?

Tôi có thể kiểm thử API mà Kimi K3 viết không?

Kimi K3 vs GPT-5.6 Sol: AI Nguồn Mở Thách Thức Đỉnh Cao Công Nghệ

TL;DR: cách chọn nhanh

Gặp gỡ hai mô hình

Kimi K3

GPT-5.6 Sol

So sánh nhanh

Chất lượng suy luận và coding

Tính mở và tự lưu trữ

Ngữ cảnh dài và phân tích tài liệu

Giá cả và kiểm soát chi phí

Hệ sinh thái, công cụ và tốc độ

Ma trận quyết định

Các trường hợp sử dụng thực tế

Trợ lý tài liệu nội bộ trong fintech

Copilot lập trình cho startup

Thử nghiệm Kimi K3 và GPT-5.6 Sol trong Apidog

Kết luận

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

Kimi K3 có tốt hơn GPT-5.6 Sol không?

Có benchmark trực tiếp giữa K3 và Sol không?

Tôi có thể tự lưu trữ Kimi K3 không?

Kimi K3 có giá bao nhiêu?

Điểm chuẩn Kimi K3: Số liệu Moonshot so với Kiểm tra độc lập

TL;DR: Kimi K3 thực sự được đánh giá như thế nào

Ba tuyên bố, được tách bạch

Tuyên bố 1: điểm neo độc lập từ Artificial Analysis

Tuyên bố 2: những gì Moonshot công bố

Tuyên bố 3: giới hạn mà Moonshot thừa nhận

Số liệu độc lập và số liệu nhà cung cấp

Những gì vẫn còn thiếu

Cách đọc benchmark của nhà cung cấp

Thử nghiệm thực tế: đánh giá K3 cho tác vụ của bạn

Chọn chỉ số theo dạng tác vụ

Vị trí thực sự của K3

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

Cách sử dụng Kimi K3 miễn phí

TL;DR

“Miễn phí” thực sự nghĩa là gì?

Phương pháp 1: Dùng ứng dụng Kimi hoặc Kimi.com

Cách bắt đầu

Bạn nhận được gì?

Cách tránh hết hạn mức quá nhanh

Phương pháp 2: Gọi moonshotai/kimi-k3 qua OpenRouter

Request tối thiểu với cURL

Ví dụ JavaScript

Cách kiểm tra khả năng dùng miễn phí

Phương pháp 3: Tự lưu trữ sau khi phát hành trọng số

Cần theo dõi ở đâu?

Thực tế phần cứng

Phương pháp 4: Tín dụng dùng thử hoặc khuyến mãi API Kimi

Cách kiểm tra tín dụng hiện có

Phương pháp 2: Gọi `moonshotai/kimi-k3` qua OpenRouter

Bắt đầu nhanh: lệnh gọi `kimi-k3` đầu tiên

Kiểm tra và gỡ lỗi `kimi-k3` trong Apidog

Kiểm thử `kimi-k3` trước khi triển khai