Ngày 09/09/2026, Red Hat công bố Red Hat AI 3.5 với trọng tâm đưa AI từ giai đoạn thử nghiệm sang môi trường production có kiểm soát. Bộ cập nhật bổ sung khả năng đánh giá model, guardrail, observability, quản lý GPU, multi-tenancy và nhiều công cụ dành cho agent. Red Hat định vị phiên bản này cho các đội platform engineering và IT đang phải vận hành AI như một hạ tầng doanh nghiệp thay vì một dự án thử nghiệm riêng lẻ. Với Red Hat AI 3.5, điểm đáng quan tâm không nằm ở việc thêm một chatbot khác. Bài toán mà nền tảng hướng tới là quản lý model, agent, GPU và policy khi nhiều nhóm cùng sử dụng một hạ tầng. Khi AI chuyển từ vài notebook của data scientist sang dịch vụ nội bộ dùng hằng ngày, những vấn đề như kiểm soát tài nguyên, quan sát lỗi và bằng chứng compliance bắt đầu trở nên quan trọng ngang chất lượng model.
Red Hat AI 3.5 đóng vai trò là nền tảng hạ tầng Hybrid Cloud chuẩn hóa, giúp doanh nghiệp dịch chuyển AI Agent từ thử nghiệm (PoC) sang vận hành thực tế (Production) (Ảnh minh họa: Snettech)
Red Hat AI 3.5 Tập Trung Vào Trust Và Control
Red Hat mô tả bốn câu hỏi mà doanh nghiệp thường gặp khi mở rộng AI: hệ thống có đáng tin, có kiểm soát được, có thể xây tiếp trên đó và có đo được hiệu quả hay không. Phiên bản 3.5 bổ sung công cụ ở cả bốn hướng thay vì chỉ tập trung inference.
EvalHub Giúp Đánh Giá Model Có Cấu Trúc Hơn
Một điểm mới là EvalHub, nơi đội ngũ có thể chạy đánh giá và lưu bằng chứng liên quan model. Red Hat cho biết hệ thống hướng tới việc chuẩn hóa quá trình benchmark và hỗ trợ yêu cầu governance hoặc compliance. Trong thực tế, chọn model không nên chỉ dựa vào bảng benchmark công khai. Một doanh nghiệp có thể cần đánh giá trên tài liệu, ngôn ngữ và workflow riêng. Model mạnh về code chưa chắc phù hợp tổng đài; model tốt cho tiếng Anh chưa chắc giữ chất lượng tương tự với dữ liệu nội bộ nhiều tiếng Việt.
EvalHub tạo cơ sở để xây bộ test riêng và lặp lại sau mỗi lần đổi model. Cách này giống CI cho AI: trước khi đẩy phiên bản mới vào production, đội ngũ có thể kiểm tra những tiêu chí đã định nghĩa thay vì chỉ tin thông báo từ nhà cung cấp.
Guardrail Được Đưa Gần Hơn Tới Hạ Tầng
Red Hat AI 3.5 mở rộng khả năng chấm điểm an toàn và tích hợp guardrail cho ứng dụng hội thoại. Điều này hữu ích với agent hoặc chatbot có quyền truy cập dữ liệu nội bộ vì output sai có thể tạo rủi ro lớn hơn một câu trả lời không chính xác đơn thuần.
Guardrail không chỉ nên hiểu là bộ lọc từ khóa. Doanh nghiệp có thể cần policy ngăn model tiết lộ dữ liệu nhạy cảm, kiểm tra prompt injection hoặc giới hạn loại công cụ agent được gọi. Mỗi ứng dụng có bối cảnh khác nên lớp bảo vệ cũng phải bám mục tiêu sử dụng. Quan trọng hơn, guardrail cần được đo. Nếu hệ thống chặn quá nhiều yêu cầu hợp lệ, người dùng sẽ tìm cách vòng qua nó; nếu quá lỏng, rủi ro tăng. Eval và observability giúp đội ngũ xem lớp an toàn đang hoạt động ra sao thay vì chỉ bật rồi quên.
Red Hat AI 3.5 giúp doanh nghiệp tối ưu chi phí và nâng cao bảo mật an toàn (Ảnh minh họa: Snettech)
Observability Giúp Nhìn GPU Và Inference Từ Một Nơi
Red Hat bổ sung dashboard GPU-as-a-Service hiển thị trạng thái deployment, loại phần cứng và năng lực GPU đã cấp hoặc đang được mượn. Đây là bước thực dụng vì nhiều tổ chức đang có GPU đắt tiền nhưng thiếu cái nhìn rõ ai đang dùng và workload nào tiêu thụ tài nguyên.
Observability còn bao gồm sức khỏe inference và token consumption. Khi một ứng dụng đột ngột tăng chi phí, đội platform có thể xác định model, nhóm hoặc endpoint liên quan nhanh hơn việc ghép log thủ công. Với AI production, latency và lỗi cần được xem như metric của dịch vụ. Một model trả lời tốt nhưng thường xuyên timeout vẫn là sản phẩm kém đối với người dùng cuối. Red Hat đang đưa cách vận hành AI gần hơn với nguyên tắc SRE vốn đã quen thuộc ở hệ thống web.
GPU Scheduling Và Multi-Tenancy Giải Bài Toán Chia Tài Nguyên
GPU là một trong những chi phí lớn của AI infrastructure. Khi nhiều đội cùng sử dụng cluster, cách phân bổ tài nguyên có thể ảnh hưởng mạnh tới chi phí và thời gian chờ. Red Hat AI 3.5 đưa thêm cơ chế fair-share scheduling và priority-aware serving để xử lý vấn đề này.
Fair-Share Giảm Tình Trạng Một Nhóm Chiếm Toàn Bộ GPU
Trong môi trường nội bộ, một team thử model lớn có thể vô tình chiếm phần lớn GPU trong nhiều giờ. Nếu không có quota hoặc scheduling, nhóm khác phải chờ dù workload của họ nhỏ hơn. Fair-share scheduling cho phép hạ tầng cân bằng quyền truy cập giữa các workload. Cùng lúc, priority-aware serving giúp dịch vụ quan trọng nhận tài nguyên sớm hơn batch job ít cấp thiết. Đây là vấn đề nghe rất hạ tầng nhưng tác động trực tiếp tới developer. Nếu môi trường test luôn phải chờ GPU, tốc độ thử nghiệm giảm; nếu production không được ưu tiên, trải nghiệm khách hàng có thể bị ảnh hưởng bởi chính các job nghiên cứu nội bộ.
Multi-Tenancy Cần Cả Cô Lập Và Quan Sát
Red Hat mở rộng mô hình hosted control plane trong OpenShift Virtualization để hỗ trợ nhiều tenant với mức cô lập tốt hơn. Điều này phù hợp doanh nghiệp có nhiều nhóm hoặc khách hàng dùng chung hạ tầng AI. Multi-tenancy không chỉ là tạo namespace khác nhau. Tổ chức còn phải tách secret, dữ liệu, network policy và quota. Nếu một agent có quyền gọi tool, phạm vi quyền cần được giới hạn theo tenant thay vì dùng credential dùng chung. Các dashboard mới giúp đội vận hành thấy tài nguyên đang được phân phối thế nào. Khi kết hợp quota và audit, AI platform có thể tiến gần mô hình dịch vụ nội bộ thay vì cụm GPU được chia bằng tin nhắn giữa các nhóm.
Inference-Time Scaling Tập Trung Vào Chi Phí Và Hiệu Năng
Red Hat AI 3.5 bổ sung khả năng phân bổ compute động trong quá trình inference, cùng các kỹ thuật offload một phần dữ liệu khỏi GPU khi phù hợp. Mục tiêu là sử dụng GPU hiệu quả hơn trong bối cảnh model và context ngày càng lớn. Không phải mọi request đều cần mức compute giống nhau. Một câu hỏi đơn giản có thể dùng ít tài nguyên hơn nhiệm vụ agent nhiều bước. Nếu hạ tầng biết điều chỉnh, doanh nghiệp có thể giảm tình trạng mọi truy vấn đều được xử lý bằng cấu hình đắt đỏ. Tuy nhiên, tối ưu cần dựa trên benchmark của workload thật. Giảm compute quá mạnh có thể ảnh hưởng chất lượng hoặc latency, còn offload không phù hợp có thể làm chậm hệ thống. Đây là nơi observability và eval lại đóng vai trò quan trọng.
Red Hat AI 3.5 là phiên bản cập nhật mang tính bước ngoặt, nổi bật với nhiều tính năng vượt trội (Ảnh minh họa: Snettech)
Agent Development Đang Được Chuẩn Hóa Dần
Red Hat AI 3.5 còn đưa vào AutoRAG, agent template và pipeline trực quan để cấu hình, kiểm tra các ứng dụng agent. Điều này phản ánh xu hướng agent đang chuyển từ demo cá nhân sang hệ thống cần quy trình triển khai lặp lại.
RAG Và Agent Cần Workflow Có Thể Tái Tạo
Một prototype thường được tạo bằng vài prompt, một vector database và một notebook. Khi chuyển lên production, đội ngũ phải biết embedding model nào được dùng, chunk size bao nhiêu, nguồn tài liệu nào được index và policy truy cập ra sao. AutoRAG có thể giảm công việc cấu hình ban đầu, nhưng doanh nghiệp vẫn cần lưu version của dataset, prompt và model. Nếu không, một câu trả lời thay đổi sau update sẽ rất khó truy nguyên. Agent template cũng có ích khi nhiều nhóm cần những cấu trúc tương tự. Thay vì mỗi team tự xây authentication và tool calling từ đầu, platform team có thể cung cấp baseline đã kiểm tra bảo mật.
Tool Calling Cần Được Xem Như API Production
Agent có thể gọi database, ticket system, email hoặc công cụ nội bộ. Khi đó, sai sót không còn dừng ở text mà có thể tạo hành động thật. Red Hat cũng đã thảo luận riêng về độ tin cậy của tool calling như một vấn đề “last mile” trong agentic AI. Developer nên thiết kế schema rõ, validation chặt và permission theo nguyên tắc quyền tối thiểu. Các hành động có rủi ro cao cần approval thay vì cho agent thực hiện tự động. Log mỗi tool call cũng rất quan trọng. Khi một agent tạo kết quả sai, đội vận hành phải biết model đã chọn công cụ nào, tham số gì và hệ thống trả về dữ liệu gì.
Red Hat AI 3.5 cho thấy AI enterprise đang bước qua giai đoạn chỉ quan tâm model mạnh ra sao. EvalHub, guardrail, observability, GPU scheduling, multi-tenancy và agent tooling đều tập trung vào câu hỏi vận hành: làm thế nào để nhiều đội dùng AI mà hệ thống vẫn kiểm soát được. Với developer và platform engineer, bài học lớn là AI production cần tư duy giống hạ tầng phần mềm truyền thống: có test, metric, quota, log, policy và quy trình rollout. Model có thể thay đổi rất nhanh, nhưng những nguyên tắc vận hành này tồn tại lâu hơn vòng đời của bất kỳ model cụ thể nào.
