Vì sao LLM chạy local của bạn có vẻ "ngu" hơn thực tế?

Bạn đã bao giờ tải về một mô hình AI được cộng đồng khen ngợi hết lời, nhưng khi tự chạy thử thì lại thất vọng vì chất lượng quá tệ? Theo một bài phân tích kỹ thuật cực kỳ chi tiết từ diễn đàn Level1Techs, nguyên nhân không hẳn nằm ở mô hình, mà đến từ cách bạn triển khai và chạy nó trên phần cứng của mình. Sự khác biệt trong kernel CUDA, bộ nhớ đệm (KV cache) và các phương pháp lượng tử hóa có thể tạo ra những lỗi sai "chết người" trong các tác vụ phức tạp như gọi công cụ (tool calling).

Sự khác biệt không ngờ từ phần mềm và phần cứng

Khi chạy một mô hình ngôn ngữ lớn (LLM) trên hệ thống local, bạn có thể sử dụng GPU khác, driver khác, và một bộ phần mềm (inference engine) khác với phòng thí nghiệm gốc. Tác giả bài viết nhấn mạnh rằng mỗi lần tính toán để tạo ra một token (đơn vị văn bản) là khác nhau giữa các hệ thống, ngay cả khi sử dụng cùng một bộ trọng số (weights).

Để chứng minh, tác giả đã thực hiện một thí nghiệm trên GPU RTX PRO 6000 Blackwell với mô hình Qwen3.6-27B (dense model). Họ so sánh ba backend attention khác nhau trong vLLM: FlashAttention 2, Flash Inference và Triton Attention trong khi mọi thành phần khác được giữ nguyên.

Kết quả: Trong vài nghìn token đầu tiên, tất cả các backend đều đồng ý về token tiếp theo. Nhưng ở phần sau của prompt dài khoảng 100k token, sự khác biệt bắt đầu xuất hiện. Đáng chú ý, các lỗi này xuất hiện thành cụm, không tăng dần theo chiều dài ngữ cảnh, cho thấy chúng phụ thuộc vào nội dung cụ thể của prompt.

Lượng tử hóa (Quantization) — Kẻ phá hoại thầm lặng

Thí nghiệm tiếp theo tập trung vào việc lượng tử hóa KV cache. Khi chuyển từ BF16 sang INT8, mô hình vẫn hoạt động ổn. Nhưng với INT4, mô hình bắt đầu gọi sai lệnh, dẫn đến các lỗi lớn trong tác vụ mô phỏng thực tế. Điều này cho thấy việc "cắt giảm" độ chính xác để tiết kiệm bộ nhớ có thể phá vỡ các quyết định nhạy cảm của mô hình.

So sánh các phương pháp lượng tử hóa

Trong cuộc so tài giữa TheDude (W8A16), FP8 (W8A8) và NVFP4 của Nvidia, kết quả thật bất ngờ: NVFP4, dù được Nvidia quảng bá, lại tệ nhất với khoảng 50% số token bị đảo ngược ở ngữ cảnh 88k. Cả NVFP4 và AWQ W4A16 đều không thể thực hiện đúng lệnh show arp thay vì show run trong bài kiểm tra cấu hình Cisco.

Hậu quả thực tế và những cái bẫy tiềm ẩn

Sự khác biệt này không chỉ là lý thuyết suông. Khi tác giả cho phép mô hình chạy tự do (forking) sau một token flip, họ thấy rằng FlashAttention 2 có thể thực thi lệnh trên interface GigabitEthernet0/1/4 thay vì GigabitEthernet0/0/1.201 như yêu cầu. Trong môi trường sản xuất thực tế, một lỗi như vậy có thể gây ra sự cố mạng nghiêm trọng.

Không chỉ dừng lại ở đó, thí nghiệm so sánh giữa cấu hình Tensor Parallelism (TP) cũng cho thấy: TP1 thì gọi lệnh đúng, TP2 thì sai, còn TP4 lại đúng. Sự bất nhất này thường do NVIDIA Collective Communications Library (NCCL) gây ra, một tầng giao tiếp dùng cho đa GPU.

Kết luận cho người dùng cuối

Bài viết nhấn mạnh rằng việc đo lường chất lượng mô hình chỉ qua một vài prompt mẫu là không đủ. Để đánh giá đúng, bạn cần kiểm thử trên các tác vụ đại diện, với các bộ dữ liệu có cấu trúc, và kiểm soát chặt chẽ toàn bộ môi trường. Nếu không, cảm giác "model này dở" của bạn có thể chỉ là sự khác biệt trong cách kernel CUDA thực hiện phép nhân ma trận.

"Sự khác biệt về runtime có thể dẫn đến lệnh gọi công cụ sai. Nếu điều này xảy ra trong sản xuất, nó có thể gây ra sự cố mạng nghiêm trọng."

Đối với người dùng Việt Nam đang chạy AI local, hãy lưu ý:

• Luôn sử dụng đúng sampler settings được công bố trên model card (thường là temp 1.0, top-p 0.95).
• Tránh đặt nhiệt độ quá thấp vì có thể khiến mô hình như Qwen bị kẹt trong vòng lặp suy nghĩ.
• Kiểm tra kỹ phương pháp lượng tử hóa. Ưu tiên FP8 hoặc INT8 để giữ được độ chính xác. Tránh NVFP4 trong các tác vụ nhạy cảm.
• Chạy benchmark với khối lượng công việc thực tế thay vì một vài prompt mẫu, đặc biệt là các bài kiểm tra gọi công cụ và xử lý ngữ cảnh dài.

Quy trình và công cụ thử nghiệm

Hãy nhớ: một mô hình giỏi không chỉ cần trọng số tốt, mà còn cần một môi trường chạy "trung thực" để phát huy hết tiềm năng của nó. Trước khi kết luận một LLM local "ngu ngốc", hãy xem lại chính hệ thống của bạn.