‘LLM in a Flash’ cho phép suy luận LLM hiệu quả với bộ nhớ hạn chế
(huggingface.co)- LLM in a Flash đặt các tham số của LLM lớn hơn DRAM trong bộ nhớ flash, chỉ đưa phần cần thiết vào DRAM để cho phép suy luận ngay cả trên thiết bị có bộ nhớ hạn chế
- Dựa trên mô hình chi phí suy luận phản ánh đặc tính truy cập của bộ nhớ flash, hệ thống giảm lượng dữ liệu truyền và thúc đẩy việc đọc các khối lớn, liên tục hơn
- windowing tái sử dụng các neuron đã được kích hoạt trước đó, còn row-column bundling tận dụng thế mạnh truy cập tuần tự của flash để giảm nút thắt cổ chai
- Khi kết hợp hai kỹ thuật này, có thể chạy mô hình có kích thước lên tới gấp 2 lần DRAM khả dụng, đồng thời suy luận nhanh hơn cách nạp đơn giản 4~5 lần trên CPU và 20~25 lần trên GPU
- Khi kết hợp nhận biết tính thưa, nạp thích ứng theo ngữ cảnh và thiết kế hướng phần cứng, khả năng chạy LLM trên thiết bị bị giới hạn bộ nhớ được mở rộng đáng kể
Suy luận LLM dựa trên bộ nhớ flash
- Các mô hình ngôn ngữ lớn đạt hiệu năng cao trong nhiều tác vụ xử lý ngôn ngữ tự nhiên, nhưng do khối lượng tính toán và yêu cầu bộ nhớ lớn nên khó chạy trên các thiết bị có dung lượng DRAM hạn chế
- LLM in a Flash xử lý ràng buộc này bằng cách lưu tham số mô hình trong bộ nhớ flash và chỉ đưa dữ liệu cần thiết vào DRAM theo yêu cầu trong quá trình suy luận
- Trọng tâm của cách tiếp cận là mô hình chi phí suy luận được thiết kế phù hợp với cách hoạt động của bộ nhớ flash
- Tối ưu để giảm lượng dữ liệu được truyền từ flash
- Được thiết kế để đọc dữ liệu theo các khối lớn hơn và liên tục hơn
Hai kỹ thuật giúp giảm lượng truyền và mẫu đọc
- windowing tái sử dụng các neuron đã được kích hoạt trước đó để giảm lượng dữ liệu cần chuyển từ flash sang DRAM
- row-column bundling tăng kích thước các khối dữ liệu đọc từ flash, phù hợp với đặc tính bộ nhớ flash mạnh về truy cập dữ liệu tuần tự
- Khi dùng đồng thời hai kỹ thuật, có thể chạy mô hình lớn tới 2 lần dung lượng DRAM khả dụng
- Mức cải thiện tốc độ suy luận so với cách nạp đơn giản khác nhau tùy phần cứng
- Trên CPU, nhanh hơn 4~5 lần
- Trên GPU, nhanh hơn 20~25 lần
- Thiết kế này tích hợp nhận biết tính thưa, nạp thích ứng theo ngữ cảnh và thiết kế hướng phần cứng để cho phép suy luận LLM trong môi trường bộ nhớ hạn chế
1 bình luận
Ý kiến trên Hacker News
Bài báo đó được xây dựng trên kỹ thuật khai thác độ thưa của bài báo Deja Vu, vốn đã khá phức tạp, nên mất thời gian để hiểu
Deja Vu cho rằng ngay cả các mô hình có độ thưa trọng số thấp cũng có “độ thưa theo ngữ cảnh (contextual sparsity)” cao. Tức là trong vector kết quả của phép nhân ma trận xuất hiện nhiều giá trị 0, nhưng vị trí nào trở thành 0 thì thay đổi tùy theo đầu vào
Tận dụng độ thưa này có thể bỏ qua việc tải một số hàng của ma trận; để đạt được lợi ích hiệu năng, cần dự đoán trước nên bỏ qua hàng nào, và việc dự đoán đó có thể thực hiện bằng ma trận hạng thấp
Bài báo của Apple đề xuất rằng phát hiện này không chỉ giúp hiệu năng tải từ RAM, mà còn hữu ích khi tải từ bộ nhớ flash mà không phải hy sinh đáng kể băng thông
Ma trận attention tương đối nhẹ, còn đối tượng cần tải theo cách thưa là FFN. Ngoài ra, nếu dự đoán đầu ra của tầng ReLU thay vì đầu vào FFN thì có thể đạt độ thưa tốt hơn nhiều. Nếu có thể dự đoán rằng “ô vector này sẽ âm sau phép nhân ma trận và trước ReLU”, thì không cần tải cột ma trận tương ứng mà chỉ xuất ra 0
Đề xuất là phần lớn các hàng của FFN hoàn toàn không cần tải; với mỗi FFN, duy trì cache các hàng được dùng gần đây rồi cập nhật từ flash khi cần. Còn có thêm tương quan giữa việc tải theo chunk và các tầng projection, nhưng có vẻ đây là insight cốt lõi
FFN là Feed Forward Network, và trong transformer đây là những khối lớn nhất
Tôi tò mò có thể không tải bao nhiêu phần của mô hình trước khi bắt đầu thấy khác biệt hiệu năng thực sự
Ví dụ, để duy trì 90% hiệu năng so với khi đưa toàn bộ vào RAM, tôi muốn biết liệu chỉ cần dùng một nửa bộ nhớ, hay cần 90%, hay 95%
Rốt cuộc vấn đề là khi giảm RAM, hiệu năng mất đi nhanh đến mức nào so với hiệu năng tối đa. Biểu đồ so sánh thuật toán này với thuật toán cơ bản trong điều kiện RAM ít; đó là một câu hỏi khác, nhưng vẫn là câu hỏi hay
Nếu có thể đạt hiệu năng tốt mà không cần đưa toàn bộ mô hình 8GB vào bộ nhớ điện thoại thì rõ ràng là hữu ích
Toàn bộ bài báo đáng để đọc, và đây là một công trình khá thú vị: https://arxiv.org/pdf/2312.11514
Phần được bài báo nhấn mạnh là hai kỹ thuật bổ trợ nhằm giảm thiểu truyền dữ liệu và tối đa hóa thông lượng bộ nhớ flash
Windowing là cách tái sử dụng các giá trị activation của các token vừa tính gần đây, đồng thời chỉ tải các tham số cần cho vài token trước đó, nhờ đó giảm số lượng yêu cầu I/O để tải trọng số
Row-column bundling nối các hàng và cột của tầng up-projection và down-projection để lưu trữ, khiến việc đọc từ flash diễn ra theo các chunk liên tục lớn hơn, và việc đọc chunk lớn giúp tăng thông lượng
Về lý thuyết, khi một phần mô hình nằm trên flash, thời gian suy luận cho một token đơn lẻ sẽ bằng thời gian suy luận khi toàn bộ mô hình nằm trong RAM cộng với thời gian tải phần mô hình nằm trên flash
Tôi giả định là không cần ghi lại vào flash, nhưng tôi không phải chuyên gia LLM nên có thể sai
Nếu số tầng nhiều hơn hẳn 10, có vẻ có thể chỉ chừa lại một phần nhỏ RAM rồi tải từng tầng một. Các LLM thông thường có vài chục tầng nên điều đó nghe hợp lý
Nếu trong quá trình suy luận RAM không phải nút thắt, có lẽ cũng có thể truyền DMA tầng tiếp theo từ flash vào RAM trong lúc đang suy luận tầng hiện tại. Trên hệ thống một bộ xử lý thì có vẻ khó hiệu quả vì nút thắt RAM
Với hệ thống hai bộ xử lý, có lẽ một bộ xử lý có thể tải tầng tiếp theo vào RAM trong khi bộ xử lý còn lại suy luận tầng trước đó, nhờ vậy có thể chạy LLM rất lớn với ít RAM
Hiện tôi đang ngồi cạnh đống linh kiện để lắp một máy AI LLM mới. Đây là z840 hai bộ xử lý, nên tôi rất háo hức được tự tay thử những thứ như thế này
Có thể thấy rõ rằng thiết bị Apple có rất ít RAM so với các thiết bị tương tự của đối thủ
Một phần là vì đội ngũ phần mềm của Apple dùng các ngôn ngữ hiệu quả hơn như Objective-C, một phần là vì ứng dụng iOS không phải nhắm tới vô số độ phân giải màn hình khác nhau. Vì vậy việc tải texture độ phân giải cao rồi thu nhỏ lại tương đối ít xảy ra
Ngoài ra, ngay cả khi mua ở quy mô của Apple thì RAM cũng không rẻ đi nhiều, nên việc tăng RAM gây ảnh hưởng tới biên lợi nhuận lớn hơn so với bổ sung các tính năng khác
Nhưng LLM vốn dĩ ngốn rất nhiều RAM, nên tất cả những lựa chọn này đang quay lại gây áp lực. Dù dùng kỹ thuật tiết kiệm bộ nhớ nào đi nữa, các đối thủ có nhiều RAM hơn vẫn có thể đưa vào những mô hình lớn hơn, tốt hơn và thông minh hơn
Tôi đang muốn mua Mac trong thời gian tới và thật sự đau đầu không biết nên đặt cấu hình bao nhiêu RAM. Ngân sách hạn chế nên càng khó. Nếu không bị giới hạn, có lẽ tôi sẽ chọn ít nhất 32GB
Tôi vẫn hy vọng Apple thay đổi chính sách giá RAM, nhưng có lẽ đó chỉ là kỳ vọng hão huyền
Cũng có thể xem phần triển khai liên quan: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libke...
Ngoài ra thiết bị Apple hỗ trợ một tính năng gọi là “jetsam”, giải phóng bộ nhớ bằng cách kết thúc các ứng dụng không dùng hoặc đang chạy nền để ứng dụng có độ ưu tiên cao tiếp tục chạy mượt: https://developer.apple.com/documentation/xcode/identifying-...
Tôi sẵn sàng nghe gợi ý về laptop Linux yên tĩnh hoặc gần như không ồn. Phần lớn quạt đều chạy khá mạnh, và tôi sẵn sàng hy sinh một phần hiệu năng CPU để có sự yên tĩnh. Nếu có thể dễ dàng bật/tắt chế độ yên tĩnh thì cũng tốt
Tới giờ tôi chưa thấy máy nào sánh được độ êm của MacBook Air, và nếu có sản phẩm nào chứng minh tôi sai thì tôi rất vui được nghe
Tất nhiên nếu rẻ hơn hoặc thay RAM được thì càng tốt. Tôi chủ yếu dùng MacBook Air cho các dịch vụ nền web, và làm terminal từ xa để kết nối tới server Linux dùng cho biên dịch dự án lớn và home/self-hosting
Rõ ràng lịch trình đã bị kéo sớm lên, nhưng tôi không nghĩ giả thuyết của họ là sai
Tôi chỉ hiểu chủ đề này ở mức hạn chế, nhưng tôi tò mò liệu cách này có cho phép chạy LLM offline trên điện thoại hay không
Nếu có thể, có lẽ sẽ mở ra nhiều ứng dụng thú vị như kiểm duyệt nội dung có trợ lý AI mà không cần gửi dữ liệu nhạy cảm lên server
Ví dụ hôm qua có một GitHub Discussion về việc chạy LLM trên chip Apple A-series (iPhone) được đăng ở đây: https://news.ycombinator.com/item?id=38703161
Tôi thích việc các bài gần đây gọi là LLM chứ không phải “AI”. Như vậy có thể biết đây là nội dung về một công nghệ cụ thể, không phải lời phóng đại marketing
Tôi tò mò điều này khác FlashAttention như thế nào. Dùng thuật ngữ tương tự mà không giải thích khác biệt trong phần tóm tắt thì dễ gây nhầm lẫn
Sửa: Có vẻ họ mở rộng hai cơ chế khác nhau trong framework flash. Tiêu đề bài báo có thể đã tốt hơn, nhưng phần giải thích nằm trong vài trang đầu
Ở phần kết luận, tôi đã kỳ vọng một mục kiểu như “tính năng này sẽ được phơi bày cho người dùng như thế nào”, nhưng có lẽ đó là chuyện nằm ngoài phạm vi bài báo
Tôi tò mò liệu tính năng như vậy sẽ xuất hiện dưới dạng lệnh gọi API hoặc cấu hình của CoreML, ví dụ phải chỉ định cờ use_flash, hay sẽ là một tối ưu hóa runtime vô hình với người dùng
Cũng tò mò liệu có ai biết bài thuyết trình hoặc talk hay nào của Apple giải thích roadmap phát triển của CoreML, Metal, v.v. không
Apple đã mua lại một công ty Iran à?
[0]: https://www.geekwire.com/2020/exclusive-apple-acquires-xnor-...
Tôi biết cách tiếp cận là khác nhau, nhưng vì cả hai đều tận dụng bộ nhớ flash nên tôi đã kỳ vọng bài báo này ít nhất sẽ nhắc đến FlashAttention [1]
[1] https://arxiv.org/abs/2205.14135
Theo cách tôi hiểu, FlashAttention nói về các mẫu truy cập để tận dụng tốt hơn bộ nhớ cục bộ, đặc biệt là SRAM. Ví dụ như giữ dữ liệu trong cache L1 của CPU hoặc tầng tương đương trên GPU
Nói cách khác, FlashAttention liên quan đến phần nhanh hơn DRAM, còn bài báo này xử lý vấn đề offload tốt hơn sang phần chậm hơn DRAM
Trong câu “mô hình OPT 6.7B, chẳng hạn, thể hiện độ thưa 97% đáng chú ý bên trong các tầng FFN”, có ai biết chính xác chỉ số này nghĩa là gì không?
Tôi thắc mắc liệu nó có nghĩa là 97% giá trị của tầng là 0, hay là có thể nén xuống còn 3% kích thước
Nhưng vì 3% được kích hoạt không cố định, nên không thể loại bỏ hoàn toàn 97% còn lại. Có vẻ bài báo nói rằng có thể dự đoán khá chính xác 3% đang hoạt động, nhờ đó làm cho mô hình nhanh hơn mà không mất quá nhiều độ chính xác