Infer-forge: Hệ thống kỹ thuật tối ưu hóa suy luận dựa trên SGLang

1. Giới thiệu

Tối ưu hóa suy luận (inference optimization) có vẻ mang tính cục bộ trong mã nguồn, nhưng tính hiệu quả của nó lại mang tính toàn cục. Một thay đổi về kernel, đường truyền thông tin hoặc lập lịch chỉ trở nên có ý nghĩa tại một điểm triển khai cụ thể được xác định bởi mô hình, khối lượng công việc (workload), SLO, cấu trúc liên kết phục vụ (serving topology), phiên bản runtime và nền tảng tăng tốc (accelerator platform). Cùng một bản vá có thể cải thiện điểm này nhưng lại gây thoái hóa điểm khác. Việc khám phá có sự hỗ trợ của Agent có thể tạo ra nhiều môi trường, thử nghiệm, phép đo và các hướng đi bị từ chối hơn, tất cả đều phải đảm bảo tính tái lập.

Do đó, yêu cầu đầu tiên là thực thi đáng tin cậy. Việc tái lập một điểm triển khai đòi hỏi nhiều hơn là khả năng của mô hình: các công cụ, môi trường, ngữ cảnh, bộ nhớ, xác minh (Verification) và các ranh giới an toàn phải luôn ổn định. Harness Engineering biến những điều kiện xung quanh đó thành một hệ thống thực thi có thể tái lập và kiểm tra được—cơ sở cho sự trừu tượng hóa Agent = Model + Harness1,2,3,6.

Việc thực thi đáng tin cậy sau đó phải duy trì tính nhất quán theo thời gian. Các tác vụ (Task) kỹ thuật suy luận thường trải qua nhiều vòng lặp điều tra, triển khai, đánh giá (Evaluation), thất bại và phục hồi. Loop Engineering kết nối các lần thực thi kế tiếp để một tác vụ có thể bảo toàn Hợp đồng Tác vụ (Task Contract), kết hợp bằng chứng mới và đáp ứng Tiêu chí Thoát (Exit Criteria) bằng cách tạo ra một Sản phẩm bàn giao (Deliverable) đã được xác minh hoặc một quy trình Bàn giao tiếp theo (Follow-up Handoff) đáng tin cậy4,5,7.

Công việc ở quy mô dự án vượt ra ngoài ranh giới của một tác vụ đơn lẻ. Nhiều tác vụ phải tiến hành song song, trao đổi các sản phẩm bàn giao, chia sẻ trạng thái, kích hoạt làm lại (Rework) và thay đổi hướng đi khi bằng chứng tích lũy. Graph Engineering tổ chức các Vòng lặp Tác vụ (Task Loops) hội tụ độc lập thành một Đồ thị Tác vụ (Task Graph) đang phát triển. Đồ thị này giữ cho các hướng đi đã phát hành và bị từ chối được kết nối với các phụ thuộc, ràng buộc và bằng chứng của chúng, để các quyết định dự án luôn có thể giải trình được10,11,12,13.

Infer-forge áp dụng tiến trình này vào kỹ thuật suy luận xung quanh SGLang. Phạm vi của nó theo sát một thay đổi kỹ thuật thông qua ngăn xếp suy luận (inference stack): từ các kernel và thư viện truyền thông, qua tích hợp engine và triển khai, đến đánh giá và chẩn đoán trực tuyến. Một không gian làm việc chung và ba cấu trúc thực thi tích lũy giữ cho lộ trình từ đầu đến cuối đó luôn nhất quán:

1.1 Trạng thái triển khai và tính khả dụng

Infer-forge là một hệ thống kỹ thuật nội bộ được phát triển độc lập xung quanh SGLang; nó không phải là thành phần chính thức của SGLang hay LMSYS.

Infer-forge hiện không phải là mã nguồn mở vì các thành phần cốt lõi của nó gắn kết chặt chẽ với các kho lưu trữ, cơ sở hạ tầng, quy trình làm việc và các biện pháp kiểm soát an toàn nội bộ của chúng tôi. Do đó, cơ sở mã hiện tại sẽ có khả năng di động hạn chế bên ngoài môi trường của chúng tôi.

Thay vào đó, bài viết này công khai phương pháp xây dựng. Mục tiêu của chúng tôi là để các nhóm và cá nhân cung cấp nó cho một công cụ lập trình AI, thêm ngữ cảnh hệ thống của riêng họ và nhanh chóng xây dựng một bản triển khai infer-forge thích ứng với môi trường của họ.

Infer-forge đã chuyển từ thiết kế quy trình làm việc sang sử dụng kỹ thuật bền vững. Trong hồ sơ từ tháng 4 đến tháng 7 của một kỹ sư, số lượng tác vụ cao điểm đang thực hiện đã tăng từ 2 lên 9. Trong một dự án phục vụ DeepSeek-V4-Pro, 38 nút tác vụ có thể xác minh độc lập trên bảy loại tác vụ đã được điều phối thành một Đồ thị Tác vụ. Cùng với nhau, các hồ sơ này cho thấy infer-forge được sử dụng bền vững trong cả hồ sơ kỹ thuật kéo dài bốn tháng và Đồ thị Tác vụ quy mô dự án.

Một Agent có năng lực có thể làm cho một lần thực thi thành công; một hệ thống kỹ thuật được thiết kế để làm cho công việc thành công có thể tái lập. Infer-forge không hứa hẹn rằng mọi tác vụ sẽ hoàn thành nhanh hơn. Nó cung cấp cấu trúc để bảo toàn nguồn gốc của từng điểm triển khai, duy trì công việc có thể xác minh qua các tác vụ chạy dài và điều phối bằng chứng qua các ranh giới tác vụ.

2. Suy luận như một không gian triển khai

Hình 1: Chuỗi ràng buộc đằng sau một điểm triển khai suy luận.

Hình 1 biến điểm triển khai được giới thiệu ở trên thành một chuỗi ràng buộc cụ thể. Mô hình xác định các phương thức (modalities) được hỗ trợ và các đường dẫn thực thi cụ thể cho mô hình. Kịch bản phục vụ (Serving Scenario) chuyển đổi phương thức và hình thái lưu lượng (Traffic Shape) thành một SLO. SLO đó ràng buộc cấu trúc liên kết phục vụ, nơi kiến trúc triển khai được kết hợp với chiến lược song song hóa (Parallelism). Cấu trúc liên kết sau đó được hiện thực hóa thông qua Hồ sơ Runtime có phiên bản (Versioned Runtime Profile), ghim cấu hình engine và hình ảnh container cho một bản sửa đổi dịch vụ cụ thể. Cuối cùng, runtime hoàn chỉnh phải được xây dựng và xác minh trên một Nền tảng tăng tốc (Accelerator Platform). Một điểm triển khai là toàn bộ lộ trình thông qua chuỗi này—không phải bất kỳ lớp đơn lẻ nào.

Không có tối ưu hóa suy luận nào không phụ thuộc vào ngữ cảnh. Các mục tiêu phục vụ và SLO khác nhau có thể yêu cầu các lộ trình triển khai hoàn toàn khác nhau, bao gồm Colocated PD, PD Disaggregation và EPD Disaggregation. Mỗi kiến trúc thay đổi ranh giới giai đoạn, đường truyền thông tin, cân bằng tài nguyên và tập hợp các chiến lược song song hóa khả thi. Những quyết định đó lan truyền vào hồ sơ runtime và việc triển khai cụ thể cho bộ tăng tốc cần được xác minh. Một cải tiến kernel chỉ trở thành kết quả phục vụ khi điểm triển khai hoàn chỉnh tái lập được nó và vượt qua các cổng kiểm soát về thông lượng, độ trễ, tính chính xác và độ ổn định. Nếu không có điểm triển khai của nó, một tuyên bố về hiệu suất không thể được tái lập, so sánh hoặc tiếp tục phát triển.

Infer-forge không loại bỏ không gian tổ hợp này; nó làm cho mọi chuyển động qua không gian đó trở nên rõ ràng và có thể xác minh. Thay vì yêu cầu một Agent “tối ưu hóa DeepSeek-V4-Pro”, chúng tôi xác định một tác vụ ghi lại điểm triển khai hiện tại, giới hạn tập hợp con các chiều mà nó có thể thay đổi và cố định các cổng xác minh trước khi thực thi bắt đầu. Một tác vụ có thể thay thế backend MoE trong khi giữ nguyên kịch bản phục vụ, cấu trúc liên kết và bộ tăng tốc, sau đó tạo ra một cải tiến được chấp nhận hoặc một sự từ chối có tài liệu. Cả hai kết quả đều làm giảm sự không chắc chắn cho tác vụ tiếp theo. Tuy nhiên, trước khi bất kỳ tác vụ nào trong số đó có thể được tái lập, trạng thái mã chính xác trên các kho lưu trữ đằng sau điểm triển khai phải được cố định. Đó là vai trò của MonoRepo.

3. MonoRepo

3.1 Tại sao lại là MonoRepo

Tối ưu hóa suy luận vượt qua các ranh giới kho lưu trữ, nhưng nó phải được vận chuyển như một hệ thống nhất quán. Một thay đổi có thể bắt đầu trong một thư viện kernel, phụ thuộc vào một backend truyền thông, đi vào SGLang thông qua tích hợp engine và cuối cùng yêu cầu một cấu hình triển khai phù hợp. Khi các kho lưu trữ này nằm trong các không gian làm việc riêng biệt, mối quan hệ của chúng trở thành kiến thức tạm thời mà các kỹ sư và Agent phải liên tục tái tạo. Một nhánh bị thiếu hoặc bản sửa đổi không tương thích là đủ để làm mất hiệu lực kết quả.

Infer-forge biến bản đồ phụ thuộc đó thành một không gian làm việc chung. Git submodules đặt các kho lưu trữ liên quan dưới một gốc duy nhất trong khi vẫn bảo toàn lịch sử độc lập, chính sách nhánh, kiểm soát truy cập và quy trình phát hành của chúng. Gốc này cung cấp cho các kỹ sư và Agent một bản đồ ổn định về ngăn xếp suy luận và một điểm truy cập duy nhất để từ đó công việc liên kho lưu trữ có thể được phát triển và xác minh.

Cấu trúc này thay đổi công việc liên kho lưu trữ theo ba cách:

Không gian làm việc điều phối thay đổi; hồ sơ tác vụ làm cho nó bền vững. Mỗi tác vụ nắm bắt các nhánh, commit và trạng thái thực thi được sử dụng cho công việc, và Journal lưu trữ hồ sơ đó sau khi hoàn thành. Các kho lưu trữ có thể tiếp tục phát triển mà không xóa bỏ nguồn gốc của công việc đã được xác minh và bàn giao.

3.2 Bản đồ kho lưu trữ

Hình 2: Infer-forge MonoRepo.

Một không gian làm việc không có nghĩa là một cơ sở mã không phân biệt. Infer-forge tách biệt các kho lưu trữ theo vai trò của chúng trong kỹ thuật: Built-in Workspace điều phối công việc liên kho lưu trữ, Inference Stack Repos chứa hệ thống phục vụ đang được thay đổi và Harness Repos mang những thay đổi đó từ thực thi đến bằng chứng đã xác minh.

Built-in Workspace

Built-in Workspace là lớp điều phối của infer-forge, không phải là một kho lưu trữ triển khai khác. Mã vẫn nằm trong kho lưu trữ sở hữu nó. Gốc chỉ chứa các cơ chế cần hoạt động trên các ranh giới kho lưu trữ:

Inference Stack Repos

Inference Stack Repos là nơi hành vi phục vụ và hiệu suất thực sự thay đổi. SGLang là trung tâm của ngăn xếp, trong khi Dynamo tổ chức các instance SGLang thành một dịch vụ phân tán. DeepGEMM, FlashMLA, FlashInfer và Humming cung cấp các kernel tính toán chuyên dụng. DeepEP và Mooncake cung cấp truyền thông song song chuyên gia và chuyển đổi KV liên nút. Các kho lưu trữ này phát triển độc lập, nhưng một kết quả phục vụ có thể phụ thuộc vào các thay đổi trên nhiều kho lưu trữ cùng một lúc.

Harness Repos

Mã không trở thành kết quả kỹ thuật chỉ vì một Agent có thể chỉnh sửa nó. Harness Repos cung cấp các khả năng mang một thay đổi qua phần còn lại của vòng đời của nó: tìm kiếm tài nguyên tính toán, chuẩn bị môi trường, triển khai dịch vụ, chạy đánh giá hiệu suất và tính chính xác, chẩn đoán lỗi và hành vi trực tuyến, bảo tồn hồ sơ dài hạn và thực thi các ranh giới an toàn. Chúng biến các bước vận hành vốn bị ngắt kết nối thành một lộ trình có thể lặp lại từ thay đổi mã đến sản phẩm bàn giao đã xác minh.

Cùng với nhau, ba nhóm tạo thành một lộ trình kỹ thuật: Built-in Workspace chuẩn bị và điều phối công việc, Inference Stack Repos cung cấp hệ thống đang được thay đổi và Harness Repos mang thay đổi đó đến xác minh. Infer-forge đưa chúng vào một không gian làm việc mà không buộc chúng phải vào một lịch sử kho lưu trữ, mô hình sở hữu hoặc quy trình phát hành duy nhất.

4. Vòng lặp tác vụ (Task Loop)

MonoRepo cung cấp không gian làm việc; Vòng lặp tác vụ cấu trúc cách công việc tiến triển theo thời gian. Kỹ thuật suy luận thường đòi hỏi nhiều vòng nghiên cứu, triển khai, đánh giá và phục hồi. Vòng lặp tác vụ giữ cho các lần thực thi đó phù hợp với một mục tiêu và hợp đồng tác vụ cho đến khi chúng đáp ứng tiêu chí thoát thông qua một sản phẩm bàn giao đã xác minh hoặc một bàn giao tiếp theo đáng tin cậy.

“Mọi thứ đều có thể là một tác vụ” áp dụng cho các đơn vị công việc có thể xác minh độc lập, không phải cho mọi hành động. Một tác vụ cần mục tiêu, phạm vi, sự chấp nhận, lộ trình xác minh và tiêu chí thoát riêng. Các lệnh và thử nghiệm trung gian vẫn nằm trong đó dưới dạng các instance Loop Block hoặc lệnh gọi công cụ. Khi một đơn vị công việc có thể hoàn thành hoặc bàn giao độc lập, nó có thể trở thành một nút tác vụ trong một Đồ thị Tác vụ lớn hơn.

4.1 Tổng quan

Hình 3: Tổng quan về Vòng lặp tác vụ.

Một Vòng lặp tác vụ giữ cho ranh giới của nó ổn định trong khi cho phép lộ trình thực thi của nó thích ứng. Định nghĩa tác vụ thiết lập loại tác vụ, ngữ cảnh bắt đầu, hợp đồng tác vụ và tiêu chí thoát. Vòng lặp chính thúc đẩy công việc thông qua một chuỗi các instance Loop Block và sử dụng “Mục tiêu tác vụ đã đạt chưa?” để quyết định thoát hoặc tiếp tục. Bộ nhớ tác vụ bảo tồn trạng thái hiện tại, mục tiêu phụ tiếp theo, hồ sơ thực thi và bàn giao giữa các lần lặp.