Tăng tốc suy luận của một mô hình bảo vệ encoder: TensorRT, Triton, vLLM, Ray Serve

Bài viết mô tả một nỗ lực nhằm tăng tốc mô hình bảo vệ (guard model) đứng giữa LLM (Large Language Model - Mô hình ngôn ngữ lớn) và người dùng, có nhiệm vụ kiểm tra nội dung nguy hiểm. Mô hình này là một bộ mã hóa PII (Personally Identifiable Information - Thông tin nhận dạng cá nhân) theo kiểu zero-shot: nó nhận đầu vào là các loại thực thể dưới dạng văn bản cùng với tài liệu, thực hiện trích xuất thực thể và phân loại mức độ an toàn trong một lượt truyền xuôi (forward pass) duy nhất. Do kiến trúc đặc thù, mô hình này đặt ra bảy giới hạn về kỹ thuật: hình dạng đầu vào biến đổi, đầu ra không phải dạng tensor nên cần giải mã span trên CPU (Central Processing Unit - Bộ xử lý trung tâm), các phép toán đặc thù như gather và tính điểm song tuyến (bilinear scoring), cơ chế attention có thể không theo chuẩn thông thường, chi phí xử lý theo batch bị quyết định bởi phần tử dài nhất, hạ tầng phục vụ (serving infrastructure) vốn được tối ưu cho các LLM tự hồi quy (autoregressive), và tầm quan trọng của độ trễ đuôi (tail latency, tức P95, P99) vì mô hình bảo vệ được gọi hai lần cho mỗi lượt hội thoại. Thí nghiệm so sánh năm công cụ: TensorRT runtime, NVIDIA Triton, vLLM, Ray Serve, và một backbone Flash DeBERTa, với các mức nền (baseline) sử dụng LitServe. Nhánh runtime dùng TensorRT áp dụng cấu hình tải ngắn (một worker, 50 người dùng, 60 giây), trong khi các nhánh serving sử dụng cấu hình tải dài hơn (bốn worker, 100 người dùng, 15 phút), do đó các số liệu chỉ có thể so sánh trong phạm vi từng nhánh riêng biệt. Phiên bản TensorRT FP16 (Floating Point 16-bit - Dấu phẩy động 16-bit) đạt 130,72 RPS (Requests Per Second - Số yêu cầu mỗi giây), so với 106,49 RPS của PyTorch FP16, tương đương mức cải thiện 23%. Các nỗ lực lượng tử hóa INT8 (Integer 8-bit - Số nguyên 8-bit) đã thất bại do thiếu hỗ trợ cho các phép toán tùy biến, dẫn đến RPS rất thấp và độ trễ cao.