AMD akuisisi MK1 untuk meningkatkan performa dan efisiensi inferensi AI

• AMD berupaya meningkatkan performa dan efisiensi inferensi AI di seluruh stack, dari perangkat keras hingga perangkat lunak, melalui akuisisi MK1
• MK1 yang berbasis di Mountain View adalah tim yang telah berfokus pada inferensi berkecepatan tinggi untuk deployment skala besar dan teknologi AI berbasis reasoning
• Flywheel milik MK1 dioptimalkan untuk perangkat keras AMD dan saat ini memproses lebih dari 1 triliun token per hari
• Tim MK1 bergabung dengan AMD Artificial Intelligence Group dan akan ditugaskan untuk memperkuat stack perangkat lunak AI enterprise serta kapabilitas inferensi
• Flywheel dan comprehension engines berfokus pada peningkatan akurasi, efisiensi biaya, dan keterlacakan untuk reasoning skala besar dengan memanfaatkan arsitektur memori GPU AMD Instinct

---

MK1 bergabung dengan stack AI AMD

• AMD telah menyelesaikan akuisisi MK1 dan menjadikannya tonggak strategis untuk meningkatkan performa dan efisiensi AI di seluruh stack
• MK1 adalah tim yang berbasis di Mountain View, California, yang telah mengembangkan inferensi berkecepatan tinggi dan teknologi AI berbasis reasoning yang dioptimalkan untuk deployment skala besar
• Teknologi Flywheel milik MK1 dioptimalkan untuk perangkat keras AMD dan saat ini memproses lebih dari 1 triliun token per hari
• Tim MK1 bergabung dengan AMD Artificial Intelligence Group
  • Teknologi dan keahlian tim ini akan dimanfaatkan untuk memajukan kapabilitas inferensi berkecepatan tinggi AMD dan stack perangkat lunak AI enterprise

AI enterprise yang dibidik Flywheel

• Flywheel dan comprehension engines milik MK1 dirancang untuk memanfaatkan arsitektur memori GPU AMD Instinct
• Teknologi ini berfokus pada penyediaan reasoning dalam lingkungan skala besar dengan akurasi, efisiensi biaya, dan keterlacakan penuh
• AMD ingin mempercepat tahap berikutnya dari AI enterprise dengan menggabungkan inovasi perangkat lunak MK1 dan kapabilitas komputasinya sendiri
  • Mendukung pelanggan mengotomatiskan proses bisnis yang kompleks
  • Membantu membuka peluang baru dalam aplikasi bernilai tinggi
• Pernyataan terkait dampak yang diharapkan dari akuisisi ini merupakan pernyataan berwawasan ke depan, dan hasil aktual dapat berbeda tergantung pada risiko dan ketidakpastian yang tercantum dalam dokumen pengajuan AMD ke SEC

[GN⁺]

Opini Hacker News

• Aneh bahwa mereka sama sekali tidak menyebut teknik kuantisasi yang sudah ada atau membandingkan hasilnya
  Biasanya saya mencoba berprasangka baik, tetapi mustahil mereka tidak tahu teknik-teknik dengan tujuan serupa yang sudah banyak dipakai, jadi seharusnya ada benchmark perbandingan
  Untuk melengkapi bagian yang hilang, ada tabel perbandingan berdasarkan kuantisasi untuk Llama 1 yang disediakan llama.cpp[0]. Memang tidak bisa dibandingkan langsung dengan metrik Llama 2, tetapi jika hanya melihat perubahan kecepatan dan perplexity, MK-1 tampak sangat mirip dengan Q5_1. Perplexity memburuk sedikit tetapi tidak bisa diabaikan, dan kecepatannya menjadi sedikit di atas 2x lebih cepat
  Jika angka ini benar, Anda bisa mengunduh model Llama 2 yang sudah dikuantisasi sebelumnya dari Hugging Face dan memperoleh performa yang pada dasarnya sama dengan yang ditawarkan MK-1. File Q5 ada di sini: https://huggingface.co/TheBloke/Llama-2-13B-GGML/tree/main
  [0] https://github.com/ggerganov/llama.cpp#quantization
  • Saya salah satu pendirinya. Alasan kami memilih untuk tidak membandingkan dengan metode yang sudah ada adalah karena kami merasa sulit membuat perbandingan yang adil
    Tiap teknik punya banyak trade-off dan use case, dan ini bukan soal satu buruk dan yang lain baik, melainkan titik desain target yang berbeda. Misalnya cloud berbeda dengan lokal. Kami mempublikasikan angka dan benchmark, dan karena sedang mencari partner awal yang sesuai dengan proposisi nilai saat ini, kami menjalankannya sebagai beta tertutup
    Misalnya, llama.cpp adalah framework yang sangat bagus untuk menjalankan model secara lokal pada kasus pengguna tunggal (batch=1). Walaupun llama.cpp mendukung berbagai backend seperti RPi, CPU, dan GPU, menurut kami tidak adil menunjukkan bahwa MKML lebih baik pada GPU untuk kasus multi-pengguna (batch >> 1) berdasarkan perplexity, rasio kompresi, dan kecepatan tertentu. Sebab setahu saya itu bukan use case target llama.cpp. Misalnya, MKML menjalankan Llama-2 7B di 4090 dengan batch 32, yaitu 32 prompt diproses paralel, sekitar 2700 tok/sec, penggunaan memori 5.2GB, dan perplexity hampir setara fp16
    Selain itu, saat ini kami tidak membungkus tool atau teknik open source untuk kuantisasi. Semuanya teknologi internal, dan akan segera ada kabar lain yang kami buka. Jika ada pertanyaan teknis spesifik, saya akan menjawab sebisa mungkin
  • Penggunaan kata “codec” juga terasa agak mengganjal. Rasanya seperti ingin membuatnya terlihat seolah mereka menemukan paradigma yang sepenuhnya baru, sambil memberi nama keren yang mengingatkan orang pada kompresi video
  • Akhir pekan ini saya mencoba-coba Llama2 di AMD 7900 XTX dengan llama.cpp dan kuantisasi q5_k_s
    Dibandingkan angka MK600 di RTX 4090 yang mereka sajikan, dengan GPU yang lebih murah sekalipun throughput yang saya ukur lebih tinggi dan perplexity lebih rendah
  • Q5_1 juga sudah merupakan metode lama. Kuantisasi seri K lebih cepat dan lebih hemat ruang pada kehilangan perplexity yang sama
    https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • MKML katanya mengurangi ukuran model Llama2-13B dari 26GB menjadi 10.5GB. Penawaran serupa dari TheBloke adalah model Q6_K berukuran 10.7GB
    Bisa jadi mereka hanya mengemas GGML dan llama.cpp agar enak dipakai, sambil membuat orang percaya itu teknologi proprietari
• Sama sekali tidak menyebut teknik kuantisasi yang sudah ada? Saya berani taruhan 10 dolar ini kemungkinan besar cuma wrapper untuk bitsandbytes atau ggml
• Sepertinya akan sulit dipakai kalau bukan open source
  Bidang ini bergerak terlalu cepat, dan kalau tidak begitu, kenyamanannya juga tidak akan cukup
  Tambahan lagi, branding-nya mengingatkan pada MK-ultra, jadi rasanya lebih baik dihindari
• Saya pernah melakukan kuantisasi model machine learning. Kuantisasi 4-bit atau 8-bit open source bukanlah yang terbaik yang bisa dicapai
  Ada teknik yang jauh lebih canggih untuk mengurangi ukuran sambil mempertahankan performa prediksi. Beberapa teknik, misalnya quantization-aware training, mencakup perubahan proses pelatihan
  • Memang pasti ada metode yang lebih baik. Namun dalam kasus ini, angka MKML tidak terlihat mengesankan jika disejajarkan dengan teknik kuantisasi representatif yang sudah banyak dipakai
    Menurut tabel ini[0], ukurannya paling mirip dengan kuantisasi Q6_K, dan perplexity-nya malah tampak sedikit lebih buruk
    Jika teknik mereka lebih baik, saya kira mereka akan mengakui keberadaan teknik open source dan memasukkannya ke tabel perbandingan, alih-alih membuatnya tampak seolah model fp16 mentah adalah satu-satunya alternatif
    [0] https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • Bagaimana dengan metode kuantisasi Unum?
    https://github.com/unum-cloud/usearch
• Terlihat seperti satu lagi grift startup AI. Polanya seperti memakai GGML, menutupnya, lalu mencari uang VC
  Tampaknya satu lagi perusahaan wrapper AI melakukan hal yang sama, mencoba menumpang sebelum demam LLM mereda
  Kalau bukan open source dan tertutup, sejak awal sudah gagal
• Bukankah ini cuma kuantisasi?
  • Dari video demonya, output pada kedua kasus persis sama, jadi saya ragu mereka memakai kuantisasi
  • Persis itu yang saya pikirkan. Ini sudah dilakukan semua orang. Kalau mereka tidak melakukan sesuatu yang berbeda, mereka perlu menunjukkan mengapa ini lebih baik daripada sekadar menguantisasi cepat ke 8-bit atau 4-bit dan sebagainya
  • Apa pun itu, kemungkinan besar segera akan direplikasi atau fitur serupa akan masuk ke tool open source seperti llama.cpp
    Tidak terlihat seperti keunggulan yang bisa dipertahankan. Tampaknya hanya satu fitur yang harus melawan alternatif open source yang bergerak cepat
• Sayang sekali ini bukan upaya open source
  Saya sama sekali tidak suka ada dependensi proprietari di stack saya
  • Saya cukup skeptis sejauh apa ini akan berjalan. Komunitas open source sudah mencapai peningkatan performa yang pada dasarnya sama lewat kuantisasi
    Rasanya seperti mengemas ulang library yang sudah ada lalu menjualnya ke startup AI yang kurang hati-hati dan kurang informasi
• Bagaimana dibandingkan dengan mlc-llm yang memakai kuantisasi 4-bit? Di 4090 saya, llama2 13B berjalan sangat cepat
  Bahkan dengan kuantisasi 4-bit yang sama, ini beberapa kali lebih cepat daripada llama.cpp di GPU
  • Betul, auto-tuning TVM Vulkan itu luar biasa. Menurut saya mereka bahkan sepertinya tidak memakai ekstensi matmul Vulkan
    Kuantisasi 4-bit MLC relatif sederhana dibandingkan llama.cpp, sehingga menurunkan perplexity, dan itu juga menjelaskan sebagian perbedaan kecepatannya. Namun fitur yang paling kurang adalah CPU offloading. Dengan itu, 70B di 4090 pun bisa dijalankan dengan cukup masuk akal
    Menurut saya cawan suci inferensi LLM lokal adalah menjalankan Llama 70B dengan TVM sambil membaginya antara GPU dan GPU terintegrasi. Rasanya sudah sangat dekat. Semua bagiannya ada, tetapi belum ada developer frontend yang menghubungkan titik-titik itu
• Zaman sekarang hal seperti ini juga bisa dilakukan di MacBook Pro. Saya tidak begitu paham mengapa saya ingin terkunci pada vendor lain di sini
  Kalau ingin yang terbaik, pakai OpenAI atau Anthropic; kalau tidak, jalankan sendiri
• Apakah ini benar-benar efek Ultra Instinct^H^H Llama2?
  Facebook pada dasarnya sedang memperkuat ekosistem, pembuat tool, dan layanan inferensi yang lebih kecil
  Perusahaan ini punya akses ke model yang kredibel dan populer, model dengan lisensi open source nyata beserta bobot terkait, sehingga mereka bisa menjual optimisasi di atasnya tanpa mengkhawatirkan lisensi atau pembatasan pada bobot itu sendiri