Tự triển khai Kimi K3: Chi phí phần cứng tăng 20%, hiệu suất giải quyết tác vụ vọt 20%

Cập nhật (29 tháng 7 năm 2026): Chúng tôi đã chạy Kimi K3 trên cùng cấu hình, được phục vụ bằng SGLang. Với trọng số 1.4TB, K3 không nằm trong giới hạn bộ nhớ của node 8×B200 được sử dụng cho GLM-5.2 (tổng 1.5TB HBM không để lại khoảng trống cho KV cache). Do đó, lần chạy này đã sử dụng node 8×B300, cung cấp 288GB HBM mỗi GPU thay vì 192GB, tức là 2.3TB mỗi node. Con số này trung bình cao hơn khoảng 20% chi phí phần cứng so với cấu hình 8×B200, tùy thuộc vào nhà cung cấp dịch vụ cho thuê của bạn.

Trong các lần chạy của chúng tôi, K3 phục vụ 16 phiên đồng thời (GLM-5.2 quản lý được 24). Tổng thông lượng token thấp hơn khoảng 30% (122 so với 170 tok/s ở mức 16 người dùng), và thời gian thực hiện tác vụ trung vị lâu hơn khoảng 50% (38 so với 26 phút). Điều đó khiến K3 chậm hơn khoảng 8 lần so với tiêu chuẩn Claude Code của chúng tôi. Tuy nhiên, K3 bù đắp bằng chất lượng, giải quyết được 86.4% tác vụ, cao hơn 24 điểm phần trăm so với cả GLM-5.2 và Opus 4.8 (đều là 62.5%). Một lưu ý là các tác vụ benchmark từ SWEBench Pro của chúng tôi có thể đã nằm trong dữ liệu huấn luyện của K3, vì vậy hãy cân nhắc kỹ về tỷ lệ giải quyết này. Chỉ các biểu đồ trong bài viết này đã được cập nhật với dữ liệu K3 mới.

01

Tại sao hóa đơn token của bạn lại tăng vọt trong năm nay

Những dấu hiệu cảnh báo đã xuất hiện khắp nơi trong nửa đầu năm nay: GitHub Copilot chuyển sang tính phí dựa trên token [1], Uber đã tiêu hết ngân sách công cụ AI hàng năm chỉ trong bốn tháng [2][3], và các lập trình viên báo cáo chi phí dự kiến tăng từ 29 USD lên 750 USD mỗi tháng [4]. Chúng ta thậm chí đã tạo ra các từ ngữ cho hiện tượng này: "tokenmaxxing", "token panic", "token budgets".

Một nhân viên trung bình [5] hiện chi khoảng 140 USD mỗi năm cho việc sử dụng API AI. Nghe có vẻ vô hại, cho đến khi bạn nhìn vào nhóm cuối: nhóm 90% cao nhất chi gần 7.300 USD mỗi năm, và nhóm 99% cao nhất tiến gần đến mức 90.000 USD. Đối với nhiều tổ chức, việc áp dụng AI tác nhân (agentic AI) mới chỉ bắt đầu, vì vậy hãy kỳ vọng những con số này sẽ thay đổi trong năm tới.

Tại sao hóa đơn lại biến động mạnh như vậy? Bởi vì cách chúng ta sử dụng các tác nhân AI: Hiện tại, hơn 70% doanh thu định kỳ hàng năm (ARR) của các nhà cung cấp mô hình lớn [4] đến từ các trường hợp sử dụng lập trình. Bạn càng giao nhiều quy trình làm việc cho các tác nhân, hóa đơn token của bạn càng cao.

Nhiều tổ chức bắt đầu áp dụng tác nhân lập trình AI bằng cách sử dụng một trong các nhà cung cấp mô hình tiên phong lớn như OpenAI hoặc Anthropic thông qua quyền truy cập API. Sau vài tháng, ngày càng nhiều tổ chức ít nhất đang cân nhắc các giải pháp thay thế vì nhiều lý do: mô hình định giá token trở nên đắt đỏ hơn, người dùng đang nâng cấp lên các mô hình AI mới hơn và đắt tiền hơn, và việc áp dụng tác nhân trong tổ chức bắt đầu bùng nổ. Có những giải pháp thay thế hợp lý chắc chắn đáng để xem xét kỹ hơn: chuyển sang các bộ định tuyến API (API routers); sử dụng các tầng mô hình rẻ hơn cho công việc thường nhật trong khi chỉ chuyển 20% công việc khó cho mô hình tiên phong, và các phương án khác.

Tuy nhiên, nếu mức tiêu thụ token của bạn trở nên đáng kể hoặc nếu bạn đang làm việc với dữ liệu nhạy cảm, bạn có thể muốn từ bỏ hoàn toàn phương pháp API và tự thiết lập hệ thống suy luận (inference stack) của riêng mình. Khi quyền sở hữu phần cứng được đặt lên bàn cân, bạn sẽ cần hiểu việc thuê hoặc sở hữu GPU thực sự mang lại cho bạn những gì. Khi nào thì việc chuyển đổi đó trở nên hợp lý? Hãy đọc tiếp khi chúng tôi cung cấp cho bạn các công cụ để tự đưa ra quyết định.

02

Bạn trả tiền cho cả bể bơi 24/7, trong khi nhóm của bạn chỉ sử dụng 8 tiếng một ngày

Vậy là bạn đã quyết định tìm hiểu xem liệu việc mua hoặc thuê GPU riêng có hợp lý hay không. Sau khi được cấu hình đúng cách, nó sẽ cung cấp cho bạn một điểm cuối (endpoint) API mà bạn có thể cắm vào các công cụ lập trình của mình, giống như cách Anthropic, OpenAI hoặc các nhà cung cấp mô hình khác cung cấp.

Trái ngược với các API tiên phong, điểm cuối của riêng bạn có giới hạn về số lượng token đầu ra mỗi giây, nhưng bạn chỉ chạm tới giới hạn đó khi hệ thống được tải đầy đủ. Một lập trình viên làm việc đơn lẻ sẽ để lãng phí phần lớn giới hạn đó, nhưng cùng một phần cứng đó phục vụ bốn mươi tám phiên tác nhân song song lại là một câu chuyện khác. Giới hạn của bạn được quyết định bởi mô hình, (các) GPU và cấu hình phục vụ.

020k40k60k124816243264tổng token / sngười dùng đồng thời →

Tổng token/giây so với người dùng đồng thời

Ví dụ minh họa về mô hình A chạy trên cấu hình phần cứng B.

Không giống như mô hình sử dụng API nơi bạn bị tính phí trên mỗi token tiêu thụ, việc tự vận hành hệ thống có nghĩa là bạn trả tiền cho cơ sở hạ tầng nền tảng và chi phí để duy trì nó hoạt động. Trong hầu hết các trường hợp, điều đó có nghĩa là bạn vẫn phải trả tiền ngay cả khi bạn không tạo ra token nào. Việc đánh đổi đó có hiệu quả với bạn hay không được quyết định bởi hai câu hỏi. Câu hỏi đầu tiên là bạn đang sử dụng bao nhiêu phần của bể bơi đó. Hãy giải quyết câu hỏi đó trước.

Bạn định cỡ cho mức đỉnh và trả tiền cho nó 24/7. Hiệu suất sử dụng, chứ không phải số lượng nhân sự, mới là yếu tố quyết định sự thành bại của bài toán chi phí.

Nhu cầu thực tế không ổn định mà thường tăng đột biến. Đối với nhiều tổ chức, token cho các tác vụ lập trình sẽ gần bằng không vào ban đêm, tăng dần vào buổi sáng, giảm rõ rệt vào giờ ăn trưa và đạt đỉnh trở lại vào giữa buổi chiều. Điều này có nghĩa là bạn mua phần cứng cho tải đỉnh, nhưng bạn trả tiền cho nó 24/7 (trừ khi bạn thuê 'GPU spot instances', nhưng những loại này khó dựa vào hơn trong trường hợp này). Hình dạng đỉnh sử dụng của bạn cũng quan trọng như khối lượng: một nhóm làm việc trong cùng một múi giờ sẽ tập trung nhu cầu token vào các đỉnh hẹp hơn so với cùng số lượng nhân sự trải dài trên nhiều múi giờ: cùng số lượng token, mức sử dụng đỉnh cao hơn, nhưng kéo dài hơn. Dữ liệu công bố về khối lượng công việc suy luận doanh nghiệp phục vụ các công cụ lập trình nội bộ báo cáo mức sử dụng GPU trung bình là 15–22% [6][7], mặc dù ngay cả một triển khai được vận hành tốt hiện nay cũng hiếm khi vượt quá 25–35% (và đó là con số đã rất lạc quan). Biểu đồ dưới đây cho thấy mức sử dụng token thực tế trong 2 ngày cách đây vài tuần từ những người bạn của chúng tôi tại TechWolf [14], phản ánh chính xác những gì chúng tôi mô tả ở trên.

claude_codecowork0200 TRIỆU400 TRIỆU600 TRIỆU800 TRIỆU1 TỶ16200004081216200004081206/2506/2606/27chi tiêu tokenthời gian

Mức sử dụng token thực tế thường tăng đột biến và khác biệt đối với mỗi tổ chức

Một xu hướng mới nổi có thể có lợi cho bạn ở đây: Khi các tổ chức trưởng thành trong các quy trình làm việc dựa trên tác nhân, ngày càng có nhiều phiên bắt đầu đến từ các tác nhân tự động thay vì con người (các công việc được lên lịch, các tác nhân tự động xử lý báo cáo lỗi lúc 3 giờ sáng, v.v.). Điều này cho phép thực hiện công việc không tuân theo giờ hành chính. Nếu được lên lịch có chủ đích, các phiên tự động này có thể tận dụng công suất vào ban đêm mà dù sao bạn vẫn đang phải trả tiền.

Bây giờ hãy giải quyết câu hỏi thứ hai, bao nhiêu lập trình viên có thể chia sẻ bể bơi trước khi nó trở nên chậm chạp?

03

Điều gì xảy ra khi 48 lập trình viên chia sẻ một chiếc máy?

Một bể bơi token chỉ có một lập trình viên sử dụng sẽ mang lại cảm giác tuyệt vời - các token truyền đến nhanh hơn mức bạn có thể đọc. Câu hỏi là điều gì sẽ xảy ra ở mức năm, mười hoặc hai mươi phiên lập trình viên đồng thời, bởi vì các tác nhân lập trình AI là những khách hàng tham lam, bùng nổ, không chỉ tiêu thụ token mà còn duyệt web, thực thi tệp hoặc biên dịch mã.

Một trong những mối quan tâm chính của bạn khi rời bỏ API của nhà cung cấp mô hình tiên phong nên là trải nghiệm của lập trình viên. Khi xem kết quả benchmark, bạn sẽ thường thấy số token mỗi giây được sử dụng để đánh giá mức độ hiệu quả của một mô hình trên một cấu hình GPU nhất định. Mặc dù đây là một chỉ số dễ hiểu, chúng tôi thấy nó ít hữu ích hơn trong bối cảnh này. Xét cho cùng, bạn có thể đốt hàng ngàn token mà không có kết quả thỏa đáng, hoặc bạn có thể chuyển sang một mô hình nhỏ hơn nhưng cuối cùng lại sử dụng nhiều token hơn gấp 10 lần.

Đơn vị giá trị tốt hơn là một tác vụ được hoàn thành thành công, và mặc dù điều đó khó định lượng hơn về mặt tổng quát, đó là điều chúng tôi sẽ thường xuyên quay lại trong phần phân tích dưới đây. Bạn sẽ muốn hiểu một tác vụ mất bao lâu để hoàn thành từ đầu đến cuối và các token truyền nhanh như thế nào trong khi tác nhân đang chờ mô hình phản hồi.

Đơn vị giá trị tốt hơn là một tác vụ được hoàn thành thành công.

Để làm cho việc hoàn thành tác vụ có thể đo lường được, chúng tôi sử dụng một tập hợp con các tác vụ từ SWEBench Pro của ScaleLabs, một bộ các tác vụ kỹ thuật mã nguồn có tầm nhìn dài hạn phổ biến. Mặc dù nó thường được sử dụng để so sánh các mô hình riêng lẻ với nhau, nhóm của chúng tôi đang sử dụng nó cụ thể để tạo ra khối lượng công việc thực tế và đủ thách thức khi chúng tôi so sánh chi phí và hiệu suất của các kết hợp mô hình và phần cứng khác nhau trong các trường hợp sử dụng thực tế có ý nghĩa đối với tổ chức của bạn.

Một vài biểu đồ sẽ giúp chúng tôi đánh giá thêm hiệu suất của các kết hợp mô hình & phần cứng mà chúng tôi đã chọn. Đầu tiên, chúng tôi chạy tập hợp con các tác vụ lập trình của mình bằng cách sử dụng một mô hình nhất định trên một cấu hình phần cứng cụ thể ở các mức độ đồng thời người dùng tăng dần và đánh giá xem điều này ảnh hưởng như thế nào đến thời gian hoàn thành các tác vụ riêng lẻ. Điều này sẽ giúp tìm ra điểm ngọt về số lượng người dùng đồng thời bạn có thể có cho cấu hình đã chọn trước khi các tác vụ bắt đầu mất quá nhiều thời gian để hoàn thành.

01020301248163248phút mỗi tác vụngười dùng đồng thời →

Phút mỗi tác vụ so với người dùng đồng thời

Ví dụ minh họa về mô hình A thực hiện các tác vụ lập trình trên cấu hình phần cứng B.

Thật thuận tiện khi xem thông tin này cùng nhau. Sự đánh đổi giữa mức độ sử dụng phần cứng so với trải nghiệm lập trình viên về mặt tốc độ thường được hiển thị trong một biểu đồ cho phép ra quyết định thuận tiện. Chúng tôi sẽ sử dụng biểu đồ dưới đây để cho thấy các kết hợp mô hình/phần cứng khác nhau tiếp cận mức đầu ra token tối đa mà chúng có thể tạo ra như thế nào khi số lượng người dùng đồng thời tăng lên, đồng thời theo dõi thời gian chúng ta có thể để các lập trình viên chờ đợi một tác vụ được giải quyết.

02040600102030C=1C=2C=4C=8C=16C=32C=64C=128token / sthời gian tác vụ trung vị →

Token/giây so với thời gian tác vụ trung vị

Ví dụ minh họa về mô hình A thực hiện các tác vụ lập trình trên cấu hình phần cứng B. C nghĩa là số lượng người dùng đồng thời.

Hiểu được các giá trị này sẽ giúp bạn hiểu rõ hơn về sự khác biệt trong hiệu suất và trải nghiệm lập trình viên giữa các tùy chọn có thể phù hợp với nhu cầu của tổ chức bạn.