- Các mô hình nhỏ (edge models) có những đặc điểm và thách thức riêng biệt, như bị giới hạn bộ nhớ, chuyên biệt theo tác vụ và nhạy cảm với độ trễ, không chỉ đơn thuần là phiên bản thu nhỏ của các mô hình lớn.
- Để tối ưu hóa hiệu suất của mô hình nhỏ, cần tập trung vào kiến trúc hiệu quả (ví dụ: giảm kích thước lớp nhúng, sử dụng tích chập ngắn) và quy trình huấn luyện chuyên biệt, bao gồm tiền huấn luyện với lượng token lớn và tinh chỉnh cho các tác vụ cụ thể.
- Các vấn đề cố hữu của mô hình nhỏ như "vòng lặp vô tận" (doom looping) có thể được khắc phục hiệu quả thông qua các kỹ thuật hậu huấn luyện như căn chỉnh ưu tiên (preference alignment) và học tăng cường (reinforcement learning), cùng với việc tích hợp công cụ bên ngoài để mở rộng khả năng.
Everything I Learned Training Frontier Small Models — Maxime Labonne, Liquid AI
- Các mô hình biên (edge models) bị giới hạn bộ nhớ, có dung lượng kiến thức thấp và nhạy cảm với độ trễ, đòi hỏi chiến lược thiết kế và huấn luyện khác biệt so với mô hình lớn.
- Tối ưu hóa kiến trúc bằng cách giảm tỷ lệ tham số của lớp nhúng so với tổng số tham số mô hình sẽ tăng số lượng tham số hiệu quả, cải thiện khả năng suy luận và dung lượng kiến thức.
- Thực hiện đánh giá hiệu suất trên thiết bị (on-device profiling) để xác định các toán tử và kiến trúc hiệu quả nhất (ví dụ: tích chập ngắn - short convolutions), giúp đạt được thông lượng cao và độ trễ thấp trên phần cứng mục tiêu.
- Thách thức các luật scale thông thường bằng cách tiền huấn luyện mô hình nhỏ với lượng mã thông báo (tokens) rất lớn (ví dụ: 28 nghìn tỷ token cho mô hình 350M tham số) vì thực nghiệm cho thấy hiệu suất vẫn tiếp tục tăng.
- Tập trung vào tính chuyên biệt theo tác vụ trong huấn luyện tinh chỉnh có giám sát (SFT) và hậu huấn luyện, nhằm tối ưu hóa mô hình cho các trường hợp sử dụng cụ thể (ví dụ: trích xuất dữ liệu, sử dụng công cụ) thay vì cố gắng đạt hiệu suất trung bình trên mọi khả năng.
- Sử dụng căn chỉnh ưu tiên (preference alignment) và học tăng cường (reinforcement learning) với môi trường đa dạng và mục tiêu hẹp để cải thiện chất lượng tổng thể của mô hình và khả năng khái quát hóa.
- Giải quyết vấn đề "vòng lặp vô tận" (doom looping) bằng cách tạo dữ liệu đa dạng trong căn chỉnh ưu tiên (sử dụng temperature sampling và LLM jury) và áp dụng các hình phạt lặp lại n-gram cùng phần thưởng tập trung vào kết quả cuối cùng trong học tăng cường.
- Bù đắp cho dung lượng kiến thức thấp của mô hình nhỏ bằng cách trang bị cho chúng các công cụ tìm kiếm web và các công cụ bên ngoài khác thông qua học tăng cường tác nhân (agentic reinforcement learning), tập trung vào khả năng suy luận mạnh mẽ để sử dụng công cụ đáng tin cậy.
- mô hình biên — edge model
- giới hạn bộ nhớ — memory bound
- chuyên biệt theo tác vụ — task specific
- nhạy cảm với độ trễ — latency sensitive
- lớp nhúng — embedding layer
- chưng cất — distillation
- đánh giá hiệu suất trên thiết bị — on-device profiling
- tích chập ngắn — short convolutions
- vòng lặp vô tận — doom looping
- học tăng cường tác nhân — agentic reinforcement learning
Giới thiệu về Mô hình nhỏ của Liquid AI
Chào mọi người, tôi là Maxim Lebon. Trong bài thuyết trình này, tôi muốn nói về những bài học mà tôi đã rút ra sau quá trình huấn luyện các mô hình nhỏ. Về ngữ cảnh, tôi làm việc tại Liquid AI với vai trò trưởng bộ phận sau huấn luyện. Tại Liquid, chúng tôi chủ yếu tập trung vào các mô hình biên (edge models) để triển khai trên thiết bị. Như bạn có thể thấy ở đây, chúng tôi có các mô hình từ 350 triệu tham số đến 24 tỷ tham số. Đây là kích thước rất, rất nhỏ. Hôm qua, chúng tôi đã phát hành VLM mới cho mô hình 50M. Và tuần trước đó, chúng tôi đã phát hành phiên bản mới của mô hình 350M cho văn bản. Đây là những gì chúng tôi làm. Chúng tôi làm việc với văn bản, thị giác và âm thanh. Các mô hình có sẵn trên Hagenface nếu bạn muốn thử nghiệm.
Đặc điểm của Mô hình nhỏ
Trong bài thuyết trình này, tôi muốn nói về điều gì tạo nên sự khác biệt giữa các mô hình nhỏ và mô hình lớn. Có ba đặc điểm chính mà tôi muốn đề cập. Thứ nhất, các mô hình nhỏ bị giới hạn về bộ nhớ (memory bound) vì phần cứng cố định trên điện thoại, trong ô tô, v.v. Chúng ta không thể thực sự sử dụng các mô hình siêu lớn, đó là lý do tại sao chúng tôi cố gắng giữ kích thước khá nhỏ. Và do đó, chúng có dung lượng kiến thức thấp hơn so với các mô hình lớn hơn. Thứ hai, các mô hình này mang tính task specific (chuyên biệt theo tác vụ), điều này rất tốt vì nếu bạn có dung lượng kiến thức nhỏ, bạn ít nhất có thể tập trung vào một việc rất tốt. Điều đó có nghĩa là chúng thường không phải là các chatbot đa năng như ChatGPT. Chúng có phạm vi tập trung hẹp hơn nhiều. Và chúng có thể thực hiện những tác vụ như tóm tắt rất, rất tốt. Đó là khía cạnh thứ hai. Và cuối cùng là chúng rất nhạy cảm với độ trễ (latency sensitive). Điều đó có nghĩa là bạn cần có thông lượng (throughput) rất nhanh. Tất cả những đặc điểm này đều rất quan trọng. Và chúng ta sẽ thấy trong bài thuyết trình này cách chúng tương tác với nhau và cách chúng ta có thể làm tốt hơn. Nhưng bài học chính mà tôi muốn bạn ghi nhớ từ bài thuyết trình này là các mô hình nhỏ không chỉ là phiên bản thu nhỏ của các mô hình lớn hơn. Chúng còn có những thách thức độc đáo riêng, và chúng ta sẽ tìm hiểu cách chúng tôi giải quyết điều đó trong bài thuyết trình này.
Kiến trúc Mô hình và Lớp nhúng
Điều đầu tiên tôi muốn nói đến là kiến trúc mô hình (model architecture), bởi vì có rất nhiều điều thú vị mà chúng ta có thể thực hiện ở đây cho các mô hình biên. Tôi muốn nói trước tiên về Gemma 3 270m và QAN 3.5 0.8B. Các mô hình này là phiên bản nhỏ nhất trong các dòng tương ứng của chúng. Và bạn có thể thấy rằng cả hai đều áp dụng kiến trúc lai (hybrid architecture). Gemma 3 có sliding window attention và GQA hybrid QAN 3.5. Có một kiến trúc mới với Gated Delta Net và Gated Attention. Điều này rất tốt vì nó nhanh hơn rất nhiều. Nhưng điều tôi quan tâm ở đây thực sự là lớp nhúng (embedding layer). Bởi vì nếu bạn nhìn vào kích thước của lớp nhúng so với tất cả các tham số của mô hình, bạn sẽ thấy rằng Gemma 3 270m thực sự chủ yếu là một lớp nhúng. Nó chiếm 63% tổng số tham số. Và ngay cả QAN 3.5 0.8B, nó vẫn chiếm khoảng 29% tham số. Điều này không hiệu quả lắm vì các tham số thực tế (effective parameters), các tham số thực sự được sử dụng cho suy luận (reasoning), cho dung lượng kiến thức (knowledge capacity) và tất cả những thứ đó, không phải là các tham số nhúng. Đó là phần còn lại. Vì vậy, kích thước hiệu quả thực sự nhỏ hơn nhiều. Và điều đó có nghĩa là bạn có thể "ép" được nhiều khả năng suy luận và hiệu suất hơn từ cùng một dung lượng bộ nhớ (memory footprint). Lý do họ làm điều đó là vì họ sử dụng chưng cất (distillation) để huấn luyện các mô hình. Họ chưng cất các mô hình này, giống như những mô hình học sinh, và chúng có các mô hình giáo viên với kích thước từ vựng (vocabulary sizes) khổng lồ. Và đây là lý do tại sao chúng ta có những lớp nhúng siêu lớn này.
Kiến trúc LFM2 và Tối ưu hóa hiệu suất
Được rồi, bây giờ hãy nói về kiến trúc LFM2. Như bạn có thể thấy, kiến trúc LFM2 thực sự không khác biệt nhiều về các lớp. Chúng tôi cũng có một kiến trúc lai. Và lần này, chúng tôi có short convolutions và GQA. Tôi muốn nói một chút về, đầu tiên, bạn có thể thấy rằng lớp nhúng thực sự nhỏ hơn nhiều so với các mô hình khác. Nó chiếm khoảng 90% tham số. Vì vậy, chúng tôi có nhiều tham số hiệu quả hơn, điều này rất tốt. Và tôi muốn nói về cách chúng tôi tạo ra kiến trúc này. Chúng tôi đã thực hiện on-device profiling (đánh giá hiệu suất trên thiết bị). Thay vì thực hiện nhiều công việc lý thuyết hơn, chúng tôi quyết định hãy thử triển khai nó trên phần cứng mục tiêu. Ở đây chúng tôi có hai phần cứng mục tiêu. Và chúng tôi muốn xem nó hoạt động như thế nào trong thực tế để có thể tối ưu hóa kiến trúc, tìm ra các operators phù hợp. Và điều chúng tôi tìm thấy là khối GQA.t.t short convolution mà bạn có thể thấy ở đây. Tại sao điều này lại tốt? Bởi vì nó rất, rất nhanh. Các short conv nhanh hơn nhiều so với tất cả các lựa chọn thay thế. Bạn có thể thấy ở đây, so với setting window attention từ Gemma 3, Github.net từ QN 3.5, Gated Linear Attention và group query attention. Bạn có thể thấy rằng tỷ lệ chi phí thực sự có lợi cho short conv, điều này rất tuyệt vì chúng tôi đã nói rằng đây là latency sensitive. Vì vậy, đây chính xác là những gì chúng tôi muốn. Điều này khá lý thuyết. Nhưng nếu chúng ta nhìn vào thực tế và profile quá trình suy luận (inference) của các mô hình này, bạn có thể thấy ở đây trên 2CPU, IndyRyzen Max Plus 395 và Samsung Galaxy S25 Ultra. Tất cả các mô hình này không nhất thiết có cùng kích thước, nhưng nó cho bạn một cái nhìn tổng quan. Và bạn có thể thấy rằng short conv thực sự cho phép LFM track nhanh hơn nhiều và cũng sử dụng ít bộ nhớ hơn. Điều đó thật tuyệt. Và bạn cũng có thể thấy trên GPU. Nó không chỉ dành cho CPU, mà cả trên GPU, bạn cũng có thể thấy điều đó. Nó có thông lượng cao, ngay cả ở mức độ đồng thời (concurrency levels) rất cao.
Huấn luyện và Quy mô
Được rồi, bây giờ hãy nói một chút về quá trình huấn luyện (training). Quy trình huấn luyện LFM 2.5 khá giống với những gì bạn có thể tìm thấy ở nơi khác về các giai đoạn. Chúng tôi đã pre-train (tiền huấn luyện) 28 nghìn tỷ mã thông báo (tokens). Chúng tôi có huấn luyện tinh chỉnh có giám sát (supervised fine-training), căn chỉnh ưu tiên (preference alignment) và học tăng cường (reinforcement learning). Và ở đây bạn có thể thấy tôi đang nói về 28 nghìn tỷ mã thông báo. Và tôi đã nói rằng chúng tôi đã phát hành một mô hình 350M tham số vào tuần trước. Vâng, chúng tôi đã pre-train một mô hình 350 triệu tham số trên 28 nghìn tỷ mã thông báo. Nếu bạn quen thuộc với gentile scaling laws, điều đó nghe có vẻ hơi lạ, vì chúng ta được cho là phải đạt compute optimal (tối ưu hóa tính toán) ở mức, tôi không biết, có thể 1 nghìn tỷ, thậm chí không phải 1 nghìn tỷ tham số. Nhưng thực tế không phải vậy. Và chúng tôi thấy rằng hiệu suất vẫn tăng lên khi bạn tăng số lượng mã thông báo pre-training. Và có một bài báo siêu thú vị của Robert Zit được xuất bản vào tuần trước về test time scaling laws. Và bạn có thể thấy ở đây cách LFM 2.5 đến 550M so sánh với test time scaling laws mới của họ. Bạn có thể thấy gentile scaling laws ở đây và những luật mới mà họ đề xuất ở đây. Và thực ra, chúng tôi đã không pre-train các mô hình với đủ mã thông báo. Chúng tôi nên pre-train nhiều hơn nữa để đạt tối ưu theo luật của họ. Nhưng điều này rất hay vì pre-training nhiều hơn có hiệu quả. Và nó có hiệu quả ngay cả ở quy mô nhỏ nhất, điều này rất tuyệt vì các mô hình này rẻ hơn nhiều để huấn luyện so với các mô hình lớn hơn nhiều. Và ở đây bạn có thể thấy sự so sánh. Nó không chỉ dành cho pre-training. Nó giống như các mô hình sau huấn luyện. Và bạn có thể thấy rằng mô hình LFM 2.5 tốt hơn đáng kể so với phiên bản trước, LFM 2.3.5.5. Trên rất nhiều điểm chuẩn (benchmarks) khác nhau. Bạn có kiến thức với UPQ diamond. Bạn có instruction following với IFBENG, bạn có case report bench, đó là trích xuất dữ liệu (data extraction). Và cũng có rất nhiều tool use với BFCL và TOU2 bench. Với mô hình này, nó chỉ có 350Mb. Vì vậy, điều chúng tôi muốn làm là chúng tôi muốn mô hình này thực sự tốt trong trích xuất dữ liệu và tool use. Còn lại, nếu nó không phải là mô hình tốt nhất về mã (code), thì cũng không thành vấn đề. Mọi người dù sao cũng không sử dụng nó theo cách đó. Tương tự với toán học. Tôi nghĩ thật tốt khi cố gắng nhắm mục tiêu vào một số khả năng (capabilities) nhất định chứ không cố gắng làm mọi thứ ở mức trung bình.
Huấn luyện hậu kỳ và Các kỹ thuật tối ưu hóa
Được rồi, hãy nói chính xác về điều đó. Huấn luyện hậu kỳ (post-training), mô hình nhỏ và lớn, điểm khác biệt là gì. Chúng ta có khá nhiều giai đoạn giống nhau. Vì vậy, sự khác biệt không thực sự nằm ở các giai đoạn, mà là ở cách bạn thực hiện nó. Đối với huấn luyện tinh chỉnh có giám sát (supervised fine-training) quy mô rộng, tốt hơn nếu bạn thực sự tập trung vào một tác vụ (task). Điều này đúng với huấn luyện hậu kỳ đa năng, nhưng cũng đúng nếu bạn thực hiện huấn luyện tinh chỉnh. Vì vậy, bạn có thể lấy một trong những mô hình này trên Hugging Face và chỉ cần tinh chỉnh (fine tune) nó cho trường hợp sử dụng của bạn. Chẳng hạn, bạn có một trường hợp sử dụng mà bạn muốn gọi một chức năng cụ thể. Điều này rất tuyệt vời. Đây là một trường hợp sử dụng xuất sắc. Bạn càng có thể tìm hoặc thiết kế nó ngay lập tức thì càng tốt. Sau đó, chúng ta có căn chỉnh ưu tiên (preference alignment). Trong quá trình huấn luyện hậu kỳ, chúng tôi có thuật toán tối ưu hóa ưu tiên trực tiếp chuẩn hóa độ dài on-policy của riêng mình mà chúng tôi khá thích. Và căn chỉnh ưu tiên rất hay vì nó mang lại những cải tiến chung. Nó không chỉ về điểm chuẩn. Nó thực sự giống như tổng thể sau căn chỉnh ưu tiên, mô hình tốt hơn, nghe tự nhiên hơn, và điều này thực sự tốt để có thể cải thiện nó một cách tổng thể. Và cuối cùng, chúng ta có học tăng cường (reinforcement learning). Và học tăng cường cực kỳ hiệu quả ngay cả ở quy mô rất nhỏ. Đó là một kỹ thuật thực sự, thực sự quan trọng mà chúng tôi sử dụng ở mọi nơi. Và điều chính yếu là nó rất hẹp về trọng tâm. Vì vậy, bạn muốn có càng nhiều môi trường và càng nhiều tác vụ càng tốt và đảm bảo rằng bạn tổng quát hóa tốt nhờ vào điều này. Và đối với các mô hình nhỏ nói riêng, chúng khá nhạy cảm với dữ liệu SFT (supervised fine-tuning) khởi động nguội (cold start). Vì vậy, nếu bạn có một tác vụ cụ thể trong học tăng cường, luôn tốt khi có các mẫu tương tự và một tác vụ tương tự trong hỗn hợp huấn luyện tinh chỉnh có giám sát của bạn. Và đây là một phản hồi tốt, như bạn có thể thấy. Trong quá trình học tăng cường, nếu có điều gì đó không huấn luyện tốt, có thể là do bạn thiếu dữ liệu SFT khởi động nguội. Có thể tác vụ quá phức tạp, có nhiều lý do khác nhau. Nhưng bạn có thể thử bắt đầu lại từ giai đoạn huấn luyện tinh chỉnh có giám sát, thêm dữ liệu của mình và sau đó xem liệu nó có cải thiện điều gì không.
Giải quyết vấn đề Vòng lặp vô tận (Doom Looping)
Được rồi, nhưng có một vấn đề mới với các mô hình ngôn ngữ nhỏ mà bạn có thể đã gặp phải ngay cả với các mô hình lớn hơn. Đó là vòng lặp vô tận (doom looping). Điểm mấu chốt của vòng lặp vô tận là, như bạn có thể thấy ở đây, mô hình sẽ bắt đầu lặp lại một chuỗi từ hết lần này đến lần khác, và nó không bao giờ dừng lại. Đây luôn là một vấn đề, nhưng nó đặc biệt trở nên nghiêm trọng nếu bạn có các mô hình nhỏ, nếu bạn có các mô hình suy luận, và nếu bạn có các tác vụ phức tạp. Nếu tác vụ về cơ bản quá phức tạp đối với mô hình. Hy vọng quy trình này không quá phức tạp đối với mô hình này, nhưng điều này có thể xảy ra ở bất cứ đâu. Và bạn có cả ba yếu tố cùng một lúc. Vì vậy, nếu bạn có các mô hình suy luận nhỏ trên các tác vụ toán học siêu khó, đây là công thức hoàn hảo để tạo ra rất nhiều vòng lặp vô tận. Vì vậy, đây là một thách thức độc đáo mà bạn tìm thấy với các mô hình nhỏ để cung cấp cho bạn một ví dụ cụ thể. Và ở đây tôi có thể nói về cách chúng tôi giải quyết nó. Điều đầu tiên là chúng tôi giải quyết nó trong giai đoạn căn chỉnh ưu tiên (preference alignment) và đặc biệt là đối với phần tạo dữ liệu mà chúng tôi thực hiện. Vì vậy, ở đây bạn có thể thấy quy trình (pipeline) mà chúng tôi sử dụng để tạo dữ liệu, tạo dữ liệu on-policy cho căn chỉnh ưu tiên. Chúng tôi bắt đầu với lời nhắc (prompt), khoảng 1 triệu mẫu để bạn có một ý tưởng sơ bộ. Và sau đó, chúng tôi sử dụng policy model, tại thời điểm chúng tôi muốn huấn luyện với lấy mẫu nhiệt độ (temperature sampling), và chúng tôi chỉ tạo ra năm roll outs. Vì chúng tôi sử dụng lấy mẫu nhiệt độ, các roll outs này có xu hướng đa dạng hơn nhiều, và chúng tôi mong rằng không phải tất cả chúng đều sẽ gặp vòng lặp vô tận. Ít nhất một cái sẽ không bị vòng lặp vô tận, phải không? Và mặt khác, chúng tôi chỉ tạo ra thêm một roll out với policy model với nhiệt độ bằng 0 (temperature zero). Và chúng tôi nghĩ rằng cái này sẽ gặp vòng lặp vô tận. Sau đó, chúng tôi giao tất cả cho một ban giám khảo LLM (LLM jury) để chấm điểm tất cả các roll outs. Chúng tôi chọn cái tốt nhất, cái có điểm cao nhất, là câu trả lời được chọn (chosen answer), cái có điểm tệ nhất là câu trả lời bị từ chối (rejected answer). Và ý tưởng là nếu chúng ta có một số vòng lặp vô tận ở đây, phản hồi cho vòng lặp vô tận sẽ bị từ chối. Vì vậy, chúng tôi sẽ huấn luyện mô hình trong quá trình căn chỉnh ưu tiên để không bị vòng lặp vô tận. Và điều này khá hiệu quả. Vì vậy, đây là giải pháp số một. Và sau đó chúng tôi có giải pháp số hai. Và giải pháp này là về việc sử dụng học tăng cường với phần thưởng time-fireball (thyme fireball rewards). Và chúng tôi thêm một chút hình phạt lặp lại n-gram (n-gram repetition penalty).
Khắc phục vòng lặp "Doom Loop" bằng Học tăng cường
Nhưng bạn có thể thấy rằng với reinforcement learning (học tăng cường) với thyme fireball rewards, đây là một cách rất hay để thực sự giải quyết vấn đề này. Bởi vì nếu bạn có một câu hỏi, chẳng hạn một câu hỏi toán học như thế này, bạn sẽ cố gắng trích xuất câu trả lời cuối cùng. Nếu bạn không có câu trả lời cuối cùng, bạn sẽ không nhận được một phần thưởng tích cực. Vì vậy, điều này đã được giải quyết trong quá trình reinforcement learning với thyme fireball rewards. Nhưng trên hết, bạn có thể thêm một chút repetition penalty (hình phạt lặp lại) để đảm bảo rằng bạn sẽ ít tạo ra các doom loops (vòng lặp lỗi) hơn nói chung. Tương tự, chúng tôi cũng sử dụng temperature sampling (lấy mẫu nhiệt độ) ở đây. Vì vậy, các rollouts (lần triển khai) cũng khá đa dạng. Và khả năng bạn gặp nhiều doom loops liên tục sẽ thấp hơn. Đây là giải pháp thứ hai, và nó cho phép chúng tôi thực sự giảm tỷ lệ doom loop.
Kết quả thực nghiệm và so sánh mô hình
Đây là một ví dụ thực tế với LFM 2.5, 1.2B thinking, một small model (mô hình nhỏ). Đó là một reasoning model (mô hình suy luận). Và trên hết, chúng tôi đã đưa ra các task (nhiệm vụ) thực sự khó cho nó. Bạn có thể thấy rằng sau mid training (giai đoạn huấn luyện giữa), tỷ lệ doom loop mà chúng tôi tính toán trên nhiều benchmarks (điểm chuẩn) là khoảng 15%, hoặc thậm chí 16%. Và sau SFT (Supervised Fine-Tuning), nó hầu như không thay đổi. SFT không phải là giai đoạn phù hợp để khắc phục điều này. Chúng tôi không có ví dụ về doom loop trong giai đoạn SFT, nhưng nó không đủ để loại bỏ vấn đề này. Sau DPO (Direct Preference Optimization) – đó là giải pháp đầu tiên – nó thực sự giảm đi đáng kể. Và bạn có thể thấy rằng sau reinforcement learning, vấn đề gần như không tồn tại. Nếu hôm nay bạn thử làm điều tương tự với QNP.5, 0.8B ở chế độ suy luận, bạn sẽ thấy rất, rất nhiều doom loops, như hơn 50% doom loops, điều mà mọi người thường phàn nàn trên mạng. Và điều đó cũng cho thấy rằng QNP.5, giống như model (mô hình) nhỏ này, chỉ là một phiên bản thu nhỏ của các model lớn hơn. Và đây không phải là cách tiếp cận mà chúng tôi đang áp dụng ở đây. Chúng tôi muốn nói rằng, các edge models (mô hình biên) là một loại riêng biệt. Và đây cũng là một cách để tối ưu hóa toàn bộ kiến trúc, toàn bộ câu hỏi và stack (ngăn xếp) để đảm bảo rằng chúng tôi xử lý chúng tốt nhất có thể.
Các bước tiếp theo cho mô hình nhỏ với học tăng cường tác nhân
Cuối cùng, tôi muốn nói về giai đoạn tiếp theo, các bước tiếp theo cho tất cả các small models này với agentic reinforcement learning (học tăng cường tác nhân). Đặc điểm cuối cùng tôi chưa đề cập ở đây là việc bị giới hạn bộ nhớ (memory-bound). Nếu bạn bị giới hạn bộ nhớ, điều đó có nghĩa là bạn có khả năng lưu trữ kiến thức thấp (low knowledge capacity). Nếu bạn có khả năng lưu trữ kiến thức thấp, điều đó có nghĩa là bạn sẽ tạo ra "ảo giác" (hallucinate) rất nhiều. Nhưng một cách hay để giải quyết vấn đề này chỉ đơn giản là cung cấp các web search tools (công cụ tìm kiếm web) cho model. Nếu bạn có một tiny model (mô hình nhỏ xíu), nhưng nó có thể Google mọi thứ bạn đưa ra về các câu hỏi kiến thức, bạn sẽ có hiệu suất tốt hơn rất nhiều so với việc bạn chỉ dựa vào các base models (mô hình cơ sở). Và tương tự với rất nhiều vấn đề mà bạn có thể đưa ra cho model. Tôi nghĩ rằng từ kinh nghiệm, các tiny models này thực sự rất giỏi trong các tác vụ tác nhân (agentic task). Và đây là cách chúng ta nên sử dụng chúng. Không quan trọng nếu chúng không có khả năng lưu trữ kiến thức như các big models (mô hình lớn). Điều chúng thực sự cần là khả năng suy luận tốt (reasoning abilities) để đảm bảo rằng chúng có thể sử dụng các công cụ này một cách đáng tin cậy.
Vượt qua hạn chế của mô hình nhỏ
Một điểm khác mà tôi chưa đề cập ở đây là các small models cũng không giỏi lắm về khả năng xử lý ngữ cảnh dài (long-context capabilities). Nhưng điều đó không sao, bởi vì nếu bạn có một môi trường recursive language model (mô hình ngôn ngữ đệ quy), thì bạn có thể sử dụng Python và về cơ bản là thực hiện một shortcut (đường tắt) để giải quyết vấn đề này. Vì vậy, hầu hết các vấn đề bạn gặp phải với các small language models (mô hình ngôn ngữ nhỏ) thực sự có thể được khắc phục theo nhiều cách khác nhau. Nó chỉ đòi hỏi sự sáng tạo hơn. Nó chỉ đòi hỏi suy nghĩ về vấn đề này không giống như bạn sẽ nghĩ về nó từ một model lớn hơn, mà mọi thứ về nó đều có thể khắc phục được.
Kết luận và những điểm chính
Tóm lại, một số điểm chính cần nhớ. Tôi hy vọng tôi đã thuyết phục bạn rằng các edge models có những thách thức độc đáo và chúng thực sự thú vị từ cả góc độ khoa học và sản xuất. Nếu bạn kết hợp chúng với các công cụ tác nhân (agentic tools), chúng có xu hướng hoạt động thực sự rất tốt. Và đây là điều hiện đang bị khám phá chưa đầy đủ. Chúng ta nói về các tải công việc tác nhân (agentic workloads) với các big models thực sự lớn, nhưng không nhất thiết đó là use case (trường hợp sử dụng) tốt nhất. Không nhất thiết lúc nào cũng phù hợp nhất. Và vâng, cuối cùng chúng tôi đang nghiên cứu LFM3 và chúng tôi có rất nhiều thí nghiệm và ý tưởng điên rồ để thử. Vì vậy, hãy đến làm việc với chúng tôi nếu bạn quan tâm đến lĩnh vực này. Cảm ơn tất cả mọi người. Vâng.
Thảo luận: Cách sử dụng và lựa chọn mô hình
Bạn có thể chia sẻ một chút về cách bạn sử dụng các model này trong công việc của mình không? Cách bạn đưa ra quyết định? Vâng, đây là một câu hỏi hay. Vậy câu hỏi là chúng tôi sử dụng model này như thế nào trong các quy trình làm việc và làm thế nào chúng tôi quyết định giữa small models và big models. Ý tưởng chính ở đây là bạn sẽ cố gắng sử dụng các small models khi bạn không có kết nối internet, chẳng hạn. Vì vậy, in-card deployment (triển khai trong xe) là một ví dụ điển hình cho điều đó vì bạn không thể có kết nối internet đáng tin cậy, nên điều đó có ý nghĩa. Latency (độ trễ) cũng là một yếu tố lớn. Nếu bạn có một workload (tải công việc) rất nhạy cảm với latency, các small models chạy cục bộ sẽ luôn tốt hơn. Và một yếu tố khác là quyền riêng tư (privacy). Nếu bạn sử dụng trong môi trường được quy định (regulated environment), nếu bạn làm việc trong lĩnh vực tài chính hoặc chăm sóc sức khỏe, đó cũng là một lựa chọn tốt. Tôi tạo ra các model. Vì vậy, tôi tạo ra các model cho người khác, nhưng trong các quy trình làm việc của tôi thì không nhất thiết.
Đây là một câu hỏi hay. Tôi nghĩ bạn cần thực hiện một số thí nghiệm để xem liệu việc chưng cất (distilling) từ một bigger model có khả năng thay đổi tốt về mặt looping hay không. Tôi sẽ nói là không. Tôi không nghĩ vậy vì tôi nghĩ nó sẽ quá gần với SFT. Nó phụ thuộc vào cách bạn thực hiện quá trình distillation (chưng cất) này. Nếu bạn dừng K và bạn có N của K, có thể điều này là đủ tốt. Nhưng tôi nghĩ rằng nó sẽ không được giải quyết hoàn toàn và bạn vẫn cần một vài batches (lô) để đảm bảo rằng nó không xảy ra lần nữa. Được rồi. Tôi nghĩ tôi nên kết thúc, nhưng tôi sẽ ở đây nếu bạn có các câu hỏi khác. Cảm ơn rất nhiều.
TL;DR
- Các mô hình nhỏ (edge models) có những đặc điểm và thách thức riêng biệt, như bị giới hạn bộ nhớ, chuyên biệt theo tác vụ và nhạy cảm với độ trễ, không chỉ đơn thuần là phiên bản thu nhỏ của các mô hình lớn.
- Để tối ưu hóa hiệu suất của mô hình nhỏ, cần tập trung vào kiến trúc hiệu quả (ví dụ: giảm kích thước lớp nhúng, sử dụng tích chập ngắn) và quy trình huấn luyện chuyên biệt, bao gồm tiền huấn luyện với lượng token lớn và tinh chỉnh cho các tác vụ cụ thể.
- Các vấn đề cố hữu của mô hình nhỏ như "vòng lặp vô tận" (doom looping) có thể được khắc phục hiệu quả thông qua các kỹ thuật hậu huấn luyện như căn chỉnh ưu tiên (preference alignment) và học tăng cường (reinforcement learning), cùng với việc tích hợp công cụ bên ngoài để mở rộng khả năng.
Điểm chính
- Các mô hình biên (edge models) bị giới hạn bộ nhớ, có dung lượng kiến thức thấp và nhạy cảm với độ trễ, đòi hỏi chiến lược thiết kế và huấn luyện khác biệt so với mô hình lớn.
- Tối ưu hóa kiến trúc bằng cách giảm tỷ lệ tham số của lớp nhúng so với tổng số tham số mô hình sẽ tăng số lượng tham số hiệu quả, cải thiện khả năng suy luận và dung lượng kiến thức.
- Thực hiện đánh giá hiệu suất trên thiết bị (on-device profiling) để xác định các toán tử và kiến trúc hiệu quả nhất (ví dụ: tích chập ngắn - short convolutions), giúp đạt được thông lượng cao và độ trễ thấp trên phần cứng mục tiêu.
- Thách thức các luật scale thông thường bằng cách tiền huấn luyện mô hình nhỏ với lượng mã thông báo (tokens) rất lớn (ví dụ: 28 nghìn tỷ token cho mô hình 350M tham số) vì thực nghiệm cho thấy hiệu suất vẫn tiếp tục tăng.
- Tập trung vào tính chuyên biệt theo tác vụ trong huấn luyện tinh chỉnh có giám sát (SFT) và hậu huấn luyện, nhằm tối ưu hóa mô hình cho các trường hợp sử dụng cụ thể (ví dụ: trích xuất dữ liệu, sử dụng công cụ) thay vì cố gắng đạt hiệu suất trung bình trên mọi khả năng.
- Sử dụng căn chỉnh ưu tiên (preference alignment) và học tăng cường (reinforcement learning) với môi trường đa dạng và mục tiêu hẹp để cải thiện chất lượng tổng thể của mô hình và khả năng khái quát hóa.
- Giải quyết vấn đề "vòng lặp vô tận" (doom looping) bằng cách tạo dữ liệu đa dạng trong căn chỉnh ưu tiên (sử dụng temperature sampling và LLM jury) và áp dụng các hình phạt lặp lại n-gram cùng phần thưởng tập trung vào kết quả cuối cùng trong học tăng cường.
- Bù đắp cho dung lượng kiến thức thấp của mô hình nhỏ bằng cách trang bị cho chúng các công cụ tìm kiếm web và các công cụ bên ngoài khác thông qua học tăng cường tác nhân (agentic reinforcement learning), tập trung vào khả năng suy luận mạnh mẽ để sử dụng công cụ đáng tin cậy.
Từ vựng
- mô hình biên — edge model
- giới hạn bộ nhớ — memory bound
- chuyên biệt theo tác vụ — task specific
- nhạy cảm với độ trễ — latency sensitive
- lớp nhúng — embedding layer
- chưng cất — distillation
- đánh giá hiệu suất trên thiết bị — on-device profiling
- tích chập ngắn — short convolutions
- vòng lặp vô tận — doom looping
- học tăng cường tác nhân — agentic reinforcement learning
Nội dung chi tiết
Giới thiệu về Mô hình nhỏ của Liquid AI
Chào mọi người, tôi là Maxim Lebon. Trong bài thuyết trình này, tôi muốn nói về những bài học mà tôi đã rút ra sau quá trình huấn luyện các mô hình nhỏ. Về ngữ cảnh, tôi làm việc tại Liquid AI với vai trò trưởng bộ phận sau huấn luyện. Tại Liquid, chúng tôi chủ yếu tập trung vào các mô hình biên (edge models) để triển khai trên thiết bị. Như bạn có thể thấy ở đây, chúng tôi có các mô hình từ 350 triệu tham số đến 24 tỷ tham số. Đây là kích thước rất, rất nhỏ. Hôm qua, chúng tôi đã phát hành VLM mới cho mô hình 50M. Và tuần trước đó, chúng tôi đã phát hành phiên bản mới của mô hình 350M cho văn bản. Đây là những gì chúng tôi làm. Chúng tôi làm việc với văn bản, thị giác và âm thanh. Các mô hình có sẵn trên Hagenface nếu bạn muốn thử nghiệm.
Đặc điểm của Mô hình nhỏ
Trong bài thuyết trình này, tôi muốn nói về điều gì tạo nên sự khác biệt giữa các mô hình nhỏ và mô hình lớn. Có ba đặc điểm chính mà tôi muốn đề cập. Thứ nhất, các mô hình nhỏ bị giới hạn về bộ nhớ (memory bound) vì phần cứng cố định trên điện thoại, trong ô tô, v.v. Chúng ta không thể thực sự sử dụng các mô hình siêu lớn, đó là lý do tại sao chúng tôi cố gắng giữ kích thước khá nhỏ. Và do đó, chúng có dung lượng kiến thức thấp hơn so với các mô hình lớn hơn. Thứ hai, các mô hình này mang tính task specific (chuyên biệt theo tác vụ), điều này rất tốt vì nếu bạn có dung lượng kiến thức nhỏ, bạn ít nhất có thể tập trung vào một việc rất tốt. Điều đó có nghĩa là chúng thường không phải là các chatbot đa năng như ChatGPT. Chúng có phạm vi tập trung hẹp hơn nhiều. Và chúng có thể thực hiện những tác vụ như tóm tắt rất, rất tốt. Đó là khía cạnh thứ hai. Và cuối cùng là chúng rất nhạy cảm với độ trễ (latency sensitive). Điều đó có nghĩa là bạn cần có thông lượng (throughput) rất nhanh. Tất cả những đặc điểm này đều rất quan trọng. Và chúng ta sẽ thấy trong bài thuyết trình này cách chúng tương tác với nhau và cách chúng ta có thể làm tốt hơn. Nhưng bài học chính mà tôi muốn bạn ghi nhớ từ bài thuyết trình này là các mô hình nhỏ không chỉ là phiên bản thu nhỏ của các mô hình lớn hơn. Chúng còn có những thách thức độc đáo riêng, và chúng ta sẽ tìm hiểu cách chúng tôi giải quyết điều đó trong bài thuyết trình này.
Kiến trúc Mô hình và Lớp nhúng
Điều đầu tiên tôi muốn nói đến là kiến trúc mô hình (model architecture), bởi vì có rất nhiều điều thú vị mà chúng ta có thể thực hiện ở đây cho các mô hình biên. Tôi muốn nói trước tiên về Gemma 3 270m và QAN 3.5 0.8B. Các mô hình này là phiên bản nhỏ nhất trong các dòng tương ứng của chúng. Và bạn có thể thấy rằng cả hai đều áp dụng kiến trúc lai (hybrid architecture). Gemma 3 có sliding window attention và GQA hybrid QAN 3.5. Có một kiến trúc mới với Gated Delta Net và Gated Attention. Điều này rất tốt vì nó nhanh hơn rất nhiều. Nhưng điều tôi quan tâm ở đây thực sự là lớp nhúng (embedding layer). Bởi vì nếu bạn nhìn vào kích thước của lớp nhúng so với tất cả các tham số của mô hình, bạn sẽ thấy rằng Gemma 3 270m thực sự chủ yếu là một lớp nhúng. Nó chiếm 63% tổng số tham số. Và ngay cả QAN 3.5 0.8B, nó vẫn chiếm khoảng 29% tham số. Điều này không hiệu quả lắm vì các tham số thực tế (effective parameters), các tham số thực sự được sử dụng cho suy luận (reasoning), cho dung lượng kiến thức (knowledge capacity) và tất cả những thứ đó, không phải là các tham số nhúng. Đó là phần còn lại. Vì vậy, kích thước hiệu quả thực sự nhỏ hơn nhiều. Và điều đó có nghĩa là bạn có thể "ép" được nhiều khả năng suy luận và hiệu suất hơn từ cùng một dung lượng bộ nhớ (memory footprint). Lý do họ làm điều đó là vì họ sử dụng chưng cất (distillation) để huấn luyện các mô hình. Họ chưng cất các mô hình này, giống như những mô hình học sinh, và chúng có các mô hình giáo viên với kích thước từ vựng (vocabulary sizes) khổng lồ. Và đây là lý do tại sao chúng ta có những lớp nhúng siêu lớn này.
Kiến trúc LFM2 và Tối ưu hóa hiệu suất
Được rồi, bây giờ hãy nói về kiến trúc LFM2. Như bạn có thể thấy, kiến trúc LFM2 thực sự không khác biệt nhiều về các lớp. Chúng tôi cũng có một kiến trúc lai. Và lần này, chúng tôi có short convolutions và GQA. Tôi muốn nói một chút về, đầu tiên, bạn có thể thấy rằng lớp nhúng thực sự nhỏ hơn nhiều so với các mô hình khác. Nó chiếm khoảng 90% tham số. Vì vậy, chúng tôi có nhiều tham số hiệu quả hơn, điều này rất tốt. Và tôi muốn nói về cách chúng tôi tạo ra kiến trúc này. Chúng tôi đã thực hiện on-device profiling (đánh giá hiệu suất trên thiết bị). Thay vì thực hiện nhiều công việc lý thuyết hơn, chúng tôi quyết định hãy thử triển khai nó trên phần cứng mục tiêu. Ở đây chúng tôi có hai phần cứng mục tiêu. Và chúng tôi muốn xem nó hoạt động như thế nào trong thực tế để có thể tối ưu hóa kiến trúc, tìm ra các operators phù hợp. Và điều chúng tôi tìm thấy là khối GQA.t.t short convolution mà bạn có thể thấy ở đây. Tại sao điều này lại tốt? Bởi vì nó rất, rất nhanh. Các short conv nhanh hơn nhiều so với tất cả các lựa chọn thay thế. Bạn có thể thấy ở đây, so với setting window attention từ Gemma 3, Github.net từ QN 3.5, Gated Linear Attention và group query attention. Bạn có thể thấy rằng tỷ lệ chi phí thực sự có lợi cho short conv, điều này rất tuyệt vì chúng tôi đã nói rằng đây là latency sensitive. Vì vậy, đây chính xác là những gì chúng tôi muốn. Điều này khá lý thuyết. Nhưng nếu chúng ta nhìn vào thực tế và profile quá trình suy luận (inference) của các mô hình này, bạn có thể thấy ở đây trên 2CPU, IndyRyzen Max Plus 395 và Samsung Galaxy S25 Ultra. Tất cả các mô hình này không nhất thiết có cùng kích thước, nhưng nó cho bạn một cái nhìn tổng quan. Và bạn có thể thấy rằng short conv thực sự cho phép LFM track nhanh hơn nhiều và cũng sử dụng ít bộ nhớ hơn. Điều đó thật tuyệt. Và bạn cũng có thể thấy trên GPU. Nó không chỉ dành cho CPU, mà cả trên GPU, bạn cũng có thể thấy điều đó. Nó có thông lượng cao, ngay cả ở mức độ đồng thời (concurrency levels) rất cao.
Huấn luyện và Quy mô
Được rồi, bây giờ hãy nói một chút về quá trình huấn luyện (training). Quy trình huấn luyện LFM 2.5 khá giống với những gì bạn có thể tìm thấy ở nơi khác về các giai đoạn. Chúng tôi đã pre-train (tiền huấn luyện) 28 nghìn tỷ mã thông báo (tokens). Chúng tôi có huấn luyện tinh chỉnh có giám sát (supervised fine-training), căn chỉnh ưu tiên (preference alignment) và học tăng cường (reinforcement learning). Và ở đây bạn có thể thấy tôi đang nói về 28 nghìn tỷ mã thông báo. Và tôi đã nói rằng chúng tôi đã phát hành một mô hình 350M tham số vào tuần trước. Vâng, chúng tôi đã pre-train một mô hình 350 triệu tham số trên 28 nghìn tỷ mã thông báo. Nếu bạn quen thuộc với gentile scaling laws, điều đó nghe có vẻ hơi lạ, vì chúng ta được cho là phải đạt compute optimal (tối ưu hóa tính toán) ở mức, tôi không biết, có thể 1 nghìn tỷ, thậm chí không phải 1 nghìn tỷ tham số. Nhưng thực tế không phải vậy. Và chúng tôi thấy rằng hiệu suất vẫn tăng lên khi bạn tăng số lượng mã thông báo pre-training. Và có một bài báo siêu thú vị của Robert Zit được xuất bản vào tuần trước về test time scaling laws. Và bạn có thể thấy ở đây cách LFM 2.5 đến 550M so sánh với test time scaling laws mới của họ. Bạn có thể thấy gentile scaling laws ở đây và những luật mới mà họ đề xuất ở đây. Và thực ra, chúng tôi đã không pre-train các mô hình với đủ mã thông báo. Chúng tôi nên pre-train nhiều hơn nữa để đạt tối ưu theo luật của họ. Nhưng điều này rất hay vì pre-training nhiều hơn có hiệu quả. Và nó có hiệu quả ngay cả ở quy mô nhỏ nhất, điều này rất tuyệt vì các mô hình này rẻ hơn nhiều để huấn luyện so với các mô hình lớn hơn nhiều. Và ở đây bạn có thể thấy sự so sánh. Nó không chỉ dành cho pre-training. Nó giống như các mô hình sau huấn luyện. Và bạn có thể thấy rằng mô hình LFM 2.5 tốt hơn đáng kể so với phiên bản trước, LFM 2.3.5.5. Trên rất nhiều điểm chuẩn (benchmarks) khác nhau. Bạn có kiến thức với UPQ diamond. Bạn có instruction following với IFBENG, bạn có case report bench, đó là trích xuất dữ liệu (data extraction). Và cũng có rất nhiều tool use với BFCL và TOU2 bench. Với mô hình này, nó chỉ có 350Mb. Vì vậy, điều chúng tôi muốn làm là chúng tôi muốn mô hình này thực sự tốt trong trích xuất dữ liệu và tool use. Còn lại, nếu nó không phải là mô hình tốt nhất về mã (code), thì cũng không thành vấn đề. Mọi người dù sao cũng không sử dụng nó theo cách đó. Tương tự với toán học. Tôi nghĩ thật tốt khi cố gắng nhắm mục tiêu vào một số khả năng (capabilities) nhất định chứ không cố gắng làm mọi thứ ở mức trung bình.
Huấn luyện hậu kỳ và Các kỹ thuật tối ưu hóa
Được rồi, hãy nói chính xác về điều đó. Huấn luyện hậu kỳ (post-training), mô hình nhỏ và lớn, điểm khác biệt là gì. Chúng ta có khá nhiều giai đoạn giống nhau. Vì vậy, sự khác biệt không thực sự nằm ở các giai đoạn, mà là ở cách bạn thực hiện nó. Đối với huấn luyện tinh chỉnh có giám sát (supervised fine-training) quy mô rộng, tốt hơn nếu bạn thực sự tập trung vào một tác vụ (task). Điều này đúng với huấn luyện hậu kỳ đa năng, nhưng cũng đúng nếu bạn thực hiện huấn luyện tinh chỉnh. Vì vậy, bạn có thể lấy một trong những mô hình này trên Hugging Face và chỉ cần tinh chỉnh (fine tune) nó cho trường hợp sử dụng của bạn. Chẳng hạn, bạn có một trường hợp sử dụng mà bạn muốn gọi một chức năng cụ thể. Điều này rất tuyệt vời. Đây là một trường hợp sử dụng xuất sắc. Bạn càng có thể tìm hoặc thiết kế nó ngay lập tức thì càng tốt. Sau đó, chúng ta có căn chỉnh ưu tiên (preference alignment). Trong quá trình huấn luyện hậu kỳ, chúng tôi có thuật toán tối ưu hóa ưu tiên trực tiếp chuẩn hóa độ dài on-policy của riêng mình mà chúng tôi khá thích. Và căn chỉnh ưu tiên rất hay vì nó mang lại những cải tiến chung. Nó không chỉ về điểm chuẩn. Nó thực sự giống như tổng thể sau căn chỉnh ưu tiên, mô hình tốt hơn, nghe tự nhiên hơn, và điều này thực sự tốt để có thể cải thiện nó một cách tổng thể. Và cuối cùng, chúng ta có học tăng cường (reinforcement learning). Và học tăng cường cực kỳ hiệu quả ngay cả ở quy mô rất nhỏ. Đó là một kỹ thuật thực sự, thực sự quan trọng mà chúng tôi sử dụng ở mọi nơi. Và điều chính yếu là nó rất hẹp về trọng tâm. Vì vậy, bạn muốn có càng nhiều môi trường và càng nhiều tác vụ càng tốt và đảm bảo rằng bạn tổng quát hóa tốt nhờ vào điều này. Và đối với các mô hình nhỏ nói riêng, chúng khá nhạy cảm với dữ liệu SFT (supervised fine-tuning) khởi động nguội (cold start). Vì vậy, nếu bạn có một tác vụ cụ thể trong học tăng cường, luôn tốt khi có các mẫu tương tự và một tác vụ tương tự trong hỗn hợp huấn luyện tinh chỉnh có giám sát của bạn. Và đây là một phản hồi tốt, như bạn có thể thấy. Trong quá trình học tăng cường, nếu có điều gì đó không huấn luyện tốt, có thể là do bạn thiếu dữ liệu SFT khởi động nguội. Có thể tác vụ quá phức tạp, có nhiều lý do khác nhau. Nhưng bạn có thể thử bắt đầu lại từ giai đoạn huấn luyện tinh chỉnh có giám sát, thêm dữ liệu của mình và sau đó xem liệu nó có cải thiện điều gì không.
Giải quyết vấn đề Vòng lặp vô tận (Doom Looping)
Được rồi, nhưng có một vấn đề mới với các mô hình ngôn ngữ nhỏ mà bạn có thể đã gặp phải ngay cả với các mô hình lớn hơn. Đó là vòng lặp vô tận (doom looping). Điểm mấu chốt của vòng lặp vô tận là, như bạn có thể thấy ở đây, mô hình sẽ bắt đầu lặp lại một chuỗi từ hết lần này đến lần khác, và nó không bao giờ dừng lại. Đây luôn là một vấn đề, nhưng nó đặc biệt trở nên nghiêm trọng nếu bạn có các mô hình nhỏ, nếu bạn có các mô hình suy luận, và nếu bạn có các tác vụ phức tạp. Nếu tác vụ về cơ bản quá phức tạp đối với mô hình. Hy vọng quy trình này không quá phức tạp đối với mô hình này, nhưng điều này có thể xảy ra ở bất cứ đâu. Và bạn có cả ba yếu tố cùng một lúc. Vì vậy, nếu bạn có các mô hình suy luận nhỏ trên các tác vụ toán học siêu khó, đây là công thức hoàn hảo để tạo ra rất nhiều vòng lặp vô tận. Vì vậy, đây là một thách thức độc đáo mà bạn tìm thấy với các mô hình nhỏ để cung cấp cho bạn một ví dụ cụ thể. Và ở đây tôi có thể nói về cách chúng tôi giải quyết nó. Điều đầu tiên là chúng tôi giải quyết nó trong giai đoạn căn chỉnh ưu tiên (preference alignment) và đặc biệt là đối với phần tạo dữ liệu mà chúng tôi thực hiện. Vì vậy, ở đây bạn có thể thấy quy trình (pipeline) mà chúng tôi sử dụng để tạo dữ liệu, tạo dữ liệu on-policy cho căn chỉnh ưu tiên. Chúng tôi bắt đầu với lời nhắc (prompt), khoảng 1 triệu mẫu để bạn có một ý tưởng sơ bộ. Và sau đó, chúng tôi sử dụng policy model, tại thời điểm chúng tôi muốn huấn luyện với lấy mẫu nhiệt độ (temperature sampling), và chúng tôi chỉ tạo ra năm roll outs. Vì chúng tôi sử dụng lấy mẫu nhiệt độ, các roll outs này có xu hướng đa dạng hơn nhiều, và chúng tôi mong rằng không phải tất cả chúng đều sẽ gặp vòng lặp vô tận. Ít nhất một cái sẽ không bị vòng lặp vô tận, phải không? Và mặt khác, chúng tôi chỉ tạo ra thêm một roll out với policy model với nhiệt độ bằng 0 (temperature zero). Và chúng tôi nghĩ rằng cái này sẽ gặp vòng lặp vô tận. Sau đó, chúng tôi giao tất cả cho một ban giám khảo LLM (LLM jury) để chấm điểm tất cả các roll outs. Chúng tôi chọn cái tốt nhất, cái có điểm cao nhất, là câu trả lời được chọn (chosen answer), cái có điểm tệ nhất là câu trả lời bị từ chối (rejected answer). Và ý tưởng là nếu chúng ta có một số vòng lặp vô tận ở đây, phản hồi cho vòng lặp vô tận sẽ bị từ chối. Vì vậy, chúng tôi sẽ huấn luyện mô hình trong quá trình căn chỉnh ưu tiên để không bị vòng lặp vô tận. Và điều này khá hiệu quả. Vì vậy, đây là giải pháp số một. Và sau đó chúng tôi có giải pháp số hai. Và giải pháp này là về việc sử dụng học tăng cường với phần thưởng time-fireball (thyme fireball rewards). Và chúng tôi thêm một chút hình phạt lặp lại n-gram (n-gram repetition penalty).
Khắc phục vòng lặp "Doom Loop" bằng Học tăng cường
Nhưng bạn có thể thấy rằng với reinforcement learning (học tăng cường) với thyme fireball rewards, đây là một cách rất hay để thực sự giải quyết vấn đề này. Bởi vì nếu bạn có một câu hỏi, chẳng hạn một câu hỏi toán học như thế này, bạn sẽ cố gắng trích xuất câu trả lời cuối cùng. Nếu bạn không có câu trả lời cuối cùng, bạn sẽ không nhận được một phần thưởng tích cực. Vì vậy, điều này đã được giải quyết trong quá trình reinforcement learning với thyme fireball rewards. Nhưng trên hết, bạn có thể thêm một chút repetition penalty (hình phạt lặp lại) để đảm bảo rằng bạn sẽ ít tạo ra các doom loops (vòng lặp lỗi) hơn nói chung. Tương tự, chúng tôi cũng sử dụng temperature sampling (lấy mẫu nhiệt độ) ở đây. Vì vậy, các rollouts (lần triển khai) cũng khá đa dạng. Và khả năng bạn gặp nhiều doom loops liên tục sẽ thấp hơn. Đây là giải pháp thứ hai, và nó cho phép chúng tôi thực sự giảm tỷ lệ doom loop.
Kết quả thực nghiệm và so sánh mô hình
Đây là một ví dụ thực tế với LFM 2.5, 1.2B thinking, một small model (mô hình nhỏ). Đó là một reasoning model (mô hình suy luận). Và trên hết, chúng tôi đã đưa ra các task (nhiệm vụ) thực sự khó cho nó. Bạn có thể thấy rằng sau mid training (giai đoạn huấn luyện giữa), tỷ lệ doom loop mà chúng tôi tính toán trên nhiều benchmarks (điểm chuẩn) là khoảng 15%, hoặc thậm chí 16%. Và sau SFT (Supervised Fine-Tuning), nó hầu như không thay đổi. SFT không phải là giai đoạn phù hợp để khắc phục điều này. Chúng tôi không có ví dụ về doom loop trong giai đoạn SFT, nhưng nó không đủ để loại bỏ vấn đề này. Sau DPO (Direct Preference Optimization) – đó là giải pháp đầu tiên – nó thực sự giảm đi đáng kể. Và bạn có thể thấy rằng sau reinforcement learning, vấn đề gần như không tồn tại. Nếu hôm nay bạn thử làm điều tương tự với QNP.5, 0.8B ở chế độ suy luận, bạn sẽ thấy rất, rất nhiều doom loops, như hơn 50% doom loops, điều mà mọi người thường phàn nàn trên mạng. Và điều đó cũng cho thấy rằng QNP.5, giống như model (mô hình) nhỏ này, chỉ là một phiên bản thu nhỏ của các model lớn hơn. Và đây không phải là cách tiếp cận mà chúng tôi đang áp dụng ở đây. Chúng tôi muốn nói rằng, các edge models (mô hình biên) là một loại riêng biệt. Và đây cũng là một cách để tối ưu hóa toàn bộ kiến trúc, toàn bộ câu hỏi và stack (ngăn xếp) để đảm bảo rằng chúng tôi xử lý chúng tốt nhất có thể.
Các bước tiếp theo cho mô hình nhỏ với học tăng cường tác nhân
Cuối cùng, tôi muốn nói về giai đoạn tiếp theo, các bước tiếp theo cho tất cả các small models này với agentic reinforcement learning (học tăng cường tác nhân). Đặc điểm cuối cùng tôi chưa đề cập ở đây là việc bị giới hạn bộ nhớ (memory-bound). Nếu bạn bị giới hạn bộ nhớ, điều đó có nghĩa là bạn có khả năng lưu trữ kiến thức thấp (low knowledge capacity). Nếu bạn có khả năng lưu trữ kiến thức thấp, điều đó có nghĩa là bạn sẽ tạo ra "ảo giác" (hallucinate) rất nhiều. Nhưng một cách hay để giải quyết vấn đề này chỉ đơn giản là cung cấp các web search tools (công cụ tìm kiếm web) cho model. Nếu bạn có một tiny model (mô hình nhỏ xíu), nhưng nó có thể Google mọi thứ bạn đưa ra về các câu hỏi kiến thức, bạn sẽ có hiệu suất tốt hơn rất nhiều so với việc bạn chỉ dựa vào các base models (mô hình cơ sở). Và tương tự với rất nhiều vấn đề mà bạn có thể đưa ra cho model. Tôi nghĩ rằng từ kinh nghiệm, các tiny models này thực sự rất giỏi trong các tác vụ tác nhân (agentic task). Và đây là cách chúng ta nên sử dụng chúng. Không quan trọng nếu chúng không có khả năng lưu trữ kiến thức như các big models (mô hình lớn). Điều chúng thực sự cần là khả năng suy luận tốt (reasoning abilities) để đảm bảo rằng chúng có thể sử dụng các công cụ này một cách đáng tin cậy.
Vượt qua hạn chế của mô hình nhỏ
Một điểm khác mà tôi chưa đề cập ở đây là các small models cũng không giỏi lắm về khả năng xử lý ngữ cảnh dài (long-context capabilities). Nhưng điều đó không sao, bởi vì nếu bạn có một môi trường recursive language model (mô hình ngôn ngữ đệ quy), thì bạn có thể sử dụng Python và về cơ bản là thực hiện một shortcut (đường tắt) để giải quyết vấn đề này. Vì vậy, hầu hết các vấn đề bạn gặp phải với các small language models (mô hình ngôn ngữ nhỏ) thực sự có thể được khắc phục theo nhiều cách khác nhau. Nó chỉ đòi hỏi sự sáng tạo hơn. Nó chỉ đòi hỏi suy nghĩ về vấn đề này không giống như bạn sẽ nghĩ về nó từ một model lớn hơn, mà mọi thứ về nó đều có thể khắc phục được.
Kết luận và những điểm chính
Tóm lại, một số điểm chính cần nhớ. Tôi hy vọng tôi đã thuyết phục bạn rằng các edge models có những thách thức độc đáo và chúng thực sự thú vị từ cả góc độ khoa học và sản xuất. Nếu bạn kết hợp chúng với các công cụ tác nhân (agentic tools), chúng có xu hướng hoạt động thực sự rất tốt. Và đây là điều hiện đang bị khám phá chưa đầy đủ. Chúng ta nói về các tải công việc tác nhân (agentic workloads) với các big models thực sự lớn, nhưng không nhất thiết đó là use case (trường hợp sử dụng) tốt nhất. Không nhất thiết lúc nào cũng phù hợp nhất. Và vâng, cuối cùng chúng tôi đang nghiên cứu LFM3 và chúng tôi có rất nhiều thí nghiệm và ý tưởng điên rồ để thử. Vì vậy, hãy đến làm việc với chúng tôi nếu bạn quan tâm đến lĩnh vực này. Cảm ơn tất cả mọi người. Vâng.
Thảo luận: Cách sử dụng và lựa chọn mô hình
Bạn có thể chia sẻ một chút về cách bạn sử dụng các model này trong công việc của mình không? Cách bạn đưa ra quyết định? Vâng, đây là một câu hỏi hay. Vậy câu hỏi là chúng tôi sử dụng model này như thế nào trong các quy trình làm việc và làm thế nào chúng tôi quyết định giữa small models và big models. Ý tưởng chính ở đây là bạn sẽ cố gắng sử dụng các small models khi bạn không có kết nối internet, chẳng hạn. Vì vậy, in-card deployment (triển khai trong xe) là một ví dụ điển hình cho điều đó vì bạn không thể có kết nối internet đáng tin cậy, nên điều đó có ý nghĩa. Latency (độ trễ) cũng là một yếu tố lớn. Nếu bạn có một workload (tải công việc) rất nhạy cảm với latency, các small models chạy cục bộ sẽ luôn tốt hơn. Và một yếu tố khác là quyền riêng tư (privacy). Nếu bạn sử dụng trong môi trường được quy định (regulated environment), nếu bạn làm việc trong lĩnh vực tài chính hoặc chăm sóc sức khỏe, đó cũng là một lựa chọn tốt. Tôi tạo ra các model. Vì vậy, tôi tạo ra các model cho người khác, nhưng trong các quy trình làm việc của tôi thì không nhất thiết.
Đây là một câu hỏi hay. Tôi nghĩ bạn cần thực hiện một số thí nghiệm để xem liệu việc chưng cất (distilling) từ một bigger model có khả năng thay đổi tốt về mặt looping hay không. Tôi sẽ nói là không. Tôi không nghĩ vậy vì tôi nghĩ nó sẽ quá gần với SFT. Nó phụ thuộc vào cách bạn thực hiện quá trình distillation (chưng cất) này. Nếu bạn dừng K và bạn có N của K, có thể điều này là đủ tốt. Nhưng tôi nghĩ rằng nó sẽ không được giải quyết hoàn toàn và bạn vẫn cần một vài batches (lô) để đảm bảo rằng nó không xảy ra lần nữa. Được rồi. Tôi nghĩ tôi nên kết thúc, nhưng tôi sẽ ở đây nếu bạn có các câu hỏi khác. Cảm ơn rất nhiều.