Tự host mô hình LLM là gì? Chi phí, hạ tầng và khi nào nên dùng

Tự host mô hình LLM là việc bạn trực tiếp vận hành toàn bộ ngăn xếp suy luận (inference stack), từ phần cứng GPU vật lý đến phần mềm engine thực thi, thay vì gọi API trả phí từ bên thứ ba.

Đây là bài toán về hiệu suất vận hành và quyền kiểm soát dữ liệu tuyệt đối.

Tuy nhiên, tự host không phải lúc nào cũng tiết kiệm ngân sách. Bạn phải chịu trách nhiệm từ khâu định lượng (quantization), cấu hình KV cache đến việc duy trì tính sẵn sàng của hệ thống dưới tải cao.

Mô hình ngôn ngữ lớn chạy trên cụm GPU nằm trong hạ tầng riêng của doanh nghiệp, đặt cạnh phương án gọi API của bên thứ ba qua Internet

Tự host mô hình LLM nghĩa là gì?

Tự host mô hình LLM là quá trình thiết lập và quản lý một ngăn xếp suy luận hoàn chỉnh trên hạ tầng bạn sở hữu hoặc thuê riêng. Bạn không chỉ gửi yêu cầu đến một endpoint có sẵn mà phải trực tiếp quản lý trọng số mô hình (weights), cấu hình engine suy luận và cấp phát tài nguyên GPU. Công việc này yêu cầu kỹ sư phải nắm rõ cách mô hình ngôn ngữ lớn (LLM) chiếm dụng bộ nhớ tĩnh, cách vận hành bộ nhớ đệm KV (KV cache) và áp dụng các kỹ thuật tối ưu để hệ thống không sập khi lượng người dùng tăng đột ngột.

Ba khái niệm dễ nhầm lẫn: vị trí lưu trữ dữ liệu, địa phương hoá dữ liệu và quyền tài phán dữ liệu, kèm phổ mức độ tự chủ từ hyperscaler đến sovereign cloud đến on-premise

Về mặt kỹ thuật và pháp lý, bạn cần phân biệt rõ giữa vị trí lưu trữ dữ liệu (residency) và quyền tài phán dữ liệu (sovereignty). Việc đặt máy chủ tại một trung tâm dữ liệu nội địa chỉ giải quyết vấn đề vị trí. Nếu nhà cung cấp hạ tầng là công ty chịu sự chi phối của các đạo luật nước ngoài như CLOUD Act của Mỹ, các cơ quan chức năng nước ngoài vẫn có quyền yêu cầu truy cập dữ liệu của bạn. Tự host trên hạ tầng tự chủ là cách duy nhất để loại bỏ hoàn toàn sự can thiệp của các bên trung gian và đảm bảo quyền tài phán tối cao.

Khi tự vận hành, đội ngũ kỹ sư phải đảm bảo tính sẵn sàng của dịch vụ, bảo trì driver CUDA và thiết lập các lớp bảo mật tại thời điểm thực thi (runtime). Bạn phải quyết định mức định lượng phù hợp để cân bằng giữa độ chính xác và dung lượng VRAM hiện có. Một node tự host cơ bản bao gồm các lớp thành phần sau:

Hạ tầng phần cứng GPU (H100, B200, L40S...).
Driver và thư viện hỗ trợ (CUDA, NCCL).
Engine suy luận (vLLM, SGLang).
API Gateway để quản lý định tuyến và kiểm soát chính sách.

Vì sao một đội kỹ thuật chấp nhận tự vận hành mô hình?

Động lực lớn nhất để bạn tự host là quyền tự chủ dữ liệu và tuân thủ các khung pháp lý khắt khe như GDPR hay EU AI Act. Khi dữ liệu rời khỏi hạ tầng của tổ chức để đến các API công cộng, nó có thể bị coi là hành vi chuyển giao dữ liệu quốc tế bị hạn chế. Việc tự vận hành cho phép bạn thực thi các chính sách bảo mật, phát hiện dữ liệu nhạy cảm (PII) và tạo nhật ký kiểm tra (audit trail) ngay tại chỗ mà không cần phụ thuộc vào cam kết của nhà cung cấp bên thứ ba.

Khả năng kiểm soát hiệu suất và tránh giới hạn số lượt gọi (rate limit) cũng là yếu tố then chốt. Khi dùng API chung, bạn thường phải đối mặt với độ trễ biến động và các giới hạn nghiêm ngặt từ phía nhà cung cấp. Tự host cho phép bạn ưu tiên tài nguyên cho các tác vụ quan trọng, tối ưu hóa độ trễ liên token (ITL) cho các ứng dụng thời gian thực hoặc tăng tối đa thông lượng cho các tác vụ xử lý lô mà không bị ngắt quãng nửa chừng.

Trong các hệ thống RAG hoặc AI agent, hiện tượng tích lũy ngữ cảnh (context accumulation) diễn ra liên tục khiến lượng dữ liệu nhạy cảm được gửi đi tăng rất nhanh. Các cuộc hội thoại kéo dài hoặc việc nhúng hàng ngàn tài liệu nội bộ vào prompt tiềm ẩn rủi ro lộ lọt thông tin rất lớn nếu dùng API bên ngoài. Tự host giúp bạn giữ toàn bộ nội dung KV cache trong môi trường khép kín, đảm bảo dữ liệu không bao giờ bị lưu trữ ngoài ý muốn trên máy chủ của bên thứ ba.

Một hệ thống tự host gồm những lớp nào?

Một hệ thống suy luận LLM hiện đại có hai giai đoạn xử lý chính. Giai đoạn Prefill (đọc prompt) là lúc engine xử lý toàn bộ yêu cầu đầu vào một cách song song; giai đoạn này thường bị giới hạn bởi băng thông bộ nhớ (memory bandwidth). Giai đoạn Decode (sinh token) diễn ra tuần tự sau đó và bị giới hạn bởi năng lực tính toán thuần túy (TFLOPS) của GPU khi sinh từng token mới.

Bốn lớp của một hệ thống tự host: hạ tầng GPU, engine suy luận với scheduler và KV cache, lớp phục vụ API và AI Gateway, kèm hai giai đoạn Prefill và Decode

Lớp điều phối (Scheduler) là nơi tối ưu hiệu suất nhiều nhất, nhờ kỹ thuật Continuous Batching (đóng gói liên tục). Thay vì chờ cả lô yêu cầu hoàn thành, engine sẽ chèn thêm các yêu cầu mới vào lô đang xử lý ngay khi có vị trí trống trong bộ nhớ đệm. Phía trên engine là lớp Model Executor, nơi thực thi các phép toán ma trận, thường tận dụng CUDA Graph để giảm thiểu chi phí khởi chạy kernel và tối ưu hóa thời gian phản hồi cho người dùng.

Để vận hành ở quy mô doanh nghiệp, bạn cần thêm lớp cổng (AI Gateway) để quản lý định tuyến và an toàn dữ liệu. Lớp này kiểm tra PII trên cả đầu vào lẫn đầu ra, đồng thời ghi lại nhật ký phục vụ mục đích tuân thủ pháp lý. Cấu trúc một hệ thống tự host tiêu chuẩn được chia thành các lớp:

Hạ tầng GPU: nền tảng tính toán vật lý.
Engine suy luận: trái tim xử lý logic (vLLM, SGLang).
Lớp điều phối bộ nhớ (KV cache): quản lý tài nguyên paged memory.
Cổng thực thi chính sách: AI Gateway kiểm soát an toàn và nhật ký.

Cần bao nhiêu GPU và VRAM để phục vụ một mô hình?

Bạn cần tính toán dung lượng VRAM theo hai thành phần: tĩnh và động. Bộ nhớ tĩnh dành cho trọng số mô hình (weights) được tính bằng số tỷ tham số nhân với số byte mỗi tham số. Một mô hình 70 tỷ tham số (70B) chạy ở định dạng FP16 (2 byte/tham số) cần ít nhất 140GB VRAM để tải. Nếu bạn định lượng xuống INT4 (0.5 byte/tham số), nhu cầu này giảm xuống còn 35GB, cho phép chạy trên các GPU đơn lẻ có dung lượng thấp hơn.

Ngân sách VRAM của một mô hình 70B: bộ nhớ tĩnh cho trọng số ở các mức FP16, FP8 và INT4, cộng bộ nhớ động KV cache tăng theo ngữ cảnh và số người dùng, cộng phần overhead ẩn của hệ thống

Bộ nhớ động (KV cache) tăng trưởng theo chiều dài cửa sổ ngữ cảnh và số người dùng đồng thời. Với mô hình 70B, nếu phục vụ 10 người dùng với ngữ cảnh 32k mỗi người (tổng 320k token), bạn cần khoảng 112GB cho FP16 cache hoặc 56GB cho FP8 cache. Bạn cũng phải trừ đi khoảng "thuế" VRAM ẩn từ 4-5GB cho CUDA context và các buffer tạm thời của hệ thống. Nếu không tính toán kỹ phần này, hệ thống sẽ gặp lỗi tràn bộ nhớ (OOM) ngay khi tải tăng nhẹ.

Phần cứng thực tế quyết định khả năng mở rộng quy mô. Một chiếc NVIDIA L40S (48GB) phù hợp cho các mô hình nhỏ hoặc định lượng sâu, trong khi H100 (80GB) là tiêu chuẩn cho các tác vụ chuyên nghiệp. Lợi thế lớn nhất của H200 (141GB) không chỉ nằm ở dung lượng mà còn ở khả năng cung cấp token pool lớn gấp 30 lần so với các thiết bị như DGX Spark, giúp xử lý nhiều người dùng đồng thời hơn. Khi mô hình vượt quá dung lượng một GPU, bạn phải dùng Tensor Parallelism để phân tách trọng số qua nhiều GPU như cụm 4xH200 hoặc 8xB200.

Chọn engine nào: vLLM, SGLang hay Ollama?

Để phục vụ trong môi trường production với hàng chục người dùng đồng thời, vLLM là lựa chọn hàng đầu nhờ thuật toán PagedAttention giúp giảm lãng phí VRAM. Engine này hỗ trợ các kỹ thuật nâng cao như Chunked Prefill để xử lý prompt dài mà không làm nghẽn hệ thống, và Prefix Caching giúp tái sử dụng KV cache cho các prompt có phần đầu lặp lại, cực kỳ hiệu quả cho các hệ thống RAG thường xuyên truy vấn cùng một tập tài liệu.

So sánh ba engine suy luận: vLLM cho môi trường production nhiều người dùng đồng thời, SGLang cho mô hình thế hệ mới trên cụm lớn, và Ollama cho chạy thử trên máy cá nhân

SGLang là một đối thủ mạnh, đặc biệt hiệu quả khi phục vụ các mô hình thế hệ mới như GLM-5.2 trên các cụm máy chủ lớn. Trong khi đó, Ollama là công cụ rất tốt để chạy mô hình trên máy cá nhân hoặc thử nghiệm nhanh. Tuy nhiên, Ollama thiếu các khả năng tối ưu batching nâng cao và quản lý tài nguyên linh hoạt, khiến nó không phải là lựa chọn đúng khi bạn cần xây dựng một hệ thống phục vụ quy mô lớn cho doanh nghiệp.

Để tăng tốc độ phản hồi, bạn có thể áp dụng Speculative Decoding (giải mã suy đoán) như n-gram hoặc EAGLE. Kỹ thuật này dùng một mô hình nhỏ hoặc các đầu dự đoán phụ để đoán trước các token tiếp theo, giúp giảm số lần phải chạy mô hình lớn. Kỹ thuật này tăng tốc rõ rệt ở mức tải thấp nhưng có thể làm giảm hiệu suất khi hệ thống chạy ở mức đồng thời cao.

bash

# Chạy server vLLM với Tensor Parallelism qua 4 GPU
vllm serve model_name --tensor-parallel-size 4

Tự host có thật sự rẻ hơn gọi API không?

Tự host rẻ hay đắt hoàn toàn phụ thuộc vào ngưỡng sử dụng (utilization). Nếu bạn đầu tư một cụm 4xH200, hệ thống phải hoạt động liên tục với hiệu suất 89% (24/7 trong 5 năm) mới rẻ hơn việc gọi API của các mô hình giá rẻ như DeepSeek-V4-Flash. Ngược lại, với các mô hình frontier đắt đỏ, một rack 8xB200 chỉ cần hiệu suất 15% là đã đánh bại được chi phí API. Thuê GPU B200 theo giờ thậm chí đưa chi phí xuống khoảng 1,11 USD cho mỗi tác vụ hoàn thành, rẻ hơn hóa đơn API của các mô hình hàng đầu.

Điểm hòa vốn theo mức sử dụng: cụm 4xH200 phải chạy ở mức rất cao mới rẻ hơn API giá thấp, trong khi rack 8xB200 chỉ cần mức sử dụng thấp là đã rẻ hơn API frontier

Mức chi cho AI phân hóa cực lớn. Chi phí trung vị cho mỗi nhân viên chỉ khoảng 140 USD/năm, nhưng ở nhóm 90th percentile con số này tăng lên 7.300 USD/năm và ở nhóm 99th percentile chạm mức 90.000 USD/năm. Hiện tượng "token panic" thường xảy ra khi các đội ngũ triển khai coding agent, nơi có tới 98% token đầu vào được cache lại. Mức sử dụng GPU trung bình trong doanh nghiệp chỉ đạt 15-22%, nên phần lớn thời gian bạn vẫn trả tiền cho phần cứng đang nằm không.

Thuê GPU thì linh hoạt, nhưng bạn phải tính đến các chi phí ẩn như tiền điện, bảo trì và giờ công của kỹ sư vận hành. Khoản này thường lớn hơn hóa đơn GPU và gần như không bao giờ xuất hiện trong bảng tính ban đầu. Chỉ nên chọn tự host khi nhu cầu sử dụng đã đủ lớn để lấp đầy ít nhất 15-20% năng lực tính toán của phần cứng cao cấp như B200, hoặc khi yêu cầu pháp lý không cho phép dữ liệu rời khỏi hạ tầng của bạn.

Khi nào tự host là lựa chọn sai?

Bạn sẽ thất bại nếu nhu cầu sử dụng mang tính chất "nhọn" (spiky) — cực cao vào giờ hành chính nhưng gần như bằng không vào ban đêm. Vì GPU là tài sản khấu hao và vẫn tiêu thụ điện ngay cả khi không chạy, nếu hệ thống nhàn rỗi 80% thời gian, chi phí thực tế cho mỗi token sẽ cao hơn nhiều so với việc dùng API tính theo lượt.

Một sai lầm phổ biến khác là cố ép mô hình lớn vào phần cứng yếu bằng cách định lượng quá mức (như INT4). Điều này dẫn đến suy giảm chất lượng nghiêm trọng với các tác vụ yêu cầu suy luận logic phức tạp hoặc lập trình. Tốc độ cũng là một cái bẫy: Kimi K3 tự host chạy chậm hơn khoảng 8 lần so với Claude Code, còn GLM-5.2 trên cụm 8xB200 đã chậm hơn 3 lần ngay từ mức 8 phiên đồng thời. Phần cứng mạnh không tự động bù lại được khoảng cách đó.

Cuối cùng, thiếu kỹ năng quản lý hạ tầng sẽ dẫn đến lỗi tràn bộ nhớ khi lượng yêu cầu biến động ngẫu nhiên. Một mô hình 70B có thể nạp vừa VRAM lúc không tải, nhưng sập ngay khi mười người dùng cùng gửi prompt 32k. Nếu độ trễ liên token quá lớn khiến người dùng khó chịu, dự án tự host của bạn sẽ bị coi là thất bại về trải nghiệm, bất kể hóa đơn có đẹp đến đâu.

Nên bắt đầu từ đâu?

Đừng mua phần cứng ngay. Hãy bắt đầu bằng cách đo lường khối lượng công việc thực tế trên các API mã nguồn mở rẻ tiền để đánh giá chất lượng mô hình bạn thực sự cần và lượng token tiêu thụ thật. Việc này giúp bạn tránh đầu tư sai vào những dàn máy không khớp với nhu cầu.

Nếu bắt đầu thử nghiệm tại chỗ, một máy nhỏ như NVIDIA DGX Spark là lựa chọn hợp lý cho nhu cầu đơn lẻ trước khi tiến lên các cụm H200 hay B200. Tự host không phải cách tiết kiệm tiền nhanh nhất cho đội nhỏ, nhưng nó là lựa chọn đúng khi bạn cần kiểm soát quyền riêng tư và độ trễ ở mức mà không hóa đơn API nào mua được.