Xây dựng nền tảng AI-as-a-Service: Tối ưu hóa GPU thời gian thực và xử lý theo lô
Joseph Stein chia sẻ hành trình xây dựng nền tảng AI-as-a-Service tại SS&C Technologies. Bài viết đề cập đến việc tối đa hóa hiệu suất GPU thông qua lập lịch đa namespace, sử dụng Valkey và Lua để quản lý hàng đợi ưu tiên, cũng như các biện pháp bảo mật chống lại rủi ro OWASP Top 10 cho LLM thông qua cổng proxy trung tâm.

Xây dựng nền tảng AI-as-a-Service: Tối ưu hóa GPU thời gian thực và xử lý theo lô
Trong bài thuyết trình tại QCon, Joseph Stein - Kiến trúc sư trưởng tại SS&C Technologies - đã chia sẻ chi tiết về hành trình kỹ thuật nhằm xây dựng một nền tảng AI-as-a-Service (AI như một dịch vụ) doanh nghiệp. Nhiệm vụ của ông là vận hành nền tảng này trong trung tâm dữ liệu đám mây riêng (private cloud), giải quyết bài toán khó khăn về tối ưu hóa tài nguyên GPU đắt đỏ và đảm bảo an toàn, tuân thủ các quy định nghiêm ngặt của ngành tài chính.
Thách thức về Bảo mật và Quản trị
Khi bắt đầu dự án cách đây hai năm, Stein nhận thấy hai nhóm nội bộ đang vận hành các hệ thống RAG (Retrieval-Augmented Generation) tiên tiến. Tuy nhiên, việc mở rộng quy mô này cho toàn bộ công ty đòi hỏi một nền tảng tập trung để quản lý GPU mà không làm vỡ ngân sách, đồng thời vẫn đảm bảo tuân thủ chính sách và quy định.
Một trong những mối quan tâm lớn nhất là bảo mật. Stein nhấn mạnh tầm quan trọng của việc áp dụng danh sách OWASP Top 10 cho LLM (Mô hình ngôn ngữ lớn). Ông chỉ ra rằng, giống như các ứng dụng web dễ bị tấn công XSS, các hệ thống AI cũng đối mặt với nguy cơ từ chối dịch vụ mô hình (Model Denial of Service) hoặc các cuộc tấn công tiêm prompt (prompt injection).
"Nếu không có cổng chặn (gateway), bạn không có gì ngoài rủi ro. Bạn chỉ có các giao dịch đi vào mô hình mà không có cách nào quản lý hay áp dụng các biện pháp kiểm soát an ninh," Stein nhận định.
Để giải quyết vấn đề này, đội ngũ đã xây dựng một tập hợp các vi dịch vụ (microservices) đóng vai trò là proxy trung tâm. Tại đây, mọi yêu cầu đều được kiểm tra qua các "hàng rào bảo vệ" (guardrails) để phát hiện prompt injection hoặc nội dung độc hại (toxicity) trước khi đến LLM, và kiểm tra lại đầu ra để đảm bảo tính chính xác và an toàn.
Tối ưu hóa GPU với vLLM và Định tuyến Đa Namespace
GPU là tài nguyên đắt đỏ nhưng lại là nút thắt cổ chai lớn nhất về tốc độ xử lý token. Stein chia sẻ rằng mặc dù chi phí cho GPU rất cao, nhưng tốc độ xử lý thực tế chỉ khoảng 4.000 token mỗi giây cho mỗi chip. Để tối đa hóa việc sử dụng tài nguyên này, SS&C Technologies đã triển khai vLLM - một thư viện inference hiệu suất cao.
Thách thức lớn nhất là làm thế nào để chia sẻ GPU giữa nhiều môi trường khác nhau như Dev, Test, UAT, Prod và Disaster Recovery (DR) mà không lãng phí tài nguyên. Đội ngũ đã sử dụng tính năng namespace của Kubernetes để phân tách các môi trường này.
Ban đầu, mỗi môi trường có các proxy LLM riêng biệt và không biết về sự tồn tại của nhau. Giải pháp được đưa ra là xây dựng một GPU Pool Proxy duy nhất. Proxy này nhìn thấy hai chiều kích thước: chiều của môi trường khách hàng (Prod, Dev...) và chiều của môi trường hạ tầng (namespace). Điều này cho phép áp dụng hàng đợi ưu tiên (priority queuing) thông minh, đảm bảo lưu lượng sản xuất luôn được ưu tiên cao nhất, trong khi các tác vụ phát triển hoặc demo có thể chạy trên các tài nguyên dự phòng mà không làm gián đoạn hệ thống chính.
Quản lý Hàng đợi với Valkey và Lua
Để xử lý việc đăng ký vượt mức (oversubscription) và quản lý áp suất ngược (backpressure) từ vLLM, Stein đã chọn sử dụng Valkey (một fork mở của Redis) kết hợp với các script Lua.
Tất cả các kiểm tra giới hạn tốc độ (rate limiting) và logic xếp hàng ưu tiên đều được thực thi nguyên tử (atomically) trong bộ nhớ bằng Lua. Điều này cực kỳ nhanh chóng và cho phép hệ thống xử lý khối lượng công việc từ bất kỳ môi trường nào dựa trên dung lượng sẵn có. Khi hàng đợi nội bộ của vLLM vượt quá ngưỡng nhất định (ví dụ: số lượng yêu cầu lớn hơn 3), hệ thống sẽ kích hoạt cơ chế backpressure để ngăn chặn sự quá tải.
Xử lý theo Lô (Batch Processing) và Tối ưu hóa Tài nguyên
Ngoài việc xử lý thời gian thực (realtime) cho chatbot, nền tảng này còn xử lý các khối lượng công việc theo lô như trí tuệ tài liệu (document intelligence) và chuyển đổi giọng nói (voice transcription).
Đội ngũ nhận thấy rằng việc xử lý tài liệu ngay lập tức trong giờ cao điểm là lãng phí tài nguyên. Thay vào đó, họ xây dựng một máy bay điều khiển (control plane) mới cho phép người dùng đăng ký tệp và cấu hình SLA (ví dụ: hoàn thành trong 5 phút hoặc lên lịch vào lúc 8 giờ tối thứ Ba). Hệ thống sẽ tính toán khả năng đáp ứng dựa trên dung lượng GPU hiện tại và lên lịch xử lý vào các giờ thấp điểm để tận dụng tối đa các tài nguyên đang bị nhàn rỗi.
Về mặt kiến trúc dữ liệu, họ đã xây dựng một máy chủ proxy S3 tùy chỉnh. Điều này giúp hệ thống không phụ thuộc vào bất kỳ nhà cung cấp đám mây cụ thể nào và cho phép tích hợp dễ dàng với các tác nhân MCP (Model Context Protocol) để truyền dữ liệu vào hệ thống RAG. Các tệp sau khi tải lên sẽ được kích hoạt webhook và gửi đến Kafka để xử lý trong các pipeline dữ liệu.
Kết luận
Trải nghiệm của SS&C Technologies cho thấy việc xây dựng một nền tảng AI nội bộ đòi hỏi sự cân bằng tinh tế giữa hiệu suất, chi phí và an ninh. Bằng cách sử dụng vLLM, Kubernetes namespace thông minh, và hệ thống hàng đợi dựa trên Valkey, họ đã tạo ra một nền tảng linh hoạt cho phép phục vụ hàng nghìn trường hợp sử dụng và người dùng mà không cần đầu tư hàng triệu USD vào phần cứng dư thừa.
Stein kết luận: "Hãy xác định rõ mô hình mối đe dọa và khẩu vị rủi ro của bạn. Đừng chỉ chạy theo xu hướng Wild West hay khóa chặt mọi thứ, hãy tìm điểm cân bằng để cung cấp các kiểm soát hiệu quả xung quanh AI."
Bài viết liên quan
Phần mềm
Vivado 2026.1: AMD loại bỏ hỗ trợ Linux trên bản miễn phí gây tranh cãi
24 tháng 5, 2026

Công nghệ
Cisco sa thải 4.000 nhân sự dù doanh thu kỷ lục, chuyển hướng mạnh sang AI
14 tháng 5, 2026

Công nghệ
Elon Musk muốn chi 119 tỷ USD xây nhà máy chip, dù chưa từng có kinh nghiệm trong lĩnh vực này
06 tháng 5, 2026
