Gemma 4 26B ohne GPU auf einem 13 Jahre alten Xeon mit 5 Tokens pro Sekunde ausführen

 (neomindlabs.com)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Auf einem Server mit dualem Xeon E5-2690 v2 aus dem Jahr 2013 und DDR3 wurde Gemma 4 26B-A4B Q8_0 rein auf der CPU betrieben und erreichte beim Dekodieren etwa 5,2 Tokens/s sowie bei der Prompt-Evaluierung etwa 16 Tokens/s
  • Der schnelle Pfad von ik_llama.cpp setzt AVX2 und FMA3 voraus, doch Ivy-Bridge-CPUs unterstützen nur AVX1; daher waren Compiler-Anpassungen und Rechen-Fallbacks für einen Build ohne AVX2 nötig
  • Der Graph Builder erzeugte MOE_FUSED_UP_GATE und FUSED_UP_GATE bedingungslos, während der Dispatcher ohne AVX2 keinen Verarbeitungspfad dafür hatte; dadurch blieben pro Forward Pass etwa 240 Tensoren unberechnet, was zu wirrer mehrsprachiger Ausgabe führte
  • Claude fand den Fehler durch Logit-Instrumentierung und Codeanalyse und ersetzte die fusionierte Operation durch zwei ggml_mul_mat_id-Aufrufe und ggml_fused_mul_unary; der Nutzer führte die Experimente aus und beurteilte den Maßstab für korrekte Ergebnisse
  • Alte Enterprise-Server können bei Ausfällen kostenpflichtiger APIs als lokale Alternative oder für langsame Batch-Jobs dienen; --run-time-repack, das ein AVX2-spezifisches Layout erzeugt, darf jedoch nicht verwendet werden

Laufzeitumgebung auf einem 13 Jahre alten Storage-Server

  • Die wiederverwendete HP-StoreVirtual-Hardware nutzt einen dualen Xeon E5-2690 v2 aus dem Jahr 2013 und DDR3-Speicher und hat keine GPU
    • Da sie zur Ivy-Bridge-Generation gehört, unterstützt sie nur AVX1 und kein AVX2 und FMA3
    • Ursprünglich wurde sie für Festplattenspeicher gebaut; der Kaufpreis lag unter 300 US-Dollar
  • Das ausgeführte Modell ist Googles Gemma 4 26B-A4B, ein Open-Weight-Mixture-of-Experts(MoE)-Modell mit 26 Milliarden Parametern
  • Beim Q8_0-quantisierten Modell wurden für das Dekodieren etwa 5,2 Tokens/s und für die Prompt-Evaluierung etwa 16 Tokens/s gemessen

Ausgangspunkt: ein Xeon-Beispiel aus dem Jahr 2016

  • Der auf Hacker News geteilte Beitrag A 10 year old Xeon is all you need beschreibt, wie Gemma 4 ohne GPU auf einem einzelnen Xeon aus dem Jahr 2016 mit 128 GB DDR3 ausgeführt wurde
  • Diese Konfiguration nutzt ik_llama.cpp und rund 25 fein abgestimmte Laufzeit-Flags
    • Spekulatives Dekodieren
    • CPU-bewusstes MoE-Routing
    • Flash Attention für CPUs
    • Laufzeit-Repacking der Gewichte
  • Derselbe Ansatz wurde auf den Ivy-Bridge-Server übertragen, brach aber bereits beim Start ab
    • Anders als der Broadwell-Prozessor aus dem Jahr 2016 verfügt der E5-2690 v2 nicht über AVX2 und FMA3
    • Diese Befehlssätze gibt es seit Haswell im Jahr 2014, also Intels v3-Generation, und die schnellen Kernel waren darauf ausgelegt

Diagnose und Patch mit Claude

  • Nachdem Claude die Startfehlerinformationen erhalten hatte, identifizierte es den Unterschied im CPU-Befehlssatz als Ursache
  • Aufbauend auf einem zuvor mit einem kostenlosen Modell versuchten, unvollständigen Ansatz passte es performancekritische C++-Pfade so an, dass sie auf CPUs vor AVX2 korrekt auf Fallbacks zurückfallen
  • Die Arbeit war nicht mit einer einzelnen fix it-Anfrage erledigt
    • Es las performanceorientierten C++-Code, der von anderen Entwicklern geschrieben wurde
    • Es analysierte, warum Kernel auf einer bestimmten Mikroarchitektur nicht gültig waren
    • Es umging nicht unterstützte Pfade, ohne bestehende Optimierungen des Forks aufzugeben
  • Statt C++-Kernel-Fallbacks selbst zu schreiben, führte der Nutzer Experimente aus, las die Ausgaben, legte die nächsten Fragen fest und beurteilte den Maßstab für korrekte Ergebnisse
  • Diagnose und Patch wurden von einer Claude-Instanz durchgeführt, die auf diesem Server lief

Defekter Rechenpfad im Build ohne AVX2

  • Das für die Gemma-4-MoE-Inferenz verwendete ik_llama.cpp ist ein Fork von llama.cpp und geht standardmäßig von AVX2 als Mindestvoraussetzung aus
  • Wenn GGML_USE_IQK_MULMAT beim Build deaktiviert wird, werden die meisten schnellen Pfade ausgeschlossen und es wird auf allgemeine Skalar-/SSE-Operationen zurückgegriffen
    • Für übliche Q8_0-Matrixmultiplikationen funktionierte dieser Fallback
    • Für zwei Graph-Operationen griff der Fallback jedoch nicht
  • Das MoE-Feedforward-Netzwerk von Gemma 4 erzeugt folgende Operationen
    • MOE_FUSED_UP_GATE: eine Operation, die Gate-/Up-Matrixmultiplikationen pro Experte mit SwiGLU kombiniert
    • FUSED_UP_GATE: die dichte Operationsvariante für Nicht-MoE-Schichten
  • Die beiden Operationen im Compute Dispatcher waren durch GGML_USE_IQK_MULMAT geschützt, doch der Graph Builder erzeugte die Operationen ohne Bedingung
    • Im Dispatcher des Builds ohne AVX2 gab es keinen case, der das entsprechende Enum behandelte
    • Die Operation fiel in den Default-Zweig, wodurch die Ziel-Tensoren aller Experten-Feedforward-Netzwerke stillschweigend unberechnet blieben
  • Gemma 4 26B nutzt über 30 Schichten hinweg 8 aktive Experten pro Token, sodass pro Forward Pass etwa 240 Tensoren verbraucht wurden, die noch alte Werte aus Speicherpuffern enthielten

Hinweise aus der wirren Ausgabe

  • Die fehlerhafte Ausgabe wirkte flüssig, bestand aber aus sinnlosen mehrsprachigen Zeichenfolgen
    • Token-IDs verteilten sich gleichmäßig über das gesamte Vokabular von 262.000 Einträgen
    • Thai, Koreanisch, <unused>-Sentinels und englische Fragmente wurden mit ähnlicher Häufigkeit erzeugt
  • Bei Temperatur 0 war die Ausgabe deterministisch, die Ergebnisse von Single-Thread- und Multi-Thread-Ausführung waren bytegenau identisch, und es traten keine NaNs auf
  • Es zeigte sich ein Muster, bei dem große Konstanten in jeder Schicht den Hidden State verschoben und das finale Softmax abflachte
  • Claude instrumentierte die rohen Logits vor dem Sampling und gab die Top-5-Tokens, den Bereich, den Mittelwert und die Anzahl der NaNs aus
    • Der mittlere Logit des ersten vorhergesagten Tokens lag nicht nahe 0, sondern bei +16
    • Rund 80 % des gesamten Vokabulars hatten positive Logits
  • Da die Verzerrung im Gegensatz zu zufälliger Beschädigung konstant war, wurde der Verdacht darauf eingegrenzt, dass ein großer Teil des Hidden State nicht initialisierten Speicher mit kleinen positiven Floating-Point-Werten verwendete

Korrektur in drei Schritten

  • Der Patch besteht aus drei Commits auf dem main des Forks

  • Compile-Fix ohne AVX2

    • Die skalaren #else-Zweige in quantize_row_q8_0_x4 und quantize_row_q8_1_x4_T in iqk_quantize.cpp verwiesen tatsächlich auf AVX2-Helper wie hsum_i32_8
    • Diese Zweige wurden als portable skalare Schleifen neu geschrieben
    • Einige IQK-Aufrufe, die nach ggml.c und ggml-quants.c durchgerutscht waren, erhielten Schutzbedingungen mit #if GGML_USE_IQK_MULMAT
    • Fehlende Includes wurden ergänzt, damit iqk_cpu_ops.cpp unabhängig kompiliert
    • Ohne diese Korrektur lässt sich der Fork selbst auf Hardware ohne AVX2 nicht bauen

  • Laufzeit-Graph-Fallback

    • Statt den Dispatcher zu korrigieren, wurde der Graph Builder so geändert, dass er in diesem Build Operationen erzeugt, für die bereits Rechenpfade existieren
    • In ggml_moe_up_gate werden die kombinierten up_gate_exps-Gewichte verarbeitet, wenn GGML_USE_IQK_MULMAT deaktiviert ist
    • Die Tensorform ist [n_embd, 2*n_ff, n_experts]; die vordere Hälfte ist gate, die hintere up
    • Sie wird in zwei ggml_view_3d-Slices aufgeteilt
    • Auf jedem Slice wird ggml_mul_mat_id ausgeführt
    • Die beiden Ergebnisse werden mit ggml_fused_mul_unary(gate, up, SILU) kombiniert
    • Wenn Gate- und Up-Gewichte bereits getrennt sind, werden ohne Slicing zwei ggml_mul_mat_id-Aufrufe sowie die fusionierte Multiplikation und unäre Operation verwendet
    • Derselbe Fallback wurde auch auf ggml_fused_up_gate angewendet, das in Nicht-MoE-Schichten genutzt wird
    • mul_mat_id nutzt die Standard-ggml-Implementierung, und fused_mul_unary verarbeitet SILU und Multiplikation in einem Schritt; für alle Bestandteile existiert daher bereits eine Nicht-IQK-Implementierung
    • Die gesamte Änderung liegt hinter #if !GGML_USE_IQK_MULMAT, sodass AVX2-Builds bitgenau dieselben Ergebnisse wie zuvor liefern

  • Aufräumen der CI-Stubs

    • Die #else-Stubs in den IQK-Quellen unterschieden sich von iqk_mul_mat.h, sodass auch ci/run.sh auf Hardware ohne AVX2 nicht baute
    • Ein <cstdint>-Include fehlte
    • Einige Stubs hatten andere Signaturen, etwa unnötige führende Parameter oder fehlende sinks-Parameter
    • Für einige Funktionen gab es gar keinen Stub, was beim Linken zu undefinierten Referenzen führte
    • Durch Abgleich der Stubs mit dem Header kann die Testsuite nun auch in Umgebungen ohne AVX2 ausgeführt werden

Performance-Kosten des Fallbacks und Repacking-Fehler

  • Der Fallback verursacht zusätzliche Kosten, weil er statt eines einzelnen fusionierten Kernels zwei mul_mat_id-Aufrufe ausführt
  • Diese CPU ist bereits durch die Speicherbandbreite begrenzt, und der ursprüngliche fusionierte Kernel war ohnehin AVX2-spezifisch; in dieser Umgebung gab es also keinen bestehenden Ausführungspfad, auf den verzichtet wurde
  • Die finale Performance liegt bei etwa 5,2 Tokens/s beim Dekodieren und etwa 16 Tokens/s bei der Prompt-Evaluierung für das 26B-A4B-MoE
  • --run-time-repack ordnet die quantisierten Gewichte beim Start in das AVX2-spezifische interleaved Format Q8_0_R8 um
    • In einer AVX1-Umgebung ist das ein separater Bug, der die Ausgabe erneut beschädigt
    • Der aktuelle Patch behebt dies nicht; das Flag wurde aus dem Ausführungsskript entfernt

Wie die Ursache eingegrenzt wurde

  • Der Befehlssatz-Mismatch war leicht zu bestätigen, doch das Problem, dass der Dispatcher ohne Fehler in den Default-Zweig fiel, war schwerer zu finden
  • Durch Code-Review wurden mehrere Kandidaten ausgeschlossen
    • Der RMSNorm-Helper sah korrekt aus
    • Auch der AVX1-Fallback von ggml_vec_dot_q8_0_q8_0 wirkte korrekt
    • Da das Single-Thread-Ergebnis bitgenau identisch war, wurden Threading-Fehler ausgeschlossen
  • Dass der Logit-Mittelwert konstant bei +16 lag und Tokens im Long Tail ähnliche Werte hatten, deutete darauf hin, dass große Teile des Residual Stream nicht initialisiert waren
  • Nach einer Suche nach #if GGML_USE_IQK_MULMAT im Dispatcher wurden die zwei fehlenden Operationspfade in etwa einer Minute gefunden

Reproduktionsbedingungen und Einsatzbereich

  • Die Reproduktionsbedingungen für Geräte vor AVX2 sind wie folgt
    • Hardware: Dual Xeon E5-2690 v2, Ivy Bridge, AVX1, DDR3, keine GPU
    • Build: ik_llama.cpp aus dem Patch-Branch ohne GGML_USE_IQK_MULMAT kompilieren
    • Modell: Gemma 4 26B-A4B Q8_0
    • Ausführung: Übliche ik_llama.cpp-CPU-Flags verwenden, aber --run-time-repack weglassen
  • Die genauen Änderungen sind in ikawrakow/ik_llama.cpp PR #2138 zu sehen
    • Zum Zeitpunkt der Erstellung war der PR noch offen und wartete auf Maintainer-Review, daher muss direkt vom Branch ausgeführt werden
    • Bugs, die auf derselben Hardware auftreten, können im PR-Thread gemeldet werden
  • Ein lokales Modell auf alten Enterprise-Servern vorzuhalten, kann als Alternative dienen, wenn kostenpflichtige APIs ausfallen, oder langsame Batch-Jobs übernehmen, bei denen Abrechnung pro Token nicht passt
  • Der Schwerpunkt liegt weniger auf der Nutzung von Abo-Diensten als auf der Fähigkeit, sich selbst in fremden Code und alte Systeme einzuarbeiten; derselbe Ansatz gilt auch für die Wartung einer 15 Jahre alten Rails-Anwendung oder einer Datenbank, deren Verantwortliche nicht mehr da sind

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Es wird erwartet, dass man bis Mitte 2027 MoE-Modelle mit über 200 Milliarden Parametern auf gewöhnlicher Consumer-Hardware betreiben kann
    Auf einem 16-GB-Mac läuft Qwen3.6-35B-A3B lokal mit 7–9 Token pro Sekunde: https://github.com/deepanwadhwa/samosa-chat
    Das entspräche also einem lokal laufenden Modell auf GPT-4-Niveau auf einem MacBook Air mit 16 GB RAM in dieser Geschwindigkeit

    • Vielleicht muss man nicht einmal so lange warten. Das vor ein paar Tagen von Prism veröffentlichte ternäre Gewichtsmodell Bonsai 27B ist nur etwa 7 GB groß und erreicht auf einem M4-Max-Laptop mehr als 44 Token pro Sekunde: https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit
      Das liegt schon in einem ähnlichen Bereich wie die Zahl aktiver Parameter der meisten Modelle mit über 200 Milliarden Parametern, daher könnte Prism so ein Modell vermutlich veröffentlichen, wenn man es wollte. Allerdings benötigen rekursive neuronale Netze wie HRM nicht so viele Parameter, weshalb diskutierbar ist, ob diese Größenordnung überhaupt wirklich nötig ist: https://huggingface.co/sapientinc/HRM-Text-1B
    • 7–9 Token pro Sekunde würde ich nicht gerade als gute Geschwindigkeit bezeichnen. Ich bin zwar kein Experte, aber bei lokalen Experimenten fühlte sich alles unter 12–16 Token pro Sekunde frustrierend langsam an
    • Der Prognose stimme ich im Großen und Ganzen zu, aber der Zeitpunkt könnte etwas später liegen. Für solche Fortschritte wäre eine Kompression nötig, die völlig anders ist als das heutige Reduzieren der Bits pro Parameter, sodass in diesem Szenario die bisherige Kennzahl der Parameteranzahl selbst bedeutungslos werden könnte
      Wenn man etwa pro Schicht nur einen 256-Bit-Seed speichert und diesen in eine Rauschfunktion einspeist, um daraus 16K reale Gewichte zu erzeugen, könnte man die gespeicherte Größe auf weniger als 1 Bit pro Gewicht senken
    • Ich betreibe Ornith 35B auf Pi und komme auf mehr als 50 Token pro Sekunde. Seit ich herausgefunden habe, dass Pi auch Suche und Abruf unterstützt, brauche ich kein großes Modell mehr speziell für Suche
      Ich freue mich darauf, dass diesen und nächsten Monat neue Modelle erscheinen dürften, die alles verändern könnten. Ornith sollte man unbedingt ausprobieren
    • 9 Token pro Sekunde wirken schwer erträglich. In Claude-Sitzungen verbrauche ich oft in weniger als einem Tag 1 Million Token, und für echte Arbeit scheint das viel zu langsam

  • Manche wollen es nicht hören, aber ich glaube, dass die Token-Kosten von Inferenzanbietern niedriger sind als die Stromkosten für den lokalen Betrieb
    Wenn man der Einfachheit halber nur die Ausgabeerzeugung betrachtet, entsprechen 5 Token pro Sekunde 18.000 Token pro Stunde, was beim Anbieter etwa 0,005 Dollar kostet. Nimmt man an, dass der Server während der Inferenz rund 500 W verbraucht, und legt Deutschland mit 0,3 Dollar pro kWh zugrunde, dann kostet dieselbe Menge lokal 0,15 Dollar und ist damit 30-mal teurer
    Wenn Datenschutz wichtig ist, ist lokales Ausführen weiterhin sinnvoll, aber man sollte wissen, dass es deutlich ineffizienter ist als bei Inferenzanbietern. Neue GPUs werden die Inferenz noch effizienter machen und diese Lücke weiter vergrößern
    Anfangs hatte ich fälschlich mit 180.000 Token gerechnet, tatsächlich sind es aber 18.000 Token; solange Strom nicht fast gratis ist, wird es schwer, konkurrenzfähig zu sein. Die Anbieter nutzen für kleine Modelle wohl immer noch H200/H100, aber wenn sie auf GB300 oder im nächsten Jahr auf Ruby-GPUs umsteigen, dürften die Inferenzkosten auf ein Dreißigstel fallen, sodass der Hauptwert lokaler Modelle wohl im Datenschutz liegen wird

    • Wenn ich zu Hause Qwen 27B betreibe, verbraucht das unter Last etwa 400 W, erzeugt rund 40 Token pro Sekunde und verarbeitet, was wichtiger ist, Prompts mit etwa 1.000 Token pro Sekunde
      In einer Stunde lassen sich damit 3,6 Millionen Eingabetoken verarbeiten oder 144.000 Token erzeugen, bei Stromkosten von etwa 0,15 Dollar. Mit Sonnet würde dieselbe Menge 7,2 Dollar für Eingabe und 1,4 Dollar für Ausgabe kosten, also ist die Cloud bei der Generierung 10-mal und bei der Verarbeitung fast 50-mal teurer
    • In den USA liegt der Strompreis nicht einmal annähernd bei 0,30 Dollar pro kWh. Zu verbrauchsarmen Zeiten ist er halb so hoch, und man könnte 1.000 Dollar in eine Batterie investieren, um Strom zu 0,11 Dollar aus extrem günstigen Zeitfenstern zu speichern
      Inferenzanbieter tragen enorme Schulden und liefern sich einen Kampf um Marktanteile, deshalb werden die Preise sicher steigen
    • Es wäre großartig, einen autarken selbstgehosteten LLM-Server mit Solarstrom und Batterie zu bauen. So wie bei Low Tech Magazine wäre er offline, wenn nicht genug Sonne da ist, und würde in einer Größe aufgebaut, die für den täglichen Gebrauch einer lokalen Gemeinschaft wie Freundeskreis, Straße oder Verein reicht
      Wenn man AI so weit demokratisiert, dass die Gemeinschaft sie selbst kontrolliert, könnte das auch das Datacenter-Problem lösen, und selbst das Maß an Zensur und Alignment ließe sich demokratisch in der Gemeinschaft festlegen. Das ist eine ähnliche Vorstellung wie in manchen Texten von Geohotz
      Open-Source-Modelle werden bald gut und effizient genug sein, um günstig auf gebrauchter Hardware betrieben zu werden. Wenn es in jeder kleinen Gemeinschaft eine technikaffine Person gibt, die ein paar Hundert Dollar Startkosten einsammelt, könnte das danach nahezu gratis und ohne laufende Stromkosten betrieben werden
      https://solar.lowtechmagazine.com/
    • Effizienz ist wichtig, aber viele Menschen haben auch billigen Strom oder effiziente Hardware. Auf einem AMD-Strix-Halo-Home-Server kann man Gemma4-26B mit nur 100 W bei ungefähr 70 Token pro Sekunde bereitstellen
    • Ob es mehr kostet, ist mir egal. Ich betreibe lokal nicht, um Geld zu sparen, sondern um Freiheit und Datenschutz zu gewinnen, und wenn es eine Alternative gibt, sinken langfristig auch die Kosten
      Ohne die lokale Alternative wären die Preise für Cloud-Modelle deutlich höher

  • Diese Generation von Dual-Xeons dürfte unter Last mehr als 300 W verbrauchen. Beim durchschnittlichen US-Strompreis sind das 1,35 US-Dollar pro Tag, und wenn man im Sommer den Raum kühlen muss, kommt noch mehr dazu
    Selbst wenn man die Prompt-Verarbeitungszeit ignoriert und das System 24 Stunden laufen lässt, sind das nur etwa 400.000 Token pro Tag, also rund 0,30 US-Dollar pro 1 Million ausgegebener Token. Zufälligerweise entspricht das dem aktuellen Preis dieses Modells bei OpenRouter, aber die Generierungsgeschwindigkeit von OpenRouter ist 8-mal höher
    Es gibt viele Gründe, mit lokalen LLMs zu experimentieren, etwa damit die Daten das Haus nicht verlassen, aber finanziell lohnt es sich kaum. Als jemand, der deutlich mehr Geld in lokale Inferenz-Hardware zu Hause investiert hat, würde ich sagen: Es macht Spaß, ist aber kein Mittel zum Sparen

    • Für jemanden, der tatsächlich in einem eigenen Haus wohnt, ist das eine vernünftige Rechnung. Ich lebe zur Miete und zahle den Strom nicht direkt, daher liegt die Grenze der Kosteneffizienz bei dem Punkt, an dem der Vermieter anfängt, sich zu beschweren
    • Ich denke, die meisten betreiben Modelle nicht lokal, um Geld zu sparen, sondern um ihre Privatsphäre nicht preiszugeben
    • Das ist ähnlich wie bei Kryptowährungen. Wegen der Stromkosten ist es für die meisten günstiger zu kaufen, als selbst zu minen
    • In der kalten Jahreszeit, wenn man zu Hause ohnehin heizt, kann man auch die Abwärme nutzen, was die Wirtschaftlichkeit verbessert

  • Ich habe Ergebnisse dazu zusammengestellt, wie verschiedene Modelle ohne GPU auf Dual-Xeons mit 256 GB DDR4 laufen
    https://gist.github.com/hparadiz/f3596d00a62d8ebb2dadcc46ee5822c7

    • Ich frage mich, ob du ausprobiert hast, nur eine CPU zu verwenden, um den NUMA-Performanceverlust zu vermeiden. Dann stünde zwar nur die Hälfte des Speichers zur Verfügung, aber mich würde interessieren, wie groß der Leistungsunterschied wäre
    • Wenn man sehr viel langsamen RAM hat, scheinen selbst kleine Modelle ziemlich schnell zu laufen. Ich frage mich, wie größere Modelle auf dieser Hardware funktionieren würden

  • Das ist ziemlich langsam. Ich erreiche selbst mit einer 13 Jahre alten CPU 8 bis 12 Token pro Sekunde, je nach Kontextgröße und anderen Einstellungen
    https://news.ycombinator.com/item?id=48354801

    • Selbst mit einem Xeon E3-1270 V2 3.50GHz und einer alten Nvidia Quadro K2200 4GB komme ich auf 8 bis 9 Token pro Sekunde. Ich betreibe in Ollama gemma4:e2b und gemma4:12b-it-qat
    • Nutzt der ursprüngliche Beitrag nicht Q8-Quantisierung, während hier Q4 verwendet wird?

  • Ich bin der Autor des ursprünglichen Beitrags. Mein ursprünglicher Kommentar wurde aus irgendeinem Grund offenbar gemeldet. Die Korrekturen habe ich als PR #2138 im Upstream-Projekt eingereicht: https://github.com/ikawrakow/ik_llama.cpp/pull/2138

  • Diese StoreVirtual-Hardware scheint keine brauchbaren Ports für die Installation von Software zu haben. Es gibt wohl nur USB-Ports, daher frage ich mich, ob die Installation über eine serielle Konsole erfolgt

  • Ich betreibe Gemma 4 26B mit derselben Konfiguration auf einem Mac Pro von 2013 und erhalte etwa 5 Token pro Sekunde. Die beiden Grafikkarten bringen hier nichts, aber für manche Aufgaben ist das durchaus praktisch

  • Ich habe mir das Setup im Keller selbst angesehen, und es ist wirklich beeindruckend. Beim nächsten Mal wäre es schön, wenn du auch den 3D-Drucker vorstellen könntest

  • Als lose verwandtes Video: Jemand betreibt ein LLM auf einem Pentium 4 und hat ihm den Spitznamen NetburstGPT gegeben. Natürlich ist es extrem langsam
    https://www.youtube.com/watch?v=ILV-eu90te8