Das 2023 in Kanada gegründete Start-up Taalas hat mit dem HC1 einen Technology Demonstrator angekündigt, der KI-Inferenz auf eine neue Stufe heben soll. Statt ein Sprachmodell per Software auf Allzweck-KI-Rechenbeschleunigern auszuführen, gießt Taalas das Modell sozusagen in Silizium. Das erste Produkt ist ein „fest verdrahtetes“ Llama 3.1 8B, das laut Herstellerangaben 17.000 Token pro Sekunde pro Nutzer erzeugen soll.

Laut Taalas bildet das Herzstück ein applikationsspezifischer Logikchip (ASIC) mit rund 53 Milliarden Transistoren, gefertigt bei TSMC im 6‑nm‑Prozess (N6) und 815 mm² Die‑Fläche.

Wie das Unternehmen in einem Blogbeitrag mitteilte, sei das nahezu zehnmal schneller als der aktuelle Stand der Technik. Zum Vergleich: Eine Nvidia H200 erreicht nach Nvidia-eigenen Baseline-Daten rund 230 Token pro Sekunde auf demselben Modell. Spezialisierte Inferenz-Anbieter wie Cerebras kommen laut den unabhängigen Benchmarks von Artificial Analysis auf rund 1.936 Token pro Sekunde – also etwa ein Neuntel des von Taalas beanspruchten Werts. SambaNova folgt mit 916 Token/s, Groq mit 609 Token/s.

Die Konkurrenz schläft jedoch nicht: Nvidia lizenziert seit Dezember 2025 Groqs Technik und hat große Teile des Designteams übernommen, um die eigene Position bei dedizierter Hardware zu stärken.

Testplattform läuft

Taalas stellt zum Ausprobieren den Chatbot „Jimmy“ bereit, der tatsächlich mit bemerkenswerter Geschwindigkeit antwortet – knapp 16.000 Token pro Sekunde waren im Test erreichbar. Einen Preis für den HC1 nennt das Unternehmen bislang nicht. Interessierte Entwickler können sich für den Zugang zu einer Inference-API registrieren.

Das vor zweieinhalb Jahren gegründete Start-up verfolgt drei Kernprinzipien: totale Spezialisierung auf einzelne Modelle, die Verschmelzung von Speicher und Rechenlogik auf einem Chip sowie eine radikale Vereinfachung des gesamten Hardware-Stacks. Taalas beansprucht, Speicher und Rechenwerk bei DRAM-typischer Dichte auf einem einzelnen Chip zu vereinen. Damit entfalle die bei herkömmlicher Inferenz-Hardware übliche Trennung zwischen langsamem Off-Chip-DRAM und schnellem On-Chip-Speicher.

Das verspricht Cerebras zwar auch, baut dazu aber seine gigantische Wafer Scale Engine (WSE), die einen kompletten Wafer belegt und 15 kW Leistung in Hitze verwandelt.

Kein HBM, keine Wasserkühlung, kein Advanced Packaging

Der Ansatz unterscheidet sich grundlegend von dem, was große Chiphersteller derzeit verfolgen. Nvidia setzt bei seinen KI-Beschleunigern wie dem H200 auf teures High Bandwidth Memory (HBM), aufwendige Gehäusetechnik (Packaging) und extrem hohe I/O-Datentransferraten.

Auch beispielsweise Googles TPU, Amazons Interentia oder Microsofts kürzlich angekündigter Azure-Beschleuniger Maia 200 nutzen bis zu 216 GByte HBM3E-Speicher bei einer Transferrate von 7 TByte/s. Microsoft verspricht zwar eine höhere Performance pro investiertem Dollar als bei Nvidia-Technik, doch Maia ist ebenfalls als Allzweckbeschleuniger für verschiedene KI-Modelle konzipiert.

Taalas eliminiert diese Komplexität, indem der HC1 ausschließlich für ein einzelnes Modell optimiert wird. Das Ergebnis komme ohne HBM, 3D-Stacking, Flüssigkühlung und Highspeed-I/O aus.

Bisher nur Mini-Modell

Das hat allerdings einen Preis in puncto Flexibilität. Der HC1 ist weitgehend fest verdrahtet – der Chip kann nur Llama 3.1 8B ausführen, nicht beliebige andere Modelle.

Llama 3.1 wurde Mitte 2024 vorgestellt, das ist im KI-Wettrüsten schon ein stattliches Alter. Die kompakte Version mit 8 Milliarden Gewichten (8 Billion, daher Llama 3.1 8B) läuft in quantisierter Form sogar auf einem Raspberry Pi 5 – wenn auch sehr langsam.

Immerhin lassen sich laut Taalas die Größe des Kontextfensters konfigurieren und per Low-Rank-Adapter (LoRA) Feinabstimmungen vornehmen. Zudem räumt das Unternehmen ein, dass die erste Silizium-Generation ein proprietäres 3-Bit-Datenformat nutzt, kombiniert mit 6-Bit-Parametern. Diese aggressive Quantisierung führe zu gewissen Qualitätseinbußen gegenüber GPU-Benchmarks mit höherer Präzision.

Nächste Generation soll Qualitätsprobleme lösen

Taalas plant, sehr schnell Nachfolger zu liefern. Der schlanke, automatisierte und schnelle Entwicklungsprozess für KI-ASICs ist das eigentliche Ziel des jungen Unternehmens. Es wurde von den Tenstorrent-Gründern Ljubisa Bajic und Drago Ignjatovic ins Leben gerufen. Beide waren zuvor länger für AMD tätig, Bajic auch für Nvidia. Wegen der prominenten Namen – derzeit leitet der bekannte Chipentwickler Jim Keller Tenstorrent – erheischt Taalas viel Aufmerksamkeit in der KI-Szene.

Gerade einmal 24 Teammitglieder hätten das erste Produkt realisiert, bei Ausgaben von 30 Millionen US-Dollar – von insgesamt über 200 Millionen eingesammeltem Kapital. Für einen N6-Chip mit 53 Milliarden Transistoren sind 30 Millionen US-Dollar Entwicklungskosten sehr wenig. Angesichts der extrem hohen Preise für Allzweck-KI-Beschleuniger erwarten die Gründer eine lukrative Marktnische.

Taalas zielt mit seinen Chips ausdrücklich auf Rechenzentren verspricht dort Kosten, die 20-mal niedriger liegen sollen als bei konventioneller GPU-Inferenz, bei einem Zehntel des Stromverbrauchs.

Ein mittelgroßes Reasoning-Modell auf Basis der gleichen HC1-Plattform soll im Frühjahr in den Taalas-Laboren eintreffen und kurz darauf als Inference-Service verfügbar werden.

Danach plant das Unternehmen, mit der zweiten Chipgeneration HC2 ein Frontier-LLM umzusetzen. Die HC2-Plattform soll standardisierte 4-Bit-Gleitkommaformate unterstützen, höhere Packungsdichte bieten und noch schneller arbeiten. Ein Deployment ist für den Winter vorgesehen.

Einordnung und offene Fragen

Die von Taalas genannten Leistungsdaten sind beeindruckend, lassen sich bislang aber nur eingeschränkt überprüfen. Die Benchmarks stammen aus hauseigenen Tests; unabhängige Messungen von Dritten liegen bisher nicht vor.

Auch ist unklar, wie sich die Qualitätseinbußen durch die aggressive Quantisierung in der Praxis auswirken – insbesondere bei komplexeren Aufgaben jenseits einfacher Chat-Konversationen. Ob das Konzept modellspezifischer Chips wirtschaftlich skaliert, wenn für jedes neue Modell eigenes Silizium gefertigt werden muss, bleibt ebenfalls abzuwarten.

Taalas geht es nicht um sogenannte „Edge AI“-Anwendungen, bei denen trainierte Modelle ohne Cloud-Anbindung direkt auf dem Gerät laufen. Das sind häufig Modelle für Spracherkennung, Sprachsteuerung, Objekterkennung in Videobildern für Überwachungskameras, Radar-Sensorauswertung oder Maschinenüberwachung durch Geräuschanalyse (Predictive Maintenance). Das ist die Domäne der Neural Processing Units (NPUs) mit derzeit 10 bis 90 Int8-Tops, die in verwirrender Vielfalt auf den Markt kommen: M5Stacks AI Pyramid-Pro, die Hailo-NPUs zum Nachrüsten des Raspberry Pi 5, Google Coral und die Embedded-Versionen von x86- und ARM-Prozessoren wie AMD Ryzen, Intel Panther Lake, Qualcomm Snapdragon, Mediatek Genio, Rockchip und etwa auch RISC-V-SoCs wie der SpacemiT K3. Auch die europäischen Automotive-Mikrocontroller-Spezialisten Infineon, STMicroelectronics und NXP offerieren alle Chips mit eingebauten NPUs, ebenso wie TI und Renesas.

(vza)

Mad Max als Vorbild für Softwareentwicklung? Das neue Framework Gas Town des Entwicklers und Bloggers Steve Yegge orchestriert mehr als zehn Coding-Agenten gleichzeitig mit einer Architektur, die von der postapokalyptischen Filmreihe inspiriert ist. Der Ansatz: nicht perfekte Einzelagenten, sondern kontrolliertes Chaos mit Agenten-Rollen wie Bürgermeister, Wächter und Raffinerie, die alle an die Mad-Max-Filme angelehnt sind (siehe Tabelle am Ende des Artikels). Gas Town ist dabei nichts für schwache Nerven oder einen kleinen Geldbeutel.

Yegge betont, dass sich das System noch im Alpha-Stadium befindet und erhebliche Vorkenntnisse zu Coding-Agenten voraussetzt, um mit dem Chaos in der Stadt der Coding-Agenten umgehen zu können. Zudem benötigt man durch die starke Skalierung schnell ein zweites oder drittes Claude-Max-Abonnement von Anthropic, das je nach Variante 100 oder 200 US-Dollar pro Monat kostet.

Gas Town zählt zu einer ganzen Gruppe an Anwendungen, die von der Community derzeit heiß diskutiert werden und deren Ziel es ist, Coding-Agenten zu koordinieren. Zu diesen Orchestratoren gehören zum Beispiel Ralph, Loom oder AutoClaude. Yegge hat das Framework am 1. Januar 2026 veröffentlicht, nach nur siebzehn Tagen Entwicklungszeit. Allerdings steckt im Konzept die Erfahrung von über einem Jahr an Experimenten. Er hat es mithilfe von KI-Agenten in Go geschrieben.

Vom Chaos zur Ordnung

Yegge geht von dem Gedanken aus, dass es schon immer die Aufgabe von Ingenieuren gewesen ist, komplexes Chaos in beherrschbare Strukturen zu verwandeln. Das Tool geht dabei einen Failure Mode nach dem anderen mit unterschiedlichen Konzepten an. Der Autor spricht von nichtdeterministischer Idempotenz, zwei Begriffen, die sich auf den ersten Blick ausschließen, aber durch die Kontrollstrukturen des Frameworks zusammenfinden. Die parallele Arbeit von drei bis fünf Coding- und anderen KI-Agenten kann zu chaotischen Systemzuständen führen. Was passiert beispielsweise, wenn mehrere Agenten an gleichen oder ähnlichen Aufgaben arbeiten? Wer kümmert sich um Merge-Konflikte? Wie lässt sich doppelte Arbeit verhindern? Gas Town bedient sich unterschiedlichster Konzepte, um Ordnung in das Chaos zu bringen (siehe folgende Abbildung).

Ein Arbeitstag des Bürgermeisters in Gas Town

Ein typischer Tag in der Stadt Gas Town beginnt damit, dass der menschliche Entwickler (Overseer) gemeinsam mit dem Hauptagenten, dem Bürgermeister (Mayor), die Aufgaben für den Tag in natürlicher Sprache festlegt. Der Bürgermeister zerlegt diese Aufgaben in kleinere Teilaufgaben und speichert sie im Task-Manager (Beads). Sobald die Vorbereitungen fertig sind, bündelt er Aufgaben in einem Arbeitsauftrag, im Convoy, und schickt sie in eines der Repositories, Rigs. Wenn Gas Town Zugriff auf eine gültige GitHub-Authentifizierung hat, kann der Bürgermeister Repositories einfach klonen und für die Verwendung mit Gas Town initialisieren.

Das Aufteilen der Aufgaben begegnet dem Problem der nachlassenden Qualität der Antworten von Coding-Agenten, je weiter sich ihr Kontextfenster füllt. Bei den Claude-LLMs sind das aktuell 200.000 Token. Bei Erreichen des Limits komprimiert der Coding-Agent die Dialoge, um Platz zu schaffen. In der Praxis führt schon ein zu sechzig Prozent gefülltes Kontextfenster zu einer merklichen Reduktion der Ausgabenqualität.

Im Rig werden Arbeiter-Agenten (Polecats) aktiv, die mit der Abarbeitung von Aufgaben beginnen. Je mehr Aufgaben anliegen, desto mehr Polecats treten in Aktion. Sie schaffen sich mit Git-Worktrees ihre eigene Arbeitsumgebung und kümmern sich eigenständig um die Umsetzung.

Über Mailboxes und Handoffs können sie miteinander kommunizieren. Das Mailbox-System ist von Erlang inspiriert und dient der Kommunikation zwischen langlebigen Agenten, wie dem Bürgermeister und dem Wächter. Handoffs hingegen arbeiten synchron und dienen der Übergabe des Arbeitszustands an eine neue Arbeiter-Instanz, wenn der Kontext über die oben beschriebene kritische Füllmenge hinaus ansteigt.

Da in Gas Town immer mal etwas schiefläuft, beschäftigt der Bürgermeister den Wächter (Deacon), der das Gesamtsystem periodisch analysiert, Zombieprozesse aufräumt, festgefahrene Sessions wieder anstößt und die wichtigsten Systemfunktionen am Leben hält. Im Unterschied zum Wächter, der auf Systemebene patrouilliert, überwacht der Aufseher (Witness) innerhalb eines Rigs einzelne Agenten. Jeden Agenten, den er etwa beim Faulenzen erwischt, ermordet er eiskalt und ersetzt ihn.

Merge-Konflikte: Die Raffinerie sortiert

Mit mehreren Agenten kommt es zu vielen parallelen Änderungen, doppelter Arbeit und unzähligen Merge-Konflikten. Außerdem berichten mehr und mehr Entwicklerinnen und Entwickler, dass die Freude an ihrem Job abgenommen hat, seit sie nur noch Code von KI-Agenten reviewen.

Um diesen Problemen Herr zu werden, gibt es in Gas Town eine Raffinerie. Sie überprüft alle Arbeitsergebnisse der Agenten und räumt auf. Merge-Konflikte und schlechte Codequalität bekämpft sie mehrheitlich durch Qualitätskriterien, die sich über konfigurierbare Review-Presets und ein projektspezifisches CLAUDE.md anlegen lassen.

Nachdem alle Aufgaben abgeschlossen sind, meldet der Bürgermeister dem Entwickler stolz die erfolgreiche Abarbeitung der Convoy-Aufgabengruppe.

Agenten in Gas Town stellen austauschbare Instanzen dar, vergleichbar mit dem Konzept von Cattle statt Pets bei der Orchestrierung der Infrastruktur mit virtuellen Maschinen oder Containern, etwa mit Kubernetes. Auch darüber hinaus hat das Framework viel mit Kubernetes gemeinsam: Es gibt eine Control Plane (Bürgermeister und Wächter), die eine Data Plane (die Polecats und Aufseher) managen. Dabei sind die Arbeiter-Agenten (Polecats) austauschbar: Wenn sie den Dienst niederlegen oder stecken bleiben, werden sie durch eine neue Instanz ersetzt, ohne dass der Kontext aus der letzten Session verloren geht.

Sweeps: Garbage Collection für technische Schulden

Wenn Entwicklerinnen und Entwickler blind mit Agenten Code produzieren, akkumulieren sich auf Dauer die technischen Schulden. Die tauchen auch als Fehlannahmen (Heresies) im inneren Monolog der Agenten auf, und menschliche Entwickler können sie darüber aufspüren und nachvollziehen. Grund für die Fehler ist oft das eingeschränkte Kontextfenster, aufgrund dessen Agenten aus dem Blick verlieren, was in der letzten Session vorgefallen ist. Früher gewählte Ansätze geraten in Vergessenheit und Agenten wählen mitunter fremde Designmethoden, die die Architekturkonsistenz verletzen. In einer größeren Codebasis können beispielsweise drei bis vier unterschiedliche Logging Libraries auftauchen.

Um dem zu begegnen, erfordert es sorgfältige Reviews durch Menschen, was wiederum am Produktivitätsgewinn durch die multiplen Agenten nagt. Gas Town wählt eine andere Strategie, die auf Stichproben basiert, den Sweeps: systematische Korrekturwellen, die Architektur-Drift und schlechte Praktiken eindämmen, ohne dass Entwickler alle Fehlannahmen bedenken oder alle Codezeilen einzeln analysieren müssen. Ein sechzigminütiger Review-Sweep mündet in konkreten Aufgaben für das Task-Management (Beads), die so in den Kontext der beteiligten Agenten gelangen. Das lenkt künftige Entscheidungen in die Richtung, die die menschlichen Entwickler für richtig halten.

Um einen Sweep zu starten, lassen sich Entwickler vom Bürgermeister über einen persistenten Workspace (~/gas-town//crew//rig/) einen Git-Worktree erzeugen und sehen dort die Arbeitsergebnisse eines Convoys wie gewohnt in der IDE oder im Terminal. Anstatt selbst Änderungen vorzunehmen, beauftragen sie den Bürgermeister mit der Erstellung von Korrekturaufgaben. Diese ändern das Verhalten der Agenten und führen zu einer weiteren Erhöhung der Codequalität. Nach und nach steigert sich so das Vertrauen in die Agentenschar und der Aufwand für Sweeps reduziert sich. Sweeps stellen eine Art Garbage Collection für technische Schulden dar. Zusätzlich sollten Developer aber nicht auf die gängigen Kontrollmethoden wie Rule-Dateien (AGENT.md oder CLAUDE.md) und statische Quality Gates wie Fitness Functions oder statische Codeanalyse verzichten.

GitHub hat erste Schritte angekündigt, um das Problem der schmuddeligen KI-Beiträge für Open-Source-Projekte anzugehen. Immer mehr Maintainer beklagen sich über derartige Pull Requests (PRs), deren Autorinnen und Autoren „möglicherweise nicht vollständig verstehen, was sie beitragen“ (Brecht Van Lommel, Blender). Das zu Microsoft gehörende GitHub steht als KI-Treiber im Zentrum der Kritik, hat nun aber eine Reihe von Maßnahmen in Planung.

Im Blogeintrag erkennt GitHub das Problem an: „Als Heimat von Open Source haben wir die Verantwortung, euch bei dem zu helfen, was auf euch zukommt.“ Als erste Maßnahme kündigt GitHub an, dass Maintainer PRs künftig einfach löschen können. Das gibt ihnen die Möglichkeit, schon anhand einer schnellen Prüfung AI Slop kurzerhand auszusortieren, um die Übersichtlichkeit des Repos zu erhalten. Das war auch eine der Hauptforderungen vieler überlasteter Projektverantwortlicher.

Weitere Funktionen, die GitHub derzeit erwägt, sind an Bedingungen geknüpfte PRs oder Triage-Tools, die PRs aussortieren, die Erfordernisse nicht erfüllen, die die Maintainer beispielsweise in einer Datei CONTRIBUTING.md manifestieren.

Vorangegangen war ein Aufruf von GitHub in der Community, in dem der Anbieter um Feedback bittet. Hier kündigt GitHub noch an, dass Maintainer PRs auf bestimmte Gruppen von Kontributoren oder für Mirrors einschränken können sollen.

Missmut in der Community steigt

In den vergangenen Wochen hatte die Kritik zugenommen: Gentoo Linux ist auf dem Weg, von GitHub zu Codeberg zu wechseln, und Curl stoppte das Bug-Bounty-Programm auf Hacker One aus ähnlichen Gründen. Zuletzt hatten sich Rémi Verschelde, Maintainer der Spiele-Engine Godot, und Brecht Van Lommel, Softwarearchitekt bei Blender, kritisch zu Wort gemeldet. Verschelde schreibt auf Bluesky: „Offen gesagt werden AI-Slop-PRs für die Godot-Maintainer immer anstrengender und demoralisierender.“ Gleichzeitig ruft er dazu auf, Godot besser finanziell zu unterstützen, um mehr Maintainer bezahlen zu können: Das „ist die einzige praktikable Lösung, die ich mir vorstellen kann.“

Weitere Vorschläge in den Kommentaren zu seinem Posting sind ein Authentifizierungssystem für Kontributoren oder ein Vorrang für erfahrene Entwickler mit ausreichend historischen GitHub-Beiträgen. Das hält auch Verschelde für möglich: „Ich möchte die Zugangsbarriere nicht erhöhen, aber wir haben vielleicht keine andere Wahl.“ An GitHub möchte er festhalten, aufgrund der guten Vernetzung der Projekte und nicht zuletzt wegen der kostenlosen CI.

Kritik an GitHub zielt in erster Linie auf die KI-treibende Politik von Microsoft, in deren Zentrum der Copilot steht. Alex McLean, Maintainer des Musik-Projekts Strudel, berichtet etwa: „Bei uns gab es keine KI-Bot-PRs mehr, seit wir von Microsoft GitHub zu Codeberg umgezogen sind. Ich vermute, dort gibt es keine Anreize dafür.“ Ein anderer Kommentator bezweifelt, dass GitHub ernsthafte Maßnahmen ergreifen will: „Das werden sie nicht. GitHub untersteht Microsofts KI-Team. Jedes neue Update auf der GitHub-Homepage hat einen KI-Bezug.“ Hier wird sich Microsoft beweisen müssen, um eine weitere Abwanderung einzudämmen.

Brecht Van Lommel schreibt im Blender-Blog neben seinem eingangs genannten Zitat: Für Maintainer ist es sinnvoll, neue Entwickler in das Projekt einzuweisen, um dieses voranzubringen, „auch wenn es für den Reviewer schneller gewesen wäre, die Änderungen selbst vorzunehmen (mit oder ohne KI). Daher sollten Reviewer wissen, ob sie mit einem Menschen zusammenarbeiten, damit sie entscheiden können, ob sich der Aufwand lohnt.“

(who)