AMD übernimmt MK1, um AI-Inferenzleistung und -Effizienz zu steigern

• AMD will durch die Übernahme von AI-Inferenzleistung und -Effizienz über den gesamten Stack hinweg – von der Hardware bis zur Software – steigern
• Das in Mountain View ansässige Unternehmen MK1 ist ein Team, das sich auf Hochgeschwindigkeits-Inferenz für großflächige Deployments und auf reasoning-basierte AI-Technologien konzentriert hat
• Flywheel von MK1 ist für AMD-Hardware optimiert und verarbeitet derzeit mehr als 1 Billion Tokens pro Tag
• Das MK1-Team tritt der AMD Artificial Intelligence Group bei und wird zur Stärkung des Enterprise-AI-Software-Stacks und der Inferenzfähigkeiten eingesetzt
• Flywheel und die Comprehension Engines nutzen die Speicherarchitektur der AMD Instinct GPUs und zielen darauf ab, Genauigkeit, Kosteneffizienz und Nachvollziehbarkeit bei groß angelegtem Reasoning zu verbessern

---

MK1 stößt zum AI-Stack von AMD

• AMD hat die Übernahme von MK1 abgeschlossen und betrachtet sie als strategischen Meilenstein, um AI-Leistung und -Effizienz über den gesamten Stack hinweg zu erhöhen
• MK1 ist ein in Mountain View, Kalifornien, ansässiges Team, das Hochgeschwindigkeits-Inferenz und reasoning-basierte AI-Technologien entwickelt hat, die für groß angelegte Deployments optimiert sind
• Die Flywheel-Technologie von MK1 ist für AMD-Hardware optimiert und verarbeitet derzeit mehr als 1 Billion Tokens pro Tag
• Das MK1-Team tritt der AMD Artificial Intelligence Group bei
  • Die Technologie und Expertise des Teams werden genutzt, um AMDs Fähigkeiten für Hochgeschwindigkeits-Inferenz und den Enterprise-AI-Software-Stack weiterzuentwickeln

Flywheel zielt auf Enterprise-AI

• Flywheel und die Comprehension Engines von MK1 sind dafür ausgelegt, die Speicherarchitektur der AMD Instinct GPUs zu nutzen
• Die Technologie konzentriert sich darauf, Reasoning in groß angelegten Umgebungen mit Genauigkeit, Kosteneffizienz und vollständiger Nachvollziehbarkeit bereitzustellen
• AMD will durch die Kombination von MK1s Software-Innovationen mit den eigenen Computing-Fähigkeiten die nächste Phase von Enterprise-AI beschleunigen
  • Unterstützung für Kunden bei der Automatisierung komplexer Geschäftsprozesse
  • Unterstützung dabei, neue Chancen in hochwertigen Anwendungen zu erschließen
• Aussagen zu den erwarteten Effekten der Übernahme sind zukunftsgerichtete Aussagen; die tatsächlichen Ergebnisse können je nach den in AMDs SEC-Einreichungen beschriebenen Risiken und Unsicherheiten abweichen

[GN⁺]

Meinungen auf Hacker News

• Es ist merkwürdig, dass bestehende Quantisierungsmethoden kein einziges Mal erwähnt oder mit den Ergebnissen verglichen werden.
  Normalerweise würde ich wohlwollend davon ausgehen, aber sie können die bereits weit verbreiteten Verfahren mit demselben Ziel kaum nicht kennen; daher sollte es Vergleichs-Benchmarks geben.
  Um die Lücke zu füllen: Für Llama 1 gibt es eine Vergleichstabelle nach Quantisierung, die llama.cpp bereitstellt[0]. Sie lässt sich nicht direkt mit den Kennzahlen von Llama 2 vergleichen, aber wenn man nur Geschwindigkeit und Veränderungsrate der Perplexity betrachtet, wirkt MK-1 Q5_1 sehr ähnlich. Die Perplexity verschlechtert sich leicht, aber nicht vernachlässigbar, und die Geschwindigkeit steigt um etwas mehr als das Doppelte.
  Wenn diese Zahlen stimmen, kann man auf Hugging Face ein vorquantisiertes Llama-2-Modell herunterladen und praktisch dieselbe Leistung erzielen wie mit dem, was MK-1 anbietet. Die Q5-Dateien gibt es hier: https://huggingface.co/TheBloke/Llama-2-13B-GGML/tree/main
  [0] https://github.com/ggerganov/llama.cpp#quantization
  • Ich bin einer der Gründer. Der Grund, warum wir nicht mit bestehenden Methoden verglichen haben, ist, dass wir es für schwierig halten, das fair zu tun.
    Jede Methode hat viele Trade-offs und Einsatzszenarien; es ist keine Frage von „eine Seite ist schlecht, die andere gut“, sondern die Ziel-Designpunkte unterscheiden sich. Cloud und lokal sind zum Beispiel unterschiedlich. Wir veröffentlichen Zahlen und Benchmarks und suchen derzeit frühe Partner, die zu unserem aktuellen Value Proposition passen, deshalb laufen wir in einer privaten Beta.
    llama.cpp ist zum Beispiel ein hervorragendes Framework, um Modelle lokal für Single-User-Szenarien (batch=1) auszuführen. Auch wenn llama.cpp verschiedene Backends wie RPi, CPU und GPU unterstützt, halten wir es nicht für fair zu zeigen, dass MKML bei Multi-User-Szenarien (batch >> 1) auf GPUs nach bestimmten Kriterien für Perplexity, Kompressionsrate und Geschwindigkeit besser ist. Soweit ich weiß, ist das nicht der Ziel-Use-Case von llama.cpp. MKML erreicht zum Beispiel mit Llama-2 7B auf einer 4090 bei Batch 32, also 32 Prompts parallel, etwa 2700 tok/sec, bei 5,2 GB Speicherverbrauch und Perplexity nahezu auf fp16-Niveau.
    Außerdem wrappen wir derzeit keine Open-Source-Tools oder -Verfahren für Quantisierung. Es ist komplett eigene Technologie, und bald gibt es dazu mehr zu berichten. Wenn es konkrete technische Fragen gibt, beantworte ich sie so gut wie möglich.
  • Auch die Verwendung des Wortes „Codec“ fühlt sich etwas unangenehm an. Es wirkt, als wolle man den Eindruck erwecken, ein völlig neues Paradigma erfunden zu haben, und ihm einen schicken Namen geben, der an Videokompression erinnert.
  • Ich habe dieses Wochenende auf einer AMD 7900 XTX mit llama.cpp und q5_k_s-Quantisierung einiges mit Llama2 ausprobiert.
    Verglichen mit den von ihnen angegebenen MK600-Zahlen auf einer RTX 4090 messe ich trotz günstigerer GPU höheren Durchsatz und niedrigere Perplexity.
  • Q5_1 ist auch schon eine alte Methode. Die K-Quantisierungen sind bei gleichem Perplexity-Verlust schneller und auch speichereffizienter.
    https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • MKML soll die Modellgröße von Llama2-13B von 26 GB auf 10,5 GB reduziert haben. Das vergleichbare Angebot von TheBloke ist ein Q6_K-Modell mit 10,7 GB.
    Vielleicht ist das einfach GGML und llama.cpp hübsch verpackt, sodass Leute glauben, es handle sich um proprietäre Technologie.
• Bestehende Quantisierungsmethoden werden kein einziges Mal erwähnt? Ich würde 10 Dollar darauf wetten, dass das nur ein Wrapper um bitsandbytes oder ggml ist.
• Wenn es nicht Open Source ist, wird es wohl schwer zu nutzen sein.
  Dieses Feld bewegt sich viel zu schnell, und sonst ist auch der Komfort nicht ausreichend.
  Nebenbei erinnert das Branding an MK-ultra; das sollte man vielleicht vermeiden.
• Ich habe schon Quantisierung von Machine-Learning-Modellen gemacht. Open-Source-Quantisierung mit 4 Bit oder 8 Bit ist nicht das Beste, was erreichbar ist.
  Es gibt deutlich ausgefeiltere Verfahren, die die Größe reduzieren und gleichzeitig die Vorhersageleistung erhalten. Einige Verfahren, etwa quantization-aware training, beinhalten Änderungen am Trainingsprozess.
  • Es gibt sicherlich bessere Methoden. In diesem Fall sind die Zahlen von MKML aber nicht beeindruckend, wenn man sie neben die bereits weit verbreiteten repräsentativen Quantisierungsmethoden stellt.
    Laut dieser Tabelle[0] ist die Größe der Q6_K-Quantisierung am ähnlichsten, und die Perplexity scheint sogar etwas schlechter zu sein.
    Wenn ihre Methode besser wäre, hätten sie wohl die Existenz von Open-Source-Methoden anerkannt und sie in die Vergleichstabelle aufgenommen, statt es so aussehen zu lassen, als sei das rohe fp16-Modell die einzige Alternative.
    [0] https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • Was ist mit der Quantisierungsmethode von Unum?
    https://github.com/unum-cloud/usearch
• Sieht aus wie ein weiterer AI-Startup-Grift. GGML nehmen, dichtmachen und dann VC-Geld einsammeln.
  Sieht so aus, als wolle noch eine AI-Wrapper-Firma dasselbe tun und auf den Zug aufspringen, bevor der LLM-Hype abkühlt.
  Wenn es nicht Open Source und geschlossen ist, ist es von Anfang an gelaufen.
• Ist das nicht einfach Quantisierung?
  • Im Demo-Video sind die Ausgaben in beiden Fällen exakt gleich, daher bin ich skeptisch, ob Quantisierung verwendet wird.
  • Genau das habe ich auch gedacht. Das machen doch schon alle. Wenn sie nicht etwas anderes tun, müssen sie zeigen, warum das besser ist, als einfach schnell auf 8 Bit, 4 Bit usw. zu quantisieren.
  • Was auch immer es ist, die Chancen stehen gut, dass es bald in Open-Source-Tools wie llama.cpp nachgebaut wird oder eine ähnliche Funktion dort landet.
    Es wirkt nicht wie ein verteidigbarer Vorteil. Eher wie ein einzelnes Feature im Kampf gegen schnell voranschreitende Open-Source-Alternativen.
• Schade, dass es keine Open-Source-Bemühung ist.
  Eine proprietäre Abhängigkeit in meinem Stack will ich überhaupt nicht.
  • Ich bin ziemlich skeptisch, wie weit das kommt. Die Open-Source-Community hat mit Quantisierung bereits praktisch dieselben Leistungsverbesserungen erreicht.
    Es fühlt sich an, als würden sie bestehende Bibliotheken neu verpacken und an unvorsichtige, schlecht informierte AI-Startups verkaufen wollen.
• Wie schneidet das im Vergleich zu mlc-llm ab, das 4-Bit-Quantisierung nutzt? Auf meiner 4090 läuft llama2 13B extrem schnell.
  Selbst bei gleicher 4-Bit-Quantisierung ist es um ein Vielfaches schneller als llama.cpp auf der GPU.
  • Stimmt, TVM-Vulkan-Autotuning ist erstaunlich. Ich glaube, sie verwenden nicht einmal die matmul-Vulkan-Erweiterung.
    Die 4-Bit-Quantisierung von MLC ist im Vergleich zu llama.cpp eher einfach, was die Perplexity senkt und einen Teil des Geschwindigkeitsunterschieds erklärt. Das größte fehlende Feature ist aber CPU-Offloading. Damit könnte man 70B auf einer 4090 ziemlich plausibel laufen lassen.
    Der heilige Gral lokaler LLM-Inferenz ist meiner Meinung nach, Llama 70B mit TVM laufen zu lassen und dabei auf GPU und integrierte GPU aufzuteilen. Es fühlt sich an, als wären wir fast dort. Die Teile sind alle da, aber es fehlt ein Frontend-Entwickler, der die Punkte verbindet.
• Heutzutage kann man so etwas sogar auf einem MacBook Pro machen. Ich sehe nicht recht, warum ich mich hier an einen weiteren Anbieter binden sollte.
  Wenn man das Beste will, nutzt man OpenAI oder Anthropic, andernfalls betreibt man es selbst.
• Ist das wirklich der Effekt von Ultra Instinct^H^H Llama2?
  Facebook stärkt damit faktisch das Ökosystem, Tool-Hersteller und kleinere Inferenzdienste.
  Dieses Unternehmen hatte Zugang zu einem vertrauenswürdigen und beliebten Modell, zu einem Modell mit echter Open-Source-Lizenz und den zugehörigen Gewichten, und konnte daher Optimierungen darauf verkaufen, ohne sich um die Lizenz oder Einschränkungen der Gewichte selbst sorgen zu müssen.