llm-d 1.0 ra mắt tại PyTorch Conference với bộ công nghệ suy luận sẵn sàng cho môi trường thực tế

Các bên đóng góp cho dự án llm-d công bố llm-d 1.0 vào ngày 20 tháng 10 năm 2026, tại PyTorch Conference North America. Thông tin này được nêu trong thông báo của IBM Research. IBM cho biết phiên bản này đưa llm-d vượt ra khỏi giai đoạn trình diễn các kỹ thuật tối ưu hiệu năng riêng lẻ, đồng thời hướng đến việc giúp các tổ chức tự triển khai mô hình khi chi phí suy luận ngày càng tăng.

llm-d được xây dựng để triển khai các bộ công nghệ suy luận cho mọi mô hình, trên mọi bộ tăng tốc và trên mọi nền tảng đám mây. Red Hat, IBM và Google là những đơn vị duy trì chính của dự án, đồng thời cùng CoreWeave và NVIDIA sáng lập llm-d; AMD, Cisco, Hugging Face, Intel, Lambda và Mistral AI đã tham gia với vai trò bên đóng góp. Cloud Native Computing Foundation (CNCF) lưu trữ llm-d dưới dạng một dự án sandbox. IBM mô tả thành quả này là một lựa chọn thay thế không phụ thuộc nhà cung cấp, dành cho các tổ chức muốn có hiệu năng suy luận thuộc hàng đầu như IBM gọi, mà không phải phụ thuộc hoàn toàn vào một nhà cung cấp mô hình độc quyền, nền tảng đám mây hay nền tảng phần cứng duy nhất.

Carlos Costa, Kỹ sư Xuất sắc tại IBM Research, đồng sáng lập kiêm trưởng nhóm duy trì llm-d, cho biết phiên bản 1.0 giúp llm-d đủ độ trưởng thành để vận hành như mọi dịch vụ trọng yếu khác. Ông nêu bật API ổn định, khả năng để nhiều bên thuê có những ưu tiên cạnh tranh cùng sử dụng một hạ tầng và việc nâng cấp không làm gián đoạn hoạt động.

Phiên bản 1.0 bổ sung những gì

Ghi chú phát hành v1.0.0 của dự án, được đăng trên GitHub vào ngày 20 tháng 10 năm 2026 cùng các thẻ phiên bản đã ký và xác minh, mở đầu bằng chất lượng dịch vụ đa bên thuê: điều tiết luồng có xét đến mức độ ưu tiên và tính công bằng, kèm cơ chế chủ động giảm tải có kiểm soát, bao gồm bộ chấp nhận xác suất, cơ chế công bằng nhận biết chương trình và chấm điểm ưu tiên theo lượt. Nhờ đó, các yêu cầu nhạy cảm với độ trễ và khối lượng công việc của tác nhân có lưu lượng đột biến có thể dùng chung một cụm máy mà không khiến bên nào bị bỏ đói khi hệ thống quá tải. Cấu hình điều tiết luồng được tập trung trong một trường flowControl duy nhất.

Để vận hành không gián đoạn, bộ định tuyến được bổ sung tính sẵn sàng cao với chế độ dự phòng nóng và khả năng cập nhật cuốn chiếu an toàn; bộ điều khiển DisaggregatedSet quản lý các bản sao tiền xử lý và giải mã như một đơn vị logic duy nhất, với các đợt triển khai được phối hợp, nâng cấp đồng bộ, chỉ đánh dấu sẵn sàng sau khi Pod snapshot đáp ứng điều kiện và định tuyến theo phiên bản tích hợp sẵn. API cấu hình bộ định tuyến được nâng lên v1, Responses API hỗ trợ previous_response_id, còn đường xử lý yêu cầu của bộ chọn điểm cuối được gia cố về độ tin cậy, hiệu năng và khả năng mở rộng. Tài liệu hướng dẫn về bộ tăng tốc có xét đến cấu trúc liên kết cho DRA và DRANET cũng được bổ sung.

Khả năng phục vụ có nhận biết tác nhân bổ sung một tiện ích mở rộng tạo trạng thái phiên và cơ chế gắn kết phiên linh hoạt để duy trì các cuộc hội thoại nhiều lượt gần với ngữ cảnh đã lưu trong bộ nhớ đệm; tính năng này kết hợp lập lịch ưu tiên theo lượt và trạng thái của Responses API nhằm giúp tác nhân tái sử dụng ngữ cảnh giữa các lượt. Bản phát hành đồng bộ các thành phần của dự án ở phiên bản v1.0.0, bổ sung các thành phần trong hệ sinh thái, bao gồm tích hợp với ai-dynamo/modelexpress để tải trọng số mô hình ngang hàng, gói llm-d-api-extensions và bộ công cụ chẩn đoán llm-d-pd-utils, đồng thời ngừng hỗ trợ các bản dựng ảnh container llm-d-rocm do chính dự án phát triển. Các ảnh máy chủ mô hình bao gồm bản dựng vLLM và SGLang cho nhiều mục tiêu bộ tăng tốc; tài liệu hướng dẫn tách biệt tiền xử lý và giải mã hiện yêu cầu LeaderWorkerSet v0.11.1 trở lên, đồng thời phải bật API DisaggregatedSet.

Các kỹ thuật cốt lõi và điều tiết luồng

Kể từ khi ra mắt, dự án tập trung vào năm phương pháp cải thiện suy luận: định tuyến có nhận biết bộ nhớ đệm tiền tố, chuyển yêu cầu đến hạ tầng có thể đã lưu ngữ cảnh dùng chung; chuyển dữ liệu khỏi bộ nhớ đệm KV, di chuyển thông tin đã lưu giữa tài nguyên GPU, CPU và bộ nhớ lưu trữ; tối ưu hóa suy luận theo lô; tách biệt tiền xử lý và giải mã, tức tách việc đọc lời nhắc khỏi việc tạo câu trả lời; và song song hóa chuyên gia trên diện rộng, phân phối các mô hình hỗn hợp chuyên gia lớn trên nhiều bộ tăng tốc. Những kỹ thuật này đã có trước phiên bản 1.0; theo IBM, điểm mới là sự tích hợp và mức độ trưởng thành trong vận hành được xây dựng xung quanh chúng, cùng kỷ luật vận hành ngày thứ hai nhằm duy trì hiệu năng khi lưu lượng thay đổi, phần cứng gặp sự cố, phần mềm được cập nhật hoặc những người dùng khác nhau cạnh tranh cùng một nguồn lực.

Trong phiên bản 1.0, điều tiết luồng, tính công bằng và cơ chế ưu tiên nhằm ngăn khối lượng công việc có lưu lượng đột biến áp đảo các dịch vụ nhạy cảm với độ trễ, dù chúng dùng chung phần cứng hay chạy trên nhiều loại bộ tăng tốc khác nhau. Các yêu cầu cũng có thể tiếp tục được ghim vào hạ tầng phù hợp qua nhiều lượt để duy trì trạng thái ấm của bộ nhớ đệm tiền tố. llm-d hoạt động cùng các công cụ suy luận như vLLM hoặc SGLang, bổ sung khả năng định tuyến phân tán và vận hành trên nền tảng của chúng. Stephen Watt, phó chủ tịch thuộc văn phòng giám đốc công nghệ của Red Hat, cho biết llm-d hợp nhất các hệ sinh thái PyTorch và CNCF bằng cách đưa khả năng điều phối dựa trên Kubernetes trực tiếp đến vLLM và các công cụ suy luận hiện đại.

Kết quả được trình diễn và chi phí được công bố

Trong một bài đăng về kết quả kiểm chuẩn được công bố ngày 22 tháng 7 năm 2026, dự án đã đo lường khả năng phục vụ tác vụ theo hướng tác nhân của GLM-5.2, được mô tả trong bài là mô hình hỗn hợp chuyên gia có 744 tỷ tham số, gồm 39 tỷ tham số hoạt động và 78 lớp. Phân tích khối lượng công việc dựa trên 219 phiên Claude Code trong môi trường sản xuất; ở mức trung vị, mỗi yêu cầu gửi đến tác nhân chính mang theo 195 nghìn token đầu vào và trả về 317 token đầu ra, còn 96% lượt tương tác của tác nhân chính sử dụng lại ít nhất 90% lượng đầu vào. Bài đăng cho biết định tuyến nhận biết tiền tố đã tận dụng được 96–97% lượng tái sử dụng bộ nhớ đệm mà khối lượng công việc cho phép. Với mức giá thuê giả định là 2,71 USD mỗi giờ-GPU cho H200, bài đăng ước tính chi phí tự vận hành dịch vụ trên hai cấu hình gồm 64 GPU là 0,05–0,08 USD cho mỗi triệu token đầu vào và 1,92–3,55 USD cho mỗi triệu token đầu ra. Theo các tác giả, những con số này chỉ tính chi phí thuê GPU và giả định tải được duy trì liên tục.

Trong một buổi trình diễn riêng, IBM và Red Hat đã triển khai GLM-5.2 trên 544 GPU NVIDIA H100. Theo mô tả trong bài viết của IBM Research, đây là mô hình trọng số mở có khoảng 753 tỷ tham số, trong đó khoảng 39 tỷ tham số hoạt động. IBM cho biết ở mức đỉnh, hệ thống triển khai đạt hơn 6,6 triệu token đầu ra mỗi phút khi phục vụ đồng thời tối đa 3.000 tác nhân lập trình mà không có lần nào bị gián đoạn trước hạn; ở mức vận hành với 2.500 tác nhân, hệ thống duy trì được 7.612 yêu cầu mỗi phút. IBM cho biết, với mức giá thuê đám mây hiện nay, tự vận hành GLM-5.2 trên GPU H100 bằng llm-d có chi phí trên mỗi token thấp hơn từ 5 đến 10 lần so với mức giá API thương mại tương đương. Maroon Ayoub, kỹ sư học máy chính cấp cao thuộc nhóm kỹ thuật suy luận của Red Hat, cho biết: “Phục vụ hàng nghìn tác nhân đồng thời mà không bị gián đoạn trước hạn giúp các đơn vị vận hành có lộ trình đáng tin cậy để chuyển từ kết quả kiểm chuẩn sang triển khai trong môi trường sản xuất.”

Theo cùng bài viết, bên dưới những kết quả đó, mặt phẳng dữ liệu phân tách đã hoàn tất 6,2 triệu lượt truyền bộ nhớ đệm KV, với dung lượng trung bình 2,71 GiB mỗi lượt và không xảy ra lỗi truyền tải nào; tất cả các bài kiểm chuẩn cũng hoàn tất mà không có lỗi phục vụ.