Kimi K3 trên AWS: blueprint tự lưu trữ tác nhân AI

Tổng quan

Nếu bạn chạy các tác nhân AI trên một API được lưu trữ, ba vấn đề sẽ dần dần phức tạp: chi phí token không thể đoán trước, sự khóa nhà cung cấp và lời nhắc rời khỏi VPC của bạn. Các nhóm đang xem xét Kimi K3 trên AWS phải đối mặt với một quyết định cụ thể: liệu khả năng kiểm soát dữ liệu và độ ổn định của phiên bản mô hình có phù hợp với chi phí và gánh nặng MLOps khi cung cấp mô hình tác nhân 2,8 nghìn tỷ tham số trên 8 GPU B300 hay không. Hướng dẫn này là sổ tay đưa ra quyết định dành cho người sáng lập, RevOps và nhóm nền tảng: hướng dẫn này giải thích kế hoạch triển khai HyperPod và EKS mới của AWS, sự cân bằng giữa quản lý và tự làm và cách so sánh việc tự lưu trữ với API theo chi phí trên mỗi kết quả được chấp nhận, sử dụng cách tiếp cận của Van Data Team đối với các hoạt động của tác nhân được quản lý và có thể quan sát được.

AWS đã gửi bản thiết kế sản xuất để triển khai Kimi K3 trên AWS thông qua SageMaker HyperPod hoặc Amazon EKS. Nó làm cho việc tự lưu trữ của một mô hình trọng lượng mở biên giới trở nên khả thi, chuyển câu hỏi khó từ khả năng kỹ thuật sang kinh tế vận hành, quản trị và kết quả tác nhân đáng tin cậy.

Đối với người sáng lập, nhà tiếp thị và lãnh đạo RevOps, sự thay đổi đó rất quan trọng vì các tác nhân tự trị chạm vào dữ liệu nhạy cảm và quy trình làm việc tiếp theo. Vanaxity là tác nhân nội dung AI của Van Data Team cho SEO, GEO và AEO. Nó nghiên cứu, viết, minh họa, xuất bản và cung cấp nội dung trên Google, AI Overviews và công cụ trả lời. Hướng dẫn này áp dụng lăng kính vận hành đó vào bản thiết kế của AWS: ngăn xếp làm gì, đường dẫn nào phù hợp và cách đánh giá mức độ sẵn sàng sản xuất.

Khung tác nhân của bạn hầu như không thay đổi quyết định này. Cho dù tác nhân của bạn chạy trên LangGraph, LangChain, CrewAI hay gọi hàm gốc bằng công cụ MCP, tất cả đều phụ thuộc vào cùng một điểm cuối suy luận. Nguyên tắc vận hành có những thay đổi gì: đặt ngân sách token cho mỗi quy trình làm việc của tác nhân, sau đó theo dõi chi phí, độ trễ, khả năng quan sát và đánh giá trên mọi mô hình hoặc thay đổi kịp thời.

Những điểm chính

• AWS ghi lại đường dẫn sản xuất thông qua SageMaker HyperPod và Amazon EKS đơn giản.
• Kimi K3 là mô hình 2,8 nghìn tỷ tham số với khoảng 104 tỷ tham số hoạt động trên mỗi token và cửa sổ ngữ cảnh 1M token.
• vLLM là công cụ phục vụ. MXFP4 là định dạng lượng tử hóa.
• HyperPod bổ sung các hoạt động cụm GPU được quản lý; EKS đơn giản để lại nhiều nền tảng hơn cho nhóm của bạn.
• Việc tự lưu trữ chỉ thắng khi khả năng kiểm soát, nhu cầu duy trì và chi phí cho mỗi kết quả được chấp nhận phù hợp với năng lực chuyên dụng.

AWS đã vận chuyển những gì cho Kimi K3 trên AWS

Hướng dẫn của AWS cung cấp cho các nhóm một lộ trình sản xuất được ghi lại từ trọng số mở đến điểm cuối suy luận sẵn sàng cho tác nhân. Theo Blog học máy của AWS, hướng dẫn này ra mắt vào ngày 30 tháng 7 năm 2026 và bao gồm hai lộ trình triển khai: SageMaker HyperPod và Amazon EKS.

AWS khuyến nghị một phiên bản ml.p6-b300.48xlarge với 8 GPU NVIDIA B300 Blackwell Ultra. Các kết nối băng thông cao hỗ trợ suy luận song song tensor trên toàn bộ nhóm chuyên gia. AWS cũng khuyến nghị sử dụng vLLM vì nó hỗ trợ phân phối Mixture-of-Experts, song song tensor và định dạng trọng số MXFP4 của Kimi K3.

AWS nêu rõ sự thay đổi trong hướng dẫn triển khai chính thức:

"Các mô hình trọng lượng mở đã trở nên đủ mạnh để xử lý các tác vụ phức tạp như quy trình làm việc tác nhân nhiều bước, lý luận nâng cao và mã hóa đường dài."

Moonshot AI phát hành phiên bản mở rộng vào ngày 27 tháng 7 năm 2026. Bản phát hành này là hệ thống trọng lượng mở đầu tiên trong lớp khoảng ba nghìn tỷ tham số. Thiết kế MoE của nó chỉ kích hoạt một phần của nhóm tham số đầy đủ cho mỗi token. Sự khác biệt đó rất quan trọng: tổng kích thước mô hình mô tả công suất, trong khi các tham số hoạt động giải thích rõ hơn công việc suy luận.

Thực tế được báo cáo: AWS cung cấp mẫu cơ sở hạ tầng, lựa chọn phân phát và lộ trình triển khai. Phân tích Vanaxity: bản thiết kế chuyển cuộc tranh luận từ "Chúng ta có thể tổ chức nó không?" đến "Chúng ta có nên sở hữu gánh nặng vận hành này không?"

Để xem nghiên cứu, cổng đánh giá, xuất bản và phân phối phù hợp như thế nào với một hệ thống tự trị, xem quy trình làm việc của nhân viên đang hoạt động.

Cách thức hoạt động thực sự của ngăn xếp phân phối

Hình minh họa sau đây tóm tắt từ trọng số mxfp4 đến điểm cuối của tác nhân:

Hình 1. Trên hai đường dẫn triển khai của AWS, MXFP4 xác định định dạng trọng số, vLLM phục vụ mô hình và tính song song tensor trải rộng trên tám GPU B300.

Ngăn xếp chỉ hoạt động khi mỗi lớp có công việc rõ ràng và chủ sở hữu rõ ràng. Kimi K3 cung cấp trọng số mở, kiến ​​trúc MoE, bối cảnh dài và tầm nhìn nguyên gốc. MXFP4 là định dạng lượng tử hóa nhỏ gọn được sử dụng để phân phối các trọng số đó. Tổng quan về kỹ thuật được xuất bản trên Ôm mặt giải thích mối quan hệ giữa kiến ​​trúc, định dạng và mô hình tự lưu trữ.

vLLM là công cụ phục vụ. Nó tải trọng số, lên lịch yêu cầu, quản lý suy luận và hiển thị API mà ứng dụng tác nhân có thể gọi. Tính song song của tensor trải rộng tính toán mô hình trên các GPU được đề xuất để vẫn có sẵn nhóm chuyên gia đầy đủ.

Giữ vai trò rõ ràng: vLLM là động cơ. MXFP4 là định dạng.

Khung tác nhân nằm phía trên điểm cuối đó. Họ quản lý lời nhắc, công cụ, bộ nhớ, trạng thái quy trình làm việc, số lần thử và báo cáo của con người. Chúng không thay thế việc phân phối mô hình và việc phân phối mô hình không thay thế việc điều phối.

Lớp dữ liệu cũng vẫn tách biệt. Tác nhân phụ thuộc vào nguồn cấp dữ liệu, chỉ mục, bản ghi CRM, dữ liệu sản phẩm, quyền và API doanh nghiệp. Một mô hình mạnh mẽ được phục vụ một cách hoàn hảo vẫn có thể tạo ra kết quả tồi tệ từ những thông tin đầu vào cũ kỹ, không đầy đủ hoặc không thể theo dõi được.

SageMaker HyperPod so với Amazon EKS

SageMaker HyperPod là lớp cụm GPU được quản lý, trong khi Amazon EKS đơn giản mang lại cho các nhóm có kinh nghiệm quyền kiểm soát vận hành trực tiếp hơn. Chúng không phải là công nghệ loại trừ lẫn nhau. Blog tin tức AWS xác nhận rằng HyperPod hỗ trợ điều phối EKS cùng với Slurm, với CLI tùy chỉnh, khả năng quan sát và quản lý cụm linh hoạt.

Đề xuất của chúng tôi rất đơn giản. Chọn HyperPod khi mô hình mang tính chiến lược nhưng việc phối hợp GPU không phải là điểm khác biệt của bạn. Kiểm tra EKS đơn giản khi nhóm nền tảng của bạn đã chạy khối lượng công việc Kubernetes đòi hỏi khắt khe và muốn kiểm soát sâu hơn.

Đừng chọn EKS vì nó trông quen thuộc trên một slide kiến ​​trúc. Cân của Kimi K3 đảm bảo công suất, tải mô hình, khắc phục lỗi và phục vụ phân phối tạo nên độ tin cậy của sản phẩm. Nhóm của bạn hẳn đã biết cách chẩn đoán tải mô hình bị đình trệ, hoạt động GPU không tốt, tăng trưởng hàng đợi và lỗi dịch vụ một phần.

AWS cũng tách riêng hoạt động mua sắm năng lực trong hướng dẫn của mình. HyperPod sử dụng Kế hoạch đào tạo linh hoạt, trong khi lộ trình EKS đơn giản sử dụng Khối công suất EC2. Điều đó có nghĩa là tính sẵn có, thời gian đặt trước và kế hoạch phục hồi thuộc về quyết định của nền tảng chứ không thuộc về nhiệm vụ mua hàng sau này.

Khi tính năng tự lưu trữ đánh bại API được lưu trữ

Tính năng tự lưu trữ đánh bại API được lưu trữ khi yêu cầu kiểm soát và nhu cầu ổn định vượt quá dung lượng GPU cố định và nhân công nền tảng. Nó không tự động rẻ hơn, riêng tư hơn hoặc dễ dàng hơn chỉ vì trọng lượng được mở.

Triển khai tự lưu trữ được định cấu hình chính xác có thể giữ lời nhắc, ngữ cảnh được truy xuất và lưu lượng truy cập mô hình bên trong ranh giới bảo mật VPC của bạn. Nhóm của bạn cũng kiểm soát phiên bản mô hình chính xác đằng sau các tác nhân của mình. Điều đó bảo vệ quy trình làm việc khỏi trường hợp nhà cung cấp thượng nguồn thay đổi mô hình hoặc lịch ngừng hoạt động mà không phù hợp với quy trình phát hành của bạn.

Lợi ích về quyền riêng tư vẫn phụ thuộc vào kiến ​​trúc. Nhật ký, dấu vết, giám sát việc xuất, tạo phẩm mô hình và quyền truy cập hỗ trợ có thể vượt qua ranh giới nếu chúng được định cấu hình bất cẩn. Coi các quy tắc mã hóa, đầu ra, lưu giữ và kiểm tra là yêu cầu triển khai.

Kiểm soát phiên bản cũng tạo ra trách nhiệm. Nhóm của bạn quyết định thời điểm cập nhật nhưng cũng sở hữu các bản vá bảo mật, cung cấp các phần phụ thuộc, kiểm tra khả năng tương thích và khôi phục. Trọng lượng mở loại bỏ một phụ thuộc; họ không loại bỏ quản lý phát hành.

Tính năng tự lưu trữ thay thế sự phụ thuộc trực tiếp vào nhà cung cấp mỗi token bằng cơ sở hạ tầng và chi phí vận hành mà bạn kiểm soát. Tuy nhiên, dung lượng Blackwell Ultra được đề xuất là một cam kết cố định nghiêm túc. GPU nhàn rỗi, mức sử dụng thấp, nhiệm vụ thất bại và nhân sự có thể xóa đi lợi thế rõ ràng về giá token.

API Kimi K3 được lưu trữ hoặc API biên giới khác thường là điểm khởi đầu tốt hơn cho lưu lượng truy cập không chắc chắn, bùng nổ hoặc khiêm tốn. Nó làm giảm công việc nền tảng và giúp so sánh mô hình nhanh hơn. Sự cân bằng của nó là xử lý dữ liệu bên ngoài, kiểm soát phát hành của nhà cung cấp, định giá sử dụng và giới hạn dịch vụ.

Chọn hoặc kiểm tra tính năng tự lưu trữ khi:

• Nơi lưu trữ dữ liệu hoặc chính sách nội bộ yêu cầu kiểm soát cơ sở hạ tầng mạnh mẽ hơn.
• Việc ghim phiên bản mô hình là trọng tâm của khả năng kiểm tra.
• Nhu cầu của tác nhân được duy trì đủ để duy trì năng suất chuyên dụng hiệu quả.
• Nhóm của bạn có thể sở hữu các đánh giá, bảo mật, ứng phó sự cố và hoạt động GPU.

Chọn hoặc kiểm tra API khi tốc độ, tính linh hoạt và chi phí vận hành thấp quan trọng hơn. Không công bố yêu cầu hòa vốn cho đến khi bạn có được mức giá theo khu vực, sản lượng thực tế và dữ liệu kết quả thực tế được chấp nhận.

MLOps dành cho tác nhân AI vượt xa điểm cuối

MLO sản xuất cho tác nhân AI phải quản lý toàn bộ quy trình làm việc chứ không chỉ máy chủ mô hình. Tình trạng điểm cuối là cần thiết nhưng điều đó không chứng minh rằng tác nhân đã hoàn thành công việc hữu ích một cách an toàn.

Quan sát độ trễ, lỗi, độ bão hòa, độ sâu hàng đợi, mức sử dụng GPU, số lần thử lại và dung lượng. Sau đó, kết nối các tín hiệu đó với dấu vết của tác nhân, lệnh gọi công cụ, báo cáo của con người và kết quả được chấp nhận. Tính năng tự động điều chỉnh quy mô sẽ đáp ứng các mẫu khối lượng công việc thực tế mà không che giấu tình trạng quá tải đằng sau các hàng đợi dài hơn.

Cổng mỗi thay đổi. Việc hoán đổi mô hình có thể thay đổi việc lựa chọn công cụ, hành vi lý luận, kết quả đầu ra có cấu trúc hoặc kiểu từ chối. Các thay đổi đối với vLLM, lời nhắc, công cụ, truy xuất hoặc dữ liệu nguồn có thể thực hiện tương tự. Ghim các phiên bản, chạy đánh giá tham khảo, phát hành theo giai đoạn, đặt ngưỡng hồi quy và duy trì đường dẫn khôi phục đã được thử nghiệm.

Áp dụng đặc quyền tối thiểu ở cả hai ranh giới: từ tác nhân đến điểm cuối suy luận, sau đó từ tác nhân đến từng công cụ và nguồn dữ liệu nội bộ. Phân biệt quyền đọc và ghi. Ghi lại các lệnh gọi công cụ mang tính hệ quả, bảo vệ thông tin xác thực và yêu cầu phê duyệt chính sách trong trường hợp một hành động có thể ảnh hưởng đến khách hàng, tiền bạc hoặc hồ sơ.

Kỹ thuật dữ liệu là một phần của độ tin cậy của tác nhân. Theo dõi độ mới của nguồn cấp dữ liệu và chỉ mục, nguồn gốc dữ liệu, thay đổi lược đồ, kiểm tra chất lượng và kỳ vọng ở cấp độ dịch vụ. Mô hình không thể sửa chữa nguồn cấp dữ liệu tài khoản mà nó chưa bao giờ nhận được hoặc xác định bản ghi cũ mà không có nguồn gốc.

Hãy xem xét một tác nhân RevOps minh họa. Nó đọc dữ liệu tài khoản, đề xuất hành động lưu giữ và cập nhật CRM. Một câu trả lời trôi chảy không phải là thành công. Kết quả chỉ được chấp nhận khi dữ liệu nguồn là hiện tại, đề xuất vượt qua chính sách, ghi thành công và tồn tại dấu vết kiểm tra.

Kiểm tra quy trình làm việc miễn phí của Van Data Team có thể biến logic đó thành phạm vi triển khai. Bạn sẽ nhận được bản đồ khối lượng công việc, đánh giá quyền, kế hoạch đánh giá, danh sách thiếu sót trên trang tổng quan và trình tự phân phối. Khám phá cách Van Data Team giúp đo lường hoạt động của tác nhân.

Đo lường chi phí trên mỗi kết quả được chấp nhận

Chi phí trên mỗi kết quả được chấp nhận là cách công bằng nhất để so sánh ngăn xếp tác nhân tự lưu trữ với ngăn xếp API. Tại Van Data Team, chúng tôi bắt đầu bằng việc xác định "được chấp nhận" nghĩa là gì trước khi so sánh các nhà cung cấp hoặc cơ sở hạ tầng.

Để triển khai tự lưu trữ, hãy sử dụng:

~~~text Chi phí tự lưu trữ trên mỗi kết quả được chấp nhận = (Dung lượng GPU + dịch vụ cụm + lưu trữ và mạng + khả năng quan sát + lao động nền tảng + chi phí thử lại và chạy không thành công + đánh giá của con người) / kết quả được chấp nhận ~~~

Đối với dịch vụ được lưu trữ, hãy sử dụng:

~~~text Chi phí API được lưu trữ trên mỗi kết quả được chấp nhận = (Việc sử dụng API + điều phối + dữ liệu và truy xuất + khả năng quan sát + chi phí thử lại và chạy không thành công + đánh giá của con người) / kết quả được chấp nhận ~~~

Một kết quả được chấp nhận là công việc kinh doanh đã hoàn thành vượt qua các cuộc kiểm tra về chất lượng, chính sách và tính toàn vẹn của dữ liệu. Đối với ví dụ RevOps, điều đó có thể có nghĩa là đề xuất hợp lệ dựa trên dữ liệu tài khoản hiện tại, theo sau là bản cập nhật CRM được ủy quyền.

Chạy cả hai đường dẫn với cùng một khối lượng công việc, khoảng thời gian, cổng chấp nhận và ranh giới chi phí. Bao gồm các bối cảnh dài, vòng lặp công cụ, số lần thử lại, lần chạy không thành công, dung lượng nhàn rỗi và sự báo cáo của con người. Đo lường độ trễ và gánh nặng xem xét bên cạnh chi phí vì kết quả rẻ hơn đến quá muộn có thể không có giá trị.

Phân đoạn kết quả theo loại quy trình làm việc. Tác nhân mã hóa có tầm nhìn dài, tác nhân đánh giá có tầm nhìn cao và quy trình làm việc RevOps ngắn có thể sử dụng năng lực rất khác nhau. Mức trung bình kết hợp có thể ẩn khối lượng công việc khiến việc tự lưu trữ trông rẻ hơn hoặc đắt hơn thực tế.

Trọng tâm kết quả này là lý do tại sao nhân viên hỗ trợ đánh bại danh sách kiểm tra. Tự động hóa có được vị trí của nó khi nó liên tục tạo ra các công việc được quản lý, chứ không phải khi nó chỉ tạo ra các token rẻ tiền.

Các dạng lỗi thường gặp trước khi đi vào hoạt động

Hầu hết các lỗi triển khai đều bắt đầu bằng lỗi danh mục hoặc thiếu điều khiển vận hành. Hãy khắc phục những lỗi này trước khi hiển thị điểm cuối cho các tác nhân sản xuất:

• Coi HyperPod là tên gọi khác của EKS. HyperPod có thể sử dụng tính năng điều phối EKS nhưng nó bổ sung thêm một lớp vận hành được quản lý.
• Gọi MXFP4 là công cụ phục vụ. vLLM phục vụ mô hình; MXFP4 mô tả định dạng trọng lượng.
• Giả sử nhóm tham số đầy đủ đang hoạt động cho mọi token. Suy luận MoE kích hoạt một phần nhỏ hơn.
• So sánh giá token trong khi bỏ qua dung lượng nhàn rỗi, số lần thử lại, lỗi, nhân công và đánh giá của con người.
• Hoán đổi mô hình, lời nhắc, công cụ hoặc nguồn dữ liệu mà không đánh giá hồi quy và khôi phục.
• Cấp cho các tác nhân quyền truy cập rộng rãi vì điểm cuối nằm trong một mạng đáng tin cậy.
• Giám sát thời gian hoạt động của máy chủ trong khi bỏ qua các lỗi công cụ, lỗi chính sách và chất lượng kết quả.
• Cung cấp trọng lượng mới cho dữ liệu kinh doanh cũ, chất lượng thấp hoặc không thể theo dõi được.
• Yêu cầu tiết kiệm mà không cần định giá AWS hiện tại, thanh toán API, tính sẵn có của công suất và điểm chuẩn khối lượng công việc.

Nhóm Van Data thực hiện hoạt động này như thế nào

Tại Van Data Team, chúng tôi coi Kimi K3 trên AWS là một quy trình vận hành chứ không phải một thử nghiệm cơ sở hạ tầng. Trước tiên, chúng tôi lập sơ đồ cách yêu cầu của tác nhân di chuyển từ dữ liệu nguồn thông qua việc điều phối, suy luận, gọi công cụ, đánh giá và hành động cuối cùng. Bản đồ đó xác định chủ sở hữu, điểm quyết định, trạng thái lỗi và đường dẫn khôi phục.

Đầu ra hữu ích là một kế hoạch phân phối có phạm vi:

• Các tín hiệu cần thu thập về độ trễ, dung lượng, mức sử dụng công cụ, độ mới của dữ liệu, lỗi và kết quả được chấp nhận
• Những khoảng trống trong quy trình làm việc cần thử lại, dự phòng, cấp quyền hoặc quyền sở hữu rõ ràng hơn
• Các hành động có tác động lớn cần có sự xem xét của con người trước khi thực hiện
• Cổng đánh giá và hồi quy cho các thay đổi về mô hình, lời nhắc, công cụ hoặc dữ liệu
• Trang tổng quan và sổ ghi chép cho người vận hành biết điều gì đã xảy ra và việc cần làm tiếp theo

Cách tiếp cận này kết nối lớp phục vụ với hoạt động kinh doanh. HyperPod hoặc EKS có thể giữ cho điểm cuối luôn sẵn sàng, nhưng chỉ tính sẵn có thì không làm cho một tác nhân trở nên đáng tin cậy. Các nhóm cũng cần quyền truy cập có đặc quyền tối thiểu, đầu vào có thể theo dõi, xem xét các điểm kiểm tra và đường dẫn đã được kiểm tra từ các hành động thất bại. Kết quả là một hệ thống sản xuất được đo lường bằng các kết quả được chấp nhận, không chỉ đơn thuần là phân phối token hay việc sử dụng GPU.

Ngân sách hoạt động

Trước khi triển khai sản xuất, hãy so sánh Kimi K3 trên AWS với API được lưu trữ của Kimi K3 và các API biên giới khác. Sử dụng các nhiệm vụ tiêu biểu tương tự và phiếu tự đánh giá chấp nhận. Giá token của nhà cung cấp chỉ là một đầu vào. Chúng loại trừ dung lượng GPU nhàn rỗi, các lần chạy không thành công, các lệnh gọi công cụ lặp lại, thời gian của người xem xét và công việc khôi phục.

Chi phí trên mỗi kết quả quy trình làm việc được phê duyệt = (tính toán + phân phát + lưu trữ và mạng + nhân công nền tảng + nhân công đánh giá + chi phí thử lại và khôi phục) `kết quả được phê duyệt.

Đối với mỗi ứng cử viên, hãy ghi lại chi phí đầu ra được chấp nhận, độ trễ trung bình và độ trễ cuối, mức sử dụng token, tốc độ thử lại, số phút đánh giá và nỗ lực khắc phục lỗi. Thêm kết quả đánh giá về chất lượng nhiệm vụ, sử dụng công cụ, nối đất, an toàn và hồi quy so với mô hình sản xuất hiện tại.

Chạy thẻ điểm trên các quy trình làm việc RevOps hoàn chỉnh chứ không phải các lời nhắc riêng lẻ. Phản hồi nhanh, ít tốn kém sẽ có ít giá trị nếu tác nhân cần thử lại nhiều lần hoặc cần có sự điều chỉnh của con người.

Nút Kimi K3 8 GPU được đề xuất có dung lượng chuyên dụng đắt tiền. Nó có nhiều khả năng mang lại lợi ích nhất khi có lưu lượng truy cập lớn, ổn định với mức độ sử dụng mạnh mẽ. API có thể vẫn rẻ hơn nếu nhu cầu không đồng đều. Tự lưu trữ giành được vị trí khi chi phí cho mỗi kết quả được chấp nhận, quản trị và kiểm soát mô hình thấp hơn gánh nặng MLOps tăng thêm.

Dụng cụ và cảnh quan phù hợp

Kimi K3 trên AWS phù hợp với các nhóm có nhu cầu tác nhân ổn định, kiểm soát dữ liệu nghiêm ngặt và đội ngũ nhân viên có khả năng vận hành các cụm GPU lớn. API được lưu trữ vẫn phù hợp hơn với lưu lượng truy cập lớn, phi công nhanh và các nhóm không muốn gặp rủi ro về năng lực.

Chọn SageMaker HyperPod khi khả năng phục hồi, tự động thay đổi quy mô, khả năng quan sát và công cụ cụm được quản lý lớn hơn nhu cầu kiểm soát cấp thấp. Chọn Amazon EKS đơn giản khi nhóm nền tảng có kinh nghiệm đã quản lý Kubernetes và muốn sở hữu trực tiếp việc lên lịch, kết nối mạng, bảo mật và nâng cấp.

Những lựa chọn cơ sở hạ tầng này không thay thế việc điều phối tác nhân. Các khung như LangGraph phối hợp trạng thái quy trình làm việc, lệnh gọi công cụ, số lần thử lại và đánh giá của con người. vLLM phục vụ mô hình, trong khi MXFP4 mô tả định dạng trọng số. Mỗi lớp giải quyết một vấn đề khác nhau.

Sự phù hợp trong sản xuất cũng phụ thuộc vào các biện pháp kiểm soát thời gian chạy. Hoán đổi mô hình cần bộ đánh giá và cổng hồi quy. Các tác nhân cần các lệnh gọi công cụ có thể theo dõi, quyền truy cập có đặc quyền tối thiểu và đường dẫn leo thang cho các hành động tiếp theo. Nguồn dữ liệu của họ cần nguồn cấp dữ liệu mới, chỉ mục đáng tin cậy, nguồn gốc dữ liệu, quyền và mục tiêu cấp độ dịch vụ rõ ràng. Nếu không có những nền tảng đó, mô hình biên giới có thể thực hiện sai quy trình làm việc nhanh hơn.

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

Nguồn tham khảo