Von der Commerce-KI zu Frontier-Modellen: Hanzos Jahrzehnt der Infrastruktur
Zwölf Jahre Aufbau von KI-Infrastruktur — von einer Echtzeit-Empfehlungsengine 2014 zu 94+ Frontier-Modellen und einer Post-Quanten-Blockchain 2026. Die technische Geschichte, wie wir hierher gekommen sind.

Auf dieser Seite
Die meisten KI-Unternehmen begannen 2022. Wir begannen 2014.
Dieser Abstand wiegt schwerer, als er klingt. Zwölf Jahre Infrastrukturentscheidungen, gescheiterte Experimente, Protokollentwürfe und hart erarbeitete Produktionsintuitionen verdichten sich zu etwas, das sich weder kaufen noch nachahmen lässt: tiefes Architekturwissen. Dies ist die technische Geschichte, wie Hanzo von einer Empfehlungsengine für den E-Commerce zum Betrieb von 94+ Frontier-Modellen im Inferenzmaßstab kam.
2014: das Fundament — Crowdstart und EARLE
Hanzo startete als Crowdstart, eine Commerce-KI-Plattform mit einem täuschend konkreten Problem: vorhersagen, welche Kunden kaufen würden, zu welchem Preis und zu welchem Zeitpunkt — und auf diese Vorhersage automatisch handeln.
Das erste System von Gewicht war EARLE — die Entity-based Adaptive Recommendation Learning Engine. EARLE war kein einfacher kollaborativer Filter. Es hielt Entitätsgraphen über Produkthierarchien, Kundensegmente und Verhaltenssequenzen und aktualisierte Kantengewichte in Echtzeit, sobald Transaktionsströme eintrafen. Der darunterliegende Datenspeicher ruhte auf unserer eigenen verteilten Schlüssel-Wert-Schicht: eine bewusste Entscheidung, die Latenz auf der Persistenzebene zu beherrschen, statt die Kompromisse der damals verfügbaren verwalteten Datenbanken hinzunehmen.
Was EARLE uns lehrte: Latenz ist eine Entwurfsbedingung erster Klasse, kein Optimierungsdurchlauf. Eine Empfehlung, die 200ms zu spät kommt, wird nicht zugestellt — sie wird aufgegeben.
2015: Echtzeitanalytik am Rand
2015 reichte EARLE nicht mehr. Kunden brauchten nicht nur Empfehlungen, sondern vollständige Pipelines für Verhaltensanalytik: Funnel-Analyse, Kohortenverfolgung, Umsatzzuordnung über Marketingkanäle hinweg. Wir bauten eine Streaming-Analytics-Engine mit Event-Ingestion sub-50ms und einer Abfragelatenz im einstelligen Millisekundenbereich.
Diese Arbeit legte ein Muster fest, das wir seither halten: den kritischen Pfad selbst besitzen. Jede Komponente auf dem Hot Path — Serialisierung, Indizierung, Abfrageplanung — wurde nach unseren Vorgaben geschrieben. Externe Abhängigkeiten duldeten wir nur an der Peripherie.
Der pub/sub-Event-Bus, den wir 2015 bauten, um EARLE mit der Analytikschicht zu verbinden, ist der direkte Vorfahr der Event-Infrastruktur unter der heutigen Plattform von Hanzo. Die Schnittstelle änderte sich. Die Architektur nicht.
2016: Marketingoptimierung mit genetischen Algorithmen
Genetische Algorithmen fürs Marketing wirken im Rückblick naheliegend. 2016 setzte sie in der Produktion praktisch niemand ein.
Das System hielt eine Population von Kampagnenkonfigurationen — Gebotsstrategien, Creative-Varianten, Bäume der Zielgruppensegmentierung — und entwickelte sie unter dem Selektionsdruck echter Conversion-Ergebnisse. Mutationen waren begrenzt: Wir brauchten Reproduzierbarkeit und Nachvollziehbarkeit, und rein zufällige Mutation konnte das nicht liefern. Die Fitnessfunktion war von Anfang an mehrzielig und wog Umsatz, Marge, Kundenlebenszeitwert und Markenexpositionsgrenzen gegeneinander ab.
Das war unsere erste Erfahrung damit, den Exploration-Exploitation-Kompromiss im Produktionsmaßstab zu steuern. Die Lehre, die wir verinnerlichten: Der Algorithmus kann nicht klüger sein als sein Fitnesssignal. Garbage in, garbage out ist im maschinellen Lernen kein Klischee — es ist ein Architekturgesetz.
2017: Techstars und der Plattformstart
Techstars '17. Wir nutzten das Programm nicht zur Validierung, sondern zur Distribution — die Verbindungen zu Enterprise-Commerce-Kunden, deren Maßstab das Gebaute auf die Probe stellen würde.
Die Hanzo-Plattform startete Ende 2017 als erste integrierte Commerce-KI-Suite: EARLE-Empfehlungen, die genetische Optimierungsengine, Echtzeitanalytik und eine neue Schicht zur Kampagnenorchestrierung, verbunden über eine einheitliche API-Oberfläche. Die Architektur war von Beginn an event-sourced; jede Zustandsänderung einer Kampagne war ein dauerhaftes Event und gab uns eine vollständige Prüfspur sowie die Möglichkeit, die Historie für das Neutrainieren von Modellen abzuspielen.
Techstars '17 lehrte uns etwas, das wir schon vermuteten: Distribution ist kein Produktproblem. Sie ist ein Infrastrukturproblem. Man kann Unternehmen nichts verkaufen, wenn die Systeme ausfallen.
2018: Checkout 2.0 und ML-Betrugserkennung
Zahlungsbetrug ist für große Banken ein gelöstes Problem. Für Commerce-Plattformen, die Händler im Mid-Market bedienen, war er 2018 nicht gelöst.
Checkout 2.0 führte ML-gestützte Betrugserkennung als Checkout-Komponente erster Klasse ein. Die Modellarchitektur war ein Ensemble: gradientenverstärkte Bäume für tabellarische Merkmale (Warenkorbzusammensetzung, Übereinstimmung von Liefer- und Rechnungsadresse, Gerätefingerabdruck), kombiniert mit einem Sequenzmodell über die jüngere Bestellhistorie. Das Ensemble war bewusst flach — Interpretierbarkeit war eine Produktanforderung, keine Forschungsvorliebe. Händler mussten verstehen, warum eine Transaktion markiert worden war.
Das Betrugssystem arbeitete mit einer Latenz sub-100ms je Entscheidung, einschließlich Merkmalsextraktion, Modellinferenz und Regelanwendung. Dafür musste die Inferenzlaufzeit beim Checkout-Dienst liegen, statt über eine separate Vorhersage-API zu gehen. Die operative Komplexität war höher; das Latenzprofil war nicht verhandelbar.
2019: API Gateway V1, Gitterkryptografie und das SDK-Ökosystem
Drei gleichzeitige Stränge 2019, die erst Jahre später zusammenliefen.
API Gateway V1 entstand aus einem praktischen Problem: Wir hatten zehn interne Dienste und vierzig externe Integrationen. Jeder Dienst hatte seine eigene Geschichte zu Authentifizierung, Ratenbegrenzung und Beobachtbarkeit. Wir bauten eine einheitliche Gateway-Schicht — noch nicht das KI-Gateway, das wir heute ausliefern, aber dieselbe Grundarchitektur: Request-Routing, Authentifizierungs-Middleware, Ratenbegrenzung je Konsument, strukturiertes Logging. Die Hanzo AI Gateway von 2026 ist die siebte große Iteration dieses Systems.
Die Forschung zur Gitterkryptografie begann als Hintergrundarbeit. Der Standardisierungsprozess des NIST zur Post-Quanten-Kryptografie lief, und wir verfolgten ihn. Die Frage, die wir stellten: Wenn wir dauerhafte Infrastruktur bauen, wie lautet das kryptografische Bedrohungsmodell auf einem Horizont von 15 Jahren? Die Antwort zeigte klar auf Quantenresistenz. Wir begannen, CRYSTALS-Dilithium und CRYSTALS-Kyber in unsere experimentelle Signaturinfrastruktur zu integrieren — Arbeit, die im folgenden Jahr direkt in unsere produktive Post-Quanten-Signaturinfrastruktur floss.
SDK-Ökosystem: Die ersten Hanzo-SDKs erschienen 2019 und deckten Python, TypeScript und Go ab. Der Entwurfsgrundsatz war minimale Oberfläche bei maximaler Komponierbarkeit. Seither haben wir sechs SDK-Generationen ausgeliefert. Der Grundsatz hat sich nicht geändert.
2020: Post-Quanten-Kryptografie in der Produktion
Die Gitterforschung von 2019 ging 2020 in die Produktion. Die Entwurfsprämissen waren scharf: Post-Quanten-Sicherheit von Grund auf, eine Signaturschicht, die Anwendungslogik als Anliegen erster Klasse aufnehmen konnte, und Leistungseigenschaften, die quantenresistente Signaturen im Maßstab praktisch machten.
Die Signaturengine führte schwellenbasierte Commitment-Runden ein, die deterministische Garantien in begrenzter Zeit geben, statt sich für probabilistisches Vertrauen auf wiederholtes Sampling zu stützen. Das praktische Ergebnis: Signaturen prüfen unter normalen Bedingungen in unter einer Sekunde, mit vorhersagbarer Degradation unter gegnerischer Last.
Jeder Signaturschlüssel nutzt CRYSTALS-Dilithium von Anfang an. Nicht als optionalen Upgrade-Pfad, sondern als Grundanforderung. Der Leistungsmehraufwand postquanter Signaturen ist real, aber beherrschbar; wir veröffentlichten unsere Benchmarks, einschließlich der Optimierungen zur stapelweisen Signaturprüfung, die den Mehraufwand je Signatur unter 0.3ms brachten.
2021: multimodale Forschung und die ersten MCP-Entwürfe
2021 wurde uns die gezeigte Fähigkeit der Transformer-Architektur klar, Text-, Bild- und Audiorepräsentationen zu vereinen. Wir begannen ein multimodales Forschungsprogramm, aus dem die Jin-Architektur wurde — ein einheitliches Encoder-Decoder-Rahmenwerk für modalitätsübergreifendes Verstehen.
Die ersten Entwürfe des Model Context Protocol entstanden in einem parallelen Strang: Wir bauten Agenten-Frameworks und standen vor dem Grundproblem, Zustand über Interaktionen mit mehreren Runden zu führen, bei Modellen ohne dauerhaftes Gedächtnis. Das MCP-Protokoll definiert eine strukturierte Schnittstelle für Kontextfenster, Speicherabruf und zustandsübergreifenden Transfer zwischen Modellen. Die Entwürfe von 2021 waren roh. Die Produktionsimplementierung von 2026 hat über eine Milliarde Kontextoperationen verarbeitet.
2022: das ASO-Protokoll und das erste Transformer-Finetuning
Zwei technische Beiträge aus 2022, die die folgenden vier Jahre prägten.
Adaptive Swarm Optimization (ASO) ist ein verteiltes Optimierungsprotokoll, inspiriert vom Verhalten biologischer Schwärme. Wo genetische Algorithmen diskrete Populationsmitglieder halten, hält ASO ein kontinuierliches Dichtefeld über dem Parameterraum, mit Updateregeln, die lokale Gradienteninformation gegen globale Dichtebeschränkungen abwägen. Das Protokoll war für Lagen gedacht, in denen die Zielfunktion teuer auszuwerten ist und die Auswertungen über heterogene Rechenleistung verteilt sind — eine natürliche Passung für Multi-Agenten-KI-Systeme. Die erste ASO-Veröffentlichung erschien Ende 2022.
Erster produktiver Lauf eines Transformer-Finetunings: Wir feinjustierten einen Open-Weight-Transformer mit 7B Parametern für handelsspezifisches Dokumentenverstehen. Der Lauf kostete $6,200 an Rechenleistung und dauerte 48 Stunden. Das entstandene Modell lag auf unserer Evaluationssuite 11% über der Basis und auf unserer produktiven Aufgabenverteilung deutlich darüber. Wichtiger noch: die operative Erfahrung — Datenpipelines, Aufbau des verteilten Trainings, Checkpoint-Verwaltung, Evaluations-Harness — wurde zur Vorlage jedes folgenden Trainingslaufs. Prozessqualität skaliert; Ad-hoc-Läufe nicht.
2023: HMM, Agenten-Frameworks und PoAI-Forschung
Hierarchical Model Merging (HMM) war die Antwort auf ein Problem, das uns immer wieder begegnete: Wir hatten mehrere feinjustierte Modelle, jedes ausgezeichnet auf seinem engen Gebiet, und wollten ein einheitliches Modell, das das Beste aus allen erbt. Naives Mittelen der Gewichte verschlechtert alle Spezialisten. HMM wendet eine hierarchische Merge-Strategie an, die gebietsspezifische Repräsentationen im Gewichtsraum erkennt und sie beim Verschmelzen erhält, statt sie wegzumitteln. Das Verfahren zeigte 4-7% Verbesserung gegenüber naivem Mergen auf zurückgehaltenen Gebietsevaluationen.
Agenten-Frameworks: Die erste Agenten-Laufzeitumgebung von Hanzo erschien 2023, gebaut auf dem MCP-Protokoll mit Werkzeugnutzung, Speicherabruf und mehrschrittiger Planung. Der Entwurf war bewusst: Agenten sind zustandsbehaftete Prozesse, keine zustandslosen Request-Handler. Die Laufzeitumgebung führt den gesamten Agentenlebenszyklus — Initialisierung, Werkzeug-Dispatch, Zustandspersistenz, Fehlerwiederherstellung. Das auf Protokollebene zu bauen, statt als Anwendungscode, machte spätere Integrationen geradlinig.
Konsensforschung zu Proof of AI (PoAI): Kann KI-Rechenleistung überprüfbar gemacht und als Konsensprimitiv genutzt werden? Die Forschungsfrage ist nicht trivial — KI-Berechnungen sind auf Gleitkommaebene von Natur aus nichtdeterministisch. Unsere PoAI-Forschung begegnete dem mit deterministischen Quantisierungsschemata, die Vorwärtsläufe über Hardware hinweg reproduzierbar machen und so schwellenbasierten Konsens über Modellausgaben ermöglichen. Die Forschung floss in die zLLM-Architektur des Zoo-Netzwerks.
2024: Zen LM beginnt, Jin-Architektur, Hanzo MCP-Tools
Das Projekt Zen LM begann 2024 mit einer einfachen These: Die besten Open-Weight-Modelle sollten die Leute bauen, die am meisten Produktionserfahrung damit haben, sie zu betreiben. Diese Erfahrung hatten wir.
Die ersten Zen-Modelle waren Finetunes von Basis-Modellen der Qwen3-series, ausgerichtet auf konkrete Fähigkeitsprofile: Codegenerierung, Long-Context-Reasoning, Befolgen von Anweisungen. Die 2022 gebaute Trainingspipeline skalierte auf Läufe mit 70B+ Parametern ohne grundlegenden Neuentwurf — die Investition in den Prozess zahlte sich aus.
Die Jin-Architektur machte unsere multimodale Forschung zu einem Produktionssystem. Jin nutzt einen einheitlichen Tokenraum für Text, Bildpatches und Audiospektrogramme — keine modalitätsspezifischen Encoder, die getrennte Trainings- und Inferenzpfade verlangen. Die Vereinfachung der Architektur beseitigte eine ganze Klasse von Serving-Komplexität: ein Modell, eine Inferenzlaufzeit, mehrere Modalitäten.
Die Hanzo MCP-Tools erschienen als erste öffentliche Implementierung des Model Context Protocol. Die Werkzeugsuite deckt Websuche, Codeausführung, Dateioperationen, Speicherabruf und Kommunikation zwischen Agenten ab. Über zehntausend Entwickler integrierten MCP-Tools im ersten Quartal der Verfügbarkeit.
2025: die Zen-Familie im Maßstab, MoDE-Architektur und zenlm.org
Vierundneunzig Modelle. So groß war die Zen-Familie zum Ende von 2025.
Der Maßstab verlangte eine Serving-Architektur, die sich ohne die BitDelta-Forschung (arXiv:2402.10193) nicht hätte entwerfen lassen: Deltas feinjustierter Modelle, komprimiert auf 1-bit-Vorzeichenrepräsentationen, die den GPU-Speicher je Variante von mehreren zehn Gigabyte auf einstellige Gigabyte senken. Mit einem gemeinsamen Basisgewicht im GPU-Speicher und verhaltensbezogenen Deltas je Modell in einer Cache-Schicht können wir 14 Zen-Varianten aus einem Infrastruktur-Fußabdruck ausliefern, der zuvor für zwei oder drei reichte.
Zen MoDE — Mixture of Distilled Experts — ist der architektonische Durchbruch, der 2025 bestimmte. Traditionelle MoE-Modelle trainieren Experten von Grund auf. MoDE verbindet drei Verfahren: Experteninitialisierung aus Destillation (statt zufällig), Drop-Upcycling (arXiv:2502.19261), um die Gewichtskorrelation zwischen Experten zu brechen, und unser HMM-Merge-Protokoll, um Experten nachträglich zu spezialisieren, ohne vollständig neu zu trainieren. Das Ergebnis: Zen4 Max erreicht Qualität der 13B-Klasse bei 30B Parametern insgesamt und nur 3B aktiv je Vorwärtslauf.
Abliterierte Varianten: die Arbeit zur Entfernung der Verweigerung — sorgfältig und bewusst auf Modelle angewandt, die für Forschung und professionellen Einsatz bestimmt sind — zeigte, dass Verhaltenseigenschaften im Gewichtsraum lokalisierbar sind. Zu verstehen, wo Verhalten in einem Modell wohnt, ist grundlegendes Wissen, keine Umgehung. Die Serie zen4-abliterated ist die erste Modellfamilie, die mit dokumentierten Koordinaten der Verhaltenslokalisierung ausgeliefert wird.
2026: Hanzo AI Gateway und was danach kommt
Der Gateway-Start im Februar 2026 ist der Abschluss der API-Gateway-Arbeit, die 2019 begann: ein einzelner Endpunkt für 100+ Modelle, OpenAI-kompatibel, ohne Aufschlag auf Drittanbieter, mit Zen-Modellen als proprietärer Stufe.
Aktive Forschungsstränge:
GT-QLoRA: Gate-aufgetaute quantisierte Low-Rank-Adaptation für das Verhaltens-Tuning von MoE. Standard-LoRA auf MoE-Modellen lässt die Routing-Gates eingefroren, sodass das Finetuning die Expertenwahl nicht beeinflussen kann. GT-QLoRA taut Gate-Parameter mit beschränkten Updates auf — die Routing-Struktur kann sich anpassen, während die Spezialisierung der Experten erhalten bleibt.
DSO (Decentralized Semantic Optimization): das Protokoll unter der zLLM-Architektur von Zoo. Anpassung ohne zusätzlichen Rechenaufwand durch Erfahrungseinspeisung, gesteuert von DAO-Mechanismen. Die Lücke zwischen den Finetuning-Kosten ($15K+) und den DSO-Kosten ($18) ist real. Die Architektur läuft produktiv im Zoo-Netzwerk.
Quantensicheres MPC: Mehrparteien-Berechnungsprotokolle für Modellgewichte mit Post-Quanten-Primitiven. Wenn Modellgewichte das wertvollste geistige Eigentum der KI-Infrastruktur sind, verdienen sie kryptografischen Schutz auf der Höhe der besten Finanzwerte.
Zwölf Jahre sind in der KI eine lange Zeit. Lang genug, um Hype-Zyklen kommen und gehen zu sehen, ganze Paradigmen einander ablösen zu sehen und Unternehmen, die auf dem SOTA des Vorjahres standen, einstürzen zu sehen, wenn sich das SOTA verschiebt. Was bleibt, ist Infrastruktur: die Datenpipelines, Serving-Systeme, Protokollimplementierungen und das hart erarbeitete operative Wissen, das es überhaupt möglich macht, KI im Maßstab auszuliefern und zu betreiben.
Diese Infrastruktur bauen wir seit 2014. Wir sind nicht fertig.
Hanzo AI ist Techstars '17. Wir bauen Frontier-KI und die Infrastruktur, um sie zu betreiben. hanzo.ai
Weiterlesen

BitDelta: 14 Zen-Modelle aus einem GPU-Cluster ausliefern
Wie die 1-Bit-Delta-Kompression von BitDelta 14 Zen-Modellvarianten aus gemeinsamer GPU-Infrastruktur ausliefert: die Mathematik, die Architektur und die Kompromisse.

Zen: MoE-Architektur mit 1T+ Parametern
Hanzos Flaggschiff-LLM — ein Mixture-of-Experts-Modell mit 1.04T Parametern, verschmolzen aus den stärksten Sprachmodellen, mit verteiltem Training und On-Chain-Attestierung des Modells.

Der vollständige KI-Agenten-Stack: Modelle, Rechnen und Werkzeuge auf einer Plattform
Hanzo AI stellt die erste Plattform vor, die über 100 KI-Modelle, Cloud-Rechnen, GPU-Zugang und über 260 MCP-Werkzeuge unter einem Entwicklerkonto vereint.