Dieser 12 Jahre alte PC kann denken

Ein Raspberry Pi der ersten Generation, veröffentlicht im Jahr 2014, bildet die Grundlage dieses kühnen Experiments. Dieser alte Einplatinencomputer verfügt über eine bescheidene 700-MHz-Single-Core-CPU und lediglich 512 MB RAM. Nach heutigen Rechenstandards ähneln diese Spezifikationen eher einem hochentwickelten Taschenrechner als einer modernen Verarbeitungseinheit.

Moderne Large Language Models (LLMs) hingegen erfordern typischerweise um Größenordnungen mehr Leistung. Sie verbrauchen routinemäßig Gigabytes an RAM und verlassen sich auf leistungsstarke Multi-Core-Prozessoren und spezialisierte Beschleuniger, um zu funktionieren. Dieser starke Kontrast verdeutlicht die immense Kluft zwischen der aktuellen KI-Technologie und den Fähigkeiten eines Jahrzehnte alten Geräts.

Diese Diskrepanz wirft eine grundlegende Frage auf: Ist es wirklich möglich, eine so alte Maschine mit zeitgenössischer KI 'denken' zu lassen? Die Herausforderung geht über das bloße Ausführen eines Programms hinaus; sie beinhaltet das Überreden komplexer, ressourcenintensiver Algorithmen auf Hardware, die nie für solche Aufgaben konzipiert wurde.

Diese Lücke zu schließen, birgt gewaltige technische Hürden. Die begrenzten 512 MB RAM haben Schwierigkeiten, selbst die grundlegenden Komponenten der meisten LLMs zu laden, geschweige denn die Inferenz auszuführen. Darüber hinaus fehlen der 700-MHz-Single-Core-CPU und ihrem veralteten ARMv6-Befehlssatz die modernen mathematischen Optimierungen und parallelen Verarbeitungsfähigkeiten, die praktisch alle KI-Frameworks heute erwarten.

Trotz dieser scheinbar unüberwindbaren Hindernisse hat ein Team erfolgreich ein lokales LLM auf einem 12 Jahre alten Raspberry Pi ausgeführt – und es hat tatsächlich funktioniert! Sie wählten das Modell Falcon-H1-Tiny, ein unglaublich kompaktes LLM mit 90 Millionen Parametern, das vom Technology Innovation Institute entwickelt wurde und speziell darauf ausgelegt ist, die Grenzen des Extreme-Edge-Sprachmodellings zu erweitern.

Das Hauptschlachtfeld war der Speicher. Ein Modell, selbst ein so kleines wie Falcon-H1-Tiny, in 512 MB unterzubringen, erforderte aggressive Quantisierung, wodurch seine Präzision auf 4-Bit reduziert wurde, während die kritische Logik erhalten blieb. Dieser Prozess wurde von größter Bedeutung, da Standard-LLM-Lademethoden in solch begrenzten 32-Bit-Adressräumen oft fehlschlagen.

Jenseits des Speichers stellte die veraltete ARMv6-Architektur einzigartige Kompilierungs- und Ausführungsprobleme dar. Moderne KI-Inferenz-Engines verlassen sich stark auf neuere CPU-Anweisungen, was einen akribischen Cross-Kompilierungsprozess erzwingt, um die Software präzise an die spezifische, begrenzte Hardware des Pi anzupassen. Diese komplizierte technische Anstrengung ebnete den Weg von der theoretischen Möglichkeit zur greifbaren Demonstration.

Das Modell, das diese unwahrscheinliche Leistung ermöglicht, ist Falcon-H1-Tiny. Entwickelt vom Technology Innovation Institute (TII) in Abu Dhabi, verschiebt dieses Sprachmodell die absoluten Untergrenzen dessen, was als „intelligent“ gilt. Es arbeitet mit erstaunlich kompakten 90 Millionen Parametern, einer Größenordnung, die für effektive Sprachverarbeitung noch vor wenigen Jahren fast unvorstellbar war. TII entwickelte Falcon-H1-Tiny speziell zur Untersuchung extremer Effizienz und demonstrierte das Potenzial für anspruchsvolle KI auf stark eingeschränkter Hardware wie dem 12 Jahre alten Raspberry Pi.

Hinter der bemerkenswerten Kompaktheit von Falcon verbirgt sich eine innovative Hybrid Transformer + Mamba-Architektur. Diese Designwahl, die auch in Modellen wie IBM's tiny Granite 4 zu finden ist, kombiniert strategisch die Stärken beider Architekturparadigmen. Sie priorisiert Effizienz und Leistung, was entscheidend ist für Modelle, die mit minimalen Rechenressourcen und Speicherplatz effektiv laufen sollen. Dieser hybride Ansatz ermöglicht es Falcon-H1-Tiny, trotz seiner geringen Größe aussagekräftige Sprachverständnis- und Generierungsfähigkeiten zu bewahren.

Betrachten Sie seine Größe im Vergleich zu den Titanen der LLM-Welt. Mainstream-Modelle wie GPT-3 verfügen über kolossale 175 Milliarden Parameter. Falcon-H1-Tiny, mit seinen lediglich 90 Millionen Parametern, stellt eine erstaunliche Reduzierung der Komplexität dar – es arbeitet mit weniger als einem Tausendstel der Parameteranzahl von GPT-3. Diese radikale Verkleinerung ist genau das, was seinen Einsatz auf Hardware wie dem Raspberry Pi der ersten Generation ermöglicht, einem Gerät mit nur 512 MB RAM und einer 700 MHz Single-Core-CPU.

Die Verfügbarkeit von Open-Source-, ultrakompakten Modellen wie Falcon-H1-Tiny markiert einen entscheidenden Moment für edge computing. Es demokratisiert den Zugang zu fortschrittlicher KI und ermöglicht es Entwicklern und Forschern, anspruchsvolle Sprachfähigkeiten direkt auf stromsparenden, ressourcenbeschränkten Geräten bereitzustellen. Diese Verschiebung ermöglicht neue Anwendungen, bei denen Datenschutz, Echtzeitverarbeitung und Offline-Funktionalität von größter Bedeutung sind, indem die KI-Inferenz von entfernten Cloud-Servern näher an die Quelle der Datengenerierung verlagert wird.

Ein solches Modell auf dem alten Raspberry Pi zu betreiben, erfordert mehr als nur ein kleines Modell; es verlangt sorgfältige Ingenieursarbeit. Das Projekt nutzt hochoptimierte Inferenz-Engines wie `llama.cpp` und spezifische Quantisierungstechniken, wie die Q4 method, die der ARMv6-Chip des Pi verarbeiten kann. Diese technischen Ermöglicher, kombiniert mit dem schlanken Design von Falcon, zeigen gemeinsam, dass portable, lokalisierte KI nicht nur eine theoretische Möglichkeit, sondern eine erreichbare Realität selbst auf der bescheidensten Hardware ist.

Das Komprimieren des Falcon-H1-Tiny-Modells auf den ursprünglichen Raspberry Pi erforderte eine radikale Speichereffizienz, wodurch die Quantisierung zu einer unverzichtbaren Technik wurde. Dieser Prozess beinhaltet die Reduzierung der numerischen Präzision der internen Parameter oder Gewichte eines KI-Modells, um dessen Dateigröße und Speicherbedarf drastisch zu verringern. Anstatt jedes Gewicht als eine Standard-32-Bit-Gleitkommazahl zu speichern, wandelt die Quantisierung sie in niedrigere Bit-Ganzzahlen um – typischerweise 8-Bit-, 4-Bit- oder sogar 2-Bit-Darstellungen. Diese signifikante Datenkompression ist entscheidend für die Bereitstellung großer Sprachmodelle auf Geräten mit extrem begrenztem RAM und Rechenleistung, wie unserem 2014er Single-Core 512MB Pi.

Falcon-H1-Tiny, von TII entwickelt, um die unteren Grenzen der Sprachmodellierung zu erforschen, bot verschiedene quantisierte Versionen an, darunter 2-Bit-, 4-Bit- und 8-Bit-Optionen. Obwohl die Versuchung bestand, modernste Methoden wie Importance Quantization (IQ) für maximale Kompression auszuprobieren, erwiesen sich diese neueren Techniken als inkompatibel mit der Zielhardware. Solche fortschrittlichen Quantisierungsstrategien basieren auf komplexer Bitmanipulation und modernen CPU-Befehlen, um effizient zu funktionieren.

Die Kernbeschränkung ergab sich aus der veralteten ARMv6-CPU des Raspberry Pi. Dieser Prozessor aus dem Jahr 2014, eine 700-MHz-Single-Core-Einheit, verfügt einfach nicht über die ausgeklügelten Befehlssätze – wie die NEON-Erweiterungen von ARMv7 –, von denen fast alle modernen AI-Bibliotheken und fortschrittlichen Quantisierungsmethoden abhängen. Ohne diese entscheidenden Hardware-Fähigkeiten konnte der Prozessor des Pi die komplexen mathematischen Operationen, die von neueren Quantisierungsschemata benötigt werden, nicht ausführen. Dies zwang das Entwicklungsteam, eine ältere, universell kompatiblere Methode zu verwenden: die Q4 quantization. Dieser 4-Bit-„Old-School“-Ansatz wurde zum zuverlässigen „Goldstandard“ für diese spezielle Herausforderung.

Das Q4 (4-Bit)-Modell erreichte die optimale Balance und lieferte das beste „Intelligenz-pro-Megabyte“-Verhältnis, während die Kernlogik des Modells erhalten blieb. Obwohl eine noch aggressivere 2-Bit quantisierte Version verfügbar und getestet wurde, litt sie letztendlich unter einem kritischen Problem: dem „logic collapse“. Diese schwerwiegende Verschlechterung bedeutete, dass die Fähigkeit des Modells, kohärente, nützliche oder sogar sinnvolle Antworten zu generieren, über den praktischen Nutzen hinaus beeinträchtigt war. Die extreme Datenkürzung führte zu einem Verlust wesentlicher Informationen, wodurch der 2-Bit Falcon-H1-Tiny praktisch unbrauchbar wurde. Die 4-Bit-Variante stellte daher den praktischen Sweet Spot dar und zeigte, dass manchmal weniger Komprimierung mehr Intelligenz liefert. Weitere Informationen zur Arbeit des TII an kompakten Modellen finden Sie unter Tiny Models, Real-World Intelligence | Technology Innovation Institute.

Ein großes Sprachmodell auf einem 2014er Raspberry Pi zu betreiben, stellte eine gewaltige architektonische Hürde dar. Seine Single-Core-700-MHz-CPU, basierend auf dem ARMv6 instruction set, fehlen entscheidend die NEON-Befehle, von denen fast alle modernen AI-Bibliotheken für die Leistung abhängen. Diese architektonische Lücke macht das Ausführen zeitgenössischer Machine-Learning-Frameworks auf solch alter Hardware praktisch unmöglich.

Dieses Projekt fand seine Rettung in llama.cpp, einer leichtgewichtigen C++-Inferenz-Engine, die sorgfältig für maximale Portabilität und Leistung auf verschiedenen CPUs, selbst älteren, entwickelt wurde. Entworfen, um Modelle wie Falcon-H1-Tiny effizient auszuführen, priorisiert ihr Design minimalen Ressourcenverbrauch, was sie einzigartig geeignet für eingeschränkte Hardware wie den ursprünglichen Pi macht.

Entscheidend ist, dass das flexible Build-System von `llama.cpp` es Entwicklern ermöglicht, nicht unterstützte CPU-Funktionen selektiv zu deaktivieren. Für den 12 Jahre alten Raspberry Pi bedeutete dies das Deaktivieren von NEON, wodurch ein benutzerdefiniertes Binary erstellt wurde, das von modernen Abhängigkeiten befreit ist. Diese gezielte Kompilierung stellt sicher, dass die Inferenz-Engine auf dem ARMv6-Chip funktionieren kann, ohne abzustürzen oder auf Befehlsfehler zu stoßen.

Ohne `llama.cpp` würde dieses ehrgeizige Vorhaben fest im Bereich der theoretischen Möglichkeit verbleiben. Das Kompilieren anderer AI-Frameworks direkt auf dem Pi würde schätzungsweise 18 Stunden oder länger dauern und wahrscheinlich aufgrund von Speichermangel fehlschlagen. Ihre inhärente Aufblähung und Abhängigkeit von fortschrittlichen CPU-Funktionen machen sie inkompatibel, wodurch `llama.cpp` der unverzichtbare Ermöglicher für das lokale Ausführen des Falcon-H1-Tiny-Modells wird.

Das direkte Ausführen von `llama.cpp` auf dem 12 Jahre alten Raspberry Pi stellte eine unüberwindbare Hürde dar. Das Board der ersten Generation, ausgestattet mit einer 700-MHz-Single-Core-CPU und lediglich 512 MB RAM, fehlte die rohe Rechenleistung und Speicherkapazität, die für eine so intensive Aufgabe erforderlich sind. Das Kompilieren einer komplexen modernen C++-Codebasis wie `llama.cpp` auf dem Pi selbst würde schätzungsweise 18+ Stunden kontinuierlicher Verarbeitung erfordern. Diese Dauer würde mit ziemlicher Sicherheit zu katastrophalen Ausfällen aufgrund von unzureichendem Speicher führen, da der Build-Prozess die alte Hardware schnell überfordert.

Ingenieure setzten stattdessen auf Cross-Kompilierung, eine Technik, die einer „Zeitmaschine“ für die Softwareentwicklung ähnelt. Diese Methode beinhaltet das Erstellen von Software auf einer leistungsstarken Host-Maschine – typischerweise einem modernen Laptop –

Jedes Byte RAM auf dem originalen Raspberry Pi ist entscheidend, besonders da nur 512 MB verfügbar sind. Um überhaupt eine Chance zu haben, Falcon-H1-Tiny auszuführen, wurde die Minimierung des Betriebssystem-Footprints von größter Bedeutung. Dies erforderte eine drastische Abkehr von Standard-Desktop-Umgebungen.

Entwickler entschieden sich für Raspberry Pi OS Lite (32-bit), eine abgespeckte Version ohne grafische Oberfläche. Dieses minimale Betriebssystem verbraucht im Leerlauf nur einen Bruchteil des Speichers der Standardedition, wodurch entscheidende Megabytes für das LLM selbst frei bleiben. Es ist ein Beweis dafür, wie aggressiv Ressourcen auf solch eingeschränkter Hardware verwaltet werden müssen.

Die Einrichtung des Pi begann mit Raspberry Pi Imager, einem Dienstprogramm, das zum Flashen des Betriebssystems auf eine SD-Karte verwendet wird. Entscheidend war, dass der Prozess die Vorkonfiguration von Wi-Fi-Zugangsdaten und die Aktivierung von SSH umfasste. Diese Voraussicht umging die Notwendigkeit einer physischen Tastatur und eines Monitors und optimierte die anschließende Fernverwaltung.

Die Fernverwaltung des 12 Jahre alten Raspberry Pi über SSH erwies sich als unverzichtbar. Das lokale Terminal des Geräts ist notorisch träge und schwer zu navigieren, was komplexe Befehlszeilenoperationen zu einer mühsamen Tortur macht. Eine stabile, reaktionsschnelle SSH-Verbindung verwandelte eine ansonsten frustrierende Erfahrung in eine beherrschbare technische Herausforderung und ermöglichte die nahtlose Übertragung von kompilierten Binärdateien und Modelldateien.

Dieser Ansatz vereinfachte den Workflow erheblich. Für diejenigen, die tiefer in benutzerdefinierte Firmware oder Modellformate wie GGUF eintauchen möchten, bieten Ressourcen wie ggml/docs/gguf.md at master · ggerganov/ggml - GitHub wertvolle Einblicke in die zugrunde liegenden technischen Spezifikationen, die für solche Low-Level-Optimierungen erforderlich sind.

Der Weg, das Falcon-H1-Tiny-Modell auf den 12 Jahre alten Raspberry Pi zu bringen, stieß auf eine letzte, heimtückische Speicherhürde: das Abbilden von Dateien in den Speicher, allgemein bekannt als `mmap`. Während `mmap` modernen Betriebssystemen und High-End-GPUs eine effiziente Möglichkeit bietet, große Modelle zu laden, indem Dateiinhalte direkt in den Adressraum eines Prozesses abgebildet werden, werden seine Vorteile auf stark eingeschränkter Hardware zu Nachteilen. Diese Technik bietet typischerweise Leistungsgewinne, indem sie den Kernel für die Speicherverwaltung nutzt und Datenkopien reduziert.

Auf einem 32-Bit-System wie dem originalen Raspberry Pi, ausgestattet mit nur 512 MB RAM, stieß `mmap` auf eine kritische Einschränkung. Das System hatte Schwierigkeiten, einen einzigen, ausreichend großen zusammenhängenden Adressbereich zu finden, der zum Abbilden der Modelldatei erforderlich war. Selbst wenn insgesamt freier Speicher vorhanden war, führte die Fragmentierung im 32-Bit-Adressraum dazu, dass `mmap`-Operationen oft fehlschlugen, was zu sofortigen Anwendungsabstürzen führte. Dies war kein Problem von unzureichendem Gesamtarbeitsspeicher, sondern vielmehr die Unfähigkeit, einen *einheitlichen* Block innerhalb des kleineren 32-Bit-Adressbereichs zuzuweisen.

Die Lösung kam mit einem spezifischen `llama.cpp`-Befehlszeilenargument: `--no-mmap`. Dieses entscheidende Flag deaktiviert explizit die Speicherzuordnung für das Laden des Modells. Stattdessen zwingt es `llama.cpp`, das gesamte Falcon-H1-Tiny-Modell direkt in den Heap-Speicher des Prozesses zu laden. Dieser Ansatz, der auf Systemen mit reichlich, unfragmentiertem Speicher potenziell weniger performant ist, erwies sich für die Vintage-Hardware als unerlässlich.

Das Laden in den `heap` umgeht die Notwendigkeit eines großen, zusammenhängenden Adressblocks. Der `heap memory manager` ist weitaus flexibler, kann kleinere, nicht zusammenhängende `chunks` nach Bedarf zuweisen und die Fragmentierung dynamischer verwalten. Dies ermöglichte es dem vollständigen `quantized model`, trotz seiner reduzierten Größe, stabil im kostbaren 512MB RAM des Raspberry Pi zu verbleiben. Ohne den `--no-mmap` `tweak` würde der `inference process` während der Modellinitialisierung ständig abstürzen.

Dieses scheinbar geringfügige `flag` stellte das letzte, entscheidende Puzzleteil für ein stabiles `memory management` dar. Es war der entscheidende `tweak`, der sicherstellte, dass das Falcon-H1-Tiny Modell endlich geladen werden und mit der Verarbeitung von `prompts` beginnen konnte, wodurch das Experiment wirklich feststellen konnte, ob ein 12 Jahre alter Raspberry Pi denken kann. Das `--no-mmap` `flag` verwandelte eine potenzielle Sackgasse in einen gangbaren Weg, um ein lokales LLM auszuführen.

Der Moment der Wahrheit kam, als das `cross-compiled llama.cpp binary` den ersten `inference test` auf dem 12 Jahre alten Raspberry Pi ausführte. Die Forscher begannen mit der aggressivsten Kompression, der 2-Bit `quantized version` des Falcon-H1-Tiny Modells. Die Ergebnisse waren entmutigend: Das Modell produzierte nur inkohärenten Unsinn und generierte etwa alle drei Sekunden ein einziges `token`.

Diese Leistung bestätigte die Grenzen extremer `quantization` auf solch eingeschränkter Hardware, insbesondere im Umgang mit einem Modell, das bereits an den unteren Grenzen des Sprachverständnisses liegt. Die starke Reduzierung der numerischen Präzision machte das Modell weitgehend unbrauchbar und konnte selbst grundlegende sprachliche Kohärenz nicht erfassen.

Ein Durchbruch gelang mit dem 4-Bit `quantized model`. Als es aufgefordert wurde, generierte es erfolgreich eine kohärente, logische Antwort. Dieser entscheidende Moment validierte das gesamte Unterfangen und bewies, dass ein `local LLM` tatsächlich auf der `vintage hardware` „denken“ konnte, wenn auch langsam. Die Fähigkeit, sinnvolle Ausgaben zu produzieren, demonstrierte die Machbarkeit des Projekts.

Das Team ging noch weiter und testete das 8-Bit `quantized model`. Diese Version, obwohl sie eine höhere `fidelity` bot, zeigte ausgeprägte „Wissenslücken“. Zum Beispiel identifizierte sie Brüssel korrekt als die Hauptstadt Belgiens, konnte sich aber nicht an die Hauptstadt Albaniens erinnern.

Diese Disparität hob einen fundamentalen Aspekt kompakter LLMs hervor: die endliche Wissenskapazität eines 90-Millionen-Parameter-Modells. Selbst bei weniger aggressiver `quantization` fehlt dem Falcon-H1-Tiny einfach das umfangreiche Weltwissen, das in größeren Modellen eingebettet ist. Die Ergebnisse unterstrichen die inhärenten Kompromisse, die mit extremer Kompression verbunden sind, wo jedes gesparte Bit ein Stück vergessener Information bedeuten kann.

Dieses kühne Experiment, bei dem erfolgreich ein `Local LLM` auf einem 12 Jahre alten Raspberry Pi ausgeführt wurde, geht über bloße technische Neugier hinaus. Es zeigt unmissverständlich, dass wirklich nützliche künstliche Intelligenz auf unglaublich eingeschränkten, stromsparenden `edge devices` arbeiten kann, nicht nur auf leistungsstarken Cloud-Servern. Diese Fähigkeit eröffnet eine Zukunft, in der fortschrittliche Berechnungen und intelligente Entscheidungsfindungen nicht auf Rechenzentren oder High-End-Workstations beschränkt sind, sondern unsere physische Umgebung durchdringen.

Ein signifikanter Trend treibt diesen Paradigmenwechsel voran: die unermüdliche Entwicklung kleinerer, hochoptimierter Modelle. Organisationen wie das Technology Innovation Institute (TII) mit ihrem 90-Millionen-Parameter Falcon-H1-Tiny und IBMs Granite-Serie entwickeln aktiv Sprachmodelle, die auch unter strengen Speicher- und Verarbeitungsbeschränkungen gedeihen. Diese kompakten Architekturen, die oft hybride Designs wie Transformer + Mamba nutzen, machen anspruchsvolle AI weit über die traditionelle Cloud hinaus zugänglich und erweitern die Grenzen des Möglichen mit minimalen Ressourcen.

Stellen Sie sich AI vor, die direkt in eine Vielzahl alltäglicher Objekte eingebettet ist, von Smart-Home-Geräten bis hin zu älteren industriellen Steuerungssystemen. Betrachten Sie ihr Potenzial in kritischer Offline-Infrastruktur, entfernten wissenschaftlichen Instrumenten oder sogar persönlichen Wearables, wo ständige Cloud-Konnektivität unpraktisch oder unmöglich ist. Dies eröffnet weitreichende Möglichkeiten für proaktive Wartung, lokalisierte Datenverarbeitung und verbesserte Privatsphäre, indem intelligente Agenten vollständig auf dem Gerät arbeiten können, ohne sensible Informationen an externe Server zu übertragen. Es ist ein Schritt hin zu wirklich autonomer, sicherer lokaler Intelligenz.

Während die Ausgaberate des ursprünglichen 2-Bit-Modells von einem Token alle drei Sekunden auf dem originalen Raspberry Pi langsam bleibt, ist der Erfolg dieses Experiments ein tiefgreifender Proof-of-Concept. Er bestätigt das Potenzial für wirklich dezentrale AI, die unsere Interaktion mit Technologie und unsere Vision zukünftiger Anwendungen grundlegend neu gestaltet. Hier geht es nicht darum, Cloud-basierte LLMs zu ersetzen, sondern sie mit allgegenwärtiger, energieeffizienter Intelligenz zu ergänzen. Die Zukunft der AI ist kleiner, allgegenwärtiger und näher bei uns als je zuvor und verspricht eine neue Ära der tragbaren Intelligenz. Weitere Details zur Herkunft der Hardware finden Sie unter Raspberry Pi - Wikipedia).

Bereit, dieses unwahrscheinliche Kunststück zu replizieren? Ein großes Sprachmodell auf einem 12 Jahre alten Raspberry Pi zu betreiben, erfordert Präzision, aber die Werkzeuge sind zugänglich. Sie benötigen einen Raspberry Pi der ersten Generation (oder ein ähnliches ARMv6-Gerät), die `llama.cpp`-Inferenz-Engine, eine `dockcross`-Umgebung für die Cross-Kompilierung und ein GGUF-quantisiertes Modell wie den Falcon-H1-Tiny. Dieses Experiment beweist, dass nützliche AI aus unglaublich eingeschränkter Hardware entstehen kann.

Beginnen Sie damit, ein minimales Betriebssystem, wie Raspberry Pi OS Lite, auf Ihr Zielgerät zu flashen, um den verfügbaren RAM zu maximieren. Als Nächstes cross-kompilieren Sie das `llama.cpp`-Binary auf einer leistungsstärkeren Maschine mit `dockcross`, speziell für ARMv6. Wichtige Kompilierungs-Flags umfassen das Deaktivieren von NEON, OpenMP und Shared Libraries, um Kompatibilität und einen schlanken Fußabdruck zu gewährleisten. Dies vermeidet die geschätzte 18-stündige Kompilierungszeit und Speicherfehler auf dem Pi selbst.

Übertragen Sie Ihr selbst erstelltes `llama.cpp`-Executable und das gewünschte GGUF-quantisierte Modell – vielleicht das 4-Bit Falcon-H1-Tiny – per SCP auf den Raspberry Pi. Führen Sie für die Inferenz das Binary mit dem Flag `--no-mmap` aus. Dieser kritische Speicher-Hack umgeht Adressraumfragmentierungsprobleme, die 32-Bit-Systemen mit begrenztem RAM eigen sind, und zwingt das Modell, direkt in den Heap zu laden, um einen stabilen Betrieb zu gewährleisten. Erwarten Sie Token-Generierungsraten von einem alle paar Sekunden.

Die Reise von inkohärentem Unsinn zu funktionaler Ausgabe liegt bei Ihnen. Tauchen Sie in die Besonderheiten dieses bahnbrechenden Projekts ein, indem Sie I Ran a Local LLM on 12-Year-Old Raspberry Pi (It Actually Worked!) ansehen. Finden Sie das Falcon-H1-Tiny Modell auf Hugging Face und detaillierte Einrichtungsanweisungen, einschließlich `llama.cpp` Kompilierungsskripte, auf dem BetterStackHQ GitHub. Erweitern Sie die Grenzen der edge AI und sehen Sie, was Ihre Vintage-Hardware erreichen kann.

Was ist das kleinste LLM, das Sie auf einem Raspberry Pi ausführen können?

Modelle wie das 90-Millionen-Parameter Falcon-H1-Tiny wurden erfolgreich auf einem Raspberry Pi der ersten Generation ausgeführt. Der Erfolg hängt stark von der Quantisierung und einer leichtgewichtigen Inferenz-Engine wie llama.cpp ab.

Warum ist Quantisierung essenziell für das Ausführen von KI auf alter Hardware?

Quantisierung reduziert den Speicherbedarf und die Rechenkosten eines LLM, indem sie die Präzision seiner Gewichte senkt (z.B. von 16-Bit auf 4-Bit). Dies ist entscheidend, um Modelle auf Geräte mit begrenztem RAM und Rechenleistung zu bringen.

Was ist Cross-Kompilierung und warum wurde sie benötigt?

Cross-Kompilierung ist der Prozess, Code auf einem Computersystem (wie einem modernen Laptop) zu erstellen, der auf einem anderen System (wie einem alten Raspberry Pi) ausgeführt werden soll. Sie war notwendig, um eine mehrtägige Kompilierungszeit und potenzielle Speicherabstürze auf dem Pi selbst zu vermeiden.

Kann ich moderne KI auf jedem alten Computer ausführen?

Obwohl technisch möglich, wie in diesem Experiment gezeigt, erfordert es erhebliches technisches Fachwissen, spezifische Software wie llama.cpp, kompatible kleine Modelle und Umgehungslösungen für Hardwarebeschränkungen wie alte CPU-Befehlssätze. Die Leistung wird auch sehr langsam sein.