Điền trước một lần, phân tán: Chia sẻ ảnh chụp nhanh KV cho các đường dẫn LLM đa tác nhân

AI tác nhân Điền một lần, phân phối: Chia sẻ ảnh chụp nhanh KV cho các đường ống LLM đa tác nhân Một phương pháp kỹ thuật hệ thống để tái sử dụng bộ nhớ đệm KV, chứng minh rằng việc tính toán một lời nhắc chung một lần luôn hiệu quả hơn N lần điền song song. Anubhab Banerjee Ngày 9/6/2026 28 phút đọc Chia sẻ Một chuyến tham quan hài hước nhưng thực tế về SwarmKV — phân phối ảnh chụp nhanh KV, bộ đệm máy chủ copy-on-fork và cách làm cho một đường ống phân tích hai tác nhân nhanh hơn khoảng 1,95 lần (và độ trễ kích hoạt của nhánh thứ hai nhanh hơn 52 lần) bằng cách "hơi khó chịu" với llama.cpp. Đây là Phần 1 của loạt bài "Suy luận tác nhân cấp độ sản xuất". Mỗi phần loại bỏ một loại công việc dư thừa khỏi đường ống LLM tác nhân. Phần 1 (bài viết này) loại bỏ việc điền dư thừa. Phần 2 giải quyết việc chờ đợi dư thừa — cách 50 vi tác nhân chia sẻ một GPU thông qua phân chia thời gian. Phần 3 giữ việc truy xuất RAG trên GPU với một kernel CUDA Top-K tùy chỉnh. Phần 4 duy trì trạng thái tác nhân qua các lần chuyển giao để tác nhân tiếp theo không bao giờ gặp vấn đề khởi động nguội. Những điểm chính Vấn đề: Khi một số tác nhân đọc cùng một tài liệu, một ngăn xếp phục vụ mặc định khiến mỗi tác nhân chạy lại chính xác cùng một quá trình điền. Lượt chú ý dày đặc dư thừa đó là sự lãng phí thuần túy. Cách khắc phục: Chạy điền một lần, tuần tự hóa bộ nhớ đệm KV vào bộ đệm máy chủ, sao chép nó cho mỗi nhánh và khôi phục nó trước khi giải mã. "Tính toán một lần, phân phối." Kết quả: Trên một GTX 1080 bảy năm tuổi, một đường ống hai tác nhân nhanh hơn 48,69% từ đầu đến cuối (khoảng 1,95 lần) và độ trễ kích hoạt của tác nhân thứ hai giảm 98,09% (khoảng 52 lần), loại bỏ 8.685 ms tính toán dư thừa. Điểm mấu chốt: Đây không phải là một thuật toán mới. Đây là kỹ thuật hệ thống — và đó là cùng một quyết định "phát sóng trạng thái chia sẻ một lần" mà một tháp di động 5G đã thực hiện cứ sau 80 ms kể từ LTE. Tóm tắt: Việc phục vụ LLM tiêu chuẩn khiến mọi tác nhân phân tích phải điền lại cùng một tài liệu được chia sẻ. GPU của bạn trung thực thực hiện lại hàng tỷ phép nhân tiền tố-điền dư thừa. Cùng một byte. Cùng một trọng số. Cùng một lượng tử hóa. Tất cả để tính toán lại một trạng thái mà nó đã hoàn thành tính toán bốn giây trước. SwarmKV chạy quá trình điền một lần, tuần tự hóa trạng thái KV kết quả vào bộ đệm máy chủ thông qua llama_state_get_data, sao chép bộ đệm đó vào một phân bổ cho mỗi nhánh và cho phép mỗi nhánh khôi phục ảnh chụp nhanh bằng llama_state_seq_set_data trước khi giải mã từ nơi tài liệu đã dừng lại. Vâng, đó là một vòng lặp thực sự — tuần tự hóa, sao chép, khôi phục, nhưng vì tính toán điền dư thừa tăng theo cấp số nhân trong khi truyền trạng thái KV tăng tuyến tính, việc di chuyển dữ liệu qua một bus bộ nhớ Pascal bị hạn chế vẫn rẻ hơn nhiều so với việc tính toán lại các ma trận chú ý từ đầu. Điều đó được phản ánh trong kết quả trên một GTX 1080 bảy năm tuổi: tăng tốc 48,69% từ đầu đến cuối trên một đường ống hai tác nhân, giảm 98,09% độ trễ kích hoạt nhánh 2 (khoảng 52 lần), loại bỏ 8.685 ms tính toán dày đặc dư thừa, không có thủ thuật biến đổi mới. Chỉ là vị trí kỹ thuật hệ thống rằng "tính toán một lần, phân phối" đánh bại "tính toán N lần, hy vọng không ai nhận ra." Kho GitHub: https://github.com/AnubhabBanerjee/swarmkv (Một lời thú nhận nhanh trước khi chúng ta bắt đầu: Tôi tiếp cận vấn đề này từ nền tảng kỹ thuật RAN 5G/6G. Hóa ra, việc phân phối một tính toán được chia sẻ cho nhiều người tiêu dùng hạ nguồn gần như chính xác những gì một tháp di động đã làm cứ sau 80 ms kể từ LTE khi nó phát sóng SIB1. Có một phần toàn bộ về điều đó bên dưới — phần 8 — nhưng đó cũng là lý do tại sao tôi viết bài này ngay từ đầu.) Mô hình tư duy kiến trúc — hãy giữ tài liệu này mở trong khi đọc. Tài liệu → PrefillNode → llama_state_get_data → host KV buffer → memcpy per branch → llama_state_seq_set_data → AnalyticalNode decode (RoPE tiếp tục tại prefix_seq_len) Tất cả những gì dưới đây chỉ là bình luận về một phần của dòng đó. Tổng quan kiến trúc SwarmKV 1. Một lời thú nhận: hầu hết "công việc" của tác nhân thứ hai của bạn là chạy lại Nếu bạn đã từng hướng hai tác nhân phân tích vào cùng một tài liệu thông qua llama.cpp tiêu chuẩn, đây là những gì thực sự xảy ra (với một chút kịch tính hóa có chủ ý): Bạn: "Vui lòng cung cấp tổng quan về thông số kỹ thuật 3.500 token này, và riêng biệt, liệt kê các nghĩa vụ cấp phép của nó." llama.cpp (Tác nhân 1): "Chắc chắn. Đang tải mô hình. Đang điền trước tài liệu. Đang giải mã câu trả lời." GPU dành 4.346 ms cho dense attention llama.cpp (Tác nhân 1): "Xong. Đây là câu trả lời 6 token." Bạn: "Tuyệt vời. Bây giờ là Tác nhân 2." llama.cpp (Tác nhân 2): "Chắc chắn. Đang tải mô hình. Đang điền trước tài liệu — " Bạn: "Khoan đã, bạn vừa mới làm điều đó mà." llama.cpp (Tác nhân 2): "Tôi là một llama_context độc lập. Tôi không có ký ức về Tác nhân 1. Tôi không có ký ức về bất cứ điều gì. Tôi là một đứa trẻ sơ sinh xinh đẹp, không trạng thái." 🫡 GPU dành thêm 4.339 ms cho phép toán attention giống hệt từng bit. Cảm biến nhiệt GPU của bạn: hoạt động hết công suất; Hóa đơn AWS của bạn: trở nên hài hước; TTFT của tác nhân thứ hai của bạn: 4,3 giây trước khi nó có thể trả lời một câu hỏi 4 token. Đó là trò đùa. Đó là bí mật bẩn thỉu của mọi pipeline "agentic" (có tác nhân) lan rộng từ một tài liệu chung. Mỗi nhánh bắt đầu từ một trạng thái trống và xây dựng lại cùng một bộ nhớ đệm KV mà nhánh trước đó vừa hoàn thành. Tài liệu càng sâu, chi phí càng lớn. Với 3.500 token trên GPU Pascal, phần lớn độ trễ nhận thấy của tác nhân thứ hai không phải là câu trả lời — mà là đọc lại tài liệu. SwarmKV là kết quả khi bạn quyết định rằng việc đọc lại lần thứ hai là tùy chọn và bạn thà viết 1.500 dòng C++ hơn là để mỗi tác nhân xây dựng cùng một bộ nhớ đệm KV lặp đi lặp lại. Bây giờ hãy tưởng tượng, bản demo thử nghiệm trong kho lưu trữ này là về hai tác nhân trên một bản tóm tắt/kiểm tra giấy phép. Hình dạng thực sự của khối lượng công việc mà nó được xây dựng cho là N bộ đánh giá chuyên biệt trên một tài liệu kỹ thuật dày đặc. Hãy hình dung một pipeline AI về bằng sáng chế và kỹ thuật trước đó: một thông số kỹ thuật 50.000 token ở gốc, và năm mươi nhánh đồng thời đánh giá tính mới, lập bản đồ các yêu cầu, truy xuất kỹ thuật trước đó, kiểm tra các yêu cầu đã được giải phóng.