Quantization, inference và chi phí GPU khi triển khai LLM

01/10/2026

Model chạy ngon trên máy của kỹ sư, rồi đem lên môi trường thật thì chậm như rùa và hóa đơn GPU cuối tháng làm cả phòng tài chính nhăn mặt. Kịch bản này lặp lại ở rất nhiều đội làm LLM tiếng Việt mà tôi biết. Gốc rễ thường là ba khái niệm mà ít người giải thích tử tế: quantization, inference và cách GPU được tính tiền. Tôi sẽ cố nói chúng bằng ngôn ngữ của người không làm kỹ thuật sâu.

Inference là gì và vì sao nó mới là khoản tiền dài hạn

Huấn luyện là lúc model học. Inference là lúc model làm việc: nhận câu hỏi, sinh câu trả lời. Huấn luyện tốn kém nhưng diễn ra một lần, hoặc vài lần. Inference diễn ra mỗi khi có người dùng, hằng ngày, hằng giờ. Với sản phẩm có người dùng thật, tổng chi phí inference thường vượt xa chi phí huấn luyện sau một thời gian đủ dài.

Một điểm hay bị hiểu sai: model sinh chữ lần lượt, từng token một. Mỗi token mới phải đọc lại gần như toàn bộ trọng số model từ bộ nhớ GPU. Vì vậy tốc độ phản hồi bị chặn bởi băng thông bộ nhớ nhiều hơn là bởi sức tính toán thuần. Hiểu điều này sẽ giúp bạn hiểu vì sao việc thu nhỏ model lại giúp chạy nhanh hơn.

Quantization: nén model như nén ảnh

Trọng số của model là hàng tỷ con số. Mặc định mỗi số được lưu với độ chính xác cao, chiếm 16 bit. Quantization là lưu những con số đó bằng ít bit hơn, thường là 8 bit hoặc 4 bit. Giống như nén một bức ảnh: file nhỏ đi nhiều, nhìn bằng mắt thường vẫn gần như cũ, nhưng nếu soi kỹ sẽ thấy vài chi tiết nhòe.

Lợi ích rất thực tế. Model chiếm ít bộ nhớ hơn, nên có thể nhét vào GPU rẻ hơn hoặc ít GPU hơn. Việc đọc trọng số nhanh hơn, nên tốc độ sinh chữ thường tăng. Cái giá là chất lượng có thể giảm, và mức giảm phụ thuộc vào model, phương pháp nén và loại tác vụ. Với tác vụ trả lời đơn giản, sự khác biệt đôi khi không đáng kể. Với suy luận nhiều bước, tính toán, hay văn bản chuyên ngành có thuật ngữ hiếm, tôi thấy chất lượng dễ bị ảnh hưởng hơn.

Không có con số thần kỳ nào cho mọi trường hợp. Cách duy nhất đáng tin là chạy bản nén trên bộ câu hỏi thật của bạn và so với bản gốc. Với tiếng Việt, hãy kiểm tra riêng những câu có dấu phức tạp, tên riêng, số liệu, vì lỗi thường lộ ra ở những chỗ đó.

Chi phí GPU được hình thành thế nào

Bỏ qua chi tiết, chi phí chạy một dịch vụ LLM gồm vài phần:

• Phần cứng: mua hoặc thuê GPU. Dung lượng bộ nhớ quyết định model nào chạy vừa.
• Thời gian chạy: GPU thuê theo giờ thì bật cả ngày vẫn tính tiền, dù chỉ có vài người hỏi lúc nửa đêm.
• Hiệu suất sử dụng: một GPU chạy 10% công suất thì phần 90% còn lại là tiền cháy.
• Nhân sự: người theo dõi, tối ưu, xử lý sự cố, thường bị quên khi tính ngân sách.

Câu hỏi thường bị bỏ sót là: dịch vụ của bạn có bao nhiêu người dùng cùng lúc, vào giờ cao điểm? Một hệ thống nội bộ cho hai trăm nhân viên có đỉnh tải rất khác một ứng dụng hướng tới khách hàng đại chúng. Thiết kế theo đỉnh thì lãng phí lúc thấp điểm. Thiết kế theo mức trung bình thì nghẽn lúc đông.

Những đòn bẩy để giảm chi phí

Theo kinh nghiệm của tôi, thứ tự cân nhắc thường như sau, từ rẻ và ít rủi ro đến tốn công hơn:

• Chọn model vừa đủ. Một model nhỏ đã finetune cho đúng tác vụ có thể làm tốt hơn một model lớn tổng quát, và rẻ hơn nhiều.
• Quantization. Giảm bộ nhớ và tăng tốc, nhưng phải đo chất lượng.
• Gom yêu cầu (batching). Xử lý nhiều câu hỏi cùng lúc để GPU không ngồi chơi. Đổi lại, mỗi người có thể chờ lâu hơn một chút.
• Bộ nhớ đệm (caching). Nếu nhiều người hỏi cùng một thứ, hoặc cùng một đoạn hướng dẫn mở đầu, đừng tính lại từ đầu.
• Giới hạn độ dài. Prompt và câu trả lời dài tốn tiền theo từng token. Nhiều hệ thống nhét cả một trang hướng dẫn vào mỗi lần gọi mà không ai nhớ ra.

Một câu chuyện về speech to text

Chuyện chi phí còn rõ hơn ở bài toán giọng nói. Một tổng đài có hàng nghìn cuộc gọi mỗi ngày cần chuyển thành văn bản. Nếu cần kết quả ngay khi đang gọi, bạn phải chạy streaming, chấp nhận GPU luôn bật. Nếu chỉ cần bản ghi sau cuộc gọi để kiểm tra chất lượng, bạn có thể gom lại chạy theo lô vào ban đêm, rẻ hơn nhiều. Cùng một model speech to text tiếng Việt, hai yêu cầu nghiệp vụ khác nhau cho ra hai hóa đơn khác nhau. Hãy hỏi nghiệp vụ thật sự cần nhanh đến mức nào trước khi mua phần cứng.

Đo cái gì trước khi quyết định

• Thời gian đến token đầu tiên, tức người dùng chờ bao lâu mới thấy chữ đầu.
• Tốc độ sinh chữ khi đang chạy.
• Số yêu cầu đồng thời hệ thống chịu được trước khi chậm.
• Chi phí trên một nghìn yêu cầu, tính theo đúng lưu lượng thật của bạn.
• Chất lượng trên bộ kiểm thử của riêng bạn, sau mỗi lần nén hoặc đổi cấu hình.

AIVISION là đơn vị AI tại Việt Nam, huấn luyện LLM trên cụm 24x NVIDIA H200 và 8x NVIDIA B300, đã phát hành model speech-to-text E1.0 và LLM L1.0 cho tiếng Việt. Chúng tôi chú ý đến chuyện triển khai vì một model hay mà không chạy nổi trong ngân sách của khách thì chưa giải quyết được gì. Bạn có thể xem thêm tại AIVISION.

Một thói quen tôi muốn đội nào cũng có: ghi lại chi phí trên mỗi yêu cầu ngay từ bản thử nghiệm đầu tiên. Con số đó ban đầu trông vô hại, nhưng nó sẽ cho bạn biết sản phẩm có sống nổi khi lượng người dùng tăng gấp mười hay không. Biết sớm vẫn tốt hơn biết khi hóa đơn đã đến.