LLM 101: Hướng dẫn thực tế (Phiên bản 2026)

Bắt đầu với vòng lặp. Văn bản trở thành token. Token di chuyển qua Transformer. Attention quyết định token trước đó nào quan trọng. Runtime duy trì KV cache để mô hình không tính toán lại toàn bộ cuộc trò chuyện mỗi lần. Sau đó, mô hình chọn token tiếp theo và lặp lại.

Một hướng dẫn thực tế về cách LLM hoạt động, cách các mô hình suy nghĩ từng token một và cách chạy chúng cục bộ.

Khi vòng lặp đó đã rõ, các lựa chọn phần cứng và phần mềm trở nên dễ suy luận hơn. VRAM, lượng tử hóa, độ dài ngữ cảnh, mẫu chat, giải mã, RAG, engine phục vụ và lựa chọn mô hình đều xuất phát từ cùng một cơ chế.

Bắt đầu với vòng lặp: Token đầu vào, xác suất đầu ra, từng token một. Trọng số cho mô hình biết các mẫu mà nó đã học. Ngữ cảnh cho nó biết nó đang nhìn vào gì ngay bây giờ. KV cache là bộ nhớ làm việc giúp vòng lặp khả thi. Phần cứng, runtime và lựa chọn mô hình chỉ có ý nghĩa khi bạn hiểu bộ nhớ, ngữ cảnh và quy tắc định dạng mà mô hình đang tuân theo.

Mục tiêu là làm cho cơ chế LLM cục bộ trở nên trực quan trước, sau đó cung cấp cho bạn một lộ trình thực tế về phần cứng, runtime, phục vụ và nghiên cứu LLM hiện tại tính đến ngày 21 tháng 5 năm 2026.

Trọng tâm

Đây là hướng dẫn tập trung vào mô hình trước tiên. Nó bắt đầu với cơ chế: suy luận, token, Transformer, attention, KV cache, prefill, decode, kiểm soát giải mã, gói mô hình, mẫu chat, loại mô hình, ngữ cảnh dài, RAG, agent, tinh chỉnh và mô hình đa phương thức.

Sau đó, nó chuyển sang lớp triển khai cục bộ: cục bộ thực sự có nghĩa là gì, lượng tử hóa, toán VRAM, cấp phần cứng, lựa chọn runtime, chế độ phục vụ, giấy phép, lựa chọn mô hình, quyền riêng tư, khắc phục sự cố, điểm chuẩn, đường dẫn thiết lập và các trường hợp sử dụng thực tế.

Thứ tự đó quan trọng. Bạn nên hiểu tại sao một prompt dài lại tốn bộ nhớ trước khi chọn GPU. Bạn nên hiểu tại sao mẫu chat lại quan trọng trước khi đánh giá một mô hình. Bạn nên hiểu tại sao decode là tuần tự trước khi quan tâm đến token mỗi giây.

Đối với đường dẫn phần cứng và phần mềm sâu hơn, tôi có một loạt ba phần dạy về LLM tự lưu trữ / AI cục bộ:

Hai phần đầu tiên giải thích về dung lượng phần cứng và toán băng thông. Phần thứ ba giải thích về lớp phần mềm biến phần cứng đó thành suy luận có thể sử dụng. Bài viết này cung cấp nền tảng về mô hình trước, sau đó chỉ lại các lớp triển khai đó khi cơ chế đã rõ.

LLM thực sự làm gì

Chạy một mô hình được gọi là suy luận. Đối với LLM chỉ có bộ giải mã tiêu chuẩn, suy luận là cùng một vòng lặp lặp đi lặp lại:

Chuyển văn bản của bạn thành token.
Đưa các token đó vào mô hình.
Tính điểm cho mọi token tiếp theo có thể.
Chọn một token bằng chính sách giải mã.
Thêm token đó vào chuỗi.
Lặp lại cho đến khi mô hình dừng, người dùng dừng hoặc đạt đến giới hạn token.

Mô hình không viết toàn bộ câu trả lời trong một lần. Nó đang tạo từng token một. Mỗi token mới trở thành một phần của chuỗi ảnh hưởng đến token tiếp theo.

Về mặt toán học, mô hình là một hàm đã học:

f(theta, sequence) -> phân phối xác suất trên next_token

Trong đó:

theta có nghĩa là trọng số của mô hình.
sequence có nghĩa là prompt cộng với các token đã tạo cho đến nay.
Logits là điểm thô trước softmax.
Probabilities là điểm đã chuẩn hóa sau softmax.
Decoding biến những xác suất đó thành một token được chọn.

Đây là lý do tại sao tốc độ tạo cục bộ được đo bằng token mỗi giây. Hệ thống của bạn liên tục chạy một forward pass, chọn hoặc lấy mẫu một token, cập nhật KV cache và tiếp tục.

Nhận thức rất quan trọng ở đây. Prefill dài có nghĩa là một khoảng dừng dài trước khi từ đầu tiên xuất hiện. Decode chậm có nghĩa là câu trả lời chảy chậm. Những người xây dựng cục bộ thường bận tâm về tốc độ decode vì đó là thứ người dùng cảm nhận được, nhưng thời gian prefill là thứ gây khó chịu khi bạn dán một tài liệu 10K token.

Token

LLM không xem văn bản thô là từ. Chúng xem token: Các đoạn văn bản nhỏ được biểu diễn nội bộ dưới dạng ID số nguyên.

Một token có thể là:

Một từ hoàn chỉnh: "hello"
Một phần từ: "inter", "national", "ization"
Một dấu câu
Một chuỗi có tiền tố khoảng trắng
Một dự phòng cấp byte
Một dấu hiệu điều khiển đặc biệt như <|user|>, <|assistant|>, hoặc

Tokenizer ánh xạ văn bản thành ID token và ID token trở lại văn bản. Các họ tokenizer phổ biến bao gồm tokenizer kiểu BPE và tokenizer kiểu SentencePiece. Các họ mô hình khác nhau sử dụng tokenizer khác nhau và điều đó rất quan trọng. Một tài liệu 4.000 từ có thể là 5.000 token trong một tokenizer và 7.500 token trong một tokenizer khác.

Kích thước từ vựng cũng quan trọng. Một tokenizer có từ vựng lớn hơn có thể nén một số văn bản thành ít token hơn, nhưng nó cũng thay đổi kích thước embedding và output-projection. Đây là một lý do tại sao token mỗi giây không thể so sánh hoàn hảo giữa các họ mô hình.

Token quan trọng vì chúng quyết định:

Bao nhiêu văn bản vừa trong cửa sổ ngữ cảnh.
KV cache sẽ lớn như thế nào.
Bạn phải trả bao nhiêu độ trễ trong quá trình xử lý prompt.
Liệu văn bản đa ngôn ngữ hoặc mã có hiệu quả hay không.
Liệu mô hình có nhìn thấy các dấu hiệu chat đặc biệt một cách chính xác hay không.

Cửa sổ ngữ cảnh của một mô hình là số token tối đa mà nó có thể chú ý cùng một lúc. Vào năm 2026, các mô hình có khả năng cục bộ phổ biến dao động từ 8K và 32K ngữ cảnh đến 128K, 256K và thậm chí 1M token ngữ cảnh trong các hệ thống cấp máy chủ.

Nhưng độ dài ngữ cảnh được hỗ trợ không giống với ngữ cảnh rẻ, nhanh hoặc chính xác như nhau. Một mô hình về mặt kỹ thuật có thể xử lý 128K token có thể chậm như rùa ở 64K và mất mạch lạc ở 100K. Luôn kiểm tra độ dài ngữ cảnh mà bạn thực sự định sử dụng.

Token là đơn vị công việc. Một khi bạn hiểu điều đó, ngữ cảnh dài không còn trông thần kỳ nữa mà bắt đầu trông giống như một hóa đơn bạn có thể ước tính.

Bài tập hữu ích: Hãy thử ứng dụng demo Tokenizer của tôi để xem văn bản được chia thành token trong thời gian thực.

Transformers

Hầu hết các LLM hiện đại đều dựa trên kiến trúc Transformer. Hầu hết các LLM chat cục bộ là Transformer chỉ có bộ giải mã: Chúng dự đoán token tiếp theo trong khi nhìn lại các token trước đó.

Mọi thứ ở trên điểm này, bao gồm token, trọng số, cấu hình và mẫu chat, đều là thiết lập cho engine thực sự bên dưới. Transformer là bộ xương di chuyển các con số.

Một lớp Transformer đơn giản hóa chứa:

Token embeddings: ID token trở thành vector.
Thông tin vị trí: Mô hình cần thứ tự token. Nhiều LLM hiện đại sử dụng RoPE (Rotary Position Embeddings), mã hóa vị trí bằng cách xoay các biểu diễn.
Self-attention: Mỗi biểu diễn token nhìn lại các biểu diễn token trước đó và quyết định điều gì quan trọng.
Khối MLP / feed-forward: Một tính toán phi tuyến dày đặc mở rộng và nén các biểu diễn. Một phần lớn các tham số sống ở đây.
Layer normalization và residual connections: Chúng ổn định các mạng sâu và giúp thông tin chảy qua nhiều lớp.
Output projection: Trạng thái ẩn cuối cùng trở thành logit trên toàn bộ từ vựng.

Xếp chồng công thức này hàng chục hoặc hàng trăm lần và bạn có một mô hình ngôn ngữ.

Tóm tắt Transformer: Token trở thành vector, attention kết nối chuỗi, MLP định hình lại biểu diễn, RoPE giữ vị trí thẳng hàng và phép chiếu cuối cùng biến trạng thái ẩn cuối cùng thành logit token tiếp theo.

Attention

Attention là cách một token quyết định token trước đó nào quan trọng cho dự đoán tiếp theo. Nó cũng là một trong những lý do tại sao suy luận cục bộ lại nhạy cảm với bộ nhớ.

MHA (multi-head attention) cổ điển lưu trữ trạng thái key/value riêng biệt cho nhiều head. Nó mang lại sự linh hoạt cho mô hình, nhưng làm cho KV cache lớn.

Các mô hình cục bộ hiện đại thường sử dụng các thiết kế attention hiệu quả hơn:

MQA: Nhiều query head chia sẻ một key/value head. Nó tiết kiệm bộ nhớ, nhưng có thể kém biểu cảm.
GQA: Các nhóm query head chia sẻ key/value head. Đây là điểm trung gian phổ biến trong nhiều mô hình cục bộ hiện tại.
MHA: Full multi-head attention. Nó có thể mạnh mẽ, nhưng ngữ cảnh dài trở nên đắt đỏ nhanh chóng.

Các kernel hiện đại như FlashAttention và các triển khai kiểu SDPA giảm lưu lượng bộ nhớ attention và giữ cho GPU bận rộn hơn. Một runtime có kernel attention tốt có thể nhanh hơn đáng kể so với runtime không có, ngay cả trên cùng một mô hình và phần cứng.

Đây là lý do tại sao hai mô hình 7B có thể hoạt động rất khác nhau ở ngữ cảnh dài. Số lượng tham số không phải là toàn bộ câu chuyện. Một mô hình 7B MHA ở ngữ cảnh 128K có thể làm cạn kiệt GPU 24 GB, trong khi mô hình 7B GQA với cùng ngữ cảnh quảng cáo có thể vừa vặn với dư địa.

Khi so sánh các mô hình, hãy xem xét loại attention, số lượng KV head, độ dài ngữ cảnh và hỗ trợ runtime, không chỉ số lượng tham số.

KV Cache

KV cache là bộ nhớ làm việc của mô hình trong quá trình tạo. Nó lưu trữ trạng thái attention key/value cho các token trước đó để mô hình không phải tính toán lại toàn bộ lịch sử từ đầu cho mỗi token được tạo.

Nếu không có KV cache, việc tạo sẽ cực kỳ kém hiệu quả. Với KV cache, việc tạo có thể sử dụng được, nhưng cache tiêu thụ bộ nhớ tỷ lệ thuận với:

tokens x layers x kv_heads x head_dim x precision x 2

x 2 là cho keys và values.

Một quy tắc ngón tay cái hữu ích cho các mô hình 7B MHA kiểu Llama cũ hơn là khoảng 0,5 MiB mỗi token trong KV cache FP16. Điều đó có nghĩa là 4K token có thể tốn khoảng 2 GiB chỉ riêng cho KV cache. Ở 32K token, bạn có thể đang nhìn vào 16 GiB KV cache một mình.

Các mô hình GQA/MQA mới hơn giảm đáng kể điều này. Một số runtime cũng hỗ trợ KV cache FP8 hoặc INT8. Đó thường là sàn nén thực tế mà tôi khuyên dùng cho người dùng cục bộ vào năm 2026.

Đừng coi KV cache dưới 8-bit là mặc định. Các hệ thống nghiên cứu như KIVI, KVQuant và các kernel cache nén mới hơn cho thấy KV 2-bit đến 4-bit có thể hoạt động với các thuật toán cẩn thận, hiệu chuẩn và kernel tùy chỉnh. Điều đó không giống như việc bật một cách tình cờ một nút bật Q4 KV trong một runtime desktop. Dưới 8-bit, hãy đánh giá điểm chuẩn một cách kỹ lưỡng, đặc biệt là cho việc viết mã, gọi công cụ, JSON, truy xuất ngữ cảnh dài và các tác vụ mà các token trước đó chính xác rất quan trọng.

Cũng đừng nhầm lẫn lượng tử hóa KV cache với giải mã suy đoán. DFlash và DDTree, thường được rút gọn không chính thức thành DTree, tấn công độ trễ giải mã bằng cách dự thảo các token tương lai và xác minh chúng. Chúng có thể cải thiện tốc độ, nhưng chúng không xóa bỏ hóa đơn bộ nhớ KV cache.

Đây là lý do tại sao một mô hình có thể vừa vặn với một prompt trống nhưng bị sập khi bạn tải một tài liệu dài. Trọng số vừa vặn. Bộ nhớ làm việc thì không.

Prefill Và Decode

Suy luận LLM có hai chế độ hiệu suất khác nhau: prefill và decode.

Prefill xử lý prompt bạn đã đưa cho mô hình. Nếu bạn dán một tài liệu 20.000 token, mô hình phải xử lý 20.000 token đó trước khi nó có thể tạo ra token câu trả lời đầu tiên. Prefill tương đối song song, vì vậy GPU có thể xử lý nó hiệu quả, nhưng nó vẫn có thể đắt đỏ.

Thời gian bạn chờ đợi token đầu tiên xuất hiện thường là thời gian prefill.

Decode tạo các token mới từng cái một. Mỗi token được tạo phụ thuộc vào chuỗi cho đến nay, vì vậy decode có tính tuần tự hơn nhiều. Đây là nơi hiệu ứng gõ phím trực tuyến đến từ, và nó thường là giai đoạn quyết định liệu một mô hình có cảm giác nhanh hay chậm.

Prompt dài trừng phạt prefill. Câu trả lời dài trừng phạt decode. Cuộc trò chuyện dài trừng phạt cả hai vì KV cache phát triển.

Trong một phiên chat, mỗi lượt thêm vào cache. Nếu bạn để một cuộc trò chuyện chạy đến 16K token, bạn đang trả chi phí bộ nhớ cho tất cả 16K token trên mỗi token mới được tạo. Đây là lý do tại sao các giao diện chat giữ lịch sử vô hạn cuối cùng bị chậm hoặc sập.

Decoding

Sau khi mô hình tạo ra logits, nó chưa viết gì cả. Nó chỉ tính điểm cho mọi token tiếp theo có thể. Decoding là chính sách biến những điểm đó thành một token thực tế, thêm token đó vào ngữ cảnh và lặp lại vòng lặp.

Runtime, hay inference engine, có thể chọn token theo nhiều cách. Nó có thể chọn token có xác suất cao nhất mỗi lần. Nó có thể lấy mẫu từ một tập hợp thu hẹp các token có khả năng. Nó có thể phạt lặp lại. Nó có thể dừng ở một dấu phân cách. Nó có thể sử dụng một seed cố định để cùng một prompt hoạt động có thể tái tạo.

Những lựa chọn này không thay đổi trọng số mô hình, nhưng chúng thay đổi giọng nói, tính xác định, sự sáng tạo, hồ sơ rủi ro và xu hướng lặp lại của mô hình.

Các núm vặn quan trọng trả lời ba câu hỏi thực tế:

Tính ngẫu nhiên: Bao nhiêu biến thể được cho phép?
Phạm vi đuôi: Sampler có thể đi bao xa vào các token có xác suất thấp hơn?
Ranh giới: Điều gì ngăn chặn các vòng lặp, lan man, vi phạm lược đồ hoặc đầu ra chạy trốn?

Đối với công việc chính xác, hãy bắt đầu hẹp: nhiệt độ thấp, giới hạn max-token ngắn, chuỗi dừng rõ ràng và giải mã bị ràng buộc khi đầu ra phải khớp với JSON hoặc một lược đồ. Đối với công việc sáng tạo, hãy cho sampler nhiều không gian hơn với nhiệt độ cao hơn, top-p và nhiều ứng viên được xếp hạng sau đó. Đối với viết mã, giữ cho lượt đầu tiên bảo thủ, sau đó lấy mẫu các lựa chọn thay thế chỉ khi bạn đang cố ý khám phá.

Giải mã tham lam không phải lúc nào cũng chính xác hơn. Nó thường dễ vỡ. Một bộ giải mã tham lam có thể bị mắc kẹt trong các vòng lặp hoặc tạo ra các câu trả lời chung chung vì nó không bao giờ khám phá các lựa chọn thay thế. Đối với đánh giá, hãy sử dụng cài đặt xác định. Đối với ý tưởng, hãy để mô hình thở.

Một Gói Mô Hình Chứa Những Gì

Một LLM cục bộ có thể chạy được là nhiều hơn một tệp trọng số lớn. Một gói mô hình thường bao gồm:

Kiến trúc/cấu hình: Số lớp, kích thước ẩn, loại attention, cài đặt RoPE, kích thước từ vựng, token đặc biệt và độ dài ngữ cảnh.
Trọng số: Các tham số đã học, thường được lưu trữ dưới dạng safetensors, GGUF, GPTQ, AWQ, EXL2 hoặc định dạng dành riêng cho runtime khác.
Tokenizer: Các quy tắc biến văn bản thành ID token và ID token trở lại văn bản.
Mẫu chat: Đánh dấu chính xác cho các tin nhắn hệ thống, người dùng, trợ lý, công cụ và lý luận.
Cấu hình tạo: Mặc định cho nhiệt độ, top-p, token dừng, phạt lặp lại và max token.
Giấy phép và thẻ mô hình: Các hướng dẫn pháp lý và vận hành về cách sử dụng mô hình.

Các trọng số là tệp lớn nhất, nhưng chúng không phải là toàn bộ mô hình. Nếu tokenizer, cấu hình hoặc mẫu chat sai, cùng một trọng số có thể cảm thấy bị hỏng.

Phần gói cho bạn biết những gì phải đi cùng nhau. Phần tiếp theo giải thích tại sao mẫu chat là phần mà mọi người thường làm hỏng nhất.

Mẫu Chat

Một mô hình chat đã được huấn luyện với một định dạng hội thoại cụ thể. Ví dụ, nó có thể mong đợi một cái gì đó như:

<|system|> Bạn là một trợ lý hữu ích. <|user|> Giải thích KV cache. <|assistant|>

Một mô hình khác có thể mong đợi:

[BOS] [INST] Giải thích KV cache. [/INST]

Một mô hình khác có thể sử dụng các dấu hiệu kiểu ChatML. Một mô hình khác có thể yêu cầu token lý luận đặc biệt. Một mô hình khác có thể cần trình bao bọc XML hoặc JSON gọi công cụ.

Sử dụng định dạng sai có thể gây ra vô nghĩa, nhầm lẫn vai trò, bỏ qua prompt hệ thống, lặp lại prompt, kỳ quặc từ chối, gọi công cụ hỏng, kết quả điểm chuẩn xấu và kết luận rằng mô hình ngu ngốc trong khi mẫu mới là lỗi thực sự.

Thực hành tốt nhất:

Sử dụng apply_chat_template của tokenizer khi sử dụng Transformers.
Sử dụng các mẫu dành riêng cho mô hình trong frontend dựa trên Harbor, llama.cpp, LM Studio, vLLM hoặc SGLang.
Kiểm tra xem mô hình là base, instruct, chat, reasoning hay tool-tuned.
Đảm bảo token BOS/EOS chính xác.
Giữ prompt hệ thống ngắn trừ khi chúng cần dài.
Đối với sử dụng công cụ, hãy tuân theo lược đồ chính xác mà mô hình/runtime mong đợi.

Nếu bạn đang xây dựng một ứng dụng cho phép người dùng chuyển đổi mô hình, bạn cũng cần chuyển đổi mẫu. Mã hóa cứng một định dạng mẫu và sau đó tải một mô hình mong đợi một định dạng khác là một nguồn phổ biến của các đánh giá mô hình cục bộ xấu.

Hãy coi mẫu như một hợp đồng API. Nếu bạn làm sai, bạn không thực sự kiểm tra mô hình mà bạn nghĩ bạn đang kiểm tra.

Các Loại Mô Hình

Không phải tất cả LLM đều được tinh chỉnh cho cùng một hành vi.

Đối với hầu hết người dùng, điểm xuất phát mặc định nên là một mô hình instruct/chat-tuned gần đây với kích thước phù hợp thoải mái trong bộ nhớ.

Đừng bắt đầu với một mô hình base trừ khi bạn biết lý do. Mô hình base hoàn thành prompt của bạn thay vì trả lời nó. Chúng hữu ích cho các nhà nghiên cứu, người tinh chỉnh và những người xây dựng pipeline tùy chỉnh. Chúng gây khó chịu cho những người khác.

Nếu bạn hỏi một mô hình base Thủ đô của Pháp là gì?, nó có thể tiếp tục với và dân số của Paris là bao nhiêu? thay vì trả lời Paris.

Sự phân chia thực tế rất đơn giản:

Mô hình base: Tốt cho nghiên cứu tiền huấn luyện, tinh chỉnh và pipeline tùy chỉnh.
Mô hình instruct: Tốt cho việc tuân theo hướng dẫn trực tiếp.
Mô hình chat: Tốt cho đối thoại nhiều lượt với định dạng vai trò.
Mô hình reasoning: Tốt khi tác vụ hưởng lợi từ các token suy nghĩ bổ sung và xác minh.
Mô hình tool-tuned: Tốt khi các cuộc gọi có cấu trúc, JSON hoặc sử dụng hàm quan trọng.

Cục Bộ Thực Sự Có Nghĩa Là Gì

LLM cục bộ là một mô hình mà trọng số và runtime suy luận nằm dưới sự kiểm soát của bạn. Bạn quyết định mô hình nào chạy, nó chạy như thế nào, nó thấy dữ liệu gì và điều gì xảy ra với đầu ra.

Sự tự do đó đi kèm với công việc. Bây giờ bạn là nhóm vận hành. Bạn xử lý tải xuống, cập nhật, tương thích, giới hạn bộ nhớ và bảo mật. Khi có sự cố, không có vé hỗ trợ nào để gửi. Chỉ có bạn, nhật ký và tài liệu.

Cục bộ có thể có nghĩa là:

Một mô hình 2B tham số chạy trên điện thoại.
Một mô hình 7B đến 14B chạy trên GPU tiêu dùng.
Một mô hình 30B đến 70B chạy trên máy trạm cao cấp.
Một mô hình MoE thưa thớt chạy trên một hoặc nhiều GPU trung tâm dữ liệu.
Một triển khai riêng tư sử dụng vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio hoặc ngăn xếp PyTorch tùy chỉnh.

Điểm chính: cục bộ không tự động có nghĩa là ngoại tuyến, riêng tư, an toàn, rẻ hoặc mã nguồn mở. Nó chỉ có nghĩa là bạn đang tự chạy mô hình. Một ứng dụng cục bộ vẫn có thể gọi về nhà. Một mô hình có thể có trọng số mở nhưng không phải là mã nguồn mở. Một mô hình có thể là cục bộ nhưng không an toàn để tải. Một mô hình lượng tử hóa có thể vừa vặn trong bộ nhớ nhưng trả lời kém.

Sự đánh đổi đáng giá khi bạn cần quyền riêng tư, độ trễ thấp, hành vi tùy chỉnh, hoạt động ngoại tuyến hoặc kiểm soát chi phí ở quy mô lớn. Nó không đáng giá khi bạn cần chất lượng mô hình tốt nhất tuyệt đối và không có phần cứng để phù hợp. Trong trường hợp đó, API được lưu trữ là công cụ phù hợp.

LLM cục bộ thực tế khi bạn hiểu một phương trình:

Thành công LLM cục bộ = phù hợp mô hình + định dạng prompt chính xác + runtime tốt + đánh giá thực tế.

Mọi thứ khác là chi tiết. Các chi tiết rất quan trọng.

Lượng Tử Hóa

Lượng tử hóa lưu trữ trọng số ở độ chính xác thấp hơn để giảm bộ nhớ và đôi khi cải thiện thông lượng.

Quy tắc ngón tay cái năm 2026 cho người dùng cục bộ:

FP16/BF16: Chất lượng tốt nhất khi bộ nhớ dồi dào. Sử dụng nó làm đường cơ sở để đánh giá.
Q8 / INT8: Gần như không mất mát cho nhiều tác vụ, nhưng vẫn lớn. Tốt khi bạn có VRAM và muốn giảm thiểu mất chất lượng.
Q6 / Q5: Chất lượng tuyệt vời với tiết kiệm vừa phải. Đây là điểm trung gian mạnh mẽ.
Q4: Điểm ngọt tiêu dùng mặc định cho nhiều quy trình công việc chat và tài liệu.
Q3 / Q2: Chỉ khi bạn phải vừa một mô hình lớn hơn. Toán, mã, đầu ra có cấu trúc và sử dụng công cụ sẽ suy giảm trước tiên.

Lượng tử hóa trọng số không giống như lượng tử hóa KV cache. Lượng tử hóa trọng số thu nhỏ mô hình. Lượng tử hóa KV cache thu nhỏ bộ nhớ ngữ cảnh trực tiếp.

Đối với KV cache, hãy coi FP16/BF16 là đường cơ sở sạch và FP8/INT8 là sàn nén cục bộ thực tế. Dưới 8-bit là nặng về nghiên cứu và nhạy cảm với khối lượng công việc. Chỉ sử dụng nó sau khi đo lường chất lượng trên các prompt thực tế của bạn.

Sự thất bại của lượng tử hóa xuất hiện đầu tiên trong toán học, lý luận nhiều bước, tính chính xác của mã, độ tin cậy của việc sử dụng công cụ, tuân thủ JSON/lược đồ, tuân theo hướng dẫn tinh tế và truy xuất ngữ cảnh dài.

Một mô hình nhỏ hơn ở độ chính xác cao hơn có thể đánh bại một mô hình lớn hơn bị nén vào quá ít bit. Đừng tôn thờ số lượng tham số. Một mô hình 7B ở Q6 có thể đánh bại một mô hình 13B ở Q2 trong các tác vụ lý luận trong khi sử dụng ít bộ nhớ hơn và chạy nhanh hơn.

Định Dạng Tệp Và An Toàn Khi Tải

safetensors là một định dạng tuần tự hóa tensor an toàn được thiết kế để lưu trữ tensor mà không có hành vi pickle Python. Sử dụng safetensors khi có thể, đặc biệt là cho các mô hình PyTorch/Transformers.

Tránh các tệp .bin ngẫu nhiên từ các nguồn không đáng tin cậy. Tải dựa trên pickle PyTorch có thể thực thi mã tùy ý trong quá trình giải tuần tự hóa. Quy tắc bảo mật AI cục bộ số một: đừng để tệp mô hình của người lạ trở thành thực thi mã của người lạ.

GGUF là định dạng mô hình nhị phân của hệ sinh thái llama.cpp. Sử dụng GGUF khi bạn muốn llama.cpp, suy luận CPU, suy luận Apple Silicon, máy chủ cục bộ đơn giản, mô hình lượng tử hóa di động hoặc các công cụ desktop như LM Studio.

ONNX hữu ích cho triển khai chuẩn hóa và tăng tốc phần cứng cụ thể, đặc biệt là bên ngoài ngăn xếp PyTorch thông thường. Nếu bạn đang triển khai lên Intel NPU, thiết bị ARM hoặc bộ tăng tốc tùy chỉnh, ONNX thường là con đường ít kháng cự nhất.

TensorRT-LLM là đường dẫn suy luận hiệu suất cao của NVIDIA cho các triển khai GPU sản xuất. Nó mạnh mẽ, nhưng phức tạp hơn llama.cpp hoặc Harbor. Bạn thường chuyển đổi checkpoint thành engine TensorRT, mất thời gian và bộ nhớ GPU, nhưng mang lại thông lượng tuyệt vời sau khi xây dựng.

Các định dạng EXL2 / GPTQ / AWQ phổ biến trong các cộng đồng suy luận cục bộ tập trung vào GPU, đặc biệt là để nhồi các mô hình lớn hơn lên một GPU duy nhất.

Lựa chọn định dạng tệp không chỉ là hình thức. Nó quyết định runtime nào có thể tải mô hình, lượng tử hóa nào bạn có thể sử dụng và mô hình chạy nhanh như thế nào.

Runtime Và Chế Độ Phục Vụ

Runtime là phần mềm tải mô hình và thực hiện suy luận. Vào năm 2026, hệ sinh thái runtime LLM cục bộ đã trưởng thành, hữu ích và phân mảnh.

Đối với một người dùng đơn lẻ thử nghiệm cục bộ, hãy bắt đầu với Harbor, LM Studio hoặc llama.cpp. Harbor là lựa chọn tốt nhất khi bạn muốn một ngăn xếp cục bộ hoàn chỉnh với frontend, backend và các dịch vụ hỗ trợ được kết nối với nhau. LM Studio là đường dẫn desktop-first dễ nhất. llama.cpp là con ngựa thồ di động cấp thấp.

Đối với một nhóm hoặc dịch vụ riêng tư, hãy xem xét vLLM hoặc SGLang. Đối với hiệu suất sản xuất NVIDIA tối đa, hãy xem xét TensorRT-LLM. Đối với triển khai trình duyệt hoặc di động, hãy xem xét MLC hoặc WebLLM.

Lựa chọn runtime thường khóa bạn vào một hệ sinh thái định dạng. llama.cpp có nghĩa là GGUF. vLLM và SGLang thường có nghĩa là safetensors hoặc checkpoint Hugging Face. TensorRT-LLM có nghĩa là ONNX hoặc engine được tối ưu hóa. Chọn runtime trước, sau đó tìm mô hình ở định dạng phù hợp.

Có ba chế độ phục vụ thực tế.

Cục bộ một người dùng có nghĩa là một ứng dụng desktop, ngăn xếp CLI hoặc máy chủ dòng lệnh cho một người. Harbor, LM Studio, máy chủ llama.cpp, ExLlama/TabbyAPI và các script Transformers nhỏ đều phù hợp ở đây. Mục tiêu là lặp lại nhanh: So sánh hành vi, tốc độ, sử dụng bộ nhớ và định dạng prompt mà không cần xây dựng một nền tảng vận hành.

Nhóm hoặc API riêng tư có nghĩa là một endpoint tương thích với OpenAI trên máy trạm hoặc máy chủ. vLLM, SGLang, TensorRT-LLM và máy chủ llama.cpp đều xuất hiện ở đây tùy thuộc vào kích thước mô hình và nhu cầu thông lượng. Khi nhiều người hoặc công việc chia sẻ một mô hình, bạn cần giám sát, quản lý phiên bản prompt, định tuyến và đo lường độ trễ thực tế.

Dịch vụ production là một công việc hoàn toàn khác. Lúc này, cuộc trò chuyện bao gồm: batching liên tục, prefix caching, speculative decoding, paged attention, tensor parallelism, pipeline parallelism, quantized serving, structured outputs, cân bằng tải, sử dụng GPU, phân vị độ trễ, prompt caching, kiểm soát truy cập, ghi log, dự phòng, quyền riêng tư và kiểm soát chi phí.

Ở quy mô production, câu hỏi "tôi có thể tải mô hình không?" là câu hỏi dễ. Câu hỏi khó là "liệu tôi có thể phục vụ nó một cách đáng tin cậy dưới lưu lượng truy cập thực tế không?"

Tính Toán VRAM Cho Các Mô Hình Cục Bộ

Có ba yếu tố tiêu thụ bộ nhớ chính:

Trọng số mô hình (Model weights)
Bộ nhớ đệm KV (KV cache)
Chi phí vận hành runtime

Công thức tính bộ nhớ trọng số gần đúng là:

bộ_nhớ_trọng_số ~= tham_số x byte_mỗi_tham_số

Các giá trị xấp xỉ hữu ích:

FP16/BF16: Khoảng 2 byte cho mỗi tham số.
INT8/Q8: Khoảng 1 byte cho mỗi tham số.
Q4: Khoảng 0.5 byte cho mỗi tham số, cộng thêm chi phí định dạng.

Sau đó, cộng thêm:

Chi phí vận hành runtime: Bộ đệm khung, chi phí CUDA, phân mảnh bộ nhớ và các tensor tạm thời.
Bộ nhớ đệm KV: Tăng lên theo mỗi token trong ngữ cảnh đang hoạt động.
Bộ nhớ batch/đồng thời: Mỗi yêu cầu đồng thời cần bộ nhớ đệm riêng.
Bộ nhớ bộ mã hóa hình ảnh (Vision encoder): Hình ảnh cũng trở thành token.
Bộ nhớ Speculative decoding: Các mô hình nháp (draft models), các đầu nháp (draft heads), hoặc các cấu trúc xác minh bổ sung không hề miễn phí.
Bộ nhớ bộ điều hợp (Adapter): Các bộ điều hợp LoRA tuy nhỏ, nhưng vẫn chiếm dung lượng.

Các mô hình MoE thêm một điểm phức tạp nữa. Một mô hình có thể chỉ kích hoạt một phần nhỏ các tham số của nó cho mỗi token, nhưng các chuyên gia không hoạt động (inactive experts) thường vẫn cần được lưu trữ ở đâu đó trong bộ nhớ. Các tham số hoạt động ảnh hưởng đến chi phí tính toán. Tổng số tham số vẫn ảnh hưởng đến việc tải và lập kế hoạch dung lượng.

Một ước tính thực tế trông như thế này:

tổng_bộ_nhớ = trọng_số_đã_lượng_tử hóa KV_cache_cho_ngữ_cảnh chi_phí_vận_hành_runtime chi_phí_batch_hoặc_đồng_thời biên_an_toàn

Đây là cái bẫy: Một mô hình 13B ở định dạng Q4 có thể vừa vặn một cách thoải mái với ngữ cảnh 8K, nhưng sau đó lại không đủ với ngữ cảnh 32K vì KV cache đã tăng gấp bốn lần. Trọng số không thay đổi. Ngữ cảnh đã thay đổi.

Hãy chừa ra 10 đến 20 phần trăm dung lượng trống. Chạy ở mức sử dụng 99% VRAM là đang tự rước lấy các lỗi hết bộ nhớ (out-of-memory) và lỗi phân mảnh.

Các Bậc Phần Cứng Trong Thực Tế

Đây là những nguyên tắc thực tế cho năm 2026, giả định suy luận đã được lượng tử hóa và độ dài ngữ cảnh hợp lý. Kết quả chính xác phụ thuộc vào runtime, lượng tử hóa, kiến trúc mô hình, loại attention, độ dài ngữ cảnh và chi phí hệ điều hành/trình điều khiển.

Đối với hầu hết người dùng cục bộ nghiêm túc vào năm 2026, 16 GB là bậc GPU tối thiểu thoải mái, 24 GB là bậc dành cho người đam mê có giá trị tốt nhất và 48 GB+ là nơi thế giới cục bộ mạnh mẽ hơn bắt đầu mở ra.

Hiệu suất phụ thuộc vào băng thông bộ nhớ, FLOPs GPU, dung lượng VRAM, kích thước KV-cache, triển khai attention, lượng tử hóa, kích thước batch, độ dài prompt, độ dài sinh và độ chín của runtime.

Quá trình giải mã (Decode) thường bị giới hạn bởi băng thông bộ nhớ: GPU truyền tải trọng số liên tục trong khi thực hiện tương đối ít phép tính trên mỗi byte. Quá trình điền sẵn (Prefill) bị giới hạn nhiều hơn bởi khả năng tính toán vì nó có thể xử lý prompt song song. Đó là lý do tại sao hai thẻ có cùng dung lượng VRAM có thể có tốc độ token rất khác nhau nếu một thẻ có băng thông bộ nhớ cao hơn nhiều.

Thiết lập cục bộ khó chịu nhất là khi mô hình gần như vừa vặn và phải tràn các lớp xuống CPU. Về mặt kỹ thuật, nó có thể chạy, nhưng tốc độ token có thể giảm mạnh. Tải xuống CPU (CPU offload) có thể chấp nhận được cho mục đích thử nghiệm. Nó không phải là một chiến lược hiệu suất.

Chọn Mô Hình Phù Hợp

Câu hỏi thực tế không phải là "mô hình nào tốt nhất?" Mà là "mô hình nhỏ nhất nào chiến thắng được khối lượng công việc thực tế của bạn trên phần cứng của bạn?"

Hãy bắt đầu với một mô hình instruct/chat gần đây phù hợp thoải mái với độ dài ngữ cảnh mà bạn thực sự cần. Nếu bạn có 8 GB đến 12 GB VRAM hoặc bộ nhớ hợp nhất (unified memory), hãy bắt đầu từ những mô hình nhỏ. Nếu bạn có 16 GB đến 24 GB, hãy thử nghiệm các mô hình lớp 7B đến 14B trước. Nếu bạn có 48 GB hoặc hơn, các mô hình dày đặc (dense) lớn hơn và mô hình MoE trở nên khả thi.

Hãy sử dụng kiểm tra bộ nhớ này trước khi bạn quá yêu thích một checkpoint:

trọng_số + KV cache + chi_phí_vận_hành_runtime <= 80 đến 90 phần trăm bộ nhớ khả dụng

Sau đó, chạy cùng 20 đến 50 prompt trên các ứng viên. Bao gồm các tác vụ thực tế của bạn: Chỉnh sửa mã nguồn (coding edits), hỏi đáp tài liệu (document Q&A), xuất JSON, tóm tắt, gọi công cụ (tool calls), ngữ cảnh dài (long context), hoặc bất cứ thứ gì bạn thực sự cần. Đo lường chất lượng câu trả lời, độ trễ, mức sử dụng bộ nhớ, độ tin cậy của template và các chế độ lỗi.

Một lựa chọn mô hình thực tế thường dựa trên năm điểm kiểm tra:

Phù hợp nhiệm vụ: Trò chuyện, viết mã, tài liệu, tác nhân (agents), đa phương thức (multimodal), biên (edge), hoặc tinh chỉnh (fine-tuning).
Phù hợp bộ nhớ: Trọng số, KV cache, chi phí vận hành runtime và biên an toàn.
Phù hợp giao diện: Tokenizer, chat template, stop token, lược đồ công cụ (tool schema) và chế độ suy luận (reasoning mode).
Phù hợp runtime: Runtime của bạn có hỗ trợ tốt cho kiến trúc, lượng tử hóa, độ dài ngữ cảnh và chế độ phục vụ này không?
Phù hợp giấy phép: Bạn có thực sự có thể sử dụng nó ở nơi bạn định sử dụng không?

Các bảng xếp hạng (Leaderboards) rất hữu ích cho việc khám phá. Chúng không phải là sự thay thế cho các đánh giá của riêng bạn. Khối lượng công việc của bạn mới là điểm chuẩn quan trọng.

Đối với một trợ lý cục bộ đơn giản, hãy chọn một mô hình instruct 7B đến 14B gần đây, lượng tử hóa Q4/Q5, chat template chính xác, ngữ cảnh 8K đến 32K, và Harbor, LM Studio, hoặc llama.cpp. Ưu tiên khả năng phản hồi nhanh hơn là kích thước khổng lồ.

Đối với một trợ lý viết mã cục bộ, hãy chọn một mô hình 14B đến 32B có khả năng viết mã nếu bạn có đủ VRAM. Sử dụng nhiệt độ thấp (low temperature), truy xuất kho lưu trữ (repository retrieval), thực thi thử nghiệm (test execution) và quy trình làm việc dựa trên bản vá (patch-based). Một mô hình viết mã không có công cụ chỉ là một nửa sản phẩm.

Đối với một trợ lý tài liệu riêng tư, hãy chọn một mô hình instruct mạnh mẽ, một mô hình nhúng cục bộ (local embedding model), một bộ xếp hạng lại (reranker), một pipeline RAG, thực thi trích dẫn (citation enforcement) và ngữ cảnh vừa phải đến dài. Đừng dán một file PDF 200 trang và hy vọng.

Đối với một thiết lập suy luận (reasoning), hãy chọn một mô hình được tinh chỉnh cho suy luận, dự trù thêm token, sử dụng nhiệt độ thấp đến trung bình, thêm xác minh, và sử dụng các công cụ cho toán học, mã nguồn hoặc tìm kiếm. Các mô hình suy luận tiêu tốn nhiều token hơn. Hãy tính toán ngân sách cho phù hợp.

Đối với một thiết lập tài nguyên thấp, hãy chọn mô hình 1B đến 4B, Q4/Q5, prompt ngắn, tác vụ có cấu trúc, truy xuất hoặc công cụ, và một lược đồ đầu ra chặt chẽ. Các mô hình nhỏ trở nên hữu ích khi nhiệm vụ bị giới hạn.

Điều Gì Kiểm Soát Tốc Độ

Số token mỗi giây không bị kiểm soát bởi một thứ duy nhất. Nó là kết quả của kích thước mô hình, băng thông bộ nhớ, sức mạnh tính toán, nhân attention (attention kernels), độ dài ngữ cảnh, lượng tử hóa, batching và chất lượng runtime.

Các đòn bẩy chính là:

Băng thông bộ nhớ: Quá trình giải mã thường truyền tải trọng số mô hình liên tục, do đó băng thông chiếm ưu thế về tốc độ token cho một người dùng.
FLOPs GPU: Quá trình điền sẵn (prefill) và các batch lớn sử dụng nhiều tính toán song song hơn, vì vậy FLOPs quan trọng hơn ở đó.
Dung lượng VRAM: Nếu mô hình hoặc KV cache tràn xuống CPU, hiệu suất có thể sụp đổ.
Triển khai Attention: FlashAttention, SDPA, paged attention và các nhân (kernels) dành riêng cho runtime thay đổi cả hành vi tốc độ và bộ nhớ.
Lượng tử hóa: Trọng số nhỏ hơn giúp giảm di chuyển bộ nhớ, nhưng lượng tử hóa mạnh có thể làm giảm chất lượng và đôi khi thêm chi phí giải lượng tử (dequantization).
Kích thước Batch và tính đồng thời: Batching cải thiện thông lượng, nhưng mỗi chuỗi hoạt động cần có KV cache.
Độ dài Prompt: Các prompt dài làm tăng thời gian điền sẵn (prefill time).
Độ dài sinh: Các câu trả lời dài làm lộ tốc độ giải mã.
Speculative decoding: Các phương pháp kiểu EAGLE, MTP, DFlash và DDTree có thể xác minh nhiều hơn một token được soạn thảo (drafted token) cho mỗi lượt (pass) mục tiêu khi được hỗ trợ.

Thiết lập khó chịu là thiết lập "gần như vừa vặn". Một mô hình làm tràn các lớp hoặc bộ nhớ đệm xuống CPU có thể chạy về mặt kỹ thuật, nhưng tốc độ token có thể giảm từ mức có thể sử dụng xuống mức thảm hại.

Hãy đánh giá điểm chuẩn chính xác runtime, lượng tử hóa, độ dài ngữ cảnh, hình dạng prompt và khối lượng công việc bạn định sử dụng. Một con số BF16 trên bảng xếp hạng không cho bạn biết ngăn xếp (stack) Q4 cục bộ của bạn sẽ hoạt động như thế nào.

Ngữ Cảnh Dài (Long Context)

Ngữ cảnh dài nghe có vẻ kỳ diệu: 128K, 256K, thậm chí 1M token trong một prompt. Nó rất hữu ích, nhưng nó có những chi phí thực tế.

Ngữ cảnh càng nhiều đồng nghĩa với bộ nhớ KV cache càng lớn, xử lý prompt chậm hơn, nhiều công việc attention hơn, đánh giá khó khăn hơn và nhiều cách hơn để văn bản không liên quan làm mất tập trung mô hình. Chất lượng cũng có thể suy giảm theo khoảng cách. Một mô hình có thể xử lý tốt phần cuối của một tài liệu dài trong khi bỏ lỡ các chi tiết quan trọng được chôn gần phần đầu.

Sử dụng ngữ cảnh dài để phân tích toàn bộ tài liệu, các lát cắt mã nguồn (codebase slices), xem xét pháp lý hoặc kỹ thuật, tóm tắt bảng điểm (transcript summarization), suy luận đa tệp (multi-file reasoning) và dự phòng RAG khi truy xuất bỏ lỡ ngữ cảnh.

Đừng coi ngữ cảnh dài như một sự thay thế cho việc truy xuất. Nó là một sự bổ sung. Sử dụng RAG cho các kho tài liệu lớn và ngữ cảnh dài cho các bằng chứng đã chọn cuối cùng.

Các thói quen thực tế rất hữu ích:

Đặt các hướng dẫn quan trọng ở gần đầu và gần cuối.
Sử dụng tiêu đề phần và dấu phân cách.
Yêu cầu trích dẫn gắn với các đoạn nguồn.
Nén lịch sử không liên quan.
Sử dụng bộ nhớ tóm tắt (summary memory) thay vì lịch sử trò chuyện vô hạn.

Hãy nghĩ về ngữ cảnh dài như một attention đắt đỏ, không phải một cuốn sổ tay miễn phí.

Đa Phương Thức (Multimodality)

Các mô hình cục bộ đa phương thức chấp nhận hình ảnh, và đôi khi là âm thanh hoặc video, ngoài văn bản. Các hệ sinh thái mã nguồn mở hiện đại ngày càng bao gồm các mô hình này.

Chi phí ẩn là đầu vào không phải văn bản cũng trở thành token. Bộ mã hóa hình ảnh (Vision encoders) thêm bộ nhớ. Các mảnh hình ảnh tiêu thụ ngữ cảnh. Âm thanh và video có thể làm bùng nổ ngân sách đầu vào. Các mẫu (template) đa phương thức cũng dễ bị sai hơn so với các mẫu chỉ có văn bản.

Một hình ảnh độ phân giải cao duy nhất có thể tiêu thụ hàng nghìn token trong cửa sổ ngữ cảnh. Nếu bạn đang chạy một mô hình đa phương thức cục bộ, hãy đếm token hình ảnh giống như cách bạn đếm token văn bản. Chúng đến từ cùng một ngân sách.

Các VLM nhỏ có thể tạo ra ảo giác về chi tiết hình ảnh. Độ tin cậy của OCR khác nhau. Biểu đồ và bảng tính vẫn còn khó khăn. Đối với các quy trình làm việc tài liệu hoặc hình ảnh nghiêm túc, hãy đánh giá với các mẫu thực tế. Đừng tin tưởng vào bản demo của một bức ảnh đơn giản để chứng minh chất lượng trích xuất hóa đơn.

Bối Cảnh Mô Hình Cục Bộ Năm 2026

Bối cảnh mô hình thay đổi nhanh chóng. Tính đến ngày 21 tháng 5 năm 2026, người dùng LLM cục bộ nên suy nghĩ theo hướng các họ và hệ sinh thái, chứ không phải một mô hình tốt nhất.

Qwen 3.5 / Qwen 3.6 là một họ mã nguồn mở lớn vì nó bao phủ toàn bộ các cấp độ: Mô hình nhỏ cho máy tính xách tay, mô hình kích thước trung bình dày đặc (dense) cho máy trạm, mô hình MoE cho phục vụ đa GPU, biến thể FP8, ngữ cảnh dài, làm việc đa ngôn ngữ, viết mã, công cụ và quy trình làm việc tác nhân (agentic workflows). Kết luận thực tế rất đơn giản: Qwen là một họ mặc định mạnh mẽ khi bạn muốn một hệ sinh thái duy nhất có thể bao trùm cả các thử nghiệm trên máy tính xách tay và việc phục vụ cục bộ nghiêm túc.

Gemma 4 rất quan trọng vì Google DeepMind đang thúc đẩy họ này hướng tới việc triển khai cục bộ hữu ích: Các mô hình biên hiệu quả, các tùy chọn dày đặc và MoE lớn hơn, đa phương thức, ngữ cảnh dài trên các mô hình lớn hơn, hỗ trợ ngôn ngữ rộng rãi, hành vi viết mã/tác nhân mạnh mẽ hơn và giấy phép Apache 2.0. Sự kết hợp đó khiến nó đáng để thử nghiệm khi việc sử dụng thương mại và triển khai phía thiết bị là quan trọng.

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax và Mistral cũng là những họ cốt lõi cần theo dõi. Kimi phù hợp cho việc viết mã tầm xa (long-horizon coding), suy luận đa phương thức, sử dụng công cụ và quy trình làm việc tác nhân. GLM rất quan trọng đối với các tác nhân viết mã, các tác vụ tầm xa, hệ thống MoE và các bản phát hành mô hình hướng tới triển khai. DeepSeek vẫn có ảnh hưởng vì các hệ thống MoE lớn, Multi-head Latent Attention, DeepSeekMoE, các đường dẫn phục vụ FP8, sparse attention và khả năng tự lưu trữ thông lượng cao. MiniMax đáng để theo dõi vì các khối lượng công việc tác nhân thực tế và các mô hình MoE hiệu quả suy luận. Mistral vẫn quan trọng vì dòng sản phẩm của nó bao gồm các trường hợp sử dụng tổng quát, viết mã, suy luận, đa phương thức và chuyên biệt với hỗ trợ triển khai mạnh mẽ.

Nemotron 3 là họ mô hình mở của NVIDIA dành cho các hệ thống tác nhân cấp sản xuất trên phần cứng NVIDIA. Họ này bao gồm các kích cỡ Nano, Super và Ultra, sử dụng thiết kế MoE hybrid Mamba-Transformer, và được gắn chặt với TensorRT-LLM, NIM, Dynamo, các đường dẫn Blackwell NVFP4/FP8, và triển khai tác nhân doanh nghiệp. Hãy coi nó ít giống một họ trò chuyện trên máy tính để bàn thông thường và giống một tín hiệu hơn về nơi NVIDIA muốn các ngăn xếp phục vụ mã nguồn mở hướng tới.

Trí tuệ nhân tạo mã nguồn mở không còn chỉ là Llama so với mọi thứ khác nữa. Bạn đang chọn một hệ sinh thái: Trọng số, giấy phép, tokenizer, template, lượng tử hóa, hỗ trợ runtime, đường dẫn phục vụ, công cụ cộng đồng và các chế độ lỗi.

Mô Hình Dày Đặc Qwen 27B

Qwen 3.5 / 3.6 27B (Dense) là một trong những tùy chọn trọng số công khai thực tế nhất cho người dùng cục bộ quan tâm đến việc viết mã, làm việc đa ngôn ngữ, sử dụng công cụ, chế độ suy nghĩ/không suy nghĩ (thinking/non-thinking modes) và ngữ cảnh dài. Các thẻ mô hình Qwen 3.5 27B và Qwen 3.6 27B mô tả các đường dẫn phục vụ tương thích OpenAI, chế độ suy nghĩ mặc định, sử dụng công cụ và độ dài ngữ cảnh lên đến 262,144 token, với phần mở rộng ngữ cảnh dài hơn thông qua YaRN trong các framework được hỗ trợ.

Qwen là một lựa chọn mặc định mạnh mẽ cho một thiết lập 2x RTX 3090 khi runtime được cấu hình chính xác cho việc viết mã, tác nhân hoặc phạm vi đa ngôn ngữ.

Nghiên Cứu Suy Luận

Ranh giới năm 2026 không chỉ là chất lượng mô hình. Nó còn là hiệu quả suy luận. PagedAttention tấn công lãng phí bộ nhớ KV-cache trong phục vụ. Bộ nhớ đệm KV FP8 hiện là một tính năng runtime thực tế trong các hệ thống như vLLM. DFlash và DDTree khám phá speculative decoding với các mô hình nháp khuếch tán khối (block diffusion draft models) và cây nháp (draft trees). NVFP4 cũng đáng để theo dõi trên phần cứng NVIDIA vì nó thay đổi cuộc trò chuyện triển khai thực tế cho các ngăn xếp được hỗ trợ.

Một số điều này đã sẵn sàng cho sản xuất. Một số vẫn đang trong giai đoạn nghiên cứu. Một số chỉ quan trọng nếu runtime của bạn hỗ trợ nó một cách sạch sẽ. Đừng coi các cải tiến tốc độ trên giấy tờ như một ô đánh dấu trong một ứng dụng máy tính để bàn.

Các Chế Độ Lỗi Và Cách Khắc Phục

Hầu hết các lỗi LLM cục bộ không phải là bí ẩn. Chúng thường đến từ sự phù hợp của bộ nhớ, định dạng, hỗ trợ runtime, cài đặt giải mã hoặc chất lượng truy xuất.

Hết bộ nhớ (Out of memory): Trọng số, KV cache, chi phí vận hành runtime hoặc kích thước batch không phù hợp. Sử dụng mô hình nhỏ hơn, giảm ngữ cảnh, giảm batch/đồng thời, chọn lượng tử hóa tốt hơn hoặc chừa nhiều dung lượng trống hơn.

Vô nghĩa hoặc nhầm lẫn vai trò (Gibberish or role confusion): Chat template, tokenizer, token BOS/EOS, công tắc chế độ suy luận hoặc lược đồ công cụ bị sai. Hãy xác minh thẻ mô hình và template runtime trước khi đổ lỗi cho chất lượng mô hình.

Token đầu tiên chậm (Slow first token): Quá trình điền sẵn (Prefill) rất tốn kém. Rút ngắn prompt, sử dụng prefix caching, cải thiện truy xuất, giảm ngữ cảnh hoặc sử dụng runtime nhanh hơn.

Truyền phát chậm (Slow streaming): Quá trình giải mã là nút thắt cổ chai. Kiểm tra băng thông bộ nhớ, lượng tử hóa, tràn CPU, backend attention, hỗ trợ speculative decoding và liệu mô hình có đơn giản là quá lớn so với phần cứng hay không.

Câu trả lời tài liệu kém (Bad document answers): Nhiều khả năng là do truy xuất thất bại. Hãy kiểm tra văn bản đã phân tích cú pháp, ranh giới đoạn (chunk boundaries), siêu dữ liệu, truy xuất top-k, xếp hạng lại và căn cứ trích dẫn.

JSON hoặc gọi công cụ kém (Bad JSON or tool calls): Sử dụng nhiệt độ thấp hơn, giải mã có ràng buộc (constrained decoding), lược đồ chặt chẽ hơn, các ví dụ tốt hơn và một mô hình được tinh chỉnh cho việc sử dụng công cụ.

Vòng lặp lặp lại (Repeating loops): Giảm nhiệt độ hoặc top-p, thêm các hình phạt lặp lại (repetition penalties), kiểm tra stop token và đảm bảo template không khiến mô hình nhìn thấy câu trả lời của chính nó như một prompt mới.

Hãy bắt đầu với các kiểm tra đơn giản. Chúng sửa được nhiều vấn đề hơn là thay đổi mô hình.

Cách Phát Triển Ngăn Xếp

Người Mới Bắt Đầu: Thiết Lập Hữu Ích Dễ Dàng Nhất

Sử dụng Harbor hoặc LM Studio, một mô hình instruct 4B đến 9B gần đây, lượng tử hóa Q4, ngữ cảnh 8K đến 32K và giao diện trò chuyện tích hợp sẵn. Tải xuống hai hoặc ba mô hình trong cùng một lớp kích thước và so sánh chúng trên cùng một prompt.

Mục tiêu: Học cách tạo prompt, so sánh các mô hình, hiểu tốc độ và bộ nhớ, và tránh mã tùy chỉnh lúc đầu.

Trung Cấp: Thiết Lập Nhà Phát Triển

Sử dụng llama.cpp hoặc Transformers, GGUF hoặc safetensors, một máy chủ cục bộ tương thích OpenAI, một pipeline RAG đơn giản và một bộ đánh giá nhỏ. Gọi máy chủ cục bộ của bạn từ một ứng dụng hoặc tập lệnh thực tế thay vì chỉ sử dụng giao diện trò chuyện.

Mục tiêu: Xây dựng các ứng dụng cục bộ, thử nghiệm truy xuất, đo lường chất lượng và phục vụ từ localhost.

Nâng Cao: Thiết Lập Phục Vụ Riêng Tư

Sử dụng vLLM hoặc SGLang, một hoặc nhiều GPU, một API tương thích OpenAI, giám sát, quản lý phiên bản prompt/phiên bản, một bộ đánh giá, RAG với xếp hạng lại và hộp cát công cụ (tool sandboxing).

Mục tiêu: Phục vụ người dùng thực tế hoặc quy trình làm việc nội bộ, tối ưu hóa thông lượng và độ trễ, đồng thời duy trì sự an toàn và khả năng quan sát.

Chuyên Gia: Tối Ưu Hóa Tùy Chỉnh

Sử dụng TensorRT-LLM, các nhân tùy chỉnh (custom kernels), runtime chuyên biệt, thử nghiệm lượng tử hóa, speculative decoding, song song đa GPU, tinh chỉnh (fine-tuning), chưng cất (distillation) và các đánh giá sản xuất.

Mục tiêu: Đánh đổi thời gian kỹ thuật để lấy hiệu quả suy luận, giảm chi phí và nâng cao chất lượng ở quy mô lớn.

Quyền Riêng Tư Không Phải Tự Động Có

LLM cục bộ cải thiện quyền riêng tư vì các prompt và đầu ra có thể ở lại trên phần cứng của bạn. Nhưng cục bộ không tự động có nghĩa là an toàn.

Các mối đe dọa bao gồm các tệp mô hình độc hại, tải trọng số dựa trên pickle, trust_remote_code không đáng tin cậy, chèn prompt trong các tài liệu được truy xuất, lạm dụng các cuộc gọi công cụ, rò rỉ bí mật qua nhật ký, telemetry từ các ứng dụng máy tính để bàn, tiện ích mở rộng trình duyệt hoặc plugin, ảo giác mô hình trong các cài đặt rủi ro cao, vi phạm giấy phép và nhiễm bẩn dữ liệu trong quá trình tinh chỉnh.

Một đường cơ sở bảo mật AI cục bộ khả thi có bốn thói quen:

Tải cẩn thận: Ưu tiên safetensors hoặc GGUF từ các nguồn uy tín, tránh các tệp .bin không đáng tin cậy và không kích hoạt trust_remote_code một cách tùy tiện.
Chạy với các ranh giới: Sử dụng một người dùng không có đặc quyền (unprivileged user), container hoặc hộp cát cho các tác nhân và tắt quyền truy cập mạng khi quyền riêng tư ngoại tuyến là quan trọng.
Bảo vệ bí mật: Giữ thông tin xác thực ngoài các prompt và chỉ mục RAG, xem xét cài đặt telemetry của ứng dụng máy tính để bàn và xác thực các lệnh gọi công cụ trước khi thực thi.
Quản lý phiên bản những thứ quan trọng: Theo dõi các phiên bản mô hình, prompt, bộ điều hợp, runtime và lượng tử hóa, đồng thời ghi đủ nhật ký để gỡ lỗi mà không tạo ra thảm họa về quyền riêng tư.

Bảo mật AI cục bộ chủ yếu là kỷ luật vận hành đơn giản. Đó cũng là cách bạn tránh tải xuống một checkpoint ngẫu nhiên, chạy nó với quyền root và biến AI cục bộ thành một sự xâm phạm cục bộ.

Các Điểm Chuẩn Quan Trọng

Hãy đánh giá điểm chuẩn cho ngăn xếp mà bạn thực sự sẽ chạy. Điểm số BF16 trên bảng xếp hạng của một mô hình không phải là thực tế Q4 cục bộ của bạn.

Đo lường chất lượng, độ trễ, bộ nhớ, độ tin cậy và sự phù hợp vận hành:

Chất lượng: Tính đúng đắn trên các tác vụ thực tế của bạn, không chỉ các điểm chuẩn chung chung.
Độ trễ: Thời gian đến token đầu tiên (time to first token), số token giải mã mỗi giây (decode tokens per second) và thời gian từ đầu đến cuối (end-to-end time).
Bộ nhớ: Bộ nhớ trọng số, mức tăng trưởng KV-cache, VRAM cao nhất và dung lượng trống khi có tải.
Định dạng: Tính chính xác của chat template, tỷ lệ thành công JSON/lược đồ, độ tin cậy của việc gọi công cụ và hành vi của stop-token.
Truy xuất: Độ trung thực của trích dẫn, căn cứ câu trả lời, hành vi khi thiếu bằng chứng và tác động của bộ xếp hạng lại.
Vận hành: Thời gian khởi động, hành vi khởi động, phục hồi sau sự cố, ghi log, quyền riêng tư và theo dõi phiên bản.

Tạo một bộ đánh giá nhỏ với 30 đến 100 prompt đại diện. Bao gồm các câu trả lời hoặc tiêu chí chấm điểm dự kiến, các phép đo độ trễ và bộ nhớ, các danh mục lỗi, kiểm tra căn cứ RAG cụ thể, kiểm tra tuân thủ JSON nếu có liên quan và đánh giá của con người cho các tác vụ mơ hồ.

Sau đó, so sánh các mô hình. Đừng để bảng xếp hạng chọn ngăn xếp cục bộ cho bạn.

Viết Mã Với Các Mô Hình Cục Bộ

Viết mã là một trong những trường hợp sử dụng LLM cục bộ tốt nhất vì các prompt thường bao gồm mã nguồn riêng tư, độ trễ rất quan trọng, việc lặp lại diễn ra thường xuyên, chi phí API có thể tăng nhanh và các mô hình cục bộ có thể tích hợp với các trình soạn thảo, shell, grep, test runner và quy trình làm việc vá lỗi.

Thiết lập viết mã cục bộ mạnh mẽ nhất không phải là một chatbot trần trụi. Đó là một mô hình instruct có khả năng viết mã được kết nối với ngữ cảnh kho lưu trữ có mục tiêu, truy xuất qua codebase, đường dẫn tệp, các đoạn mã có liên quan, thực thi thử nghiệm và một vòng lặp vá lỗi.

Giữ cho việc giải mã mang tính xác định (deterministic) hoặc nhiệt độ thấp. Yêu cầu các bản vá (patches) thay vì lời khuyên chung chung. Chạy các thử nghiệm tự động. Giữ một bộ đánh giá nhỏ về các lỗi và tác vụ thực tế để bạn có thể biết khi nào một mô hình mới thực sự tốt hơn.

Đừng để một mô hình cục bộ viết lại toàn bộ codebase mà không có sự xem xét. Cục bộ không làm cho một tác nhân viết mã trở nên khôn ngoan. Nó chỉ làm cho ngữ cảnh trở nên riêng tư, vòng lặp rẻ hơn và việc tích hợp dễ kiểm soát hơn.

Các Tác Nhân Cục Bộ Cần Có Rào Chắn (Guardrails)

Một LLM cục bộ trở nên hữu ích hơn nhiều khi nó có thể sử dụng các công cụ: Tìm kiếm tệp, lệnh shell, tự động hóa trình duyệt, cơ sở dữ liệu, thực thi mã, lịch, hệ thống vé (ticket systems), API nội bộ, cơ sở dữ liệu vector, tự động hóa gia đình, robot hoặc thiết bị biên.

Việc sử dụng công cụ thay đổi mô hình an toàn. Một chatbot bị ảo giác thì gây khó chịu. Một tác nhân có quyền truy cập vào hệ thống tệp có thể xóa mọi thứ. Một tác nhân có quyền truy cập trình duyệt có thể làm rò rỉ bí mật. Một tác nhân có quyền truy cập shell có thể làm hỏng máy nhanh hơn bạn có thể đọc nhật ký.

An toàn cho tác nhân cục bộ có bốn lớp. Giới hạn phạm vi của tác nhân một cách chặt chẽ bằng cách chỉ cung cấp cho nó các thư mục, API, quyền truy cập mạng và thông tin xác thực mà nó thực sự cần. Hạn chế việc thực thi bằng hộp cát, container, người dùng có đặc quyền tối thiểu (least-privilege users), xác nhận cho các hành động phá hoại và các đối số công cụ đã được xác thực lược đồ (schema-validated). Coi các đầu vào là thù địch vì các tài liệu, trang web, vé (tickets) và email được truy xuất có thể chứa chèn prompt. Giữ một dấu vết kiểm toán (audit trail) bằng cách ghi lại các lệnh gọi công cụ, phiên bản mô hình, prompt và sự chấp thuận mà không để lộ bí mật vào nhật ký.

Đầu ra có cấu trúc (Structured outputs) rất hữu ích, nhưng chúng không phải là ranh giới bảo mật. Các lược đồ JSON, giải mã có ràng buộc (constrained decoding) và chữ ký hàm (function signatures) giúp việc xác thực các lệnh gọi công cụ dễ dàng hơn. Chúng không chứng minh rằng mô hình đã hiểu yêu cầu, chọn hành động an toàn hoặc tránh được các hướng dẫn được chèn vào.

Đối với việc sử dụng công cụ nghiêm túc, hãy đặt các kiểm tra chính sách bên ngoài mô hình.

RAG Vượt Trội Hơn Các Prompt Khổng Lồ

RAG là viết tắt của Retrieval-Augmented Generation. Thay vì nhồi nhét tất cả thông tin vào prompt, bạn truy xuất các đoạn có liên quan từ một cơ sở kiến thức và chỉ cung cấp những đoạn đó cho mô hình.

Một hệ thống RAG cục bộ tốt thường có các bước: Tiếp nhận tài liệu (document ingestion), phân tích cú pháp (parsing), chia đoạn (chunking), nhúng (embeddings), chỉ mục vector (vector index), truy xuất (retrieval), xếp hạng lại (reranking), xây dựng prompt, tạo câu trả lời, kiểm tra căn cứ (grounding checks) và đánh giá (evaluation). Mỗi giai đoạn là một điểm có thể xảy ra lỗi.

Phân tích cú pháp kém biến bảng biểu thành rác. Chia đoạn kém chia cắt câu trả lời qua các ranh giới. Truy xuất kém trả về các đoạn văn không liên quan. Xếp hạng lại kém chôn vùi câu trả lời đúng ở vị trí thứ 20. Một mô hình tốt không thể trả lời một cách đáng tin cậy từ các bằng chứng mà nó chưa bao giờ nhận được.

Hầu hết các hệ thống RAG tồi không phải là tồi vì LLM. Chúng tồi vì việc chia đoạn, truy xuất, xếp hạng lại và đánh giá.

Chiến lược chia đoạn (Chunking strategy) là kẻ giết người thầm lặng. Các đoạn có kích thước cố định không có sự chồng lấn (overlap) có thể chia cắt câu và mất ngữ cảnh. Chia đoạn theo ngữ nghĩa (Semantic chunking) hoặc chia đoạn theo thứ bậc (hierarchical chunking) với truy xuất tài liệu cha (parent-document retrieval) thường hoạt động tốt hơn, nhưng không có câu trả lời chung cho tất cả. Bạn phải đánh giá kích thước đoạn, mức độ chồng lấn và các quy tắc phân chia trên các tài liệu thực tế của bạn.

Một bộ xếp hạng lại (reranker) tốt có thể cứu vãn việc truy xuất tầm thường. Không có bộ xếp hạng lại nào có thể sửa được các đoạn đã đánh mất câu trả lời trong quá trình tiếp nhận (ingestion).

Tài Liệu Và Công Việc Tri Thức

Đối với các tài liệu riêng tư, LLM cục bộ tỏa sáng: Tóm tắt bảng điểm cuộc họp, xem xét hợp đồng, hỏi đáp tài liệu kỹ thuật, tổng hợp ghi chú nghiên cứu, soạn thảo email, tìm kiếm chính sách, trợ lý hỗ trợ nội bộ và quy trình làm việc tuân thủ đều được hưởng lợi từ việc giữ tài liệu gần với máy móc hoặc tổ chức sở hữu chúng.

Quy trình làm việc rất đơn giản nhưng khó tính. Phân tích cú pháp tài liệu một cách cẩn thận, bảo tồn siêu dữ liệu trang và phần, chia đoạn theo ngữ nghĩa, sử dụng embeddings và rerankers, yêu cầu trích dẫn, tách biệt câu trả lời khỏi các nguồn khỏi suy luận chung và đánh giá độ trung thực của trích dẫn.

Đừng cho rằng mô hình biết những gì có trong tài liệu của bạn. Nó chỉ biết những gì bạn đưa vào prompt hoặc truy xuất vào ngữ cảnh.

Đối với bảng điểm cuộc họp, hãy bảo tồn nhãn người nói (speaker labels) và dấu thời gian. Đối với xem xét hợp đồng, hãy chia đoạn theo điều khoản hoặc phần thay vì số lượng token tùy ý. Đối với hỏi đáp tài liệu kỹ thuật, hãy bao gồm số trang hoặc điểm neo phần (section anchors) trong các đoạn được truy xuất để mô hình có thể trích dẫn các nguồn một cách chính xác.

Đối với công việc tài liệu, trình phân tích cú pháp (parser) và bộ truy xuất (retriever) của bạn quan trọng không kém gì mô hình.

Triển Khai Biên (Edge Deployment)

Các mô hình nhỏ ngày càng hữu ích trên điện thoại, máy tính xách tay, robot, cổng IoT (IoT gateways), thiết bị nhà máy, xe cộ, thiết bị y tế, thiết bị thực địa ngoại tuyến và ứng dụng trình duyệt. Biên (edge) không chỉ là một phiên bản nhỏ hơn của máy trạm. Nó có một bộ ràng buộc khác.

Triển khai biên địa (edge deployment) bị chi phối bởi bộ nhớ thấp, năng lượng thấp, giới hạn nhiệt, kết nối không liên tục, yêu cầu về quyền riêng tư, độ trễ thời gian thực, cửa sổ ngữ cảnh nhỏ và hành vi dự phòng có thể dự đoán được. Trên các thiết bị đó, một mô hình nhỏ đáng tin cậy sẽ đánh bại một mô hình lớn mong manh.

Một thiết lập biên địa thực tế thường sử dụng mô hình từ 0.5B đến 4B, lượng tử hóa trọng số mạnh, prompt nhỏ, lược đồ cố định, workflow hỗ trợ công cụ, embedding cục bộ, bộ nhớ đệm và không có lịch sử trò chuyện không cần thiết.

Khi kết nối bị mất, một mô hình cục bộ vẫn hoạt động có giá trị hơn một mô hình lớn hơn bị lỗi. Tương lai của AI cục bộ không chỉ là những mô hình máy trạm khổng lồ. Đó còn là những mô hình nhỏ làm những công việc hữu ích gần với dữ liệu.

Sổ Tay Vận Hành LLM Cục Bộ

Hãy sử dụng phần này như một bước kiểm tra cuối cùng trước khi tin tưởng một mô hình cục bộ cho công việc thực tế.

Chọn và phù hợp: Chọn một dòng mô hình phù hợp với tác vụ, đọc giấy phép, xác nhận yêu cầu phần cứng, chọn mức lượng tử hóa và ước tính tổng hóa đơn bộ nhớ. Đừng dừng lại ở kích thước trọng số. Bao gồm KV cache, chi phí runtime, batch/đồng thời và biên an toàn.

Tải và định dạng: Ưu tiên safetensors hoặc GGUF từ các nguồn uy tín, tránh các tệp dựa trên pickle không đáng tin cậy, xác minh tokenizer và mẫu trò chuyện (chat template), đặt độ dài ngữ cảnh có chủ đích và chọn tham số giải mã cho tác vụ. Nếu mẫu sai, quá trình đánh giá sẽ không hợp lệ.

Đánh giá và vận hành: Kiểm tra với các prompt đại diện, đo thời gian đến token đầu tiên và tốc độ giải mã, theo dõi bộ nhớ đỉnh, đánh giá khả năng truy xuất trước khi thêm RAG, sandbox các công cụ trước khi thêm tác nhân và tinh chỉnh chỉ khi các phương pháp đơn giản hơn thất bại.

Kiểm soát phiên bản mọi thứ quan trọng: Mô hình, lượng tử hóa, runtime, prompt, mẫu trò chuyện, bộ chuyển đổi (adapter), mô hình embedding, bộ xếp hạng lại (reranker), tập đánh giá và cấu hình phần cứng. Các hệ thống cục bộ chỉ dễ kiểm soát hơn khi bạn có thể tái tạo những gì bạn đã chạy.

Tinh Chỉnh (Fine-Tuning)

Tinh chỉnh thay đổi hành vi của mô hình bằng cách huấn luyện trên dữ liệu bổ sung. Đối với người dùng cục bộ, các phương pháp quan trọng nhất là LoRA và QLoRA.

LoRA đóng băng mô hình cơ sở và huấn luyện các trọng số bộ chuyển đổi hạng thấp nhỏ. Điều đó làm giảm các tham số có thể huấn luyện và cho phép bạn duy trì nhiều bộ chuyển đổi nhẹ. QLoRA mở rộng điều này bằng cách tinh chỉnh thông qua một mô hình lượng tử hóa 4-bit bị đóng băng vào các bộ chuyển đổi LoRA.

Hãy tinh chỉnh khi bạn cần một phong cách viết nhất quán, định dạng đầu ra theo miền cụ thể, hành vi phân loại hoặc trích xuất lặp đi lặp lại, độ tin cậy của định dạng gọi công cụ, một nhân cách trợ lý chuyên biệt, thích ứng miền mà RAG không thể giải quyết hoặc hiệu suất mô hình nhỏ tốt hơn cho một tác vụ hẹp.

Đừng tinh chỉnh trước. Hãy thử theo thứ tự này: mẫu trò chuyện đúng, tạo prompt tốt hơn, mô hình tốt hơn, giải mã tốt hơn, RAG, xếp hạng lại, vài ví dụ (few-shot), sau đó là tinh chỉnh.

Hầu hết các vấn đề trông giống như mô hình không hiểu miền của tôi thực chất là prompt của tôi mơ hồ, mẫu của tôi sai hoặc khả năng truy xuất của tôi bị hỏng.

Một kế hoạch tinh chỉnh tốt bao gồm dữ liệu sạch, phân chia train/validation/test, đánh giá cơ sở, hành vi mục tiêu rõ ràng, đánh giá an toàn, kiểm tra quá khớp (overfitting), đánh giá hồi quy (regression), kiểm soát phiên bản bộ chuyển đổi, xem xét giấy phép và kế hoạch khôi phục.

Trọng Số Mở Không Có Nghĩa Là Mã Nguồn Mở

Vào năm 2026, cụm từ mô hình mở thường được sử dụng một cách cẩu thả. Bạn nên phân biệt giữa trọng số mở, mã nguồn có sẵn, mã nguồn mở và tương thích cục bộ.

Trọng số mở thường có nghĩa là bạn có thể tải xuống các trọng số. Nó không tự động có nghĩa là bạn có thể sử dụng mô hình cho mục đích thương mại, sửa đổi nó một cách tự do, huấn luyện trên đầu ra của nó, triển khai nó ở bất kỳ quy mô nào hoặc bỏ qua các yêu cầu ghi nhận tác giả.

Mã nguồn có sẵn có nghĩa là mã hoặc trọng số có thể được xem. Nó không nhất thiết có nghĩa là giấy phép là mã nguồn mở.

Mô hình AI mã nguồn mở là một tuyên bố mạnh mẽ hơn. Định nghĩa AI Mã Nguồn Mở của OSI coi một hệ thống AI bao gồm kiến trúc, tham số/trọng số, mã suy luận và đủ thông tin dữ liệu và mã được sử dụng để suy ra các tham số. Đó là một tiêu chuẩn cao hơn nhiều so với việc các trọng số có trên Hugging Face.

Một số giấy phép trông có vẻ cho phép nhưng chứa các hạn chế: Không được sử dụng cạnh tranh, không được huấn luyện trên đầu ra, không được triển khai trên một quy mô nhất định, loại trừ theo địa lý, yêu cầu ghi nhận tác giả, điều khoản bằng sáng chế hoặc nghĩa vụ giống copyleft đối với các dẫn xuất.

Nguyên tắc: hãy đọc thẻ mô hình và giấy phép trước khi sử dụng bất kỳ mô hình nào cho mục đích thương mại. Một mô hình có thể xuất sắc, có thể tải xuống và chạy cục bộ nhưng vẫn không phù hợp với các ràng buộc pháp lý hoặc triển khai của bạn.

Bảng Thuật Ngữ

Thuật Ngữ Về Mô Hình Và Tinh Chỉnh

Active Parameters (Tham số hoạt động): Trong mô hình MoE, chỉ một số tham số được sử dụng cho một token nhất định. Một mô hình có thể có hàng trăm tỷ tổng tham số nhưng số lượng tham số hoạt động trên mỗi token lại ít hơn nhiều.
Adapter (Bộ chuyển đổi): Một mô-đun nhỏ có thể huấn luyện được thêm vào mô hình cơ sở, thường thông qua LoRA.
Base Model (Mô hình cơ sở): Mô hình được tiền huấn luyện, không được tinh chỉnh cụ thể cho việc trò chuyện hoặc tuân theo hướng dẫn.
Fine-Tuning (Tinh chỉnh): Huấn luyện bổ sung thay đổi hành vi của mô hình cho một miền mục tiêu hoặc phong cách đầu ra.
Instruct Model (Mô hình hướng dẫn): Mô hình được tinh chỉnh để tuân theo hướng dẫn.
LoRA / QLoRA: Các phương pháp tinh chỉnh hiệu quả sử dụng bộ chuyển đổi hạng thấp, với QLoRA huấn luyện thông qua các mô hình cơ sở được lượng tử hóa.
MoE: Mixture of Experts (Hỗn hợp chuyên gia). Một kiến trúc thưa thớt nơi chỉ các mạng con chuyên gia được chọn mới được kích hoạt cho mỗi token.
Weights / Parameters (Trọng số / Tham số): Các giá trị số đã học được bên trong mô hình.

Cơ Chế Suy Luận

BOS / EOS: Token bắt đầu chuỗi và kết thúc chuỗi.
Chat Template (Mẫu trò chuyện): Định dạng được sử dụng để biểu diễn các tin nhắn hệ thống, người dùng, trợ lý và công cụ.
Context Window (Cửa sổ ngữ cảnh): Số lượng token tối đa mà mô hình có thể xử lý cùng một lúc.
Decode (Giải mã): Giai đoạn mô hình tạo ra các token mới từng cái một.
DFlash: Một phương pháp giải mã suy đoán (speculative decoding) năm 2026 sử dụng khuếch tán khối (block diffusion) để phác thảo song song.
DDTree / DTree: Một phương pháp giải mã suy đoán xây dựng một cây phác thảo từ các phân phối khuếch tán khối và xác minh nó một cách hiệu quả.
GQA / MQA: Các biến thể chú ý (attention) giúp giảm kích thước KV-cache và cải thiện hiệu quả suy luận.
Inference (Suy luận): Chạy mô hình để tạo ra đầu ra.
KV Cache: Bộ nhớ đệm các trạng thái chú ý khóa/giá trị (key/value) cho các token trước đó.
Prefill (Điền trước): Giai đoạn mô hình xử lý prompt đầu vào trước khi tạo sinh.
RoPE: Rotary Position Embeddings, một phương pháp mã hóa vị trí phổ biến trong các LLM hiện đại.
Speculative Decoding (Giải mã suy đoán): Một kỹ thuật tăng tốc nơi một trình đề xuất rẻ hơn đưa ra các token và mô hình mục tiêu xác minh chúng.
Tokenizer: Thành phần chuyển đổi văn bản thành ID token và ngược lại.
Top-p / Top-k / Temperature: Các biện pháp kiểm soát lấy mẫu để tạo token.

Truy Xuất, Tệp Và Phục Vụ

AWQ: Lượng tử hóa trọng số nhận biết kích hoạt (Activation-aware weight quantization).
Embedding Model (Mô hình embedding): Mô hình chuyển đổi văn bản thành vector để tìm kiếm/truy xuất.
FP8 KV Cache: Một chế độ nén KV-cache 8-bit thực tế được hỗ trợ trong một số runtime.
GGUF: Một định dạng tệp mô hình được sử dụng nhiều bởi llama.cpp.
PagedAttention: Một kỹ thuật quản lý bộ nhớ KV-cache được sử dụng bởi các dịch vụ kiểu vLLM.
Quantization (Lượng tử hóa): Giảm độ chính xác số học để tiết kiệm bộ nhớ và cải thiện hiệu quả.
RAG: Retrieval-Augmented Generation (Tạo sinh tăng cường truy xuất). Truy xuất ngữ cảnh bên ngoài có liên quan và cung cấp nó cho mô hình.
Reranker (Bộ xếp hạng lại): Mô hình sắp xếp lại các đoạn văn bản đã truy xuất theo mức độ liên quan.
Safetensors: Một định dạng tuần tự hóa tensor an toàn hơn, tránh các rủi ro thực thi dựa trên pickle.

Lời Kết

Hệ sinh thái LLM cục bộ bao gồm các mô hình biên địa nhỏ gọn, mô hình tiêu dùng mạnh 7B đến 32B, hệ thống trọng số mở MoE lớn, mô hình đa phương thức, mô hình ngữ cảnh dài, mô hình suy luận cục bộ, runtime suy luận trưởng thành và các ngăn xếp dịch vụ riêng tư ngày càng có khả năng.

Nhưng những điều cơ bản vẫn không thay đổi: mô hình dự đoán từng token một, token không phải là từ, trọng số không phải là toàn bộ mô hình, mẫu trò chuyện rất quan trọng, KV cache là hóa đơn bộ nhớ ẩn, lượng tử hóa là một sự đánh đổi, ngữ cảnh dài không miễn phí, chất lượng RAG phụ thuộc vào khả năng truy xuất, tinh chỉnh cần đánh giá và quyền riêng tư cục bộ vẫn yêu cầu kỷ luật bảo mật.

Bạn không cần thần thoại để chạy các mô hình cục bộ tốt. Bạn cần biết cái gì vừa vặn trong bộ nhớ, mẫu nào mô hình mong đợi, runtime hoạt động như thế nào và liệu các đánh giá của bạn có phù hợp với công việc bạn quan tâm hay không.

LLM cục bộ chủ yếu là tính toán bộ nhớ cộng với định dạng cộng với đánh giá. Hãy nắm vững những điều đó và phần còn lại của ngăn xếp sẽ trở nên dễ suy luận hơn nhiều.

Hẹn gặp lại lần sau.

-Ahmad