AMD mua lại MK1 nhằm nâng cao hiệu năng và hiệu quả suy luận AI

 (mkone.ai)
1 điểm bởi GN⁺ 2023-08-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • AMD thông qua việc mua lại MK1 muốn nâng hiệu năng và hiệu quả suy luận AI trên toàn bộ stack, từ phần cứng đến phần mềm
  • MK1, có trụ sở tại Mountain View, là đội ngũ tập trung vào suy luận tốc độ cao phù hợp cho triển khai quy mô lớn và công nghệ AI dựa trên reasoning
  • Flywheel của MK1 được tối ưu hóa cho phần cứng AMD và hiện xử lý hơn 1 nghìn tỷ token mỗi ngày
  • Đội ngũ MK1 sẽ gia nhập AMD Artificial Intelligence Group, tham gia tăng cường stack phần mềm AI doanh nghiệp và năng lực suy luận
  • Flywheel và các comprehension engine tập trung tận dụng kiến trúc bộ nhớ của GPU AMD Instinct để nâng cao độ chính xác, hiệu quả chi phí và khả năng truy vết của reasoning quy mô lớn

MK1 gia nhập stack AI của AMD

  • AMD đã hoàn tất việc mua lại MK1 và xem đây là cột mốc chiến lược nhằm nâng hiệu năng và hiệu quả AI trên toàn bộ stack
  • MK1 là đội ngũ có trụ sở tại Mountain View, California, đã phát triển suy luận tốc độ cao được tối ưu cho triển khai quy mô lớn và công nghệ AI dựa trên reasoning
  • Công nghệ Flywheel của MK1 được tối ưu hóa cho phần cứng AMD và hiện xử lý hơn 1 nghìn tỷ token mỗi ngày
  • Đội ngũ MK1 gia nhập AMD Artificial Intelligence Group
    • Công nghệ và chuyên môn của đội ngũ này sẽ được dùng để phát triển năng lực suy luận tốc độ cao và stack phần mềm AI doanh nghiệp của AMD

AI doanh nghiệp mà Flywheel hướng tới

  • Flywheel và các comprehension engine của MK1 được thiết kế để tận dụng kiến trúc bộ nhớ của GPU AMD Instinct
  • Công nghệ này tập trung cung cấp reasoning trong môi trường quy mô lớn với độ chính xác, hiệu quả chi phí và khả năng truy vết đầy đủ
  • AMD muốn kết hợp đổi mới phần mềm của MK1 với năng lực điện toán của mình để tăng tốc giai đoạn tiếp theo của AI doanh nghiệp
    • Hỗ trợ khách hàng tự động hóa các quy trình kinh doanh phức tạp
    • Hỗ trợ mở ra cơ hội mới trong các ứng dụng có giá trị gia tăng cao
  • Các câu liên quan đến tác động kỳ vọng của thương vụ mua lại là tuyên bố hướng tới tương lai, và kết quả thực tế có thể khác tùy theo các rủi ro và bất định được nêu trong hồ sơ AMD nộp cho SEC

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-07
Ý kiến trên Hacker News
  • Thật lạ là họ không hề nhắc đến các kỹ thuật lượng tử hóa hiện có hay so sánh với kết quả của chúng
    Thường thì tôi cố nhìn theo hướng thiện chí, nhưng khó có chuyện họ không biết đến các kỹ thuật cùng mục đích vốn đã được dùng rộng rãi, nên cần có benchmark so sánh
    Để bổ sung phần còn thiếu, có bảng so sánh theo từng kiểu lượng tử hóa mà llama.cpp cung cấp cho Llama 1[0]. Không thể so sánh trực tiếp với các chỉ số của Llama 2, nhưng nếu chỉ nhìn vào tốc độ và tỷ lệ thay đổi perplexity thì MK-1 trông rất giống Q5_1. Perplexity xấu đi ở mức nhỏ nhưng không thể bỏ qua, còn tốc độ nhanh hơn hơn 2 lần một chút
    Nếu các con số này đúng, có thể tải mô hình Llama 2 đã được lượng tử hóa sẵn từ Hugging Face và đạt hiệu năng gần như tương đương với những gì MK-1 cung cấp. File Q5 nằm ở đây: https://huggingface.co/TheBloke/Llama-2-13B-GGML/tree/main
    [0] https://github.com/ggerganov/llama.cpp#quantization
    • Tôi là một trong các nhà sáng lập. Lý do chúng tôi quyết định không so sánh với các phương pháp hiện có là vì cho rằng khó so sánh một cách công bằng
      Mỗi kỹ thuật có nhiều đánh đổi và trường hợp sử dụng khác nhau; không phải vấn đề một bên tệ còn bên kia tốt, mà là điểm thiết kế mục tiêu khác nhau. Ví dụ, cloud và chạy cục bộ là khác nhau. Chúng tôi đang công bố các số liệu và benchmark, đồng thời đang tìm các đối tác ban đầu phù hợp với đề xuất giá trị hiện tại, nên đang triển khai beta kín
      Ví dụ, llama.cpp là một framework tuyệt vời để chạy mô hình cục bộ trong trường hợp một người dùng (batch=1). Dù llama.cpp hỗ trợ nhiều backend như RPi, CPU, GPU, tôi không nghĩ sẽ công bằng nếu so sánh và nói MKML tốt hơn trên GPU trong trường hợp nhiều người dùng (batch >> 1) theo một mức perplexity, tỷ lệ nén và tốc độ nhất định. Theo tôi biết, đó không phải trường hợp sử dụng mục tiêu của llama.cpp. Ví dụ, MKML chạy Llama-2 7B trên 4090 với batch 32, tức xử lý song song 32 prompt, đạt khoảng 2700 tok/sec, dùng 5.2GB bộ nhớ, và perplexity gần như ở mức fp16
      Ngoài ra, hiện tại chúng tôi không bọc hay dùng các công cụ hoặc kỹ thuật mã nguồn mở cho lượng tử hóa. Tất cả đều là công nghệ tự phát triển, và sắp có thêm thông tin được công bố. Nếu có câu hỏi kỹ thuật cụ thể, tôi sẽ trả lời trong khả năng có thể
    • Việc dùng từ “codec” cũng khiến tôi hơi khó chịu. Cảm giác như họ muốn làm cho nó trông như đã phát minh ra một mô thức hoàn toàn mới, rồi gắn một cái tên nghe hay gợi liên tưởng đến nén video
    • Cuối tuần này tôi đã thử nghiệm đủ thứ với Llama2 trên AMD 7900 XTX bằng llama.cpp và lượng tử hóa q5_k_s
      So với các con số MK600 trên RTX 4090 mà họ đưa ra, dù dùng GPU rẻ hơn, throughput tôi đo được lại cao hơn và perplexity thấp hơn
    • Q5_1 cũng đã là cách làm cũ. Các kiểu lượng tử hóa dòng K nhanh hơn và tiết kiệm không gian hơn với cùng mức tổn thất perplexity
      https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
    • MKML nói rằng họ giảm kích thước mô hình Llama2-13B từ 26GB xuống 10.5GB. Bản cung cấp tương tự của TheBloke là mô hình Q6_K dung lượng 10.7GB
      Có khi họ chỉ đóng gói GGML và llama.cpp cho dễ dùng, rồi khiến mọi người tin rằng đó là công nghệ độc quyền
  • Không nhắc đến các kỹ thuật lượng tử hóa hiện có dù chỉ một lần? Tôi cá 10 đô rằng đây rất có thể chỉ là wrapper bọc bitsandbytes hoặc ggml
  • Nếu không phải mã nguồn mở thì có lẽ sẽ khó dùng
    Lĩnh vực này chuyển động quá nhanh, nếu không thì mức tiện lợi cũng không đủ
    Nói thêm, branding làm tôi liên tưởng đến MK-ultra, có lẽ nên tránh
  • Tôi từng làm lượng tử hóa mô hình học máy. Lượng tử hóa 4-bit hay 8-bit trong mã nguồn mở không phải là mức tốt nhất có thể đạt được
    Có những kỹ thuật tinh vi hơn nhiều để giảm kích thước trong khi vẫn giữ hiệu năng dự đoán. Một số kỹ thuật, ví dụ huấn luyện nhận biết lượng tử hóa, bao gồm cả việc thay đổi quá trình huấn luyện
    • Chắc chắn là có những cách tốt hơn. Nhưng trong trường hợp này, các con số của MKML không ấn tượng khi đặt cạnh các kỹ thuật lượng tử hóa tiêu biểu đã được dùng rộng rãi
      Theo bảng này[0], kích thước gần nhất với lượng tử hóa Q6_K, còn perplexity thì thậm chí có vẻ hơi tệ hơn
      Nếu kỹ thuật của họ tốt hơn, tôi nghĩ họ đã thừa nhận sự tồn tại của các kỹ thuật mã nguồn mở và đưa chúng vào bảng so sánh, thay vì làm như thể mô hình fp16 gốc là lựa chọn thay thế duy nhất
      [0] https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
    • Phương pháp lượng tử hóa của Unum thì sao?
      https://github.com/unum-cloud/usearch
  • Trông giống một vụ lùa gà startup AI nữa. Kiểu dùng GGML, đóng lại rồi đi gọi tiền VC
    Có vẻ lại là một công ty wrapper AI khác làm điều tương tự để tranh thủ leo lên trước khi cơn sốt LLM hạ nhiệt
    Nếu không mã nguồn mở mà đóng kín thì ngay từ đầu coi như đã hết cửa
  • Đây chẳng phải chỉ là lượng tử hóa sao?
    • Nhìn video demo thì đầu ra của hai trường hợp giống hệt nhau, nên tôi nghi ngờ việc họ có dùng lượng tử hóa hay không
    • Tôi cũng nghĩ đúng như vậy. Đây là việc mọi người đã làm rồi. Nếu họ không làm điều gì khác, họ cần cho thấy vì sao nó tốt hơn việc chỉ lượng tử hóa nhanh xuống 8-bit, 4-bit, v.v.
    • Dù là gì thì rất có khả năng nó sẽ sớm được sao chép hoặc có chức năng tương tự trong các công cụ mã nguồn mở như llama.cpp
      Không giống một lợi thế có thể phòng thủ được. Trông giống một tính năng đơn lẻ phải cạnh tranh với các lựa chọn mã nguồn mở đang tiến rất nhanh
  • Tiếc là đây không phải nỗ lực mã nguồn mở
    Tôi hoàn toàn không thích có phụ thuộc độc quyền trong stack của mình
    • Tôi khá hoài nghi chuyện này sẽ đi được đến đâu. Cộng đồng mã nguồn mở về cơ bản đã đạt được cải thiện hiệu năng tương tự bằng lượng tử hóa
      Cảm giác như họ đóng gói lại các thư viện hiện có để bán cho những startup AI thiếu thận trọng và thiếu thông tin
  • So với mlc-llm dùng lượng tử hóa 4-bit thì thế nào? Trên 4090 của tôi, llama2 13B chạy cực nhanh
    Dù cùng dùng lượng tử hóa 4-bit, nó vẫn nhanh hơn llama.cpp trên GPU vài lần
    • Đúng vậy, tự động tinh chỉnh TVM Vulkan thật đáng kinh ngạc. Tôi nghĩ thậm chí nó còn không dùng extension matmul Vulkan
      Lượng tử hóa 4-bit của MLC khá đơn giản so với llama.cpp nên làm perplexity kém hơn, và cũng giải thích một phần chênh lệch tốc độ. Nhưng tính năng thiếu lớn nhất là offload sang CPU. Nếu có tính năng này thì có thể chạy 70B trên 4090 khá ổn
      Tôi nghĩ chén thánh của suy luận LLM cục bộ là chạy Llama 70B bằng TVM và chia tải giữa GPU với GPU tích hợp. Cảm giác như gần tới nơi rồi. Các mảnh ghép đều đã có, chỉ thiếu một lập trình viên frontend nối các điểm lại với nhau
  • Giờ những việc như thế này cũng có thể làm trên MacBook Pro. Tôi không rõ vì sao lại muốn bị khóa vào một nhà cung cấp khác ở đây
    Nếu muốn dùng thứ tốt nhất thì dùng OpenAI hoặc Anthropic, còn không thì tự vận hành
  • Đây có phải thật sự là hiệu ứng của Ultra Instinct^H^H Llama2 không?
    Facebook về cơ bản đang tiếp sức cho hệ sinh thái, các nhà làm công cụ và các dịch vụ suy luận nhỏ hơn
    Công ty này đã có quyền tiếp cận một mô hình đáng tin cậy và phổ biến, cùng các trọng số liên quan với giấy phép mã nguồn mở thực sự, vì vậy họ có thể xây tối ưu hóa lên trên đó và bán mà không phải lo về giấy phép hay hạn chế của chính các trọng số