AMD, yapay zeka çıkarım performansı ve verimliliğini artırmak için MK1’i satın aldı

 (mkone.ai)
1 puan yazan GN⁺ 2023-08-07 | 1 yorum | WhatsApp'ta paylaş
  • AMD, MK1 satın alımıyla yapay zeka çıkarım performansı ve verimliliğini donanımdan yazılıma kadar tüm yığın boyunca artırmayı hedefliyor
  • Mountain View merkezli MK1, geniş ölçekli dağıtımlara uygun yüksek hızlı çıkarım ve akıl yürütme tabanlı yapay zeka teknolojilerine odaklanan bir ekip
  • MK1’in Flywheel teknolojisi AMD donanımı için optimize edilmiş durumda ve şu anda günde 1 trilyondan fazla token işliyor
  • MK1 ekibi, kurumsal yapay zeka yazılım yığınını ve çıkarım yeteneklerini güçlendirmek üzere AMD Artificial Intelligence Group’a katılıyor
  • Flywheel ve comprehension engines, AMD Instinct GPU’ların bellek mimarisinden yararlanarak büyük ölçekli akıl yürütmede doğruluk, maliyet verimliliği ve izlenebilirliği artırmaya odaklanıyor

AMD AI yığınına katılan MK1

  • AMD, MK1 satın alımını tamamladı ve bunu yığın genelinde yapay zeka performansı ve verimliliğini artırmaya yönelik stratejik bir dönüm noktası olarak görüyor
  • MK1, California, Mountain View merkezli bir ekip olarak, büyük ölçekli dağıtımlar için optimize edilmiş yüksek hızlı çıkarım ve akıl yürütme tabanlı yapay zeka teknolojileri geliştiriyordu
  • MK1’in Flywheel teknolojisi AMD donanımı için optimize edilmiş durumda ve şu anda günde 1 trilyondan fazla token işliyor
  • MK1 ekibi AMD Artificial Intelligence Group’a katılıyor
    • Ekibin teknolojisi ve uzmanlığı, AMD’nin yüksek hızlı çıkarım yeteneklerini ve kurumsal yapay zeka yazılım yığınını geliştirmekte kullanılacak

Flywheel’ın hedeflediği kurumsal yapay zeka

  • MK1’in Flywheel ve comprehension engines teknolojileri, AMD Instinct GPU’ların bellek mimarisinden yararlanacak şekilde tasarlandı
  • Bu teknoloji, büyük ölçekli ortamlarda doğruluk, maliyet verimliliği ve tam izlenebilirlikle akıl yürütme sunmaya odaklanıyor
  • AMD, MK1’in yazılım yenilikleri ile kendi bilgi işlem yeteneklerini birleştirerek kurumsal yapay zekanın bir sonraki aşamasını hızlandırmak istiyor
    • Müşterilerin karmaşık iş süreçlerini otomatikleştirmesine destek olmak
    • Yüksek katma değerli uygulamalarda yeni fırsatların önünü açmak
  • Satın alımın beklenen etkilerine ilişkin ifadeler ileriye dönük beyanlar niteliğindedir ve gerçek sonuçlar, AMD’nin SEC başvurularında belirtilen riskler ve belirsizliklere bağlı olarak farklılık gösterebilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-07
Hacker News yorumları
  • Mevcut kuantizasyon tekniklerinden hiç bahsetmemeleri ya da sonuçlarla karşılaştırmamaları tuhaf.
    Genelde iyi niyetle bakmaya çalışırım, ama aynı amaç için zaten yaygın kullanılan teknikleri bilmiyor olmaları mümkün değil; bu yüzden karşılaştırmalı benchmark’lar olmalıydı.
    Eksik kısmı tamamlamak gerekirse, Llama 1 için llama.cpp’nin sunduğu kuantizasyonlara göre bir karşılaştırma tablosu[0] var. Llama 2 metrikleriyle doğrudan karşılaştırılamaz, ama yalnızca hız ve perplexity değişim oranına bakınca MK-1, Q5_1’e çok benziyor. Perplexity küçük ama göz ardı edilemeyecek ölçüde kötüleşiyor, hız ise 2 katın biraz üzerinde artıyor.
    Bu sayılar doğruysa Hugging Face’ten önceden kuantize edilmiş bir Llama 2 modeli indirip MK-1’in sunduğuyla fiilen aynı performansı elde edebilirsiniz. Q5 dosyaları burada: https://huggingface.co/TheBloke/Llama-2-13B-GGML/tree/main
    [0] https://github.com/ggerganov/llama.cpp#quantization
    • Kuruculardan biriyim. Mevcut yöntemlerle karşılaştırmama nedenimiz, adil bir karşılaştırma yapmanın zor olduğunu düşünmemizdi.
      Her tekniğin pek çok ödünleşimi ve kullanım senaryosu var; mesele birinin kötü, diğerinin iyi olması değil, hedeflenen tasarım noktalarının farklı olması. Örneğin bulut ile yerel kullanım farklı. Biz sayıları ve benchmark’ları yayımlıyoruz; şu anda değer önerimize uygun ilk iş ortaklarını aradığımız için kapalı beta yürütüyoruz.
      Örneğin llama.cpp, tek kullanıcı senaryosunda (batch=1) modeli yerelde çalıştırmak için harika bir framework. llama.cpp RPi, CPU, GPU gibi çeşitli backend’leri desteklese de, çok kullanıcılı senaryolarda (batch >> 1) GPU üzerinde belirli perplexity, sıkıştırma oranı ve hız kriterlerine göre MKML’in daha iyi olduğunu göstererek karşılaştırma yapmanın adil olmadığını düşünüyorum. Çünkü bildiğim kadarıyla bu, llama.cpp’nin hedef kullanım senaryosu değil. Örneğin MKML, Llama-2 7B’yi 4090 üzerinde batch 32, yani 32 prompt’u paralel işleyerek yaklaşık 2700 tok/sec hızında çalıştırıyor; bellek kullanımı 5.2GB, perplexity ise neredeyse fp16 seviyesinde.
      Ayrıca şu anda kuantizasyon için açık kaynak araçları ya da teknikleri sarmalayıp kullanmıyoruz. Hepsi kendi teknolojimiz ve yakında paylaşacağımız daha fazla haber var. Spesifik teknik sorularınız varsa elimden geldiğince yanıtlarım.
    • “Codec” kelimesini kullanmaları da biraz rahatsız edici. Sanki tamamen yeni bir paradigma icat etmişler gibi görünmesini sağlayıp, video sıkıştırmayı çağrıştıran havalı bir ad takmak istiyorlar gibi.
    • Bu hafta sonu AMD 7900 XTX üzerinde llama.cpp ve q5_k_s kuantizasyonu ile Llama2 üzerinde çeşitli denemeler yaptım.
      RTX 4090 için sundukları MK600 sayılarıyla karşılaştırınca, daha ucuz bir GPU kullanmama rağmen throughput daha yüksek, perplexity ise daha düşük ölçüldü.
    • Q5_1 de zaten eski bir yöntem. K serisi kuantizasyonlar aynı perplexity kaybında daha hızlı ve alan açısından da daha verimli.
      https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
    • MKML, Llama2-13B model boyutunu 26GB’den 10.5GB’ye düşürdüğünü söylüyor. TheBloke’un benzer sunumu 10.7GB’lık Q6_K modeli.
      Belki de GGML ve llama.cpp’yi kullanımı kolay olacak şekilde paketleyip insanları bunun özel bir teknoloji olduğuna inandırıyorlardır.
  • Mevcut kuantizasyon tekniklerinden tek bir kez bile bahsetmiyorlar mı? 10 dolarına bahse girerim, bu büyük olasılıkla bitsandbytes ya da ggml’i saran bir wrapper’dan ibaret.
  • Açık kaynak değilse kullanması zor olacak gibi.
    Bu alan çok hızlı hareket ediyor; aksi takdirde kullanım kolaylığı da yeterli olmuyor.
    Ek olarak, markalama MK-ultra’yı çağrıştırıyor; bence bundan kaçınmaları daha iyi olur.
  • Makine öğrenimi modeli kuantizasyonu yaptım. Açık kaynağın 4-bit ya da 8-bit kuantizasyonu elde edilebilecek en iyi şey değil.
    Boyutu küçültürken tahmin performansını koruyan çok daha gelişmiş teknikler var. Bazı teknikler, örneğin kuantizasyon farkındalıklı eğitim, eğitim sürecinde değişiklik yapmayı içeriyor.
    • Daha iyi yöntemlerin olduğu kesin. Ama bu durumda MKML’in sayıları, halihazırda yaygın kullanılan başlıca kuantizasyon teknikleriyle yan yana konduğunda etkileyici görünmüyor.
      Bu tabloya[0] göre boyut Q6_K kuantizasyonuna en çok benziyor, perplexity ise hatta biraz daha kötü görünüyor.
      Teknikleri daha iyi olsaydı, ham fp16 model tek alternatifmiş gibi göstermek yerine açık kaynak tekniklerin varlığını kabul edip karşılaştırma tablosuna koyarlardı diye düşünüyorum.
      [0] https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
    • Unum’un kuantizasyon yöntemi nasıl?
      https://github.com/unum-cloud/usearch
  • Bir başka AI startup grift gibi görünüyor. GGML’i kullanıp kapatmak, sonra VC parası almak tarzı.
    LLM furyası sönmeden trene atlamaya çalışan, aynı şeyi yapan bir başka AI wrapper şirketi gibi görünüyor.
    Açık kaynak değilse ve kapalıysa daha baştan iş bitmiş sayılır.
  • Bu sadece kuantizasyon değil mi?
    • Demo videosuna bakınca iki durumdaki çıktı tamamen aynı, bu yüzden kuantizasyon kullanıp kullanmadıklarından şüpheliyim.
    • Ben de tam bunu düşündüm. Zaten herkesin yaptığı şey. Farklı bir şey yapmıyorlarsa, neden hızlıca 8-bit ya da 4-bit vb. kuantize etmekten daha iyi olduğunu göstermeleri gerek.
    • Ne olursa olsun, yakında llama.cpp gibi açık kaynak araçlarda kopyalanması ya da benzer bir özelliğin eklenmesi çok olası.
      Savunulabilir bir avantaj gibi görünmüyor. Hızla ilerleyen açık kaynak alternatiflerle savaşan tek bir özellik gibi duruyor.
  • Açık kaynak bir çaba olmaması üzücü.
    Stack’ime özel/proprietary bir bağımlılık girmesini hiç tercih etmem.
    • Bunun ne kadar ilerleyeceği konusunda oldukça şüpheliyim. Açık kaynak topluluğu kuantizasyonla zaten fiilen aynı performans iyileştirmesini elde etti.
      Mevcut kütüphaneleri yeniden paketleyip, temkinli olmayan ve yeterince bilgili olmayan AI startup’larına satmaya çalışıyorlar gibi geliyor.
  • 4-bit kuantizasyon kullanan mlc-llm ile karşılaştırınca nasıl? Benim 4090’ımda llama2 13B inanılmaz hızlı çalışıyor.
    Aynı 4-bit kuantizasyonu kullansa bile GPU’daki llama.cpp’den birkaç kat hızlı.
    • Evet, TVM Vulkan otomatik ayarı şaşırtıcı. Bence matmul Vulkan uzantısını bile kullanmıyor gibi.
      MLC’nin 4-bit kuantizasyonu llama.cpp’ye kıyasla daha basit, bu da perplexity’yi düşürüyor ve hız farkının bir kısmını açıklıyor. Ama en büyük eksik özellik CPU offloading. Bu olsaydı 4090 üzerinde 70B’yi de gayet makul şekilde çalıştırmak mümkün olurdu.
      Yerel LLM çıkarımının kutsal kâsesinin Llama 70B’yi TVM ile çalıştırıp GPU ve entegre GPU arasında paylaştırmak olduğunu düşünüyorum. Neredeyse eşiğine gelmiş gibiyiz. Parçaların hepsi var, ama bu noktaları birleştirecek bir frontend geliştiricisi yok.
  • Günümüzde böyle şeyler MacBook Pro üzerinde bile yapılabiliyor. Burada neden başka bir vendor lock-in’e girmek isteyeyim, pek anlamıyorum.
    En iyisini istiyorsanız OpenAI ya da Anthropic kullanın; değilse kendiniz çalıştırın.
  • Bu gerçekten Ultra Instinct^H^H Llama2 etkisi mi?
    Facebook fiilen ekosistemi, araç geliştiricilerini ve daha küçük inference servislerini güçlendiriyor.
    Bu şirket güvenilir ve popüler bir modele, gerçek açık kaynak lisansına sahip bir modele ve ilgili ağırlıklara erişebildi; bu yüzden ağırlıkların kendi lisansı ya da kısıtları hakkında endişelenmeden bunun üzerine optimizasyon yapıp satabildi.