Chitu (赤兔): Inferenz-Framework mit Fokus auf chinesische Beschleuniger
High-performance inference framework for large language models, focusing on efficiency, flexibility, and availability.
Auf einen Blick
- Was ist das?
- Chitu ist ein Python-Inferenz-Framework für große Sprachmodelle, das neben NVIDIA-Hardware ausdrücklich Ascend, Moore Threads, MetaX und Hygon unterstützt. Der interessanteste Teil ist aber nicht die Modellliste, sondern die Bereitstellung über eine einzige Binärdatei.
- Für wen ist es gedacht?
- Chitu ist die naheliegende Wahl, wenn die Zielhardware Ascend 910B, Moore Threads, MetaX oder Hygon ist und ein Team bereit ist, die Versionshinweise als Kompatibilitätsliste zu lesen. Wer auf einer homogenen NVIDIA-Flotte bleibt und breite Modellabdeckung über die im Projekt dokumentierten Familien hinaus braucht, sollte zuerst prüfen, ob das eigene Modell in docs/zh/SUPPORTED_MODELS.md überhaupt auftaucht: diese Datei ist die Grenze, nicht die README.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Chitu adressiert
Die README beschreibt Chitu als produktionsreife Inferenz-Engine für große Modelle. Der Satz, der die Zielgruppe am schärfsten eingrenzt, steht in der Einleitung: das Projekt wolle den schrittweisen Weg von kleinen Experimenten bis zur großen Bereitstellung abdecken. Genau dort liegt der Unterschied zu Frameworks, die von vornherein einen Cluster voraussetzen. Chitu nennt drei Eigenschaften, an denen sich der Anspruch messen lassen muss: Anpassung an unterschiedliche Rechenbeschleuniger, Skalierung von reinem CPU-Betrieb über eine einzelne GPU bis zum Cluster, sowie Stabilität im Dauerbetrieb.
Wer das liest, sollte die Reihenfolge beachten. Die Hardware-Vielfalt steht zuerst, nicht die Modellvielfalt. Das Projekt positioniert sich damit gegen die verbreitete Annahme, Inferenzoptimierung sei eine NVIDIA-Angelegenheit. Die Versionshinweise stützen diese Lesart: v0.5.1 nennt Moore Threads, v0.4.0 nennt Ascend, NVIDIA, MetaX und Hygon in einem Eintrag, v0.3.5 liefert nach eigener Angabe vollständige native Unterstützung für Ascend 910B. Wer ausschließlich auf H100 oder A100 plant, findet in diesen Einträgen keinen Vorteil.
Was die Modellliste tatsächlich abdeckt
Die README verweist für Details auf docs/zh/SUPPORTED_MODELS.md und nennt im Fließtext nur die Familien, die im Zusammenhang mit konkreten Releases auftauchen: DeepSeek, Qwen, GLM und Kimi. Einzelne Meilensteine werden sehr konkret. v0.3.9 nennt die erstmalige Unterstützung von GLM-4.5 MoE auf Ascend 910B, v0.3.5 nennt die Qwen3-Reihe, v0.1.0 und v0.3.0 kreisen um DeepSeek-R1 671B.
Das ist eine andere Form der Modellpflege als bei Frameworks, die eine lange, alphabetisch sortierte Tabelle pflegen. Chitu dokumentiert Unterstützung release-für-release, jeweils zusammen mit der Hardware, auf der sie erprobt wurde. Für die Adoption bedeutet das: die Frage lautet nicht, ob ein Modell grundsätzlich unterstützt wird, sondern ob die Kombination aus Modell und Beschleuniger in einem Release auftaucht. Die README selbst macht keine Zusage über die Breite der Liste, sie verweist nur darauf. Wer ein Modell außerhalb dieser vier Familien einsetzt, muss vor dem Deployment in der Datei nachsehen.
Quantisierung als eigener Mechanismus
Zwei Meilensteine beschreiben konkrete Rechenkerne statt allgemeiner Leistungsversprechen. v0.3.0 führt eine effiziente Operator-Implementierung ein, die FP4 zur Laufzeit nach FP8 oder BF16 wandelt, und verweist auf eine FP4-Quantisierung von DeepSeek-R1 671B. v0.1.0 nennt denselben Ansatz für FP8 nach BF16.
Das ist mehr als ein Detail. Wer ein Modell in niedriger Präzision vorhält und erst bei der Berechnung in ein breiteres Format überführt, spart Speicherplatz und Bandbreite beim Laden der Gewichte. Der Preis ist eine Umrechnung pro Durchlauf, deren Kosten von der Implementierung abhängen. Chitu beschreibt diese Kerne als effizient, veröffentlicht in der README aber keine Zahlen dazu. Die tatsächlichen Messwerte liegen laut README in docs/zh/PERFORMANCE.md, und die README schränkt selbst ein, dass diese Daten von Hardware, Softwareversion und Last abhängen und zwischen Läufen schwanken können. Diese Einschränkung ist ernst zu nehmen: sie stammt vom Projekt selbst, nicht von einem Kritiker.
CPU und GPU im selben Verbund
Der Meilenstein v0.2.2 nennt heterogene Inferenz über CPU und GPU und behauptet damit die Ausführung von DeepSeek-R1 671B auf einer einzelnen Karte. Das ist der architektonisch interessanteste Eintrag, weil er die Grenze zwischen Speicher und Rechenwerk verschiebt. Ein Modell dieser Größenklasse passt in keinem gängigen Format vollständig in den Speicher einer einzelnen GPU. Wenn ein Teil der Gewichte im Hauptspeicher bleibt und die CPU daran rechnet, während die GPU den Rest übernimmt, wird die Karte zum Beschleuniger statt zum alleinigen Träger.
Die README erläutert den Datenfluss hinter dieser Aufteilung nicht. Ob Schichten abwechselnd auf CPU und GPU liegen, ob ein Cache zwischen beiden wandert und wie die Bandbreite zwischen den beiden Domänen den Durchsatz begrenzt, lässt sich aus dem vorliegenden Material nicht ableiten. Wer diesen Modus produktiv erwägt, sollte die Angaben in docs/zh/DEVELOPMENT.md prüfen, bevor er Kapazität plant. Die Aussage "auf einer einzelnen Karte" bezieht sich auf die Machbarkeit, nicht auf einen Durchsatzwert.
Bereitstellung über chitu.run
Der jüngste Meilenstein, v0.6.0 vom Juli 2026, führt eine ausführbare Datei namens chitu.run ein. Laut Release-Notiz startet eine einzige Datei auch komplexe Aufgaben: mehrere Knoten, mehrere Instanzen und die Trennung von Prefill und Decode (PD). Die README empfiehlt chitu.run ausdrücklich als Weg für die Bereitstellung und verweist für den Bezug auf die Assets-Seite der Releases.
Das ist eine bewusste Entscheidung gegen den üblichen Python-Weg. Statt eine Umgebung aufzulösen und Abhängigkeiten zu installieren, wird eine Datei heruntergeladen und gestartet. Für ein Team, das dieselbe Konfiguration auf vielen Maschinen ausrollen muss, entfällt damit ein ganzer Fehlerbereich. Der Preis ist, dass die Datei an eine Plattform und eine Version gebunden ist. Die README nennt keine Paketquelle, kein Container-Image und keine Konfigurationsschlüssel. Wer wissen will, wie die Trennung von Prefill und Decode konkret konfiguriert wird oder welche Flags chitu.run akzeptiert, findet in der README keine Antwort. Die vollständige Anleitung liegt laut Projekt in docs/zh/DEVELOPMENT.md. Bis dahin bleibt der Einstiegspunkt bekannt, die Bedienung aber offen.
Wartung, Lizenz und der ehrliche Vorbehalt
Die Release-Kadenz ist dicht: v0.5.6 im Mai 2026, v0.5.7 im Juni, v0.6.0 im Juli, jeweils etwa einen Monat auseinander. Wer Chitu produktiv einsetzt, muss damit rechnen, regelmäßig zu aktualisieren, und zwar nicht nur wegen neuer Modelle. Die Hardware-Anpassungen aus v0.4.0 und v0.5.1 betreffen die Beschleuniger selbst. Ein Team, das auf Ascend oder Moore Threads setzt, hängt an dieser Kette, weil Verbesserungen für die eigene Plattform in neuen Versionen erscheinen.
Lizenzseitig ist die Lage übersichtlich, aber nicht trivial. Das Projekt steht unter Apache License v2.0. Die README weist jedoch darauf hin, dass der Quellbaum Codefragmente aus anderen Open-Source-Projekten enthält, deren Copyright-Vermerke im SPDX-Format direkt im Code stehen und deren Lizenzen im Verzeichnis LICENSES/ liegen. Zusätzlich enthält das Repository Fremdmodule unter third_party/ mit eigenen Lizenzdateien. Wer Chitu weiterverbreitet oder in ein eigenes Produkt einbettet, muss diese beiden Verzeichnisse prüfen. Die Apache-Lizenz des Hauptprojekts allein sagt nichts über die Bedingungen der eingebetteten Teile aus. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, an denen eine Prüfung ansetzt.
Bemerkenswert offen ist der Absatz zur Unterstützung. Das Team schreibt, es könne wegen begrenzter Kapazität nicht zusagen, alle gemeldeten Probleme zeitnah zu lösen, und verweist für professionellen Service auf eine Kontaktadresse. Für ein Projekt, das sich als produktionsreif bezeichnet, ist das eine wichtige Einschränkung. Wer Chitu in einem System mit Verfügbarkeitszusage betreibt, sollte klären, ob der eigene Vertriebsweg diesen Kanal abdeckt oder ob man auf die Community-Antwortzeit angewiesen ist.
Wann Chitu die falsche Wahl ist
Chitu ist kein allgemeiner Ersatz für jede Inferenzumgebung. Drei Fälle sprechen dagegen. Erstens: Wenn das eingesetzte Modell nicht zu DeepSeek, Qwen, GLM oder Kimi gehört und auch nicht in docs/zh/SUPPORTED_MODELS.md auftaucht, gibt es keine dokumentierte Grundlage. Zweitens: Wenn die Zielhardware eine homogene NVIDIA-Flotte ist und der Hauptvorteil des Projekts, die Anpassung an mehrere Beschleuniger, gar nicht zum Tragen kommt, dann trägt man die Komplexität eines breit aufgestellten Frameworks ohne Gegenwert. Drittens: Wenn ein Team auf eine breite, langjährig gepflegte Modellbibliothek und ein großes Ökosystem an Werkzeugen angewiesen ist.
Der naheliegende Vergleich ist vLLM, das die README selbst in der Danksagung als eines der Projekte nennt, von denen Chitu gelernt und Funktionen übernommen hat. Der Unterschied liegt im Schwerpunkt. vLLM verfolgt eine breite Modellabdeckung als Kernziel. Chitu verfolgt Hardware-Abdeckung als Kernziel und dokumentiert Modelle release-weise entlang der Hardware, auf der sie laufen. Ein Team mit Ascend-910B-Knoten findet bei Chitu eine dokumentierte Release-Historie für genau diese Plattform. Ein Team, das ein ungewöhnliches Modell auf einer Standard-GPU betreiben will, wird bei vLLM schneller fündig. Die beiden Ansätze schließen sich nicht aus, aber sie führen zu unterschiedlichen Prüffragen vor dem Deployment.
Redaktionelles Fazit
Chitu ist die naheliegende Wahl, wenn die Zielhardware Ascend 910B, Moore Threads, MetaX oder Hygon ist und ein Team bereit ist, die Versionshinweise als Kompatibilitätsliste zu lesen. Wer auf einer homogenen NVIDIA-Flotte bleibt und breite Modellabdeckung über die im Projekt dokumentierten Familien hinaus braucht, sollte zuerst prüfen, ob das eigene Modell in docs/zh/SUPPORTED_MODELS.md überhaupt auftaucht: diese Datei ist die Grenze, nicht die README.
Community-Notizen