Open-Source-FPGA-Beschleuniger führt moderne LLMs mit vollständiger Toolchain aus

Der GitHub-Nutzer FeSens hat openTPU veröffentlicht, einen Open-Source-KI-Beschleuniger, der seine eigene Hardwarebeschreibung, Befehlssatzarchitektur, Simulator, Compiler und Profiler in einem einzelnen Repository umfasst. Das am 6. Oktober 2026 veröffentlichte Projekt demonstriert, dass moderne große Sprachmodelle (LLMs) effizient auf FPGA (Field-Programmable Gate Arrays) laufen können, indem ein vollständig transparenter Software- und Hardware-Stack verwendet wird.

Was passiert ist

Das openTPU-Projekt beantwortet zwei grundlegende Fragen zum aktuellen Stand des KI-Hardware-Designs: Wie weit können autonome Agenten bei der Entwicklung von Hardware gehen, und können sie die Chips bauen, die ihre eigene Inferenz ausführen? Der gesamte Beschleuniger befindet sich in einem kleinen Monorepo, sodass Entwickler den Code Ende-zu-Ende lesen können. Dies umfasst das SystemVerilog-Hardware-Design, die Definition des Befehlssatzes, einen bit-exakten Simulator, eine Kernel-Sprache samt Compiler sowie die Host-Software, die erforderlich ist, um eine physische PCIe-Karte anzusteuern.

Das Design wurde auf einer Inspur YPCB-00338 Karte getestet, die über ein Xilinx Kintex-7 xc7k480t FPGA und zwei DDR3-Speicherkänale verfügt. Sie führt erfolgreich zehn moderne Modelle mit ihren echten Gewichten aus und erzeugt Tokens, die bitweise mit der Ausgabe des Simulators übereinstimmen. Das Projekt stellt detaillierte Benchmarks für Modelle wie LFM2.5-230M, Qwen3-0.6B, Qwen3.5-0.8B, Gemma 4 E2B, LFM2-2.6B, SmolLM3-3B, Phi-4-mini sowie Qwen3.5-2B und 4B bereit. Diese Tests decken sowohl Int8- als auch 4-Bit-Quantisierungsschemata ab und zeigen Dekodiergeschwindigkeiten von 3,75 Tokens pro Sekunde für größere Modelle bis hin zu 85,8 Tokens pro Sekunde für kleinere Modelle.

Ein bedeutendes Update, bezeichnet als Build B, verbesserte die Dekodierungsleistung im Vergleich zu früheren Produktionsimages um 8–9 % für mehrere Modelle. Dieser Build erhöhte zudem die Auslastung der DRAM-Bandbreite auf zwischen 91 % und 94 % der maximalen DDR3-1066-Geschwindigkeit. Das System unterstützt Mixture-of-Experts-Modelle, die größer sind als der 4 GiB Speicher der Karte, indem Experten vom Host-Speicher gestreamt werden. Dabei bleibt die bit-exakte Genauigkeit mit dem Simulator auch während dieser komplexen Operationen erhalten.

Wie es funktioniert

Die Architektur ist bewusst einfach gehalten, um Transparenz und einfache Fehlerbehebung zu gewährleisten. Ein Sequencer gibt pro Zyklus eine Anweisung an einige spezialisierte Einheiten aus: eine DMA-Engine für Datenbewegungen, eine Matrixeinheit für die aus dem DRAM gestreamte Int8-Gewichtsmultiplikation, eine Vektoreinheit für FP32-Mathematik und einen Quantisierer zur Rückkonvertierung der Ergebnisse in Int8. Es gibt keine Caches oder versteckten Scheduling-Mechanismen. Jede Datenbewegung wird explizit als Anweisung definiert, was bedeutet, dass ein Ausführungstrace genau zeigt, wo Zyklen verbraucht werden.

Entwickler schreiben Kernels in einer Python-ähnlichen Sprache namens ol, die Decorators wie @ol.jit verwendet, um High-Level-Operationen in den benutzerdefinierten Befehlssatz zu kompilieren. Der Compiler behandelt Layouts, affine Loop-Adressierung und Fusion. Die resultierenden Anweisungen werden auf dem FPGA ausgeführt oder gegen den Python-basierten ISA-Simulator verifiziert. Da der Simulator und das RTL-Design (Register Transfer Level) dieselben Bits verarbeiten, werden sie durch Tests auf Konsistenz überprüft. Dies ermöglicht Entwicklern, Prototypen zu erstellen und auf einem Laptop zu debuggen, bevor sie auf die physische Hardware deployen.

Das System enthält einen Profiler namens Lens, der Läufe vom RTL, Simulator oder der Karte aufzeichnet und diese in einem Browser anzeigt. Lens bietet ein Roofline-Modell, eine Timeline und Tabellen pro Anweisung, wobei jeder Zyklus eingefärbt wird, um zu zeigen, ob eine Einheit beschäftigt ist, auf DRAM wartet oder auf eine andere Anweisung wartet. Diese Sichtbarkeit hilft Ingenieuren, Leistungsengpässe zu verstehen, wie etwa DRAM-Bandbreitenlimits, die derzeit die Dekodierungsgeschwindigkeit auf 82–85 % des theoretischen Peaks begrenzen.

Wichtige Details

• Das Projekt läuft auf einem Xilinx Kintex-7 xc7k480t FPGA mit zwei DDR3-Kanälen und erreicht eine Spitzenbandbreite von bis zu 17,1 GB/s.
• Benchmarks zeigen Dekodierungsgeschwindigkeiten von 3,75 tok/s für Qwen3.5-4B bis zu 85,8 tok/s für LFM2.5-230M mit 4-Bit-Quantisierung.
• Das System unterstützt 4-Bit-Gewichte unter Verwendung von FP4-Werten mit zweistufigen Block-Skalen, was die Bytes pro Token um etwa ein Drittel reduziert.
• Mixture-of-Experts-Modelle wie LFM2.5-8B-A1B laufen durch Streaming von Experten vom Host-Speicher und erreichen 10,6 tok/s mit einer Slot-Trefferquote von 98,5 %.
• Alle Konfigurationen stimmen tokenweise mit dem Simulator überein, was eine bit-exakte Reproduzierbarkeit zwischen Softwaresimulation und Hardwareausführung gewährleistet.
• Der Overhead der Host-Software ist minimal und fügt nur 0,17 bis 0,30 ms pro Token auf optimierten Systemen hinzu, wodurch der Beschleuniger weitgehend unabhängig bleibt.

Warum es wichtig ist

Für Software-Ingenieure und ML-Praktiker entmystifiziert openTPU die Black Box von KI-Beschleunigern. Durch die Bereitstellung eines vollständigen Stacks von Python-Kernels bis hinunter zu SystemVerilog RTL bietet es eine seltene Gelegenheit zu verstehen, wie Matrixmultiplikationen und Aufmerksamkeitsmechanismen in physische Drahtbewegungen und Taktzyklen übersetzt werden. Diese Ebene der Transparenz ist für Bildungszwecke und für Entwickler, die Modelle für spezifische Hardware-Einschränkungen optimieren müssen, ohne proprietäre Tools zu verwenden, von unschätzbarem Wert.

Das Projekt hebt auch die praktischen Grenzen der aktuellen FPGA-basierten Inferenz hervor. Die detaillierten Benchmarks zeigen, dass die Dekodierungsleistung stark durch die DRAM-Bandbreite und nicht durch die Rechenleistung begrenzt ist. Diese Erkenntnis leitet Ingenieure dazu an, Speicherzugriffsmuster und Quantisierungsstrategien zu optimieren, anstatt nur den rechnerischen Durchsatz zu erhöhen. Die Fähigkeit, moderne Modelle wie Qwen3 und Gemma 4 auf relativ älterer Hardware wie dem Kintex-7 auszuführen, deutet darauf hin, dass effiziente Software- und Architekturdesigns die Lebensdauer bestehender Infrastruktur verlängern können.

Darüber hinaus weist die Integration von KI-Agenten in den Designprozess, wie durch den Ansatz "auto-arch-tournament" vorgeschlagen, auf eine Zukunft hin, in der das Hardware-Design selbst automatisiert sein könnte. Die Tatsache, dass das System den Chip bauen und ausführen kann, der seine eigenen Inferenzschleifen ausführt, schafft eine geschlossene Entwicklungsumgebung, die Innovationen in spezialisierter KI-Hardware beschleunigen könnte.

Was Sie tun können

• Installieren Sie das openTPU-Paket via pip und führen Sie den ISA-Simulator auf Ihrem Laptop aus, um Modelle wie LFM2.5-230M ohne Hardware zu testen.
• Studieren Sie die Dokumentation des Befehlssatzes in docs/isa.md, um die Low-Level-Operationen zu verstehen, die den Beschleuniger antreiben.
• Verwenden Sie den Lens-Profiler, um Ausführungstraces zu visualisieren und DRAM-Engpässe in Ihren eigenen Kernel-Implementierungen zu identifizieren.
• Experimentieren Sie mit 4-Bit-Quantisierungsschemata, um die Dekodierungsgeschwindigkeiten zu verbessern, und beachten Sie die in der Quantisierungsdokumentation berichteten Trade-offs bei der Perplexität.
• Wenn Sie eine kompatible Kintex-7 PCIe-Karte haben, erstellen Sie den Bitstream und laden Sie ihn über JTAG, um Echtzeit-Inferenz mit otpu-chat auszuführen.
• Tragen Sie zum Projekt bei, indem Sie das Verzeichnis rtl/ erkunden und helfen, Timing-Margen und Flächeneffizienz in zukünftigen Builds zu verbessern.