Tại sao AI chạy nội bộ không 'khôn' bằng bản chính thức? Thủ phạm là 734 gói phụ thuộc

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

29-08-2026 21:11:08 Nguồn: QbitAI

Chỉ cần những khác biệt nhỏ trong ngăn xếp phần mềm suy luận (inference software stack) cũng có thể làm thay đổi token đầu ra.

Meng Chen, đưa tin từ Aofeisi, QbitAI | Tài khoản chính thức QbitAI

Toang rồi! Tại sao mô hình lớn (LLM) mà mình vất vả triển khai cục bộ lại "ngu" hơn hẳn so với phiên bản chính thức vậy??

Ngay cả khi dùng cùng một card đồ họa, cùng một trọng số (weights) y hệt nhau, những khác biệt nhỏ trong ngăn xếp phần mềm suy luận vẫn khiến mô hình đưa ra các token hoàn toàn khác biệt ở những vị trí quan trọng, thậm chí dẫn đến việc gọi công cụ (tool calling) thất bại hoàn toàn.

Cái bẫy này rất dễ mắc phải nhưng lại cực kỳ khó kiểm tra, cứ ngỡ như người ngoài hành tinh Tam Thể đang dùng Trí Tử (Sophon) để phong tỏa vậy.

Người dùng thr3e trên diễn đàn Level1Techs đã thực hiện một loạt thí nghiệm, sử dụng Qwen3.6-27B trên card đồ họa RTX PRO 6000 Blackwell để hoàn thành bài kiểm tra thu thập toàn bộ logit với hơn 100.000 token.

Logits là tập hợp các điểm số thô được tính toán cho tất cả các token ứng viên, sau đó đi qua bộ lấy mẫu (sampler) để xuất ra token tiếp theo.

Điểm mấu chốt nằm ở chỗ Logits là sản phẩm thuần túy của toán học, là kết quả số thực dấu phẩy động sau khi chồng lớp các phép nhân ma trận, tính toán cơ chế chú ý (attention) và hàm kích hoạt. Nếu hai hệ thống chạy cùng một bộ trọng số và cùng một đoạn đầu vào, về lý thuyết chúng phải tính ra các logits hoàn toàn giống hệt nhau.

Nhưng trong thực tế, độ chính xác của phép tính dấu phẩy động, thứ tự cộng dồn và sự khác biệt trong tập lệnh phần cứng đều sẽ khiến giá trị cuối cùng tạo ra những sai lệch nhỏ.

Khi sai lệch này đủ lớn để thay đổi token có xác suất cao nhất, mô hình sẽ biểu hiện ra sự khác biệt.

Mặc dù việc triển khai cục bộ của bạn rất tệ, nhưng đừng buồn, những người khác triển khai cũng có những kiểu "tệ" khác nhau.

Trọng số không đổi, chỉ cần đổi backend chú ý là mô hình trở nên "ngớ ngẩn"

Một điểm mấu chốt nằm ở khâu "backend chú ý" (attention backend) trong quy trình suy luận.

vLLM cung cấp ba backend chú ý toàn phần (full attention) tùy chọn cho Qwen3.6-27B: FlashAttention 2, Flash Inference và Triton Attention.

Ngoài việc thay đổi cấu hình này, tất cả các yếu tố khác như phần cứng, phần mềm, trọng số và độ chính xác của KV cache đều được giữ nguyên.

Dữ liệu đầu vào được sử dụng trong thí nghiệm là một kịch bản công việc thực tế dài khoảng 100.000 token, đến từ một quy trình làm việc của Agent bao gồm nhiều lần gọi công cụ.

thr3e nhấn mạnh rằng dữ liệu này không xuất hiện trong bất kỳ bộ benchmark công khai hay tập huấn luyện nào, không ai có thể tối ưu hóa benchmark hay hiệu chuẩn lượng tử hóa (quantization calibration) cho nó.

Phương pháp kiểm tra là lấy mẫu logit toàn bộ từ vựng sau mỗi 32 token, sau đó sử dụng độ chính xác FP64 để tính toán phân kỳ KL (KL divergence) và độ nhất quán Top-1.

Kết quả quan sát được hiện tượng "đảo ngược Top-1", nghĩa là chỉ cần chuyển đổi backend sẽ chọn ra token giải mã tham lam (greedy decoding token) khác với đường cơ sở (baseline).

Ví dụ, theo dõi một trường hợp lỗi cụ thể, mô hình thực hiện một lệnh gọi công cụ, mục tiêu là một giao diện GigabitEthernet0/0/1.201 trên bộ định tuyến Cisco.

FlashAttention 2 đã làm sai, khiến giao diện biến thành GigabitEthernet0/1/4, sau đó mô hình tiếp tục thực hiện các lệnh sai trong hai lần gọi công cụ tiếp theo.

Để duy trì khả năng so sánh toán học, tất cả các backend đều chia sẻ cùng một lịch sử token bắt buộc, việc đảo ngược chỉ ghi lại những trường hợp "đáng lẽ đã chọn sai", không để lỗi lan truyền.

Kết quả là trong vài nghìn token đầu tiên, đầu ra của ba backend hoàn toàn nhất quán. Nhưng khi ngữ cảnh tăng lên, sự khác biệt bắt đầu xuất hiện và phân bổ không đồng đều.

thr3e cũng thực hiện đối chứng lặp lại trên cùng một backend, chỉ cần thay đổi một mục cấu hình của vLLM, trên cùng một GPU, cùng một hệ điều hành và trình điều khiển, cùng một bộ trọng số, cùng một đoạn prompt, thì logit của mỗi trạng thái ẩn (hidden state) giữa các lần chạy đều giống hệt nhau đến từng bit.

Điều này có nghĩa là sự khác biệt quan sát được hoàn toàn đến từ sự khác biệt về giá trị khi các nhân CUDA khác nhau thực hiện phép nhân ma trận và cộng dồn trong giai đoạn prefill.

Lượng tử hóa KV cache dẫn đến chỉ số thông minh sụt giảm nghiêm trọng

Các thí nghiệm tiếp theo được thiết lập để giữ nguyên trọng số ở mức BF16, backend chú ý cố định là Triton, chỉ thay đổi độ chính xác lượng tử hóa của KV cache, lần lượt kiểm tra ba cấu hình: BF16, INT8 và INT4.

Kết quả là tỷ lệ đảo ngược Top-1 của KV cache INT4 tăng vọt trong ngữ cảnh dài, cuối cùng dẫn đến việc gọi công cụ không thể phục hồi. Mặc dù KV cache INT8 cũng xuất hiện đảo ngược, nhưng mô hình cuối cùng đã xoay xở để quay lại đúng quỹ đạo. Chỉ có KV cache BF16 là duy trì sự ổn định trong suốt quá trình.

thr3e để cho quá trình tạo văn bản sau khi đảo ngược chạy tự do thay vì kéo về đường cơ sở để quan sát hậu quả thực tế.

BF16 hoàn thành bình thường tất cả các lệnh gọi, INT8 sau khi lỗi đã "vật lộn để phục hồi", trong khi INT4 thì chệch hướng hoàn toàn, việc gọi công cụ thất bại và không thể tự sửa lỗi.

Vấn đề này đặc biệt gây khó khăn cho những người dùng cục bộ muốn tiết kiệm VRAM nên đã nén KV cache xuống INT4.

Trong ngữ cảnh ngắn, bạn có thể không cảm nhận được sự khác biệt, nhưng một khi cuộc hội thoại hoặc quy trình làm việc của agent kéo dài đến hàng chục nghìn token, sự trôi dạt giá trị tích lũy là đủ để khiến mô hình đưa ra những quyết định sai lầm chết người.