Hugging Face TGI: phục vụ model mở trong môi trường production
TGI có batching liên tục, tensor parallelism, streaming SSE, Prometheus và OpenTelemetry, nhưng đang ở maintenance mode. Playbook này giúp đội hạ tầng đánh giá, triển khai có kiểm soát và chuẩn bị rollback cho endpoint LLM nội bộ.
Một ticket quen thuộc của đội hạ tầng: “Hãy dựng endpoint nội bộ cho model mở; dữ liệu không được ra ngoài công ty.”
Việc để model trả lời được chỉ là bước đầu. Câu hỏi quan trọng hơn là: cụm GPU có đáp ứng không, tải tăng thì xử lý thế nào, ai được quyền gọi endpoint, và khi thay đổi model gây sự cố thì quay về bản ổn định bằng cách nào?
Với Hugging Face Text Generation Inference (TGI), có một điểm cần đặt lên đầu quyết định kỹ thuật: TGI hiện ở maintenance mode. Hugging Face cho biết dự án tiếp nhận các đóng góp sửa lỗi nhỏ, cải thiện tài liệu và công việc bảo trì nhẹ. Đồng thời, tài liệu khuyến nghị cân nhắc các engine như vLLM, SGLang, hoặc những lựa chọn chạy cục bộ có khả năng tương thích như llama.cpp và MLX cho hướng phát triển tiếp theo.
Vì vậy, mục tiêu không phải là “có GPU là dựng TGI”, mà là vận hành một endpoint có giới hạn rõ ràng, quan sát được và có đường lui.
TGI cung cấp gì cho cụm GPU nội bộ?
TGI là toolkit để triển khai và phục vụ mô hình ngôn ngữ lớn. Tài liệu nêu hỗ trợ nhiều model mở phổ biến, gồm Llama, Falcon, StarCoder, BLOOM, GPT-NeoX và T5.
Với quản trị viên hệ thống, các khả năng đáng chú ý gồm:
Continuous batching: xử lý liên tục các request đến để tăng tổng throughput.
Tensor parallelism: dùng nhiều GPU cho suy luận nhanh hơn.
Quantization qua bitsandbytes và GPT-Q.
Streaming token qua Server-Sent Events (SSE).
Prometheus metrics và distributed tracing qua OpenTelemetry.
Tối ưu suy luận với Flash Attention và Paged Attention trên các kiến trúc phổ biến.
Nạp trọng số bằng safetensors.
Các tùy chọn sinh văn bản như temperature, top-p, top-k, repetition penalty, stop sequences và log probabilities.
Hỗ trợ model fine-tune và Guidance để ép đầu ra theo schema đã định nghĩa, phục vụ function calling hoặc tool use.
Đây là những thành phần hữu ích cho một dịch vụ inference dùng chung trong doanh nghiệp. Tuy nhiên, tài liệu tham chiếu không đưa ra mức VRAM, throughput, độ trễ hay số request đồng thời cho từng model và loại GPU.
Không nên lấy kết quả từ một cụm khác làm cam kết năng lực cho cụm của mình.
Chốt ba giới hạn trước khi dựng endpoint
Đừng bắt đầu bằng tên model. Hãy bắt đầu bằng các giới hạn vận hành mà dịch vụ phải tuân thủ.
1. Giới hạn tài nguyên GPU
Tensor parallelism cho phép phân tán suy luận trên nhiều GPU. Quantization là một lựa chọn có thể giúp giảm yêu cầu bộ nhớ.
Nhưng việc chọn cấu hình nào cần được kiểm thử trên chính model, GPU, driver, độ dài ngữ cảnh và kiểu tải thực tế của doanh nghiệp. Đừng coi tensor parallelism hoặc quantization là phương án thay thế cho việc đo đạc.
2. Giới hạn request đồng thời
Continuous batching hướng đến việc tăng tổng throughput, nhưng không khiến tài nguyên GPU trở nên vô hạn.
Cần xác định cách xử lý khi tải vượt ngưỡng: xếp hàng, từ chối request, hay để ứng dụng phía trên retry theo chính sách đã thống nhất. Nếu không có giới hạn ở lớp trước endpoint, tải tăng đột ngột có thể kéo theo hàng đợi dài và độ trễ khó dự đoán.
3. Giới hạn phạm vi truy cập
Tài liệu tham chiếu mô tả khả năng inference, streaming và quan sát của TGI, nhưng không nêu cấu hình cụ thể cho xác thực, phân quyền, TLS hoặc giới hạn mạng.
Vì vậy, không nên mặc định TGI là lớp kiểm soát truy cập hoàn chỉnh. Với endpoint nội bộ, hãy đặt service sau reverse proxy, API gateway hoặc lớp kiểm soát mạng hiện có; chỉ cho phép ứng dụng và mạng nguồn cần thiết truy cập.
Biến yêu cầu mơ hồ thành phiếu triển khai
Tài liệu được cung cấp không kèm lệnh cài đặt, tham số launcher, cổng mặc định, manifest container hay ví dụ API. Thay vì tự tạo một lệnh triển khai không có căn cứ, đội vận hành nên yêu cầu một phiếu thông tin tối thiểu trước khi cấp GPU.
text
Tên dịch vụ: <ten-dich-vu>
Model và phiên bản trọng số: <model-version>
Mục đích nghiệp vụ: <muc-dich>
Nhóm được phép gọi: <nhom-nguoi-dung>
Mạng nguồn được phép truy cập: <network-allowlist>
GPU được cấp: <gpu-layout>
Chế độ phục vụ dự kiến: <single-gpu|tensor-parallel>
Có dùng quantization: <co|khong>
Giới hạn request đồng thời: <nguong-concurrency>
Chính sách khi quá tải: <queue|reject|retry-upstream>
Metrics cần theo dõi: <prometheus-metrics>
Tracing cần bật: <opentelemetry-tracing>
Nơi lưu log: <log-destination>
Trường dữ liệu không được ghi log: <sensitive-fields>
Phiên bản đang phục vụ: <current-version>
Phiên bản dùng để rollback: <rollback-version>
Điều kiện rollback: <rollback-criteria>
Người có quyền kích hoạt rollback: <owner>
Sau bước này, đầu ra không chỉ là “đã có endpoint”. Đội hạ tầng cần biết chính xác model nào sẽ chạy, ai gọi được, GPU nào chịu tải và phiên bản nào là đường lui khi có sự cố.
Nếu chủ ứng dụng chưa xác định được giới hạn tải hoặc điều kiện rollback, hạ tầng không nên tự đoán. Hãy bắt đầu thận trọng, quan sát rồi mới mở rộng.
Quan sát trước khi mở cho người dùng
TGI có Prometheus metrics và OpenTelemetry tracing, tạo nền tảng để kết nối vào hệ thống quan sát hiện hữu.
Tuy nhiên, phần tài liệu tham chiếu không nêu tên metric, nhãn metric, dashboard mẫu hay ngưỡng cảnh báo. Vì vậy, khi nghiệm thu, nên tập trung trả lời các câu hỏi vận hành:
Request có bị xếp hàng không?
Độ trễ thay đổi thế nào khi mức đồng thời tăng?
Tài nguyên GPU có ổn định trong kiểu tải thực tế không?
Continuous batching có cải thiện throughput cho lưu lượng của ứng dụng không?
Trace có giúp phân biệt độ chậm đến từ gateway, hàng đợi, model hay đường truyền không?
Log có vô tình lưu prompt hoặc dữ liệu nội bộ nhạy cảm không?
Không nên chỉ nhìn một chỉ số đơn lẻ. GPU bận có thể phản ánh việc khai thác tài nguyên tốt, nhưng cũng có thể đi cùng thời gian chờ cao. Cần xem đồng thời độ trễ, lỗi, hàng đợi và mức sử dụng tài nguyên.
Rollback phải là thao tác đã chuẩn bị
TGI hỗ trợ sử dụng model fine-tune. Khi thay đổi trọng số hoặc cấu hình phục vụ, rủi ro không chỉ là service không khởi động; đầu ra của ứng dụng cũng có thể thay đổi.
Hãy luôn phân biệt rõ:
Phiên bản ổn định đang phục vụ.
Phiên bản ứng viên đang được kiểm thử.
Tiêu chí chuyển lưu lượng sang phiên bản mới.
Tiêu chí rollback về phiên bản ổn định.
Trước khi chuyển lưu lượng, hãy kiểm tra bằng tập prompt đại diện cho nghiệp vụ. Nếu ứng dụng sử dụng streaming, stop sequences hoặc Guidance cho đầu ra có cấu trúc, các chức năng này cũng cần nằm trong phạm vi kiểm thử.
Khi có lỗi, rollback nên là chuyển lưu lượng về phiên bản đã được xác nhận thay vì sửa nóng trên node đang phục vụ. Sau đó, giữ lại trace, log vận hành và trạng thái tài nguyên cần thiết để phân tích sự cố. Không nên mặc định ghi toàn bộ prompt vào log nếu prompt có thể chứa dữ liệu nội bộ.
Checklist trước ngày go-live
[ ] Xác nhận TGI vẫn phù hợp dù dự án đang ở maintenance mode.
[ ] Đã đánh giá vLLM hoặc SGLang nếu cần lộ trình phát triển dài hạn.
[ ] Chốt model, phiên bản trọng số và cấu hình GPU.
[ ] Xác định có dùng tensor parallelism hoặc quantization hay không.
[ ] Đặt giới hạn request đồng thời và chính sách xử lý quá tải.
[ ] Giới hạn truy cập theo mạng và danh tính cần thiết.
[ ] Kết nối Prometheus metrics, OpenTelemetry tracing và logging vào quy trình giám sát hiện có.
[ ] Kiểm thử bằng prompt nghiệp vụ, không chỉ bằng prompt thử nghiệm đơn giản.
[ ] Có phiên bản rollback, tiêu chí kích hoạt và người chịu trách nhiệm rõ ràng.
TGI vẫn có nhiều mảnh ghép quan trọng cho dịch vụ inference: batching, đa GPU, streaming và khả năng quan sát. Nhưng một endpoint production tốt không được đo bằng việc model “trả lời được”, mà bằng khả năng vận hành có kiểm soát, theo dõi được và quay lui được khi mọi thứ không diễn ra như dự kiến.