Đợt triển khai AI quan trọng tiếp theo có thể sẽ không chạy trong một cụm máy chủ đám mây khổng lồ. Nó có thể chạy bên trong một chiếc camera, robot nhà máy, phương tiện, thiết bị y tế hoặc thiết bị đầu cuối bán lẻ—nơi băng thông, điện năng, độ trễ, quyền riêng tư và chi phí vận hành quan trọng hơn việc sở hữu mô hình lớn nhất có thể.

Sự chuyển dịch đó đang tạo ra một dạng công việc AI khác. Các nhóm vẫn cần những người xây dựng mô hình, nhưng đồng thời cũng cần những người có thể khiến mô hình phù hợp với phần cứng thực tế, đo lường chất lượng trong điều kiện bị giới hạn, tích hợp các runtime suy luận gốc và quyết định khi nào một mô hình nhỏ hơn là đủ tốt cho một nhiệm vụ.

Đây là nửa kém hào nhoáng hơn của cuộc đua mô hình: không chỉ cải thiện trí tuệ, mà còn khiến trí tuệ có thể triển khai được.

Vì sao các mô hình nhỏ hơn làm thay đổi bài toán triển khai

Một mô hình đám mây thường có thể dùng thêm năng lực tính toán để trả lời một yêu cầu. Một hệ thống nhúng không thể mặc định rằng kết nối mạng luôn ổn định, pin là vô hạn hay ngân sách cho mỗi lần gọi là dư dả. Một robot phải chờ vài trăm mili giây cho mỗi quyết định nhận thức hoặc điều khiển có thể trở nên không an toàn hoặc hoạt động kém hiệu quả. Một sản phẩm gửi mọi hình ảnh hoặc mẫu âm thanh đến API có thể tạo ra chi phí về quyền riêng tư và truyền dữ liệu không thể chấp nhận.

Những ràng buộc đó làm thay đổi mục tiêu kỹ thuật. Câu hỏi trở thành: mô hình nhỏ nhất nào đáp ứng các mục tiêu yêu cầu về độ chính xác, độ trễ, bộ nhớ, năng lượng và độ tin cậy trên chính thiết bị thực tế?

Câu hỏi đó được áp dụng vượt xa các thiết bị tiêu dùng. Nó quan trọng đối với các nhà sản xuất kiểm tra linh kiện trên dây chuyền, các công ty logistics theo dõi thiết bị, bệnh viện xử lý các tín hiệu nhạy cảm và các nhà cung cấp phần mềm muốn cung cấp tính năng AI mà không biến hóa đơn suy luận thành khoản chi phí biến đổi lớn nhất.

Ba kỹ thuật đứng sau sự chuyển dịch

Lượng tử hóa biểu diễn các trọng số mô hình, và đôi khi cả các activation, bằng những số có độ chính xác thấp hơn. Việc chuyển từ các định dạng như BF16 hoặc FP16 sang biểu diễn 8-bit hoặc 4-bit có thể giảm yêu cầu bộ nhớ và có thể cải thiện thông lượng, tùy thuộc vào phần cứng và cách triển khai. Đánh đổi ở đây là độ chính xác thấp hơn có thể làm giảm chất lượng hoặc gây ra các vấn đề số học, vì vậy cần kiểm thử thay vì mặc định cho rằng nó vô hại.

Chưng cất huấn luyện một mô hình học sinh nhỏ hơn để tái hiện hành vi hữu ích từ một mô hình giáo viên lớn hơn. Mô hình học sinh có thể học từ đầu ra của mô hình giáo viên, các tín hiệu trung gian hoặc những ví dụ dành riêng cho nhiệm vụ. Nó không cần tái tạo mọi năng lực của mô hình lớn hơn; nó chỉ cần thực hiện đủ tốt công việc mục tiêu.

Suy luận được tối ưu hóa điều chỉnh quá trình thực thi cho một runtime và bộ xử lý cụ thể. Việc này có thể bao gồm lựa chọn kernel, biên dịch đồ thị, batching, lập kế hoạch bộ nhớ, caching và tăng tốc dành riêng cho phần cứng. TensorRT Model Connect của NVIDIA, được công bố ở dạng bản xem trước công khai, là một ví dụ về công cụ nhằm chuyển các checkpoint được hỗ trợ của Hugging Face hoặc checkpoint cục bộ thành suy luận TensorRT đầu-cuối mà không cần xuất ONNX trung gian. Mục tiêu được nêu của công cụ này bao gồm các khối lượng công việc về robot, thiết bị và nền tảng.

Các kỹ thuật này củng cố lẫn nhau. Chưng cất có thể tạo ra một mô hình nhỏ gọn; lượng tử hóa có thể tiếp tục giảm dấu chân của mô hình; runtime được tối ưu hóa có thể quyết định liệu mô hình kết quả có thực sự nhanh trên chip dự kiến hay không.

Một kết quả hữu ích không đồng nghĩa với một tệp nhỏ hơn

Nén mô hình nên được xem là một bài toán về sản phẩm và hệ thống, không phải một mánh khóe để leo bảng xếp hạng. Một mô hình nhỏ hơn 40 phần trăm nhưng bỏ sót các vật thể quan trọng trong điều kiện ánh sáng kém có thể tệ hơn đối với robot kho hàng. Một mô hình ngôn ngữ có chi phí thấp trên mỗi token nhưng tạo ra đầu ra có cấu trúc sai định dạng có thể làm tăng công việc sửa chữa ở các bước tiếp theo. Một mô hình hoạt động tốt trong điểm chuẩn có thể thất bại khi hiện tượng giảm xung do nhiệt, nhiễu camera, kết nối chập chờn hoặc đầu vào bất thường của người dùng xuất hiện.

Báo cáo của Liquid AI về chưng cất có nhận biết lượng tử hóa cho các mô hình nhỏ LFM2.5 là một minh họa hữu ích cho mục tiêu này. Công ty báo cáo duy trì 96.5% đến 97.4% hiệu năng BF16 trong khi vẫn giữ mức sử dụng bộ nhớ và thông lượng Q4_0. Những con số đó do công ty báo cáo và chỉ áp dụng cho từng mô hình cụ thể; không nên khái quát chúng cho mọi kiến trúc. Nhưng chúng cho thấy kiểu so sánh mà người thực hành nên tìm kiếm: khả năng duy trì chất lượng được đo cùng với bộ nhớ và tốc độ, thay vì chỉ dựa vào riêng tỷ lệ nén.

Đối với một hệ thống triển khai, bài kiểm tra nghiệm thu ít nhất nên bao gồm:

  • chất lượng thực hiện nhiệm vụ trên các ví dụ đại diện và khó;
  • yêu cầu về bộ nhớ đỉnh và dung lượng lưu trữ;
  • độ trễ của phản hồi đầu tiên và trạng thái ổn định;
  • thông lượng trong điều kiện đồng thời thực tế;
  • mức sử dụng năng lượng hoặc trạng thái nhiệt khi phù hợp;
  • cách hệ thống xử lý thất bại khi đầu vào bị thiếu, nhiễu hoặc nằm ngoài phân phối;
  • chi phí và gánh nặng vận hành khi cập nhật mô hình.

Các chỉ số cụ thể thay đổi tùy theo sản phẩm. Một camera có thể quan tâm đến số khung hình mỗi giây và tỷ lệ bỏ sót. Một giao diện giọng nói có thể quan tâm đến thời gian phản hồi đầu-cuối. Một robot có thể quan tâm đến thời hạn của vòng lặp điều khiển và cách chuyển sang chế độ dự phòng an toàn. Điểm cốt lõi là kết nối việc đánh giá mô hình với những hậu quả vật lý hoặc tài chính của sự cố.

Những công việc mới xuất hiện ở đâu

Cơ hội đang mở rộng không chỉ dành cho những người phát minh ra các kiến trúc. Nó còn bao gồm một số vai trò thực tiễn:

  • Kỹ sư suy luận lập hồ sơ hiệu năng của mô hình trên các bộ tăng tốc mục tiêu, lựa chọn môi trường chạy, tối ưu hóa đồ thị, và chẩn đoán các điểm nghẽn về độ trễ hoặc bộ nhớ.
  • Kỹ sư nén mô hình thiết kế các quy trình lượng tử hóa và chưng cất, lựa chọn dữ liệu hiệu chuẩn, và đo mức suy giảm chất lượng theo từng tác vụ và phân khúc.
  • Kỹ sư ML biên đóng gói mô hình cho các môi trường di động, nhúng, công nghiệp hoặc ô tô, đồng thời quản lý việc cập nhật trong điều kiện kết nối hạn chế.
  • Kỹ sư phần mềm robot kết nối các mô hình nhận thức với cảm biến, hệ thống lập kế hoạch và các ràng buộc an toàn, trong những tình huống mà thời gian là yếu tố quan trọng.
  • Kỹ sư sản phẩm am hiểu phần cứng quyết định một khối lượng công việc nên được xử lý trên thiết bị, tại biên hay trên đám mây—và thiết kế cơ chế chuyển giao linh hoạt giữa các bên.
  • Chuyên gia triển khai và kiểm định xây dựng các bộ kiểm thử bao gồm điều kiện nhiệt, điện năng, mạng và môi trường thực tế.

Các nhà phát triển ứng dụng cũng có việc phải làm. Một nhóm sản phẩm có thể không huấn luyện mô hình, nhưng vẫn phải lựa chọn định dạng mô hình, tích hợp thư viện suy luận, xử lý các toán tử không được hỗ trợ, cung cấp thông tin về độ tin cậy hoặc hành vi từ chối dự đoán, và bảo đảm có thể hoàn tác các bản nâng cấp.

Phân tách đám mây-biên đang trở thành một kỹ năng thiết kế

Các mô hình nhỏ không loại bỏ mô hình đám mây. Chúng khiến các hệ thống lai trở nên hấp dẫn hơn. Một thiết bị có thể sử dụng mô hình nhỏ gọn để phát hiện tức thời, sau đó gửi các sự kiện được chọn đến một mô hình lớn hơn để giải thích hoặc phân tích sâu hơn. Một robot có thể giữ phần nhận thức quan trọng đối với an toàn ở cục bộ, đồng thời sử dụng đám mây để học ở cấp độ toàn đội robot. Một sản phẩm hỗ trợ khách hàng có thể chuyển việc phân loại thông thường cho một mô hình nhỏ và chuyển các trường hợp không rõ ràng cho một mô hình có năng lực hơn.

Kiến trúc này có thể giảm băng thông và độ trễ, nhưng đồng thời đưa vào những quyết định cần có người chịu trách nhiệm rõ ràng. Thông tin nào được gửi ra khỏi thiết bị? Điều gì xảy ra khi không có kết nối? Phiên bản mô hình nào đã tạo ra một hành động? Thiết bị có thể khôi phục an toàn không? Hiệu năng được giám sát như thế nào khi mỗi cấu hình phần cứng lại hoạt động khác nhau?

Đây là những câu hỏi về triển khai, không đơn thuần là câu hỏi về mô hình. Chúng mang lại lợi thế cho những chuyên gia hiểu được giao diện giữa học máy, hệ thống nhúng, mạng, yêu cầu sản phẩm và vận hành.

Một lộ trình học tập thực tiễn

Nếu muốn hướng đến công việc này, hãy xây dựng một hệ thống triển khai nhỏ nhưng có thể đo lường, thay vì chỉ sưu tầm các chứng chỉ về mô hình. Bắt đầu với một tác vụ có mục tiêu rõ ràng, chẳng hạn như phân loại hình ảnh, nhận diện từ khóa, phân loại tài liệu hoặc một trợ lý cục bộ nhỏ gọn.

  1. Thiết lập đường cơ sở. Ghi lại chất lượng, kích thước mô hình, mức sử dụng bộ nhớ, độ trễ và thông lượng bằng một tập kiểm thử có thể tái lập.
  2. Lượng tử hóa mô hình. So sánh ít nhất một phiên bản có độ chính xác thấp hơn với đường cơ sở. Ghi lại những ví dụ nào thay đổi và liệu lỗi có tập trung ở một nhóm quan trọng hay không.
  3. Thử chưng cất hoặc tinh chỉnh theo tác vụ. Đo xem một mô hình nhỏ hơn có thể duy trì hành vi mà sản phẩm thực sự cần hay không.
  4. Chạy trên phần cứng mục tiêu. Kết quả đo trên máy tính để bàn không phải là bằng chứng về hiệu năng trên điện thoại, máy tính siêu nhỏ, GPU, bộ tăng tốc hoặc máy tính robot.
  5. Đóng gói hệ thống triển khai. Bao gồm tiền xử lý, hậu xử lý, siêu dữ liệu phiên bản, kiểm tra tình trạng và một đường dẫn dự phòng.
  6. Viết báo cáo đánh đổi. Giải thích vì sao mô hình được chọn là lựa chọn tốt hơn xét trên chất lượng, độ trễ, bộ nhớ, năng lượng, quyền riêng tư và chi phí—không chỉ vì nó có điểm số cao nhất.

Các công cụ hữu ích phụ thuộc vào ngăn xếp mục tiêu, nhưng những kỹ năng có thể chuyển đổi thì nhất quán: lập hồ sơ hiệu năng, tư duy định lượng, lựa chọn dữ liệu, thiết kế kiểm thử, gỡ lỗi và truyền đạt rõ ràng các đánh đổi. Hãy học cách đọc đồ thị mô hình, kiểm tra khả năng hỗ trợ toán tử, xác định việc di chuyển bộ nhớ là một điểm nghẽn, và phân biệt năng lực tính toán trên lý thuyết với độ trễ đầu-cuối được đo thực tế.

Tín hiệu nghề nghiệp

Sự chuyển dịch quan trọng trong nghề nghiệp là từ việc hỏi “Mô hình nào thông minh nhất?” sang hỏi “Hệ thống nào mang lại kết quả cần thiết trong các ràng buộc thực tế?” Các mô hình lớn vẫn sẽ có giá trị, đặc biệt đối với suy luận mở và việc tạo nội dung phức tạp. Nhưng nhiều tác vụ thương mại và trong thế giới vật lý đủ hẹp để một mô hình nhỏ gọn, nhanh và riêng tư có thể là sản phẩm tốt hơn.

Điều đó tạo không gian cho những người thực hành có thể kết nối nghiên cứu với triển khai. Những người chiến thắng sẽ không phải lúc nào cũng là các đội có mô hình lớn nhất. Họ có thể là những đội hiểu rõ khối lượng công việc, nén mô hình một cách thông minh, đánh giá trung thực và đưa vào vận hành một hệ thống đáng tin cậy trên phần cứng sẵn có.

Đối với sự nghiệp trong lĩnh vực AI, đó là một bài học bền vững: trí thông minh chỉ là một phần của sản phẩm cần bàn giao. Phần còn lại là khiến nó phù hợp.