Xây dựng với CometAPICần một API cho nhiều mô hình?Kiểm thử quy trình trong Playground, sau đó tạo API key khi mô hình và chi phí phù hợp với trường hợp sử dụng của bạn.
Cách triển khai Kimi K3.1 Pro cục bộ: Yêu cầu phần cứng, thiết lập vLLM
Tìm hiểu cách tự triển khai Kimi K3.1 Pro với vLLM, kiểm tra yêu cầu GPU, tải xuống trọng số, kiểm thử suy luận và so sánh triển khai cục bộ với truy cập API.
Triển khai Kimi K3.1 Pro trên máy chủ GPU Linux, sau đó kết nối ứng dụng cục bộ với endpoint suy luận của nó. Hướng dẫn này sử dụng một nút NVIDIA B300 tám GPU với vLLM. Bạn sẽ cần quyền truy cập shell vào máy chủ, driver tương thích và bộ nhớ lưu trữ cho toàn bộ checkpoint. Bắt đầu bằng cách hoàn thành một yêu cầu văn bản ngắn trước khi thử các đầu vào dài hơn hoặc quy trình tác tử.
Nếu không có GPU phù hợp, bạn có thể chạy ứng dụng cục bộ và kết nối nó với Kimi API chính thức hoặc nhà cung cấp bên thứ ba như CometAPI.
Điểm chính
104B tham số hoạt động của mô hình không đại diện cho yêu cầu lưu trữ đầy đủ của nó.
Tương thích phần cứng bao gồm bộ nhớ GPU, liên kết liên GPU, hỗ trợ lượng tử hóa và kernel suy luận.
Đã được xem xét về độ rõ ràng, ghi nguồn và thuật ngữ API hiện tại.
Kết quả benchmark mạnh đáng để thử nghiệm, nhưng không đảm bảo hiệu năng tương đương trong ứng dụng của bạn.
Một endpoint suy luận hoạt động không tự động bao gồm trình duyệt, sandbox mã hoặc runtime tác tử đầy đủ.
So sánh tự lưu trữ và truy cập API theo chi phí trên mỗi tác vụ thành công, bao gồm thử lại và bảo trì.
Kimi K3.1 Pro là gì?
Kimi K3.1 Pro là mô hình đa phương thức open-weight của Moonshot AI dành cho lập trình, phân tích tài liệu và sử dụng công cụ. Các thông số kỹ thuật chính của nó được liệt kê bên dưới, dựa trên model card chính thức.
Thông số
Cấu hình đã công bố
Kiến trúc
MoE; 2.8T tổng tham số, 104B hoạt động
Attention
93 lớp: 69 KDA + 24 Gated DSA
Experts
896 được định tuyến; 16 chọn mỗi token; 2 dùng chung
Ngữ cảnh
1,048,576 token
Đầu vào
Văn bản và hình ảnh; bộ mã hóa thị giác MoonViT-V2
Lượng tử hóa
Trọng số MXFP4 / kích hoạt MXFP8; checkpoint độ chính xác hỗn hợp
Engine khuyến nghị
vLLM, SGLang, TokenSpeed
Mô hình kích hoạt 104B tham số mỗi token, nhưng triển khai vẫn yêu cầu toàn bộ checkpoint 2.8T tham số. Engine suy luận cũng phải hỗ trợ các lớp KDA và Gated DSA của nó cùng lượng tử hóa MXFP4.
Cần phần cứng gì để chạy Kimi K3.1 Pro cục bộ?
Bảng dưới đây tóm tắt các cấu hình vLLM liên quan đến hướng dẫn này. Hướng dẫn sử dụng một nút B300 tám GPU; triển khai GB300 và AMD yêu cầu cấu hình tương ứng của chúng.
Phần cứng
Lộ trình được ghi nhận
Ghi chú lập kế hoạch
NVIDIA B300
Một nút tám GPU, TP8
Cơ sở cho hướng dẫn bên dưới
NVIDIA GB300
Tám GPU trên hai khay, TP8
Yêu cầu cấu hình multi-node và thiết lập liên kết
AMD MI355X
Nút tám GPU với cấu hình đặc thù AMD
Sử dụng đường ROCm/AITER; không tái sử dụng môi trường NVIDIA
GPU tiêu dùng 24–32 GB đơn
Không đủ cho tải trực tiếp full-checkpoint
Không phải mục tiêu thực tế cho hướng dẫn này
Về quy mô, 2.8T tham số sẽ chiếm xấp xỉ 5.6 TB ở BF16, 2.8 TB ở tám bit hoặc 1.4 TB ở bốn bit lý tưởng. Đây là tính toán lưu trữ tham số thô, không phải kích thước checkpoint thực tế hoặc mức tối thiểu VRAM khi chạy. Độ chính xác hỗn hợp và metadata thay đổi kích cỡ tệp; cache và cấp phát runtime làm tăng yêu cầu phục vụ.
Dành dung lượng NVMe cho toàn bộ bản tải xuống, tệp tạm và một bản sao rollback. Trên hệ thống multi-node, xác thực liên lạc trước khi tải mô hình.
Cách triển khai Kimi K3.1 Pro
Hãy tự lưu trữ nếu bạn có phần cứng phù hợp; nếu không, hãy bắt đầu với API được lưu trữ. Các bước dưới đây sử dụng vLLM, với SGLang là một lựa chọn ở cuối mục này. So sánh chi phí lưu trữ sau khi bạn có một yêu cầu hoạt động.
Chạy các lệnh thiết lập, tải xuống, khởi chạy và xác minh ban đầu trong Bash shell trên máy chủ GPU. Nếu làm việc từ laptop, trước tiên kết nối tới máy chủ đó bằng SSH. Client Python có thể chạy trên bất kỳ máy nào sau này bằng các hướng dẫn kết nối bên dưới.
Hướng dẫn này theo công thức triển khai chính thức; nó chưa được kiểm thử độc lập cho bài viết này.
1. Kiểm tra khả năng nhìn thấy GPU, lưu trữ và kết nối
Bắt đầu với các kiểm tra hạ tầng cơ bản:
nvidia-smi
nvidia-smi topo -m
df -h
Xác nhận rằng tất cả GPU mục tiêu đều nhìn thấy được và thư mục mô hình có đủ dung lượng. Dành thêm không gian cho cache tải xuống, log và các phiên bản checkpoint trong tương lai.
Đối với triển khai multi-node, xác minh liên lạc giữa các nút trước khi thử khởi động mô hình.
Giữ mốc đầu tiên hẹp: tải checkpoint và hoàn thành một yêu cầu văn bản ngắn. Điều này giúp việc chẩn đoán lỗi dễ dàng hơn.
2. Chuẩn bị môi trường phục vụ
Sử dụng máy chủ Linux với tám GPU B300 cho ví dụ single-node này. Trong môi trường CUDA tương thích với công thức đã công bố, tạo môi trường cô lập và cài đặt công cụ phục vụ:
Ngưỡng phiên bản không đảm bảo tương thích với mọi driver hoặc wheel. Nếu công thức phần cứng yêu cầu container hoặc bản build chuyên dụng, hãy sử dụng môi trường đó. Cố định phiên bản đã kiểm thử thành công trước khi đưa vào sản xuất.
Giữ các tệp cấu hình, tokenizer, processor và weight index cùng với các shard trọng số. Chỉ sao chép một số tệp tensor có thể khiến triển khai không đầy đủ.
Đối với triển khai sản xuất có thể tái lập, ghi lại và cố định revision của kho mà bạn đã xác thực. Xem lại giấy phép tùy chỉnh của kho trước khi sử dụng thương mại.
4. Khởi chạy vLLM server
Công thức chính thức chỉ định vLLM 0.34.0 hoặc mới hơn. Bắt đầu với cấu hình môi trường đặc thù phần cứng, sau đó cố định phiên bản và phụ thuộc vượt qua bài kiểm thử của bạn.
Sau khi chuẩn bị môi trường, dùng lệnh cơ bản sau. Nó khởi động song song tensor tám chiều và giới hạn cửa sổ ngữ cảnh ban đầu ở 32.768 token:
Tên kimi-local là bí danh hướng tới ứng dụng. Dùng cùng tên này trong các yêu cầu tiếp theo.
Thiết lập 32.768 token là điểm bắt đầu thận trọng cho hướng dẫn này, không phải ngữ cảnh tối đa mà mô hình hỗ trợ.
Tùy chọn --trust-remote-code cho phép tải mã tùy chỉnh của kho. Ghép nó với một checkpoint revision đã được xem xét và cố định.
Ở đây, 127.0.0.1 đề cập tới máy chạy client. Các kiểm tra curl bên dưới chạy trên máy chủ GPU, nơi chúng tới tiến trình suy luận của nó. Để dùng client Python từ laptop của bạn, mở một SSH tunnel trong một terminal laptop riêng và giữ nó chạy:
ssh -N -L 8000:127.0.0.1:8000 user@gpu-server
Thay user@gpu-server bằng thông tin đăng nhập SSH và địa chỉ máy chủ của bạn. Với tunnel này mở, client trên laptop có thể dùng http://127.0.0.1:8000/v1. Nếu cổng 8000 đã bận trên laptop, chọn cổng cục bộ khác và cập nhật URL client.
finish_reason cho biết việc sinh đã hoàn tất hay chạm giới hạn.
Lỗi bộ nhớ GPU hoặc thao tác không được hỗ trợ.
Phần suy luận có thể tiêu tốn một phần ngân sách sinh. Nếu yêu cầu chạm giới hạn trước khi tạo câu trả lời cuối cùng, hãy tăng ngân sách và thử lại trước khi kết luận server hỏng.
6. Kết nối ứng dụng Python cục bộ
python -m pip install openai
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:8000/v1",
api_key="EMPTY",
timeout=300.0,
max_retries=1,
)
response = client.chat.completions.create(
model="kimi-local",
messages=[{"role": "user", "content": "Write a Python function that removes duplicate filenames while preserving order."}],
reasoning_effort="low",
max_tokens=2048,
)
print(response.choices[0].message.content)
print(response.choices[0].finish_reason)
EMPTY là placeholder cho server loopback-only này không có xác thực API-key. Hãy dùng thông tin xác thực đã cấu hình của bạn cho endpoint yêu cầu xác thực. Xác thực đầu vào hình ảnh và thực thi công cụ riêng trước khi kết nối một tác tử.
Lựa chọn SGLang
Với SGLang, hãy sử dụng cookbook đặc thù phần cứng chính thức. Chọn B300, Unified và Low-Latency (TP8) để gần nhất với hướng dẫn single-node này. Kiểm tra trạng thái xác minh hiển thị; một cấu hình được tạo ra không nhất thiết là cấu hình đã được kiểm thử.
Trên máy chủ GPU, cài Docker và cấu hình NVIDIA Container Toolkit, sau đó tạo container với checkpoint đã tải gắn tại /models/Kimi-K3.1-Pro. Dừng vLLM trước để tránh cả hai engine tranh chấp cùng GPU.
Bên trong container, dán lệnh khởi chạy đầy đủ do cookbook tạo cho cấu hình bạn chọn. Thay đường dẫn mô hình bằng /models/Kimi-K3.1-Pro, đặt host dịch vụ là 0.0.0.0 và port là 30000, đồng thời giữ các cờ đặc thù phần cứng. Container phải lắng nghe trên giao diện mạng của nó để docker port forwarding hoạt động; cổng phía host ở trên vẫn gắn vào loopback. Chờ thông báo service-ready trước khi thử nghiệm.
Trong shell thứ hai trên máy chủ GPU, liệt kê mô hình đang phục vụ, sau đó gửi một yêu cầu bằng đúng model ID trả về:
curl http://127.0.0.1:30000/v1/models
MODEL_ID="replace-with-id-from-models-response"
curl http://127.0.0.1:30000/v1/chat/completions \
-H "Content-Type: application/json" \
-d "{\"model\":\"$MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"Explain database indexes in three sentences.\"}],\"reasoning_effort\":\"low\",\"max_tokens\":2048}"
Phản hồi thành công phải chứa một câu trả lời cuối cùng. Nếu khởi động thất bại, kiểm tra log container và xác nhận công thức phần cứng đã chọn và image phù hợp. Đối với truy cập từ laptop, dùng cùng mẫu SSH tunnel với cổng 30000. Xem hướng dẫn cài đặt Docker của SGLang cho các điều kiện tiên quyết của container.
Kimi K3.1 Pro hoạt động thế nào trên các benchmark?
Sử dụng kết quả đánh giá chính thức bên dưới để chọn tác vụ cho thử nghiệm triển khai của bạn. Các điểm số này mô tả thiết lập đánh giá đã công bố; chúng không đo server cục bộ được cấu hình trong hướng dẫn này.
Bảng sau cho thấy một số kết quả được chọn và vị trí của chúng trong tập so sánh được công bố trong model card.
Benchmark và kết quả chính thức
Điểm mô hình
Vị trí trong tập so sánh đó
Terminal-Bench 4.0
65.7
Thứ hai
SWE Marathon v1.1
51.7
Thứ nhất
Program Bench
31.5
Thứ tư
OfficeQA Pro v2
64.4
Đứng đầu trong các kết quả đã báo cáo
Frontier Finance
58.6
Thứ hai
Các kết quả này ủng hộ việc thử nghiệm mô hình cho các tác vụ kỹ thuật kéo dài và quy trình tài liệu. Kimi K3.1 Pro dẫn đầu so sánh này ở SWE Marathon nhưng xếp thứ tư ở ProgramBench, khiến cả hai trở thành ứng viên hữu ích cho thử nghiệm theo ứng dụng cụ thể.
Các vị trí này được tính trong bảng so sánh chính thức, không phải bảng xếp hạng toàn cầu thời gian thực. Bộ công cụ đánh giá, công cụ, ngân sách suy luận và lựa chọn mẫu khác nhau giữa các benchmark.
Để quyết định triển khai, hãy xây dựng một tập đánh giá nhỏ từ công việc thực tế: sửa kho, câu hỏi xuyên tài liệu và tác vụ công cụ nhiều bước. Đo chất lượng hoàn thành, chỉnh sửa của con người và thời gian trôi qua. Điểm số đã công bố hữu ích cho việc lọc danh sách; thử nghiệm ứng dụng xác định liệu triển khai có đáng giá hay không.
Bạn có thể tối ưu suy luận cục bộ Kimi K3.1 Pro như thế nào?
Kiểm soát độ dài ngữ cảnh và mức độ đồng thời
Khi các yêu cầu ngắn hoạt động, hãy thử tài liệu dài hơn, hình ảnh, hội thoại nhiều lượt và gọi công cụ riêng biệt.
Theo dõi độ trễ token đầu tiên, số token đầu ra mỗi giây và đỉnh bộ nhớ GPU ở độ dài ngữ cảnh và mức đồng thời dự định. Cũng ghi nhận tỉ lệ thành công tác vụ và chi phí trên mỗi tác vụ thành công, để tốc độ đầu ra nhanh hơn không che giấu nhiều lần thử lại hoặc chỉnh sửa của con người.
Thay đổi một biến lớn tại một thời điểm. Tăng đồng thời độ dài ngữ cảnh, mức đồng thời và thiết lập tối ưu hóa cùng lúc khiến việc giải thích hồi quy hiệu năng trở nên khó khăn.
Lựa chọn mức độ suy luận và thiết lập cache có chủ đích
Sử dụng mức suy luận thấp, cao hoặc tối đa tùy theo tác vụ. Bắt đầu với thấp cho kiểm tra giao diện, sau đó so sánh cao và tối đa trên các tác vụ khó, sử dụng cả chất lượng hoàn thành và thời gian trôi qua. Dấu vết suy luận dài hơn không tự thân là bằng chứng của kết quả tốt hơn.
Đối với phiên dài, đánh giá dung lượng cache và tái sử dụng tiền tố trước khi thêm giải mã suy đoán hoặc tăng đồng thời. Giữ một đường cơ sở đã biết hoạt động và thay đổi một thiết lập tại một thời điểm.
Vì sao gọi công cụ của Kimi K3.1 Pro có thể thất bại sau triển khai?
Ứng dụng của bạn thực thi các lệnh gọi công cụ, trả về kết quả của chúng và tiếp tục hội thoại. Bảo toàn toàn bộ tin nhắn assistant — bao gồm reasoning_content và tool_calls — và trả về mỗi kết quả công cụ với tool_call_id khớp.
Xử lý nhiều lượt cũng quan trọng. Hướng dẫn sử dụng của mô hình yêu cầu bảo toàn toàn bộ tin nhắn assistant, bao gồm các trường suy luận và gọi công cụ, thay vì chỉ giữ lại văn bản cuối cùng.
Triệu chứng
Kiểm tra đầu tiên
Không nhận diện kiến trúc mô hình
Phiên bản runtime, mã tùy chỉnh và cấu hình
Hết bộ nhớ khi tải
Dung lượng GPU, song song và tiến trình cạnh tranh
Yêu cầu ngắn hoạt động nhưng dài thất bại
Giới hạn ngữ cảnh, dung lượng cache và đồng thời
Không thể parse lệnh gọi công cụ
Thiết lập parser và schema công cụ
Tác tử dừng sau khi yêu cầu một công cụ
Thực thi ứng dụng và xử lý kết quả công cụ
Trả lời nhiều lượt trở nên không nhất quán
Thiếu các trường của tin nhắn assistant
Sử dụng một yêu cầu có thể tái tạo tối thiểu để cô lập mỗi lỗi. Khi nó hoạt động, đưa lại dần các thiết lập bổ sung của ứng dụng từng cái một.
Nên tự lưu trữ hay dùng API được lưu trữ?
Chọn tự lưu trữ khi bạn cần kiểm soát trọng số, hạ tầng hoặc vị trí dữ liệu và có thể giữ GPU hoạt động hữu ích. Đối với đánh giá ban đầu hoặc nhu cầu biến động, so sánh Kimi API chính thức và CometAPI bằng cùng prompt và tiêu chí chấp nhận. Xác nhận quyền truy cập mô hình, tham số được hỗ trợ, hạn ngạch và điều khoản xử lý dữ liệu của mỗi dịch vụ.
Yếu tố chi phí hoặc vận hành
Tự lưu trữ
Kimi API chính thức / CometAPI
Chi phí công suất
Mua hoặc thuê GPU, bao gồm thời gian rảnh
Tính phí sử dụng API; kiểm tra mức giá hiện tại
Lưu trữ và mạng
Lưu trữ checkpoint, cache và phí mạng
Bất kỳ lưu trữ và phí mạng phía ứng dụng
Vận hành
Triển khai, giám sát, nâng cấp và khôi phục
Tích hợp, quản lý hạn ngạch và giám sát yêu cầu
Thử lại
Tính thời gian GPU của chúng vào chi phí tính toán
Tính token hoặc cuộc gọi của chúng vào phí API
Rà soát của con người
Tính thời gian chỉnh sửa với cùng mức
Tính thời gian chỉnh sửa với cùng mức
Phù hợp nhất
Nhu cầu ổn định và kiểm soát hạ tầng
Đánh giá và nhu cầu biến động
Một so sánh hữu ích là:
Chi phí trên mỗi tác vụ thành công = (chi phí tính toán GPU hoặc API + lưu trữ và mạng + vận hành + chỉnh sửa của con người) / số tác vụ hoàn thành thành công.
Sử dụng chi phí và số lượng tác vụ thành công từ cùng một khoảng đo lường. Bao gồm các lần thất bại và thử lại trong tổng tính toán hoặc API một lần; không cộng thêm phí thử lại lần thứ hai. Đối với quy trình lai, bao gồm cả chi phí tính toán và API. Đếm các tác vụ hoàn thành duy nhất, không phải số lần yêu cầu.
Một máy chủ ít được dùng có thể vẫn tốn kém ngay cả khi thông lượng lý thuyết của nó tuyệt vời. Ngược lại, một đội có hạ tầng hiện có, nhu cầu ổn định và yêu cầu dữ liệu nghiêm ngặt có thể thu được giá trị đáng kể từ tự lưu trữ.
Sử dụng cùng prompt và tiêu chí chấp nhận khi so sánh các lộ trình triển khai. Bao gồm độ trễ end-to-end và chất lượng đầu ra trong quyết định.
Thử endpoint được lưu trữ mà không tải trọng số
Kimi API quickstart chính thức sử dụng endpoint bên dưới. Đặt MOONSHOT_API_KEY trong môi trường của bạn và xác nhận quyền truy cập mô hình trong tài khoản. Yêu cầu này chạy trên hạ tầng của nhà cung cấp.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3.1-pro",
messages=[{"role": "user", "content": "Explain database indexes in three sentences."}],
reasoning_effort="low",
max_completion_tokens=2048,
)
print(response.choices[0].message.content)
Đối với Kimi K3.1 Pro API trong CometAPI, đặt COMETAPI_API_KEY trong môi trường của bạn và xác nhận rằng tài khoản có quyền truy cập mô hình yêu cầu. Yêu cầu chạy từ xa:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_API_KEY"],
base_url="https://api.cometapi.com/v1",
)
response = client.chat.completions.create(
model="kimi-k3.1-pro",
messages=[{"role": "user", "content": "Explain database indexes in three sentences."}],
max_tokens=2048,
)
print(response.choices[0].message.content)
So sánh kết quả với endpoint cục bộ của bạn bằng cùng tiêu chí chấp nhận. Kiểm tra mức giá hiện tại của lộ trình và tham số được hỗ trợ trước khi ước tính chi phí sản xuất.
Kết luận
Tự lưu trữ Kimi K3.1 Pro là khả thi với cấu hình GPU được hỗ trợ và môi trường suy luận phù hợp. Sử dụng các bước triển khai ở trên để thiết lập một endpoint hoạt động, sau đó đo chất lượng tác vụ, độ trễ và chi phí trên khối lượng công việc của riêng bạn. Chọn API được lưu trữ nếu bạn vẫn đang xác thực ứng dụng hoặc không có phần cứng phù hợp.
Câu hỏi thường gặp (FAQ)
Một laptop thông thường có chạy đầy đủ mô hình không?
Laptop thông thường không phải mục tiêu thực tế cho yêu cầu dung lượng của checkpoint gốc. Nó có thể đóng vai trò là client kết nối đến server suy luận của bạn hoặc API được lưu trữ.
Cài đặt ứng dụng desktop có tính là triển khai cục bộ không?
Vị trí cài đặt ứng dụng không xác định nơi suy luận diễn ra. Tự lưu trữ yêu cầu trọng số mô hình và tiến trình suy luận chạy trong hạ tầng bạn kiểm soát.
Tại sao mô hình cần nhiều bộ nhớ nếu chỉ 104B tham số hoạt động?
Các token khác nhau có thể chọn các expert khác nhau. Tham số hoạt động mô tả sự tham gia vào tính toán; triển khai vẫn cần lưu trữ và truy cập toàn bộ tập trọng số.
Tôi có thể bật ngay ngữ cảnh một triệu token không?
Tăng dần độ dài ngữ cảnh và đo sử dụng bộ nhớ GPU ở mức đồng thời mục tiêu của bạn. Mô hình hỗ trợ 1,048,576 token, nhưng dung lượng phục vụ sử dụng được phụ thuộc vào cache và thiết lập song song.
Triển khai cục bộ có tái tạo điểm benchmark đã công bố không?
Không tự động. Lượng tử hóa, ngân sách suy luận, công cụ, prompt và khung đánh giá đều có thể ảnh hưởng kết quả. Xác thực cấu hình theo tác vụ của riêng bạn.
Tôi có nên thử qua API trước khi mua phần cứng không?
Nếu bạn chưa xác định mô hình đáp ứng yêu cầu chất lượng, thử nghiệm qua API cung cấp đường cơ sở ban đầu với ít công việc hạ tầng hơn. Các nhóm có phần cứng phù hợp và yêu cầu cư trú dữ liệu rõ ràng có thể tiến hành đánh giá tự lưu trữ có kiểm soát.
Cách triển khai Kimi K3.1 Pro cục bộ: Yêu cầu phần cứng, thiết lập vLLM - CometAPI