Tăng tốc phần cứng cho LLM: Khảo sát và so sánh tổng hợp

 (arxiv.org)
1 điểm bởi GN⁺ 2024-09-08 | 1 bình luận | Chia sẻ qua WhatsApp

Các LLM được tăng tốc bằng phần cứng: khảo sát và so sánh tổng hợp

  • LLM đã nổi lên như một công cụ mạnh mẽ trong các tác vụ xử lý ngôn ngữ tự nhiên, cách mạng hóa lĩnh vực này nhờ khả năng hiểu và tạo ra văn bản giống con người
  • Bài báo này khảo sát một cách toàn diện nhiều nỗ lực nghiên cứu về tăng tốc mạng biến đổi cho các mô hình ngôn ngữ lớn bằng cách sử dụng các bộ gia tốc phần cứng

Khung làm việc và so sánh

  • Giới thiệu khung làm việc được đề xuất và thực hiện so sánh định tính lẫn định lượng về công nghệ, nền tảng xử lý (FPGA, ASIC, In-Memory, GPU), mức tăng tốc, hiệu quả năng lượng, hiệu năng (GOPs) và hiệu quả năng lượng (GOPs/W)
  • Thách thức chính là mỗi phương án được đề xuất đều được triển khai trên các công nghệ quy trình khác nhau, khiến việc so sánh công bằng trở nên khó khăn
  • Đóng góp chính của bài báo là ước tính kết quả về hiệu năng và hiệu quả năng lượng trên cùng một công nghệ, từ đó cho phép so sánh công bằng

Thí nghiệm và kết quả

  • Triển khai một phần của LLM trên nhiều chip FPGA để ước tính kết quả trên cùng công nghệ quy trình và so sánh hiệu năng một cách công bằng

Tóm tắt của GN⁺

  • Bài báo này cung cấp một khảo sát toàn diện về tăng tốc phần cứng cho các mô hình ngôn ngữ lớn (LLMs)
  • So sánh hiệu năng và hiệu quả năng lượng trên nhiều nền tảng xử lý khác nhau để cho phép đối chiếu công bằng
  • Sử dụng chip FPGA để thực nghiệm nhằm ước tính kết quả trên cùng một công nghệ
  • Có thể hữu ích với những người quan tâm đến việc cải thiện hiệu năng của LLM trong lĩnh vực xử lý ngôn ngữ tự nhiên
  • Các dự án khác có chức năng tương tự bao gồm bộ gia tốc GPU của NVIDIA và TPU của Google

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-08
Ý kiến trên Hacker News

  • Bài báo này phần giải thích bối cảnh còn khá nông, nên nếu bổ sung thêm ngữ cảnh thì từ đầu thập niên 1990 đã có nhận định rằng hiệu năng tính toán của CPU (FLOPs) cải thiện nhanh hơn băng thông bộ nhớ, và vào năm 1995, William Wulf cùng Sally Mckee dự đoán khoảng cách này sẽ dẫn tới bức tường bộ nhớ, nơi phần lớn phép tính bị chặn không phải bởi toán học mà bởi truy cập dữ liệu
    Trong 20 năm qua, FLOPS tối đa của phần cứng máy chủ đã tăng gấp 3 sau mỗi 2 năm, nhưng băng thông DRAM và interconnect chỉ tăng lần lượt khoảng 1,6 lần và 1,4 lần
    Vì thế, trong huấn luyện và suy luận LLM, nút thắt hiệu năng ngày càng chuyển sang băng thông bộ nhớ, và đặc biệt trong các mô hình decoder Transformer tự hồi quy, đây có thể trở thành nút thắt chi phối
    Xu hướng này đang tạo ra nhu cầu cho các công nghệ như Compute-in-memory (CIM), processing-in-memory (PIM). Đây là phần cứng thực hiện tính toán trực tiếp trên dữ liệu trong bộ nhớ thay vì phải chuyển dữ liệu trước vào thanh ghi CPU, nên có thể giảm độ trễ và điện năng tiêu thụ, đồng thời có khả năng vượt qua bức tường bộ nhớ
    Bài báo ngoại suy bằng khớp đa thức về chuẩn 16nm để so sánh phần cứng ASIC và FPGA ở các kích thước tiến trình bán dẫn khác nhau: “Dựa trên ‘Scaling equations for the accurate prediction of CMOS device performance from 180 nm to 7nm’ của Aaron Stillmaker và B.Baas, chúng tôi đã ngoại suy hiệu năng và hiệu quả năng lượng ở công nghệ 16nm để so sánh công bằng”
    Nhưng với CIM/PIM thì họ không ngoại suy, với lý do rằng “hiệu năng của bộ gia tốc in-memory không chỉ dựa trên công nghệ tiến trình, vì vậy chúng tôi chỉ thực hiện ngoại suy với các bộ gia tốc FPGA và ASIC, nơi công nghệ tiến trình ảnh hưởng lớn đến hiệu năng hệ thống”. Bề ngoài thì đây có vẻ là một quyết định hơi lạ, và chắc sẽ cần ai đó giải thích thêm về quyết định này
    Đọc thêm: https://arxiv.org/abs/2403.14123, https://en.m.wikipedia.org/wiki/In-memory_processing, http://vcl.ece.ucdavis.edu/pubs/2017.02.VLSIintegration.Tech...

    • Những nỗ lực kiểu này nhìn chung đều đã thất bại trên thị trường, danh sách được tổng hợp ở đây: https://news.ycombinator.com/item?id=41069685
      Dù vậy, mình vẫn thích các sản phẩm dạng mô-đun RAM vì giá rẻ. Có thể hình dung việc cắm đầy chúng lên một bo mạch 1U rồi nối lại bằng interconnect tốc độ cao, hoặc thậm chí nhồi kín cả một thẻ PCI
    • Có thể điều đó đúng cho tới trước năm 2018, nhưng từ sau đó Ethernet 400GbE đã trở thành interconnect được chấp nhận nhanh nhất, và hiện nay đã có cả interconnect 1.6Tbit
      PCI-e V4 trôi qua quá nhanh, có cảm giác vòng đời chỉ khoảng 2 năm, còn NVMeOF thì đã mở rộng khá tốt cùng với hiệu năng fabric. H100 DGX hiện có interconnect 400GB/s
    • Không rõ cuối cùng memristor và lời hứa về việc bộ nhớ sẽ nằm cạnh CPU đã đi đến đâu rồi
    • Đúng vậy. Gần đây Dr. Jung Bae Lee của Samsung cũng đã nói điều tương tự
      “Sự tăng trưởng bùng nổ của các mô hình AI đang bị giới hạn bởi khoảng cách ngày càng rộng giữa hiệu năng tính toán và băng thông bộ nhớ. Các mô hình thế hệ tiếp theo như GPT-5 được kỳ vọng sẽ đạt quy mô chưa từng có, từ 3 đến 5 nghìn tỷ tham số, nhưng nút thắt kỹ thuật là băng thông bộ nhớ đang trở thành rào cản then chốt ngăn chúng phát huy hết tiềm năng”
      https://www.lycee.ai/blog/2024-09-04-samsung-memory-bottlene...

  • Từ lâu tôi đã thích mảng systolic, và sau khi xem qua nhiều lựa chọn trong vài thập kỷ qua, tôi cho rằng lưới Descartes của các ô là lời giải tối ưu
    Mỗi ô có 4 bit đầu vào, mỗi bit đến từ một ô lân cận, và 4 bit đầu ra, mỗi bit đi tới một ô lân cận. Ở giữa là thanh ghi dịch 64 bit của một chuỗi scan dài, và đầu ra của nó đi vào 4 bộ ghép kênh 16:1 cùng một latch 4 bit
    Nếu dùng phép màu của tô màu đồ thị để cấp xung nhịp cho mọi ô theo mẫu bàn cờ, dữ liệu có thể chảy theo bất kỳ hướng nào mà không bị thiên lệch theo một hướng nhất định và không có điều kiện tranh chấp. Mọi đầu vào của bất kỳ ô nào cũng sẽ ổn định
    Cách này mang lại sự linh hoạt của FPGA mà không cần lo về vấn đề timing, điều kiện tranh chấp hay glitch. Các đường dây cũng đều ngắn nên mọi thứ đều cục bộ, nhanh và tiết kiệm điện
    Đổi lại, nó không tối ưu về hiệu quả cổng logic cũng như không cung cấp đường ngắn nhất cho logic. Mọi phép toán đơn lẻ về cơ bản diễn ra song song, và toàn bộ tính toán đều được pipeline hóa
    Đây là ý tưởng tôi đã có từ khoảng năm 1982, và tôi mong ai đó sẽ tiếp nối rồi hiện thực hóa nó cho đúng nghĩa. Tôi gọi nó là BitGrid

    • Nghe khá giống chip GA144 do người phát minh ra Forth tạo ra
    • Làm tôi nghĩ tới TPU

  • Tài liệu liên quan: https://arxiv.org/pdf/2406.08413
    Memory Is All You Need: An Overview of Compute-in-Memory Architectures for Accelerating Large Language Model Inference

  • Tôi muốn thấy LLM chạy trong WebGL, nơi mọi thứ đều là texture. Nhìn sự khác biệt kiến trúc theo kiểu trực quan như vậy chắc sẽ khá thú vị

    • Chẳng phải khi đó sẽ giống như chỉ đang nhìn nhiễu tĩnh sao?
    • Google có công cụ để xem trạng thái kích hoạt của ma trận đúng không? Hình như là Gemma Scope

  • Nút thắt hiện nay là di chuyển bộ nhớ, và đó là lý do HBM đắt. Thiết kế của Nvidia cũng được tối ưu xoay quanh bộ nhớ, vốn là nút thắt thực sự, ở cả cấp độ chip lẫn cấp độ hệ thống

    • Không hiểu vì sao mọi GPU lại chưa chuyển hết sang HBMx
      Trên thực tế gần như không thấy điều đó

  • Liệu kiến trúc lai FPGA + ASIC + in-memory có thể đóng vai trò về khả năng mở rộng và tính linh hoạt không? FPGA có ưu thế về độ linh hoạt, ASIC về hiệu năng, còn in-memory về hiệu quả năng lượng, nên cũng tò mò liệu cách tiếp cận lai tích hợp chúng lại có thể đẩy hiệu năng LLM lên cao hơn nữa hay không

    • Thông thường sẽ bắt đầu với FPGA + bộ nhớ trước, rồi khi thị trường đạt đến điểm phù hợp để có sản lượng đủ lớn thì sẽ đổi FPGA sang ASIC để tăng hiệu năng và giảm chi phí. Các công ty lớn thường đi thẳng tới ASIC

  • In-memory có vẻ không chỉ đúng ở khía cạnh hiệu năng mà cả về hướng đi tổng thể nữa. Việc làm ASIC hoặc lập trình FPGA cho một mô hình mà dù may mắn cũng có thể thành lỗi thời chỉ sau vài tháng thì không thực sự hợp lý

  • Đã có một bài báo nói về việc chạy LLM với mức điện năng chỉ cỡ một bóng đèn
    https://arxiv.org/abs/2406.02528
    https://news.ucsc.edu/2024/06/matmul-free-llm.html

    • Bài này tuyên bố giảm 90% bộ nhớ cùng với mã nguồn mở có thể tái hiện trên GPU tiêu chuẩn: https://github.com/ridgerchu/matmulfreellm
      Cốt lõi là dùng hai kỹ thuật để tránh phép nhân ma trận. Thứ nhất, ép mọi con số trong ma trận chỉ nhận ba giá trị -1, 0, +1 để biến phép nhân thành phép cộng. Thứ hai, thay vì nhân từng phần tử một, họ chồng các ma trận lên rồi chỉ thực hiện những phép tính quan trọng
      Nhóm nghiên cứu cho biết họ đã đưa tính toán dựa trên thời gian vào quá trình huấn luyện mô hình để giữ được hiệu năng mạng nơ-ron, và nhờ vậy mạng có “ký ức” về thông tin quan trọng mà nó xử lý, từ đó hiệu năng được cải thiện
      Trên GPU tiêu chuẩn, lượng bộ nhớ giảm xuống còn khoảng 1/10 và tốc độ nhanh hơn khoảng 25%, đồng thời có thể mở ra cách chạy thuật toán ở dung lượng tối đa ngay cả trên các thiết bị ít bộ nhớ như smartphone. Nguyên mẫu FPGA được làm trong 3 tuần đã vượt ngưỡng thông lượng con người có thể đọc được chỉ với 13W điện, trong khi GPU sẽ cần khoảng 700W, nên phần cứng tùy biến được cho là hiệu quả hơn GPU hơn 50 lần

  • Không rõ in-memory ở đây có nghĩa là phần cứng đặc biệt kết hợp CPU và RAM hay không

    • Có lẽ là cách đưa phần cứng MAC vào die DRAM. Nếu là HBM xếp chồng thì có thể sẽ nằm trên die nền
      Trích một bài báo tăng tốc cũ cho thấy cải thiện gấp 19 lần so với DRAM + GPU: “Vì phép toán MAC chiếm phần chi phối trong thời gian thực thi của hầu hết các tác vụ machine learning, chúng tôi đề xuất phép nhân bên trong subarray và phép cộng dồn bên trong bank. Phép nhân được xử lý theo cách dựa trên cột, thực hiện phép AND và phép cộng, với chi phí diện tích bổ sung dưới 1%”
      https://arxiv.org/pdf/2105.03736
    • In-memory nói chung có nghĩa là không phải đọc lại dữ liệu từ thiết bị lưu trữ

  • Có cách nào để xem nội dung Arxiv dễ đọc hơn không?
    Mỗi lần vào trang đó tôi đều bị bối rối không biết có giao diện tử tế hay không và cứ như đi lạc, nên thường thoát ra trước khi đọc được nội dung

    • Bấm View PDF hoặc HTML (experimental) ở góc trên bên phải là có thể vào phần nội dung
    • Đây là trang công bố trước bài báo nên về cơ bản mọi thứ đều ở dạng PDF. Gần đây họ cũng đã thêm HTML: https://arxiv.org/html/2409.03384v1
      Với từng bài riêng lẻ thì đây là cách tốt nhất, và cũng có một vài frontend cho Arxiv như https://arxiv-sanity-lite.com/
    • Hôm nay tôi cũng mở liên kết này rồi nghĩ kiểu “à, chỉ có abstract thôi, thoát vậy”. Tôi đã từng đọc bài trên Arxiv, nhưng chỉ nhìn UI thì đúng là không có cảm giác nội dung đầy đủ đang được cung cấp