Cơ sở hạ tầng hỗ trợ các tác nhân LLM cục bộ thực sự hữu ích

Trí tuệ nhân tạo Cơ sở hạ tầng hỗ trợ các tác nhân LLM cục bộ thực sự hữu ích Những bài học từ việc xây dựng một tác nhân khoa học nhanh, đáng tin cậy với các mô hình mã nguồn mở cục bộ, vLLM và cơ sở hạ tầng ngữ cảnh dài Hussen Mohammed Ibrahim Ngày 28/5/2026 22 phút đọc Chia sẻ Một vòng lặp của tác nhân. Tiền tố cố định lặp lại trong mỗi lần gọi và lịch sử hội thoại tăng lên theo mỗi lần lặp. Chạy một mô hình ngôn ngữ cục bộ nghe có vẻ đơn giản. Tải xuống các trọng số, khởi động máy chủ và gửi yêu cầu. Điều đó hiệu quả với một chatbot, nhưng không tự động hiệu quả với một tác nhân. Trong trường hợp của tôi, tôi đã xây dựng một tác nhân để phân tích RNA-seq đơn bào tự động. Ý tưởng là, với dữ liệu thô, tác nhân có thể tự chạy toàn bộ quy trình, quyết định công cụ nào sẽ gọi, đọc kết quả và thực hiện phân tích từng bước. Bạn có thể hỏi tại sao không sử dụng thứ gì đó như Claude Code với kỹ năng phân tích đơn bào. Câu trả lời ngắn gọn là đối với các quy trình làm việc khoa học, điều đó chưa đủ. Kỹ năng cuối cùng là các lời nhắc và do đó có thể bị ghi đè hoặc bỏ qua. Quan trọng hơn, công việc khoa học đòi hỏi khả năng tái tạo và theo dõi nguồn gốc: biết chính xác các tham số nào đã được sử dụng, tế bào nào đã được lọc, độ phân giải phân cụm nào tạo ra kết quả nào, v.v. Hồ sơ đó cần phải có cấu trúc và bền vững, không phải được tái tạo từ một cuộc hội thoại. Đối với các phiên chạy dài, bạn cũng cần quản lý trạng thái thế giới rõ ràng thay vì dựa vào việc nén ngữ cảnh để bảo toàn những gì quan trọng. Đây là những điều bạn phải xây dựng một cách có chủ đích. Xây dựng tất cả những điều này trên một mô hình cục bộ cũng có nghĩa là bạn sở hữu cơ sở hạ tầng, và đó là điều tôi sẽ tập trung vào ở đây. Tác nhân chúng tôi xây dựng chạy trên phần cứng HPC của tổ chức sử dụng các mô hình mã nguồn mở gần đây. Thật dễ dàng để cho rằng các mô hình mã nguồn mở không đủ mạnh cho loại công việc này. Nhưng điều đó đang ngày càng ít đúng hơn. Các bản phát hành gần đây như Qwen3.6–27B và Gemma 4–31B thực sự hữu ích cho các khối lượng công việc có cấu trúc, dựa trên công cụ (Nếu bạn quan tâm đến việc theo dõi sự phát triển của mã nguồn mở, Interconnects AI có những nội dung thú vị bạn có thể theo dõi). Và đó là một trong những lý do chính khiến việc lưu trữ cục bộ có ý nghĩa ở đây. Tác nhân của chúng tôi cũng hỗ trợ các API đám mây như Claude và GPT, nhưng khi bạn sử dụng chúng, tất cả cơ sở hạ tầng tôi sắp mô tả đều vô hình đối với bạn. Ai đó đã giải quyết nó rồi. Khi bạn tự lưu trữ mô hình, những vấn đề đó trở thành của bạn. Khi tôi chạy mô hình lần đầu tiên, nó hoạt động theo nghĩa hẹp. Mô hình sẽ gọi các công cụ, các công cụ sẽ chạy và phân tích sẽ tiến triển. Nhưng nó vẫn chưa thực sự hữu ích. Một phân tích đơn bào đơn giản có thể có 50–80 lệnh gọi công cụ trong một vòng lặp. Mỗi lệnh gọi đều mang cùng một gánh nặng cố định: lời nhắc hệ thống, lược đồ công cụ và lịch sử hội thoại ngày càng tăng. Đối với tác nhân này, lời nhắc hệ thống và lược đồ công cụ riêng đã là khoảng 36.000 token. Trước khi mô hình có thể quyết định bất cứ điều gì, nó phải đọc hàng chục nghìn token hướng dẫn và định nghĩa công cụ. Sau đó, nó phải làm lại điều đó trong lần lặp tiếp theo. Và lại một lần nữa sau đó. Mỗi lần lặp mất 10 đến 15 giây. Và một phiên dài cuối cùng sẽ bị lỗi với lỗi tràn ngữ cảnh, mang theo tất cả trạng thái phân tích trong bộ nhớ. Bài viết này nói về việc khắc phục cả hai vấn đề đó. Phần đầu tiên đề cập đến việc tăng tốc suy luận thông qua một tập hợp các tối ưu hóa tổng hợp cho máy chủ suy luận vLLM (một công cụ suy luận mã nguồn mở được xây dựng để phục vụ LLM thông lượng cao). Phần thứ hai đề cập đến việc duy trì các phiên dài thông qua quản lý ngữ cảnh tốt hơn và trạng thái thế giới có cấu trúc tồn tại sau khi cắt bớt. Tôi đã thực hiện các thử nghiệm trên GPU A100 và H100 để đo lường tác động của từng thay đổi, và những điều đó được mô tả dưới đây. Phần 1: Tăng tốc suy luận Trước khi đi sâu vào các tối ưu hóa riêng lẻ, việc hiểu điều gì đang thực sự xảy ra trong mỗi lần lặp của vòng lặp tác nhân sẽ hữu ích. Sơ đồ dưới đây cho thấy một lần lặp duy nhất: tác nhân gửi một yêu cầu chứa lời nhắc hệ thống, lược đồ công cụ và toàn bộ lịch sử cuộc trò chuyện đến mô hình. Mô hình đọc tất cả và quyết định công cụ nào sẽ gọi. Công cụ chạy và trả về kết quả, và kết quả đó được thêm vào lịch sử trước khi lần lặp tiếp theo bắt đầu. Hai điều đáng chú ý ở đây. Tiền tố cố định, là lời nhắc hệ thống cộng với lược đồ công cụ, có khoảng 36 nghìn token và được gửi trong mỗi lần gọi. Và lịch sử cuộc trò chuyện tăng lên theo mỗi lần lặp. Đến lần lặp thứ 40, mô hình không còn đọc một hướng dẫn ngắn nữa. Nó đang đọc một bản ghi phân tích dài với nhiều lệnh gọi công cụ, đầu ra công cụ, kết quả trung gian, v.v. Cả hai điều này đều ảnh hưởng đến hiệu suất của tác nhân. Hình 1: Một lần lặp của vòng lặp tác nhân. Tiền tố cố định lặp lại trong mỗi lần gọi và lịch sử cuộc trò chuyện tăng lên theo mỗi lần lặp. (Hình ảnh của tác giả) 1.1 Đồ thị CUDA: Giảm hàng trăm lệnh trên mỗi token xuống còn một Để hiểu điều này, việc biết điều gì xảy ra bên trong GPU khi nó tạo ra một token duy nhất sẽ hữu ích. Tạo một token duy nhất trong giai đoạn giải mã liên quan đến việc thực hiện một chuỗi các kernel GPU theo thứ tự: attention, feed-forward, normalization, v.v. Mỗi trình khởi chạy kernel này có một chi phí phối hợp nhỏ ở phía CPU. CPU phải xếp hàng một lệnh cho GPU biết chính xác kernel nào sẽ chạy, với hình dạng tensor và con trỏ bộ nhớ nào. Đối với một mô hình 27 tỷ tham số mà chúng tôi đang làm việc, điều này có nghĩa là hàng trăm lần điều phối riêng lẻ trên mỗi token. Mỗi lần điều phối đều nhỏ, nhưng chúng cộng lại. Đồ thị CUDA loại bỏ chi phí này. Trước khi xử lý bất kỳ yêu cầu thực tế nào, vLLM có thể chạy một lượt khởi động, nơi nó ghi lại tất cả các lần điều phối kernel cho bước giải mã vào một đối tượng có thể phát lại duy nhất. Sau đó, việc tạo mỗi token là một lệnh cho GPU thay vì hàng trăm. Kết quả là độ trễ giảm khoảng 20–25% từ thay đổi duy nhất này, mà không có bất kỳ thay đổi nào đối với chính mô hình.