Chạy LLM trên thiết bị biên là việc đưa một mô hình ngôn ngữ lớn thu nhỏ xuống chạy trực tiếp trên điện thoại, laptop hay máy tính cá nhân, không cần gửi dữ liệu lên máy chủ đám mây. Nhờ lượng tử hóa INT4 và các công cụ như llama.cpp, Ollama, ONNX Runtime, một mô hình vài tỷ tham số vốn cần hàng chục GB bộ nhớ nay có thể chạy offline ngay trên laptop thông thường, trả lời trong vài chục mili-giây, không tốn phí API theo lượt dùng, và dữ liệu của bạn không bao giờ rời khỏi thiết bị. Bài viết này giải thích vì sao chạy LLM tại chỗ lại quan trọng, lượng tử hóa hoạt động ra sao, các định dạng và công cụ phổ biến khác nhau thế nào, cách chọn mô hình nhỏ cho thiết bị biên, và hướng dẫn thực hành chạy LLM offline trên laptop của bạn.
Chạy LLM trên thiết bị biên là gì?
Chạy LLM trên thiết bị biên (on-device LLM, edge LLM) là việc thực thi một mô hình ngôn ngữ lớn ngay trên thiết bị của người dùng — điện thoại thông minh, laptop, máy tính bảng, máy tính mini, thậm chí máy tính nhúng — thay vì gọi API tới một mô hình đặt trên máy chủ đám mây. Khi bạn gõ một câu hỏi vào ứng dụng chatbot chạy tại chỗ, toàn bộ quá trình xử lý diễn ra trong chính thiết bị của bạn: mô hình đọc câu hỏi, tính toán xác suất cho từng từ tiếp theo, và sinh ra câu trả lời, token nối tiếp token, mà không một byte dữ liệu nào phải đi qua internet.
Khái niệm này nghe có vẻ mới, nhưng thực ra nó là sự quay lại của một nguyên tắc cũ trong kỹ thuật phần mềm: đưa tính toán về gần nơi dữ liệu sinh ra. Trong nhiều năm, xu hướng chung là tập trung sức mạnh tính toán vào trung tâm dữ liệu, vì mô hình ngôn ngữ quá lớn để chạy ở đâu khác. Một mô hình hàng trăm tỷ tham số cần hàng trăm GB bộ nhớ và các GPU chuyên dụng đắt tiền, nên cách duy nhất để người dùng bình thường tiếp cận nó là qua API. Nhưng khi các mô hình nhỏ trở nên đủ tốt cho nhiều tác vụ thực tế, và khi kỹ thuật lượng tử hóa thu nhỏ mô hình xuống còn một phần nhỏ kích thước gốc, cán cân bắt đầu đổi chiều. Một mô hình 7 tỷ tham số ở độ chính xác FP16 cần khoảng 14 GB bộ nhớ chỉ để chứa trọng số; sau khi lượng tử hóa xuống INT4, nó chỉ còn khoảng 4 GB — vừa đủ để chạy trên một laptop tầm trung hay một điện thoại cao cấp.
Sự thay đổi này không chỉ là chuyện kỹ thuật. Nó thay đổi cả mô hình kinh tế và mô hình quyền riêng tư của AI. Khi mô hình chạy trên thiết bị, chi phí biên của mỗi câu hỏi gần như bằng không: không có hóa đơn API tăng theo số lượt dùng, không có nhà cung cấp nào ghi lại nội dung trò chuyện, không có rủi ro rò rỉ dữ liệu qua đường truyền. Với doanh nghiệp, điều đó có nghĩa là có thể đưa trợ lý AI vào sản phẩm mà không phụ thuộc vào một nhà cung cấp bên ngoài, không lo giá API thay đổi, và không lo dịch vụ ngừng hoạt động khi mất mạng. Với người dùng cá nhân, điều đó có nghĩa là một trợ lý AI luôn sẵn sàng, kể cả trên máy bay, trong vùng không có sóng, hay trong môi trường yêu cầu bảo mật cao.
Cần phân biệt rõ chạy LLM trên thiết bị biên với hai khái niệm hay bị nhầm lẫn. Thứ nhất, nó khác với AI biên phần cứng — các chip NPU, SoC AI chuyên dụng như chip trong bài viết về REGULUS Edge AI SoC. Bài về chip tập trung vào phần cứng: TOPS, watt, kiến trúc NPU và DSP. Bài này tập trung vào phía phần mềm: làm thế nào để một mô hình ngôn ngữ vốn được huấn luyện trên cụm GPU khổng lồ lại có thể chạy được trên phần cứng phổ thông mà bạn đã có sẵn. Phần cứng và phần mềm bổ sung cho nhau — chip AI biên mạnh giúp mô hình chạy nhanh hơn — nhưng ngay cả không có chip AI chuyên dụng, bạn vẫn có thể chạy LLM trên CPU và GPU thông thường nhờ lượng tử hóa và các công cụ tối ưu. Thứ hai, chạy LLM tại chỗ khác với việc tinh chỉnh mô hình (fine-tuning). Tinh chỉnh là quá trình huấn luyện thêm để mô hình học một nhiệm vụ riêng; chạy tại chỗ là quá trình suy luận (inference) — dùng mô hình đã có để trả lời câu hỏi. Bạn hoàn toàn có thể chạy một mô hình đã được người khác tinh chỉnh sẵn cho một lĩnh vực cụ thể, ví dụ mô hình viết code hay mô hình y khoa, mà không cần tự huấn luyện gì thêm.
Vì sao nên chạy LLM ngay trên thiết bị?
Riêng tư là lý do mạnh nhất. Khi bạn dùng chatbot đám mây, mọi câu hỏi, tài liệu và đoạn hội thoại đều được gửi lên máy chủ của nhà cung cấp. Với tài liệu nội bộ, hợp đồng, hồ sơ bệnh án, mã nguồn độc quyền hay đơn giản là nhật ký cá nhân, việc gửi dữ liệu ra ngoài luôn tiềm ẩn rủi ro — dù nhà cung cấp cam kết không dùng dữ liệu để huấn luyện, dữ liệu vẫn phải đi qua mạng, nằm trên máy chủ của bên thứ ba, và chịu chính sách của họ. Chạy LLM tại chỗ loại bỏ hoàn toàn rủi ro này: dữ liệu thô không bao giờ rời khỏi thiết bị. Đây là lý do các tổ chức trong lĩnh vực tài chính, y tế, pháp lý và quốc phòng đặc biệt quan tâm tới LLM trên thiết bị biên. Ngay cả khi bạn chỉ là người dùng cá nhân, một trợ lý AI có thể đọc toàn bộ email, ghi chú và tài liệu của bạn mà không gửi bất kỳ thứ gì lên mạng là một sự khác biệt rất lớn về mặt cảm giác an toàn.
Hoạt động offline là lý do thứ hai. Internet không phải lúc nào cũng có sẵn và đáng tin cậy. Trên máy bay, trên tàu, ở vùng sâu vùng xa, trong nhà máy có mạng nội bộ bị cô lập, hay đơn giản là khi mạng Wi-Fi chập chờn, một chatbot đám mây trở nên vô dụng. LLM trên thiết bị hoạt động độc lập với kết nối mạng — chỉ cần tải mô hình về một lần, sau đó dùng bao nhiêu lần cũng được. Với các ứng dụng quan trọng như trợ lý cho kỹ sư hiện trường, phiên dịch trong vùng không có sóng, hay công cụ hỗ trợ bác sĩ ở trạm y tế vùng cao, khả năng offline không phải là tính năng thêm mà là yêu cầu bắt buộc.
Độ trễ thấp là lý do thứ ba. Mỗi lần gọi API đám mây đều phải trải qua một vòng đi và về qua mạng: gửi câu hỏi, chờ máy chủ xử lý, nhận từng token trả về. Ngay cả với mạng tốt, độ trễ này thường là hàng trăm mili-giây cho token đầu tiên, và có thể tăng vọt khi máy chủ quá tải. Khi mô hình chạy tại chỗ, token đầu tiên xuất hiện gần như ngay lập tức sau khi bạn nhấn Enter, vì không có bước truyền mạng nào. Với các ứng dụng tương tác theo thời gian thực — gợi ý code khi đang gõ, dịch lời nói trực tiếp, trợ lý giọng nói — độ trễ thấp tạo ra cảm giác mượt mà mà API đám mây khó đạt được. Ngoài ra, tốc độ sinh token của mô hình nhỏ trên thiết bị thường đủ nhanh cho nhu cầu đọc của con người: tốc độ 10–20 token mỗi giây đã tương đương hoặc nhanh hơn tốc độ đọc trung bình, nên người dùng không cảm thấy chờ đợi.
Không phí API và chi phí dự đoán được là lý do thứ tư. API của các mô hình đám mây thường tính phí theo số token đầu vào và đầu ra. Với một ứng dụng có nhiều người dùng, hoặc một tác vụ cần xử lý khối lượng lớn tài liệu — ví dụ tóm tắt hàng nghìn trang văn bản, phân loại hàng vạn email — chi phí API có thể tăng rất nhanh và khó dự đoán. Ngược lại, chi phí của LLM trên thiết bị là chi phí phần cứng trả trước một lần: mua laptop, tải mô hình miễn phí, và dùng bao nhiêu cũng không phát sinh thêm phí. Với các mô hình mã nguồn mở hoặc mở trọng số, bản thân mô hình cũng miễn phí, nên tổng chi phí sở hữu trong dài hạn thường thấp hơn nhiều so với việc trả phí API liên tục. Đây là lý do nhiều startup chọn LLM trên thiết bị cho các tính năng AI có tần suất sử dụng cao nhưng mỗi lần dùng chỉ cần mô hình nhỏ là đủ.
Độc lập với nhà cung cấp là lý do thứ năm. Khi sản phẩm của bạn phụ thuộc vào một API bên ngoài, bạn phụ thuộc vào chính sách giá, giới hạn sử dụng, thời gian hoạt động và cả sự tồn tại của nhà cung cấp đó. API có thể tăng giá, thay đổi điều khoản, giới hạn tốc độ, hoặc ngừng hỗ trợ một mô hình mà sản phẩm của bạn đang dùng. LLM trên thiết bị loại bỏ sự phụ thuộc này: mô hình nằm trong tay bạn, chạy trên phần cứng của bạn, theo lịch trình của bạn. Điều này đặc biệt quan trọng với sản phẩm phần cứng — ví dụ một thiết bị bán ra thị trường phải hoạt động ổn định trong nhiều năm — vì bạn không thể chấp nhận việc một dịch vụ đám mây thay đổi làm hỏng thiết bị đã bán.
Tuy vậy, cần nói thẳng: chạy LLM tại chỗ không phải lúc nào cũng là lựa chọn đúng. Nếu nhiệm vụ cần mô hình lớn nhất, kiến thức cập nhật nhất, khả năng suy luận phức tạp nhất, hoặc cần truy cập internet để tra cứu thông tin mới, mô hình đám mây vẫn vượt trội. Phần cuối bài sẽ nói rõ giới hạn này. Lựa chọn đúng thường không phải “biên hay đám mây” mà là “cái nào cho việc nào” — và để quyết định được, trước hết cần hiểu rào cản kỹ thuật của việc chạy LLM trên thiết bị.
Rào cản: vì sao LLM khó chạy trên thiết bị biên?
Kích thước mô hình là rào cản đầu tiên và lớn nhất. Một mô hình ngôn ngữ được tạo thành từ hàng tỷ tham số — mỗi tham số là một con số mà mô hình học được trong quá trình huấn luyện. Mô hình 7 tỷ tham số có 7 tỷ con số; mô hình 70 tỷ tham số có 70 tỷ con số. Nếu mỗi con số được lưu ở độ chính xác FP16 (16 bit, tức 2 byte), mô hình 7B cần khoảng 14 GB bộ nhớ chỉ để chứa trọng số, chưa tính bộ nhớ cho quá trình tính toán. Mô hình 70B cần khoảng 140 GB — vượt xa bộ nhớ của bất kỳ laptop hay điện thoại nào. Ngay cả mô hình 7B ở FP16 cũng đã vượt quá RAM của nhiều laptop phổ thông và gần như mọi điện thoại. Đây là lý do trong nhiều năm, LLM chỉ có thể chạy trên máy chủ: đơn giản là thiết bị cá nhân không đủ bộ nhớ để chứa chúng.
Bộ nhớ trong quá trình chạy (KV cache) là rào cản thứ hai, ít được nhắc tới nhưng rất thực tế. Khi mô hình sinh văn bản, nó cần nhớ lại những gì đã xử lý trước đó để duy trì ngữ cảnh — cơ chế này gọi là key-value cache, hay KV cache. KV cache tăng lên theo độ dài của cuộc trò chuyện: hội thoại càng dài, càng nhiều token ngữ cảnh, KV cache càng lớn. Một mô hình 7B với ngữ cảnh 8.000 token có thể cần thêm vài GB bộ nhớ chỉ cho KV cache. Điều này có nghĩa là dung lượng bộ nhớ thực tế cần thiết lớn hơn con số trọng số mô hình, và một thiết bị vừa đủ chứa mô hình có thể vẫn bị tràn bộ nhớ khi cuộc trò chuyện kéo dài. Các công cụ hiện đại đã có nhiều kỹ thuật để nén KV cache, nhưng người dùng vẫn cần chừa dư bộ nhớ cho nó khi chọn mô hình và độ dài ngữ cảnh.
Tốc độ tính toán và điện năng là rào cản thứ ba. Sinh mỗi token mới đòi hỏi mô hình phải thực hiện một lượt tính toán qua toàn bộ mạng thần kinh — với mô hình 7B, đó là hàng tỷ phép tính cho mỗi token. CPU của laptop có thể làm được việc này, nhưng chậm hơn GPU chuyên dụng nhiều lần, và khi chạy hết công suất sẽ nóng máy, tốn pin và làm quạt kêu to. Điện thoại còn bị giới hạn chặt hơn: pin nhỏ, tản nhiệt thụ động, và hệ điều hành có thể giảm hiệu năng khi máy nóng lên. Vì vậy, chạy LLM trên thiết bị biên luôn là một bài toán cân bằng giữa tốc độ, nhiệt độ và thời lượng pin — không chỉ là chuyện “chạy được hay không” mà là “chạy đủ nhanh và đủ mát để dùng được lâu hay không”.
Chất lượng mô hình nhỏ là rào cản thứ tư, về mặt nội dung chứ không phải phần cứng. Mô hình càng nhỏ thì kiến thức và khả năng suy luận càng hạn chế. Một mô hình 1–3 tỷ tham số có thể viết văn bản trôi chảy, tóm tắt tài liệu ngắn và trả lời câu hỏi thông thường khá tốt, nhưng sẽ gặp khó với toán học phức tạp, suy luận nhiều bước, viết code dài, hay kiến thức chuyên ngành sâu. Người dùng cần hiểu rõ giới hạn này để đặt kỳ vọng đúng: LLM trên thiết bị là một trợ lý giỏi cho nhiều việc hàng ngày, không phải là một chuyên gia toàn năng. May mắn là chất lượng mô hình nhỏ đang cải thiện rất nhanh nhờ dữ liệu huấn luyện tốt hơn và kiến trúc hiệu quả hơn — một mô hình 3B ngày nay có thể làm được những việc mà mô hình 7B của hai năm trước còn chật vật.
Tóm lại, bài toán chạy LLM trên thiết bị biên có thể phát biểu gọn như sau: làm thế nào để nhét một mô hình đủ thông minh vào một bộ nhớ đủ nhỏ, chạy đủ nhanh trên phần cứng đủ yếu, mà vẫn giữ được chất lượng trả lời đủ tốt. Lượng tử hóa là câu trả lời quan trọng nhất cho bài toán này, và đó là chủ đề của phần tiếp theo.
Lượng tử hóa là gì? Từ FP16 xuống INT8 rồi INT4
Lượng tử hóa (quantization) là kỹ thuật giảm độ chính xác số học của các tham số trong mô hình, từ đó thu nhỏ kích thước mô hình và tăng tốc độ tính toán. Ý tưởng rất đơn giản: thay vì lưu mỗi tham số bằng một số thực 16 bit hay 32 bit với độ chính xác cao, ta lưu nó bằng một số nguyên 8 bit hay 4 bit với độ chính xác thấp hơn. Vì các tham số của mô hình ngôn ngữ thường tập trung trong một khoảng giá trị hẹp và mô hình có khả năng chịu nhiễu nhất định, việc làm tròn các con số này chỉ làm giảm chất lượng một chút, trong khi kích thước mô hình giảm đi nhiều lần.
Để hiểu vì sao điều này hiệu quả, hãy hình dung mỗi tham số như một điểm trên một thước đo. Ở độ chính xác FP32 (32 bit), thước đo có hàng tỷ vạch chia, mô tả vị trí của điểm cực kỳ chính xác. Ở FP16 (16 bit), thước đo có khoảng 65.000 vạch chia — vẫn rất chính xác cho hầu hết mục đích. Ở INT8 (8 bit), thước đo chỉ còn 256 vạch chia, và ở INT4 (4 bit) chỉ còn 16 vạch chia. Rõ ràng, INT4 là một phép làm tròn rất thô: mỗi tham số chỉ còn 16 giá trị có thể. Điều đáng ngạc nhiên là các mô hình ngôn ngữ vẫn hoạt động tốt sau phép làm tròn này, vì chúng có hàng tỷ tham số bù trừ cho nhau — sai số của từng tham số riêng lẻ phần lớn triệt tiêu lẫn nhau, và mô hình vẫn giữ được “hình dáng” tổng thể của kiến thức đã học. Đây là một phát hiện thực nghiệm quan trọng của ngành, không phải điều hiển nhiên từ lý thuyết.
FP16 là điểm xuất phát. Hầu hết mô hình ngôn ngữ hiện nay được huấn luyện và phát hành ở độ chính xác FP16 hoặc BF16 (một biến thể 16 bit khác, phổ biến trong huấn luyện). Đây là độ chính xác “đầy đủ” của mô hình, cho chất lượng cao nhất. Một mô hình 7B ở FP16 cần khoảng 14 GB bộ nhớ. FP16 là lựa chọn tốt khi bạn có GPU mạnh với nhiều VRAM, ví dụ chạy mô hình trên máy trạm có GPU 24 GB, nhưng nó quá nặng cho laptop và điện thoại thông thường.
INT8 là bước lượng tử hóa nhẹ. Mỗi tham số chỉ còn 8 bit, tức 1 byte, nên mô hình 7B chỉ còn khoảng 7 GB. Chất lượng sau khi lượng tử hóa INT8 gần như không thay đổi so với FP16 trong hầu hết tác vụ — sai số làm tròn ở mức 8 bit quá nhỏ để ảnh hưởng đáng kể tới đầu ra. INT8 là lựa chọn an toàn khi bạn có đủ bộ nhớ và muốn giữ chất lượng tối đa: ví dụ laptop có 16 GB RAM có thể chạy mô hình 7B INT8 thoải mái, còn chừa chỗ cho KV cache và hệ điều hành. Nhược điểm duy nhất của INT8 là mô hình vẫn còn khá lớn, và tốc độ tính toán trên CPU chưa được tối ưu bằng INT4.
INT4 là bước lượng tử hóa mạnh và là tiêu chuẩn thực tế cho LLM trên thiết bị biên. Mỗi tham số chỉ còn 4 bit, tức nửa byte, nên mô hình 7B chỉ còn khoảng 3,5–4 GB. Đây là mức giảm 4 lần so với FP16, đủ để đưa mô hình 7B vào laptop 8 GB RAM hay điện thoại cao cấp. Chất lượng sau INT4 có giảm so với FP16, nhưng mức giảm thường nhỏ và khó nhận thấy trong sử dụng hàng ngày: văn bản vẫn trôi chảy, câu trả lời vẫn đúng trong phần lớn trường hợp, chỉ một số tác vụ nhạy cảm như toán học chính xác hay suy luận logic phức tạp mới thấy rõ sự khác biệt. Trong thực tế, nhiều người dùng không phân biệt được đầu ra của mô hình 7B INT4 với FP16 khi dùng cho tóm tắt, viết email, hỏi đáp kiến thức chung hay trò chuyện. INT4 là điểm cân bằng tốt nhất hiện nay giữa kích thước, tốc độ và chất lượng — đó là lý do hầu hết hướng dẫn chạy LLM trên thiết bị đều bắt đầu từ INT4.
Còn có thể đi xa hơn INT4 không? Có — các định dạng INT3, INT2 và thậm chí 1 bit đang được nghiên cứu, và một số công cụ đã hỗ trợ thử nghiệm. Nhưng ở mức đó, chất lượng giảm rõ rệt: mô hình bắt đầu nói lan man, lặp từ, mất mạch logic. Với người dùng thực tế năm 2026, INT4 là ngưỡng nên dừng lại; INT3 chỉ nên thử khi bạn thực sự thiếu bộ nhớ và chấp nhận đánh đổi chất lượng. Một hướng khác là lượng tử hóa hỗn hợp: giữ một số lớp quan trọng của mô hình ở độ chính xác cao hơn (ví dụ INT8) và lượng tử hóa mạnh các lớp ít nhạy cảm hơn xuống INT4. Các định dạng hiện đại như GGUF đã làm điều này một cách tinh vi, giúp chất lượng tổng thể tốt hơn so với lượng tử hóa đều toàn bộ mô hình xuống cùng một mức.
Một điểm quan trọng cần hiểu đúng: lượng tử hóa không làm mô hình “thông minh hơn” hay “học thêm kiến thức”. Nó chỉ là kỹ thuật nén — giống như nén một bức ảnh từ định dạng không nén sang JPEG: ảnh nhỏ hơn nhiều, chất lượng giảm một chút, nhưng vẫn nhận ra nội dung. Và giống như JPEG, mức nén càng mạnh thì mất mát càng nhiều. Người dùng nên chọn mức lượng tử hóa theo bộ nhớ sẵn có: đủ bộ nhớ thì dùng INT8, thiếu bộ nhớ thì dùng INT4, và chỉ dùng mức thấp hơn khi không còn lựa chọn nào khác.
Các định dạng lượng tử hóa: GGUF, AWQ, GPTQ và EXL2
Khi tải một mô hình đã lượng tử hóa về, bạn sẽ gặp nhiều định dạng file khác nhau. Mỗi định dạng gắn với một công cụ suy luận nhất định, và chọn sai định dạng có thể khiến mô hình không chạy được trên công cụ bạn định dùng. Dưới đây là các định dạng phổ biến nhất mà người dùng thiết bị biên sẽ gặp.
GGUF — định dạng chuẩn cho CPU và thiết bị biên
GGUF là định dạng file mô hình của llama.cpp, và hiện là định dạng phổ biến nhất cho chạy LLM trên CPU và thiết bị biên. GGUF chứa toàn bộ trọng số mô hình đã lượng tử hóa cùng với siêu dữ liệu như từ điển token, cấu hình kiến trúc và các tham số cần thiết để chạy mô hình. Điểm mạnh lớn nhất của GGUF là tính linh hoạt: cùng một file GGUF có thể chạy trên CPU, GPU, hay kết hợp cả hai, trên Windows, macOS, Linux, Android, và cả trên các thiết bị nhúng. llama.cpp đã tối ưu rất sâu cho GGUF trên CPU, tận dụng các tập lệnh vector như AVX2, AVX-512 trên CPU Intel/AMD và NEON trên CPU ARM, nên tốc độ sinh token trên CPU hiện đại đã đủ nhanh cho sử dụng thực tế.
GGUF có nhiều biến thể lượng tử hóa, ký hiệu bằng các mã như Q4_K_M, Q4_K_S, Q5_K_M, Q8_0. Mã này cho biết mức độ lượng tử hóa và chiến lược phân bổ độ chính xác giữa các lớp. Quy tắc chung: số càng lớn thì chất lượng càng cao và file càng lớn; hậu tố K_M (medium) cân bằng hơn K_S (small). Trong thực tế, Q4_K_M là lựa chọn mặc định tốt nhất cho hầu hết người dùng: mô hình 7B ở Q4_K_M khoảng 4 GB, chất lượng rất gần FP16, tốc độ nhanh. Nếu bạn có nhiều RAM và muốn chất lượng cao hơn, Q5_K_M (khoảng 5 GB cho mô hình 7B) là bước nâng cấp hợp lý. Nếu bạn thiếu RAM, Q4_K_S nhỏ hơn Q4_K_M một chút với chất lượng thấp hơn không đáng kể. Q8_0 là mức gần như không mất chất lượng, phù hợp khi bạn có RAM dư dả. Người mới bắt đầu chỉ cần nhớ: bắt đầu với Q4_K_M, và chỉ thay đổi khi có lý do cụ thể.
AWQ — lượng tử hóa tối ưu cho GPU
AWQ (Activation-aware Weight Quantization) là phương pháp lượng tử hóa xuống 4 bit được thiết kế riêng để chạy nhanh trên GPU. Ý tưởng của AWQ là không phải mọi trọng số đều quan trọng như nhau: một số ít trọng số có ảnh hưởng lớn tới đầu ra, và AWQ bảo vệ các trọng số quan trọng này bằng cách giữ chúng ở độ chính xác cao hơn hoặc điều chỉnh thang đo cho phù hợp. Kết quả là mô hình AWQ INT4 thường giữ chất lượng tốt hơn so với lượng tử hóa INT4 thông thường ở cùng kích thước, đồng thời chạy rất nhanh trên GPU nhờ các kernel tính toán được tối ưu riêng. AWQ là lựa chọn tốt khi bạn có GPU NVIDIA và dùng các công cụ suy luận hỗ trợ AWQ như vLLM hay các giao diện chạy trên GPU. Nhược điểm của AWQ là nó kém linh hoạt hơn GGUF: mô hình AWQ chủ yếu chạy trên GPU, không tối ưu cho CPU, và hệ sinh thái công cụ hỗ trợ hẹp hơn.
GPTQ — lượng tử hóa 4 bit kinh điển cho GPU
GPTQ là một trong những phương pháp lượng tử hóa 4 bit đầu tiên được dùng rộng rãi cho LLM, ra đời trước AWQ. GPTQ lượng tử hóa từng lớp của mô hình một cách lần lượt, dùng thông tin từ dữ liệu hiệu chuẩn để giảm thiểu sai số do làm tròn gây ra. Mô hình GPTQ chạy tốt trên GPU với các công cụ như text-generation-webui hay các backend suy luận hỗ trợ GPTQ. So với AWQ, GPTQ có hệ sinh thái rộng hơn về số lượng mô hình đã được lượng tử hóa sẵn, nhưng AWQ thường cho tốc độ nhanh hơn một chút trên GPU hiện đại. Với người dùng thiết bị biên chạy trên CPU hoặc laptop không có GPU mạnh, cả AWQ và GPTQ đều ít phù hợp hơn GGUF — chúng là lựa chọn của người có GPU, không phải của người chạy trên CPU.
EXL2 và các định dạng khác
EXL2 là định dạng của ExLlamaV2, một công cụ suy luận tối ưu cho GPU, cho phép lượng tử hóa hỗn hợp với độ chính xác khác nhau cho từng lớp — ví dụ trung bình 4,5 bit hay 5 bit thay vì cố định 4 bit. EXL2 cho phép tinh chỉnh rất chi tiết giữa kích thước và chất lượng, và chạy rất nhanh trên GPU. Ngoài ra còn có các định dạng như MLC cho MLC LLM, Core ML cho thiết bị Apple, và ONNX cho ONNX Runtime — mỗi định dạng gắn với một hệ sinh thái công cụ riêng. Người dùng không cần nhớ hết tất cả: chỉ cần nhớ nguyên tắc chọn công cụ trước, chọn định dạng sau. Nếu bạn định dùng llama.cpp hay Ollama, hãy tải file GGUF. Nếu bạn định dùng vLLM trên GPU, hãy tải AWQ hoặc GPTQ. Nếu bạn định dùng ONNX Runtime, hãy tải mô hình ONNX. Tải sai định dạng là lỗi phổ biến nhất của người mới, và cách tránh nó rất đơn giản: đọc tài liệu của công cụ bạn dùng trước khi tải mô hình.
| Định dạng | Mức lượng tử hóa | Chạy tốt nhất trên | Công cụ chính | Ưu điểm | Hạn chế |
|---|---|---|---|---|---|
| GGUF | INT4, INT5, INT8 | CPU, GPU, đa nền tảng | llama.cpp, Ollama | Linh hoạt nhất, chạy tốt trên CPU, nhiều mô hình sẵn có | Tốc độ trên GPU chưa bằng AWQ/EXL2 |
| AWQ | INT4 | GPU NVIDIA | vLLM, các backend GPU | Nhanh trên GPU, chất lượng tốt ở INT4 | Kém hiệu quả trên CPU, hệ sinh thái hẹp hơn |
| GPTQ | INT4, INT3 | GPU NVIDIA | text-generation-webui, vLLM | Nhiều mô hình sẵn có, đã kiểm chứng lâu năm | Tốc độ thường chậm hơn AWQ trên GPU mới |
| EXL2 | Hỗn hợp 3–8 bit | GPU NVIDIA | ExLlamaV2 | Tinh chỉnh chi tiết, rất nhanh trên GPU | Chỉ chạy trên GPU, ít mô hình sẵn có |
| ONNX | INT8, FP16 | CPU, GPU, thiết bị di động | ONNX Runtime | Chuẩn mở, chạy đa nền tảng, tích hợp ứng dụng tốt | Ít mô hình LLM sẵn có ở dạng ONNX tối ưu |
Một lưu ý thực tế về nguồn tải mô hình: cộng đồng chia sẻ rất nhiều mô hình đã lượng tử hóa sẵn trên các nền tảng mở như Hugging Face, trong đó có các tài khoản chuyên lượng tử hóa mô hình phổ biến sang GGUF, AWQ hay GPTQ. Việc tải mô hình đã lượng tử hóa sẵn giúp bạn bỏ qua bước tự lượng tử hóa — một bước đòi hỏi kiến thức kỹ thuật và máy tính mạnh. Tuy nhiên, hãy chỉ tải mô hình từ các nguồn uy tín, kiểm tra giấy phép sử dụng của mô hình gốc, và lưu ý rằng mô hình lượng tử hóa bởi bên thứ ba có thể khác đôi chút so với mô hình gốc về chất lượng. Với các dự án thương mại, hãy đọc kỹ giấy phép: một số mô hình mở trọng số cho phép dùng thương mại, một số khác giới hạn ở mục đích nghiên cứu hoặc yêu cầu ghi rõ nguồn gốc.
Các công cụ chạy LLM trên thiết bị: llama.cpp, Ollama, ONNX Runtime, MLC LLM, ExecuTorch
Có mô hình đã lượng tử hóa rồi, bạn vẫn cần một công cụ để chạy nó — gọi là bộ máy suy luận (inference engine). Bộ máy suy luận đọc file mô hình, nạp trọng số vào bộ nhớ, nhận câu hỏi của bạn, chạy tính toán và sinh ra câu trả lời token by token. Mỗi công cụ có triết lý riêng, đối tượng riêng và mức độ dễ dùng riêng. Phần này giới thiệu năm công cụ quan trọng nhất mà người dùng thiết bị biên nên biết.
llama.cpp — nền tảng của hầu hết mọi thứ
llama.cpp là dự án mã nguồn mở viết bằng C/C++ chuyên chạy LLM trên CPU và GPU, và là nền tảng mà rất nhiều công cụ khác xây dựng lên trên. Điểm mạnh lớn nhất của llama.cpp là hiệu năng trên CPU: nhờ tối ưu sâu cho các tập lệnh vector của CPU hiện đại và kỹ thuật tính toán tiết kiệm bộ nhớ, llama.cpp có thể chạy mô hình 7B INT4 trên một laptop thông thường với tốc độ đủ dùng, điều mà trước đây nhiều người cho là không thể. llama.cpp cũng là nơi định dạng GGUF ra đời, và là công cụ đầu tiên hỗ trợ các tính năng mới như cửa sổ ngữ cảnh dài hay các kiến trúc mô hình mới.
llama.cpp đi kèm với llama-server, một máy chủ HTTP nhỏ chạy trên máy của bạn, cung cấp API tương thích với OpenAI. Điều này rất thực tế: bạn có thể chạy llama-server trên laptop, rồi kết nối bất kỳ ứng dụng nào hỗ trợ API OpenAI tới máy chủ cục bộ của mình — ví dụ giao diện chat trên trình duyệt, ứng dụng ghi chú có AI, hay công cụ lập trình. Nhờ đó, bạn có được trải nghiệm giống như dùng API đám mây, nhưng toàn bộ xử lý diễn ra tại chỗ. Nhược điểm của llama.cpp là nó hướng tới người dùng có kiến thức kỹ thuật: bạn cần làm quen với dòng lệnh, các tham số như số luồng CPU, kích thước ngữ cảnh, và cách biên dịch từ mã nguồn hoặc tải bản dựng sẵn. Với người mới, llama.cpp có thể hơi khó tiếp cận, nhưng nó là công cụ đáng học nhất nếu bạn muốn hiểu sâu và kiểm soát tối đa quá trình chạy mô hình.
Ollama — cách dễ nhất để bắt đầu
Ollama là công cụ được xây dựng trên llama.cpp, với mục tiêu làm cho việc chạy LLM trên máy cá nhân trở nên dễ dàng như chạy một ứng dụng thông thường. Bạn cài Ollama, gõ một lệnh để tải mô hình, gõ một lệnh khác để trò chuyện — không cần quan tâm tới định dạng file, tham số dòng lệnh hay cách biên dịch. Ollama tự động chọn cấu hình phù hợp với phần cứng của bạn, tự động dùng GPU khi có, và cung cấp sẵn một thư viện mô hình phổ biến để bạn chọn. Ollama cũng cung cấp API tương thích OpenAI trên máy cục bộ, nên bạn có thể kết nối các ứng dụng khác tới nó giống như llama-server.
Ollama phù hợp nhất với người dùng cá nhân và lập trình viên muốn thử nghiệm nhanh: cài đặt trong vài phút, chạy được ngay, giao diện đơn giản. Hạn chế của Ollama là mức độ tùy biến thấp hơn llama.cpp thuần: bạn khó tinh chỉnh sâu các tham số suy luận hay dùng các định dạng mô hình không có trong thư viện của Ollama. Nhưng với đa số người dùng, sự đơn giản này là một ưu điểm, không phải nhược điểm. Nếu bạn chưa từng chạy LLM tại chỗ, hãy bắt đầu với Ollama — nó là con đường ngắn nhất từ “chưa biết gì” tới “đang trò chuyện với mô hình chạy trên máy mình”. Sau khi đã quen, bạn có thể chuyển sang llama.cpp khi cần kiểm soát sâu hơn.
ONNX Runtime — chuẩn mở cho ứng dụng sản phẩm
ONNX Runtime là bộ máy suy luận mã nguồn mở của Microsoft, hỗ trợ định dạng ONNX — một định dạng mô hình chuẩn mở được nhiều framework huấn luyện hỗ trợ. Điểm mạnh của ONNX Runtime là tính đa nền tảng và khả năng tích hợp vào ứng dụng sản phẩm: nó chạy trên Windows, macOS, Linux, Android, iOS, trên CPU, GPU, và cả trên các chip AI chuyên dụng thông qua các execution provider riêng. Với các nhà phát triển ứng dụng muốn nhúng AI vào sản phẩm của mình — ví dụ một ứng dụng di động có tính năng tóm tắt văn bản offline, hay một phần mềm desktop có trợ lý AI tích hợp — ONNX Runtime là lựa chọn tự nhiên, vì nó được thiết kế cho mục đích đó ngay từ đầu.
Với LLM, ONNX Runtime hỗ trợ các mô hình đã được chuyển đổi sang định dạng ONNX và tối ưu cho suy luận, bao gồm cả các mô hình ngôn ngữ nhỏ. Quy trình thường là: lấy mô hình gốc, chuyển đổi sang ONNX bằng công cụ chuyển đổi, tối ưu và lượng tử hóa, rồi nhúng vào ứng dụng qua ONNX Runtime. Quy trình này phức tạp hơn so với việc tải file GGUF và chạy bằng Ollama, nhưng đổi lại bạn có được một mô hình tích hợp chặt chẽ vào ứng dụng, phân phối cùng ứng dụng, và chạy ổn định trên nhiều loại thiết bị. ONNX Runtime cũng là lựa chọn tốt cho môi trường doanh nghiệp dùng hệ sinh thái Microsoft, vì nó tích hợp tốt với Azure và các công cụ của Microsoft.
MLC LLM — đưa LLM lên điện thoại và trình duyệt
MLC LLM (Machine Learning Compilation for LLM) là dự án mã nguồn mở chuyên biên dịch mô hình ngôn ngữ để chạy trên nhiều loại thiết bị, từ điện thoại, máy tính bảng, laptop tới trình duyệt web. Triết lý của MLC LLM là: thay vì viết một bộ máy suy luận riêng cho từng loại phần cứng, hãy dùng trình biên dịch để biến mô hình thành mã máy tối ưu cho từng thiết bị cụ thể. Nhờ đó, cùng một mô hình có thể chạy trên GPU của điện thoại Android, chip Apple Silicon, GPU NVIDIA trên laptop, hay thậm chí trong trình duyệt web qua WebGPU — mà không cần viết lại code.
MLC LLM đặc biệt phù hợp với các nhà phát triển ứng dụng di động muốn đưa chatbot AI vào ứng dụng của mình mà không phụ thuộc vào máy chủ. Ví dụ: một ứng dụng học ngoại ngữ có trợ lý AI trò chuyện offline, hay một ứng dụng ghi chú có tính năng tóm tắt ngay trên điện thoại. MLC LLM đi kèm với ứng dụng mẫu cho iOS và Android, giúp lập trình viên thử nghiệm nhanh trước khi tích hợp vào sản phẩm thật. Hạn chế của MLC LLM là quy trình biên dịch mô hình đòi hỏi một số bước kỹ thuật, và số lượng mô hình được hỗ trợ sẵn ít hơn so với hệ sinh thái GGUF của llama.cpp. Nhưng nếu mục tiêu của bạn là điện thoại di động, MLC LLM là một trong những lựa chọn đáng xem nhất.
ExecuTorch — suy luận trên thiết bị của Meta
ExecuTorch là framework suy luận trên thiết bị của Meta, được thiết kế để chạy các mô hình AI — bao gồm cả mô hình ngôn ngữ — trực tiếp trên điện thoại và thiết bị biên, với hiệu năng cao và mức tiêu thụ điện năng thấp. ExecuTorch kế thừa từ PyTorch, framework huấn luyện phổ biến nhất hiện nay, nên các mô hình PyTorch có thể được xuất sang ExecuTorch tương đối thuận lợi. Meta dùng ExecuTorch trong các sản phẩm của mình, và đã công bố hỗ trợ chạy các mô hình ngôn ngữ nhỏ trên điện thoại thông qua framework này.
Với lập trình viên, ExecuTorch là lựa chọn đáng cân nhắc khi đã quen với PyTorch và muốn đưa mô hình vào ứng dụng di động một cách bài bản, có hỗ trợ từ một framework lớn. Với người dùng cuối, bạn ít khi tương tác trực tiếp với ExecuTorch — bạn sẽ gặp nó dưới dạng tính năng AI bên trong một ứng dụng nào đó, chứ không phải một công cụ độc lập để tải về và chạy như Ollama. Vì vậy, trong bài này, ExecuTorch được giới thiệu để bạn hiểu bức tranh đầy đủ: phía sau những ứng dụng AI trên điện thoại trong tương lai, rất có thể là ExecuTorch, MLC LLM hay ONNX Runtime đang làm việc.
| Công cụ | Đối tượng chính | Chạy tốt nhất trên | Độ dễ dùng | Điểm mạnh nổi bật |
|---|---|---|---|---|
| llama.cpp / llama-server | Người dùng kỹ thuật, nghiên cứu | CPU, GPU đa nền tảng | Trung bình, cần dòng lệnh | Hiệu năng CPU tốt nhất, hỗ trợ mô hình mới sớm nhất, kiểm soát tối đa |
| Ollama | Người dùng cá nhân, lập trình viên mới bắt đầu | Laptop, máy tính cá nhân | Rất dễ, vài lệnh là chạy | Cài đặt nhanh, thư viện mô hình sẵn có, API tương thích OpenAI |
| ONNX Runtime | Nhà phát triển ứng dụng, doanh nghiệp | Đa nền tảng, di động, desktop | Trung bình, cần tích hợp code | Chuẩn mở, nhúng vào sản phẩm tốt, chạy nhiều loại phần cứng |
| MLC LLM | Nhà phát triển ứng dụng di động | Điện thoại, trình duyệt, laptop | Trung bình, cần biên dịch mô hình | Một mô hình chạy nhiều thiết bị, hỗ trợ WebGPU và di động tốt |
| ExecuTorch | Nhà phát triển dùng PyTorch | Điện thoại, thiết bị biên | Trung bình, cần kiến thức PyTorch | Kế thừa PyTorch, tối ưu cho di động, được Meta dùng trong sản phẩm thật |
Nguyên tắc chọn công cụ rất đơn giản. Người dùng cá nhân muốn thử ngay: chọn Ollama. Người dùng kỹ thuật muốn kiểm soát tối đa và hiệu năng CPU tốt nhất: chọn llama.cpp. Nhà phát triển muốn nhúng AI vào ứng dụng di động hay desktop: xem xét MLC LLM, ONNX Runtime hoặc ExecuTorch tùy theo hệ sinh thái mình đang dùng. Doanh nghiệp muốn triển khai LLM offline cho nội bộ: bắt đầu bằng Ollama hoặc llama-server để kiểm chứng, rồi mới tính tới tích hợp sâu bằng ONNX Runtime hay MLC LLM. Trong mọi trường hợp, đừng chọn công cụ chỉ vì nó nổi tiếng — hãy chọn công cụ phù hợp với phần cứng bạn có và mục đích bạn cần.
Chọn mô hình nhỏ cho thiết bị biên: mô hình 1–8B nào phù hợp?
Kích thước mô hình, tính bằng số tỷ tham số (B), là yếu tố đầu tiên cần xem xét. Mô hình càng lớn thì càng thông minh, nhưng càng nặng và càng chậm. Trên thiết bị biên, dải kích thước thực tế là từ 1B tới khoảng 8B — lớn hơn nữa thường vượt quá bộ nhớ và tốc độ chấp nhận được của laptop hay điện thoại thông thường. Trong dải này, mỗi mức kích thước có vị trí riêng.
Mô hình 1–3B: nhanh, nhẹ, đủ cho tác vụ đơn giản. Một mô hình 1–3B sau khi lượng tử hóa INT4 chỉ nặng khoảng 1–2 GB, chạy rất nhanh ngay cả trên CPU laptop tầm trung, và đủ tốt cho các tác vụ như: trả lời câu hỏi ngắn, tóm tắt đoạn văn ngắn, viết lại câu, dịch đơn giản, gợi ý tiêu đề, hay trò chuyện thông thường. Đây là lựa chọn tốt nhất cho điện thoại và các thiết bị yếu, hoặc khi bạn cần tốc độ cao và không yêu cầu suy luận sâu. Hạn chế là mô hình nhỏ dễ mắc lỗi kiến thức, dễ bịa thông tin khi không biết câu trả lời, và khả năng làm theo hướng dẫn phức tạp còn hạn chế. Hãy dùng mô hình 1–3B cho các tác vụ mà sai sót không gây hậu quả lớn, và luôn kiểm tra lại đầu ra khi nội dung quan trọng.
Mô hình 7–8B: điểm cân bằng tốt nhất cho laptop. Đây là dải kích thước được dùng nhiều nhất cho LLM trên thiết bị biên. Một mô hình 7–8B INT4 nặng khoảng 4–5 GB, chạy được trên laptop có 16 GB RAM với tốc độ 10–20 token mỗi giây trên CPU hiện đại, và nhanh hơn nhiều nếu có GPU. Chất lượng của mô hình 7–8B tốt hơn rõ rệt so với mô hình 3B: trả lời mạch lạc hơn, làm theo hướng dẫn tốt hơn, viết code đơn giản được, tóm tắt tài liệu dài tốt hơn, và ít bịa thông tin hơn. Với hầu hết người dùng laptop, mô hình 7–8B là lựa chọn mặc định nên bắt đầu. Nếu laptop của bạn có 16 GB RAM trở lên, hãy bắt đầu từ đây.
Mô hình trên 8B: chỉ khi phần cứng cho phép. Mô hình 13–14B INT4 nặng khoảng 8 GB, cần laptop có 16–32 GB RAM và chạy chậm hơn đáng kể trên CPU. Mô hình 30B trở lên thực tế chỉ chạy được trên máy trạm có GPU mạnh hoặc nhiều RAM, không còn là “thiết bị biên” theo nghĩa thông thường. Người dùng không nên cố chạy mô hình quá lớn trên phần cứng yếu: tốc độ sinh token quá chậm sẽ khiến trải nghiệm trở nên khó chịu, và chất lượng tăng thêm không bù được sự chậm chạp đó. Nguyên tắc thực tế: mô hình nhỏ chạy nhanh luôn tốt hơn mô hình lớn chạy chậm trong sử dụng hàng ngày.
Ngoài kích thước, cần xem xét mục đích tinh chỉnh của mô hình. Cùng là mô hình 7B, nhưng một mô hình được tinh chỉnh cho trò chuyện chung sẽ khác với một mô hình được tinh chỉnh cho viết code, và khác nữa với mô hình được tinh chỉnh cho lĩnh vực y khoa hay pháp lý. Khi chọn mô hình, hãy đọc mô tả của nó: nó được huấn luyện cho mục đích gì, dữ liệu nào, và được đánh giá ra sao. Với nhu cầu chung, hãy chọn mô hình trò chuyện đa năng (general chat/instruct) — loại mô hình làm theo hướng dẫn tốt và trả lời được nhiều loại câu hỏi. Với nhu cầu chuyên biệt như viết code, hãy chọn mô hình chuyên viết code, vì nó sẽ cho kết quả tốt hơn hẳn mô hình chung ở cùng kích thước. Đừng chọn mô hình chỉ vì tên tuổi — hãy chọn mô hình vì nó phù hợp với việc bạn cần làm.
Cửa sổ ngữ cảnh (context window) cũng là một tiêu chí chọn mô hình. Cửa sổ ngữ cảnh là độ dài tối đa của văn bản mà mô hình có thể “nhớ” trong một lần xử lý — bao gồm cả câu hỏi của bạn và câu trả lời nó đang sinh ra. Mô hình có cửa sổ ngữ cảnh 4.000 token chỉ xử lý được khoảng 3.000 từ tiếng Việt trong một lần; mô hình có cửa sổ 32.000 hay 128.000 token có thể xử lý cả một tài liệu dài. Tuy nhiên, cửa sổ ngữ cảnh càng dài thì KV cache càng lớn và tốc độ càng chậm. Với trò chuyện thông thường, cửa sổ 4.000–8.000 token là đủ. Với tóm tắt tài liệu dài, hãy chọn mô hình có cửa sổ 32.000 token trở lên. Lưu ý: cửa sổ ngữ cảnh mà nhà phát triển công bố là giới hạn tối đa, không phải mức nên dùng hàng ngày — hãy đặt mức ngữ cảnh vừa đủ cho nhu cầu thực tế để tiết kiệm bộ nhớ và tăng tốc độ.
Cuối cùng, một lời khuyên thực tế: hãy thử hai hoặc ba mô hình khác nhau trước khi chốt một mô hình dùng lâu dài. Chất lượng mô hình là thứ rất khó đánh giá qua con số — cùng một kích thước, hai mô hình khác nhau có thể cho cảm nhận rất khác nhau về văn phong, độ chính xác và khả năng làm theo hướng dẫn. Hãy chuẩn bị một bộ khoảng 10 câu hỏi mẫu đại diện cho công việc hàng ngày của bạn — ví dụ tóm tắt một đoạn văn bản, viết một email, giải thích một khái niệm, viết một đoạn code đơn giản — rồi chạy thử từng mô hình với cùng bộ câu hỏi đó. Mô hình nào trả lời tốt nhất cho công việc của bạn thì đó là mô hình nên dùng, bất kể bảng xếp hạng nói gì.
Hướng dẫn thực hành: chạy LLM offline trên laptop trong 30 phút
Phần này là hướng dẫn thực hành từng bước, dùng Ollama vì đây là con đường dễ nhất cho người mới. Các bước được mô tả ở mức chung, áp dụng được trên Windows, macOS và Linux, và không yêu cầu kiến thức lập trình. Nếu bạn dùng llama.cpp thay vì Ollama, nguyên tắc vẫn giống nhau — chỉ khác ở câu lệnh cụ thể.
Bước 1: kiểm tra phần cứng của bạn
Trước khi tải mô hình, hãy kiểm tra laptop của bạn có bao nhiêu RAM và có GPU rời hay không. Trên Windows, mở Task Manager, vào tab Performance, xem mục Memory để biết tổng RAM và RAM đang trống. Trên macOS, mở About This Mac để xem dung lượng bộ nhớ. Trên Linux, dùng lệnh free -h trong terminal. Quy tắc chọn mô hình theo RAM như sau: laptop 8 GB RAM — chỉ nên chạy mô hình 1–3B INT4, vì hệ điều hành và các ứng dụng khác đã chiếm 3–4 GB; laptop 16 GB RAM — chạy thoải mái mô hình 7–8B INT4; laptop 32 GB RAM trở lên — có thể thử mô hình 7–8B INT8 hoặc mô hình 13B INT4. Nếu laptop có GPU rời của NVIDIA với 8 GB VRAM trở lên, bạn có thể chạy mô hình nhanh hơn nhiều bằng cách để GPU gánh phần tính toán — Ollama và llama.cpp đều tự động phát hiện và dùng GPU khi có thể. Ngoài RAM, hãy kiểm tra dung lượng ổ đĩa trống: mỗi mô hình 7B INT4 cần khoảng 4–5 GB ổ đĩa, và bạn nên chừa ít nhất 10 GB trống để tải và thử nghiệm thoải mái. Ổ SSD sẽ giúp tải mô hình nhanh hơn ổ HDD đáng kể.
Bước 2: cài đặt Ollama
Tải Ollama từ trang chủ chính thức của dự án và cài đặt như một ứng dụng thông thường. Trên macOS và Windows, Ollama có bản cài đặt với giao diện đồ họa; trên Linux, Ollama cung cấp script cài đặt qua dòng lệnh. Sau khi cài đặt, Ollama chạy ngầm dưới dạng một dịch vụ trên máy của bạn, sẵn sàng nhận lệnh tải và chạy mô hình. Bạn có thể kiểm tra Ollama đã chạy hay chưa bằng cách mở terminal và gõ lệnh kiểm tra phiên bản — nếu terminal trả về số phiên bản, Ollama đã sẵn sàng. Lưu ý: Ollama cần kết nối internet trong bước tải mô hình, nhưng sau khi mô hình đã nằm trên máy, mọi lần sử dụng sau đó đều hoàn toàn offline.
Bước 3: chọn và tải mô hình đầu tiên
Với laptop 16 GB RAM, hãy bắt đầu với một mô hình trò chuyện đa năng khoảng 7–8B ở định dạng mà Ollama hỗ trợ. Trong thư viện mô hình của Ollama, mỗi mô hình thường có nhiều phiên bản kích thước — hãy chọn phiên bản 7B hoặc 8B, và để Ollama tự chọn mức lượng tử hóa mặc định (thường là Q4_K_M). Lệnh tải mô hình chỉ gồm tên mô hình và kích thước; quá trình tải có thể mất vài phút tùy tốc độ mạng, vì file mô hình nặng vài GB. Trong lúc chờ, đừng tắt máy hay ngắt mạng. Sau khi tải xong, mô hình được lưu trong thư mục dữ liệu của Ollama trên máy bạn, và bạn có thể dùng lại bất cứ lúc nào mà không cần tải lại. Nếu laptop chỉ có 8 GB RAM, hãy chọn mô hình 3B thay vì 7B — trải nghiệm với mô hình 3B chạy mượt mà luôn tốt hơn mô hình 7B chạy chậm và giật.
Bước 4: trò chuyện thử và đo tốc độ
Sau khi tải xong, hãy chạy mô hình và trò chuyện thử với vài câu hỏi quen thuộc. Hãy chú ý tới hai điều: chất lượng câu trả lời và tốc độ sinh token. Về chất lượng, hãy hỏi những câu mà bạn biết đáp án: một câu hỏi kiến thức chung, một yêu cầu tóm tắt đoạn văn ngắn, một yêu cầu viết email. Nếu câu trả lời đúng, mạch lạc và đúng ý bạn, mô hình đó phù hợp. Về tốc độ, hãy để ý xem chữ hiện ra nhanh hay chậm. Ollama hiển thị thống kê sau mỗi câu trả lời, trong đó có tốc độ tính bằng token mỗi giây. Bạn cũng có thể ước lượng bằng cảm nhận: nếu chữ hiện ra đều đặn và bạn đọc kịp, tốc độ là đủ. Dưới đây là cách đọc tốc độ token mỗi giây một cách thực tế.
Đo tốc độ token/giây: bao nhiêu là đủ dùng?
Token mỗi giây (tokens per second) là chỉ số tốc độ quan trọng nhất khi chạy LLM trên thiết bị. Một token tương đương khoảng 0,75 từ tiếng Anh, hay khoảng một âm tiết tới một từ ngắn trong tiếng Việt. Tốc độ đọc trung bình của người trưởng thành là khoảng 200–250 từ mỗi phút, tức khoảng 4–5 token mỗi giây. Điều này có nghĩa là: chỉ cần 10 token mỗi giây, mô hình đã sinh chữ nhanh gấp đôi tốc độ đọc của bạn — bạn sẽ không bao giờ phải chờ mô hình. Dưới đây là bảng tham chiếu thực tế.
| Tốc độ | Cảm nhận khi dùng | Phù hợp với |
|---|---|---|
| Dưới 5 token/giây | Chậm, phải chờ, khó chịu khi câu trả lời dài | Chỉ dùng tạm, nên đổi mô hình nhỏ hơn hoặc dùng GPU |
| 5–10 token/giây | Chấp nhận được, chữ hiện ra đều, đọc kịp | Trò chuyện thông thường, tóm tắt ngắn |
| 10–20 token/giây | Mượt mà, gần như không phải chờ | Hầu hết nhu cầu hàng ngày trên laptop CPU |
| 20–50 token/giây | Rất nhanh, chữ hiện ra gần như tức thì | Laptop có GPU, hoặc mô hình nhỏ trên CPU mạnh |
| Trên 50 token/giây | Nhanh hơn nhu cầu đọc rất nhiều | Xử lý hàng loạt tài liệu, sinh văn bản dài |
Tốc độ thực tế phụ thuộc vào nhiều yếu tố: CPU của bạn mạnh hay yếu, mô hình lớn hay nhỏ, mức lượng tử hóa, độ dài ngữ cảnh, và có dùng GPU hay không. Một số mẹo tăng tốc độ: giảm độ dài ngữ cảnh xuống mức vừa đủ; chọn mô hình nhỏ hơn nếu tốc độ hiện tại quá chậm; đóng các ứng dụng nặng khác để dành CPU cho mô hình; nếu laptop có GPU, hãy chắc chắn Ollama hoặc llama.cpp đã nhận GPU — tốc độ trên GPU thường nhanh hơn CPU nhiều lần. Đừng quá ám ảnh với con số tốc độ tối đa: với sử dụng tương tác hàng ngày, 10–20 token mỗi giây đã là đủ tốt, và chất lượng câu trả lời quan trọng hơn tốc độ sinh chữ.
Bước 5: dùng mô hình trong công việc hàng ngày
Sau khi đã chọn được mô hình ưng ý, hãy tích hợp nó vào quy trình làm việc của bạn. Cách đơn giản nhất là dùng giao diện chat của Ollama hoặc một ứng dụng chat mã nguồn mở kết nối tới API cục bộ của Ollama — bạn sẽ có một cửa sổ trò chuyện giống như chatbot đám mây, nhưng chạy hoàn toàn tại chỗ. Một số ứng dụng bạn có thể thử: tóm tắt tài liệu trước khi đọc, viết nháp email rồi chỉnh lại, giải thích khái niệm khó bằng ngôn ngữ đơn giản, gợi ý dàn ý cho bài viết, hay dịch đoạn văn bản ngắn. Hãy bắt đầu với các tác vụ ít rủi ro, kiểm tra đầu ra cẩn thận, và chỉ mở rộng sang các tác vụ quan trọng hơn khi bạn đã hiểu rõ điểm mạnh và điểm yếu của mô hình mình đang dùng. Một thói quen tốt là: không bao giờ dùng đầu ra của mô hình nhỏ làm đáp án cuối cùng cho các quyết định quan trọng mà không kiểm chứng — hãy coi nó là bản nháp, không phải bản chính thức.
Checklist trước khi chạy LLM trên thiết bị
- RAM: đã kiểm tra tổng RAM và RAM trống; mô hình INT4 cần RAM trống lớn hơn kích thước file mô hình ít nhất 2 GB để chứa KV cache và hệ điều hành.
- Ổ đĩa: còn ít nhất 10 GB trống; ưu tiên ổ SSD để tải mô hình nhanh.
- Định dạng: đã xác định công cụ sẽ dùng (Ollama hay llama.cpp) và tải đúng định dạng mô hình tương ứng (GGUF cho llama.cpp/Ollama).
- Kích thước mô hình: 8 GB RAM chọn mô hình 1–3B; 16 GB RAM chọn 7–8B; 32 GB RAM trở lên mới cân nhắc 13B.
- Giấy phép: đã đọc giấy phép của mô hình nếu dùng cho mục đích thương mại.
- Nguồn tải: chỉ tải mô hình từ nguồn uy tín, kiểm tra tên file và kích thước sau khi tải.
- Kỳ vọng: đã hiểu mô hình nhỏ không thay thế được mô hình đám mây lớn cho nhiệm vụ phức tạp.
- Offline: đã thử ngắt mạng và xác nhận mô hình vẫn chạy bình thường.
Giới hạn của LLM trên thiết bị: mô hình biên không thay thế được mô hình đám mây lớn
Khả năng suy luận phức tạp là giới hạn lớn nhất. Các mô hình đám mây lớn nhất hiện nay có hàng trăm tỷ tham số, được huấn luyện trên lượng dữ liệu khổng lồ với chi phí tính toán mà không một thiết bị cá nhân nào sánh được. Chúng giỏi hơn mô hình nhỏ ở hầu hết các nhiệm vụ khó: suy luận toán học nhiều bước, viết code phức tạp, phân tích tài liệu dài và chuyên sâu, lập luận logic chặt chẽ, và xử lý các câu hỏi mơ hồ cần kiến thức nền rộng. Một mô hình 7B trên laptop có thể giải bài toán đơn giản, nhưng sẽ gặp khó với bài toán cần suy luận chuỗi dài hay kiến thức chuyên ngành sâu. Đây không phải là lỗi của lượng tử hóa — mà là giới hạn cố hữu của kích thước mô hình. Lượng tử hóa chỉ làm mô hình nhỏ lại; nó không thể làm mô hình nhỏ thông minh bằng mô hình lớn.
Kiến thức cập nhật là giới hạn thứ hai. Mô hình ngôn ngữ chỉ biết những gì có trong dữ liệu huấn luyện của nó, và dữ liệu đó luôn có một thời điểm cắt (cutoff date). Một mô hình được huấn luyện với dữ liệu tới đầu năm sẽ không biết các sự kiện xảy ra sau đó, không biết giá cả mới, không biết các công nghệ vừa ra mắt. Mô hình đám mây có thể bù đắp bằng cách truy cập internet, tra cứu thông tin mới và trích dẫn nguồn theo thời gian thực — khả năng mà mô hình chạy offline trên thiết bị không có. Vì vậy, đừng dùng LLM trên thiết bị để hỏi tin tức mới nhất hay thông tin thay đổi nhanh; hãy dùng nó cho kiến thức ổn định và các tác vụ xử lý văn bản mà không cần dữ liệu mới.
Độ tin cậy và ảo giác (hallucination) là giới hạn thứ ba, và là giới hạn nguy hiểm nhất nếu không được hiểu đúng. Mô hình ngôn ngữ nhỏ có xu hướng bịa thông tin cao hơn mô hình lớn, đặc biệt khi được hỏi về những điều nó không biết: nó có thể đưa ra con số, tên người, ngày tháng hay trích dẫn trông rất thuyết phục nhưng hoàn toàn không có thật. Lượng tử hóa xuống INT4 có thể làm xu hướng này tăng nhẹ. Người dùng cần có thói quen kiểm chứng: với các con số, ngày tháng, tên riêng và khẳng định mang tính sự thật, hãy đối chiếu với nguồn đáng tin cậy trước khi sử dụng. Với các tác vụ sáng tạo như viết nháp, gợi ý ý tưởng hay viết lại văn bản, ảo giác ít gây hại hơn; với các tác vụ đòi hỏi độ chính xác như tư vấn pháp lý, y tế hay tài chính, mô hình nhỏ trên thiết bị không phải là nguồn tham khảo đáng tin cậy duy nhất.
Khả năng xử lý đa phương thức còn hạn chế. Hầu hết mô hình ngôn ngữ nhỏ chạy trên thiết bị hiện nay chỉ xử lý văn bản. Các mô hình đa phương thức — hiểu hình ảnh, âm thanh, video — thường lớn hơn, nặng hơn và khó chạy trên thiết bị biên hơn nhiều. Nếu công việc của bạn cần AI đọc hình ảnh hay phân tích giọng nói, bạn sẽ cần các mô hình chuyên biệt khác, hoặc vẫn phải dùng dịch vụ đám mây. Tình hình đang cải thiện nhanh, với các mô hình thị giác-ngôn ngữ nhỏ dần xuất hiện, nhưng ở thời điểm hiện tại, LLM văn bản thuần túy vẫn là trường hợp sử dụng chính của thiết bị biên.
Nhìn tổng thể, cách tiếp cận khôn ngoan nhất là mô hình lai: dùng LLM trên thiết bị cho các tác vụ thường xuyên, nhạy cảm về riêng tư, cần offline và không đòi hỏi suy luận quá phức tạp; dùng mô hình đám mây lớn cho các tác vụ khó, cần kiến thức mới, cần suy luận sâu hay cần độ chính xác cao. Hai loại mô hình này không cạnh tranh mà bổ sung cho nhau — và người dùng hiểu rõ điểm mạnh của từng loại sẽ tận dụng được cả hai.
Kết luận: bắt đầu từ mô hình nhỏ, dùng cho việc thật
Chạy LLM trên thiết bị biên đã chuyển từ một thử nghiệm kỹ thuật thành một lựa chọn thực tế cho người dùng và doanh nghiệp. Lượng tử hóa INT4 đã thu nhỏ mô hình 7B xuống còn khoảng 4 GB, llama.cpp và Ollama đã biến việc chạy mô hình thành vài lệnh đơn giản, và chất lượng mô hình nhỏ đã đủ tốt cho nhiều công việc hàng ngày. Lợi ích mang lại là thật: riêng tư tuyệt đối, hoạt động offline, độ trễ thấp, không phí API, và độc lập với nhà cung cấp. Giới hạn cũng là thật: mô hình nhỏ không thông minh bằng mô hình lớn, không biết tin tức mới, và dễ bịa thông tin hơn. Người dùng khôn ngoan là người hiểu cả hai mặt, bắt đầu với một mô hình 7–8B INT4 trên Ollama, thử với công việc thật của mình, đo tốc độ và chất lượng, rồi mới quyết định mở rộng. Bạn không cần chờ đợi thêm — laptop bạn đang dùng rất có thể đã đủ mạnh để chạy một trợ lý AI riêng, ngay hôm nay, hoàn toàn offline.
Câu hỏi thường gặp (FAQs)
Chạy LLM trên thiết bị biên là gì?
Chạy LLM trên thiết bị biên là việc vận hành một mô hình ngôn ngữ lớn ngay trên thiết bị của người dùng — laptop, điện thoại, máy tính bảng hay thiết bị IoT — thay vì gửi yêu cầu tới máy chủ đám mây. Mô hình được nén bằng lượng tử hóa xuống INT4 để vừa bộ nhớ thiết bị, và chạy bằng công cụ như llama.cpp hay Ollama. Cách này mang lại sự riêng tư tuyệt đối, hoạt động offline, độ trễ thấp và không tốn phí API, với chi phí là mô hình nhỏ hơn và kém thông minh hơn so với các mô hình đám mây lớn nhất.
Lượng tử hóa INT4 là gì và có làm giảm chất lượng mô hình không?
Lượng tử hóa INT4 là kỹ thuật nén mô hình ngôn ngữ bằng cách biểu diễn mỗi trọng số bằng 4 bit thay vì 16 bit, giúp mô hình 7B giảm từ khoảng 14 GB xuống còn khoảng 4 GB và chạy được trên thiết bị phổ thông. Lượng tử hóa INT4 làm giảm chất lượng mô hình một chút so với bản gốc FP16, nhưng mức giảm thường nhỏ và khó nhận thấy trong các tác vụ thông thường như viết nháp, tóm tắt hay trò chuyện. Với các tác vụ đòi hỏi độ chính xác cao, có thể chọn INT8 hoặc Q8 để giữ chất lượng tốt hơn, đổi lại là mô hình nặng gấp đôi.
Nên chọn llama.cpp hay Ollama để chạy LLM trên laptop?
Người dùng mới bắt đầu nên chọn Ollama vì nó đơn giản nhất: chỉ cần một lệnh để tải và chạy mô hình, có sẵn trên Windows, macOS và Linux, và tự động tận dụng GPU khi có. llama.cpp phù hợp hơn với người dùng muốn kiểm soát sâu: chạy được nhiều định dạng, tùy chỉnh tham số chi tiết, và chạy trên các thiết bị đặc biệt như Raspberry Pi hay điện thoại Android qua Termux. Cả hai đều dùng định dạng GGUF và miễn phí, nên bạn có thể bắt đầu với Ollama và chuyển sang llama.cpp khi cần tùy chỉnh nhiều hơn.
Laptop bao nhiêu RAM thì chạy được LLM 7B?
Để chạy mô hình 7B đã lượng tử hóa INT4, laptop cần tối thiểu 8 GB RAM, trong đó mô hình chiếm khoảng 4–5 GB và hệ điều hành cùng ứng dụng khác cần thêm vài GB. Với 16 GB RAM, bạn chạy mô hình 7B thoải mái và có thể thử mô hình 13B. Với 32 GB RAM, bạn có thể chạy mô hình 13–14B INT4 hoặc 7B ở chất lượng cao hơn như Q8. Nếu laptop có GPU rời với VRAM từ 6 GB trở lên, tốc độ sinh token sẽ nhanh hơn nhiều so với chỉ dùng CPU.
Tốc độ bao nhiêu token/giây là đủ dùng?
Với trò chuyện và viết nháp, tốc độ từ 10 token/giây trở lên đã đủ dùng thoải mái, vì tốc độ đọc trung bình của con người chỉ khoảng 5 token/giây — mô hình sinh nhanh hơn tốc độ bạn đọc. Tốc độ 20–40 token/giây cho cảm giác gần như tức thì trên laptop có GPU. Tốc độ dưới 5 token/giây vẫn dùng được cho các tác vụ ngắn nhưng sẽ gây khó chịu khi cần văn bản dài. Để đo tốc độ thực tế trên thiết bị của bạn, hãy chạy cùng một prompt cố định, bấm giờ, và chia số token sinh ra cho số giây đã trôi qua.
GGUF khác AWQ và GPTQ như thế nào?
GGUF là định dạng lượng tử hóa phổ biến nhất cho CPU, được llama.cpp và Ollama dùng, hỗ trợ nhiều mức chất lượng như Q4_K_M hay Q8_0 và chạy tốt trên cả CPU lẫn GPU. AWQ và GPTQ là các định dạng tối ưu cho GPU: AWQ thường nhanh hơn trên GPU NVIDIA đời mới nhờ thuật toán kích hoạt nhận thức, còn GPTQ là chuẩn lâu đời với nhiều mô hình được chuyển đổi sẵn. Nếu bạn chạy trên CPU hoặc dùng Ollama, hãy chọn GGUF; nếu bạn có GPU NVIDIA mạnh và cần tốc độ tối đa, hãy thử AWQ hoặc GPTQ qua vLLM hay llama.cpp với hỗ trợ CUDA.
LLM trên thiết bị có thay thế được ChatGPT hay các mô hình đám mây lớn không?
LLM trên thiết bị chưa thể thay thế hoàn toàn ChatGPT hay các mô hình đám mây lớn, vì mô hình biên nhỏ hơn nhiều nên kém hơn ở suy luận phức tạp, kiến thức cập nhật, độ tin cậy và khả năng đa phương thức. Tuy nhiên, với các tác vụ thường xuyên như viết nháp, tóm tắt, dịch thuật, trò chuyện và xử lý dữ liệu nhạy cảm, mô hình nhỏ trên thiết bị đã đủ tốt và có lợi thế lớn về riêng tư, offline và chi phí bằng không. Cách tiếp cận tốt nhất là mô hình lai: dùng LLM trên thiết bị cho tác vụ riêng tư và thường xuyên, dùng mô hình đám mây lớn cho tác vụ khó và cần kiến thức mới.
Chạy LLM offline có cần internet không?
Không — sau khi đã tải mô hình về máy, bạn có thể chạy LLM hoàn toàn offline mà không cần internet, vì mô hình và công cụ chạy đều nằm ngay trên thiết bị của bạn. Internet chỉ cần trong hai trường hợp: lần đầu tải mô hình về, và khi muốn cập nhật mô hình lên phiên bản mới. Đây chính là ưu điểm lớn nhất của LLM trên thiết bị biên: bạn có thể dùng AI trên máy bay, ở vùng không có sóng, hay trong môi trường yêu cầu bảo mật mà không lo dữ liệu bị gửi ra ngoài.
Liên hệ AIA qua hotline 0939 936 168 để được tư vấn giải pháp AI phù hợp với dự án của bạn.
