KI-gestützte Patches für den Linux-Kernel benötigen künftig keinen „Assisted by“-Tag in der Commit-Nachricht mehr. Dafür sprach sich eine Mehrheit der rund 30 geladenen Entwicklerinnen und Entwickler auf dem Maintainers Summit aus, der am 8. Oktober in Prag stattfand.

Ganz umgesetzt ist dieser Konsens noch nicht. Auf der Linux-Kernel-Mailingliste ist ein entsprechender Patch indes schon eingereicht. Sasha Levin, Distinguished Software Engineer bei Nvidia und Co-Maintainer der Stable- und LTS-Kernel, beantragte dort am 9. Oktober, die Tag-Vorgabe aus der Dokumentation zu streichen. Der zuständige Maintainer Jonathan Corbet hat den Patch inzwischen in den Entwicklungszweig docs-next übernommen, in den Mainline-Kernel muss er es aber noch schaffen.

Die Chancen dafür stehen gut, denn Linus Torvalds und Greg Kroah-Hartman, ebenfalls einer der prominentesten Kernel-Entwickler, unterstützen die Änderung. Auf der Mailingliste sind die Meinungen allerdings geteilt.

Richtlinie bringt wenig bis gar nichts

Was Entwickler bei KI-gestützten Kernel-Patches beachten müssen, regelt seit Linux 7.0 die Richtlinie AI Coding Assistants, basierend auf dem Konsens des Maintainers Summit 2025 und einem am 23. Dezember 2025 eingereichten Patch, den Jonathan Corbet im Januar 2026 absegnete.

Seitdem werden Entwicklerinnen und Entwickler darum gebeten, einen „Assisted by“-Tag für ihre Commits zu verwenden, wenn diese mithilfe eines fortgeschrittenen Coding-Tools wie eines LLM zustande kommen. Initiiert hatte die Richtlinie ebenfalls Sasha Levin, der nun für die Abschaffung des Tags plädiert hat. Ein erster Vorschlag, ihn zu streichen, war im Juli noch gescheitert; damals hatte sich auch Kroah-Hartman für die Beibehaltung ausgesprochen.

Die Begründung für die Abschaffung reichte Levin in seinem überarbeiteten Patch vom 13. Oktober nach: Nur rund 10 Prozent der 18.533 Commits in Linux 7.3 bis -rc7 tragen den Tag, Merge-Commits nicht mitgezählt. Tatsächlich werde KI aber viel häufiger eingesetzt. Manche Entwickler kennen die Regel laut Levin nicht, andere lassen den Tag absichtlich weg, und kaum ein Maintainer fragt nach. Ein fehlender Tag sage deshalb nichts darüber aus, wie ein Patch entstanden ist. Bei Entwicklern, die KI für fast alles nutzen, sage aber auch ein gesetzter Tag wenig.

Der Grundgedanke, Maintainern Transparenz über die Entstehung eines Patches zu verschaffen, soll aber weiterhin gelten. Wie KI-Tools eingesetzt wurden, sollen Entwickler künftig im Cover-Letter beschreiben, der Begleitmail zu einem Patch oder einer Patch-Serie. In die Commit-Nachricht gehört es nicht mehr.

Landet der Patch im Mainline-Kernel, erschließt sich aus der Git-Historie künftig nicht mehr direkt, welche Änderungen mit KI-Hilfe entstanden sind. Verlässlich war das allerdings schon bisher nicht. Unverändert bleibt die Verantwortung: KI-Agenten dürfen keine Signed-off-by-Zeile setzen.

Auch Linus Torvalds nutzt LLMs

Linus Torvalds hält wenig von Regeln für KI-Werkzeuge. Regeln, die den Einsatz bestimmter Werkzeuge verbieten, nennt er „stupid“. Er erwarte, dass Leute verstehen, was sie tun. Mit den verwendeten Werkzeugen habe dieses Verständnis aber wenig zu tun.

Torvalds hat fast zeitgleich mit dem Summit selbst Kernel-Code mit einem LLM entwickelt. In der Commit-Nachricht schreibt er, der Code, die Testprogramme, die Prüfung, auf der die Liste bekannter Probleme beruht, und der erste Entwurf des Textes seien mit Claude Code unter seiner Anleitung entstanden. Die Patches sollen das Lesen aus dem Page-Cache deutlich beschleunigen, wenn viele Threads gleichzeitig kleine Blöcke aus derselben Datei lesen.

(mro)

Lange mussten wir auf ein Modell warten, das speziell auch mit deutschen Texten gut umgehen kann. Zwischenzeitlich kam mit der Ankündigung des Soofi-Modells Hoffnung auf. Diese zerstreute sich aber sehr schnell wieder, weil das Modell bis heute nicht frei zugänglich ist und das Konsortium wohl auch beim Training sehr kreativ Benchmark-Daten mitverwendet hat. Umso gespannter kann man auf das nun veröffentlichte Kolibri-1-Modell von Aleph Alpha sein.

Größe und Architektur

Zuerst fällt die Größe des Modells ins Auge: Sie ist mit 78 Milliarden Parametern relativ unkonventionell. Bei vielen Modellen haben sich zwischenzeitlich Standardgrößen etabliert. In dieses Schema passt das Modell nicht. Die Anzahl der Experten ist mit 384 für diese Anzahl an Parametern verhältnismäßig groß, was bei sechs gerouteten und einem festen Experten zu nur 3,46 Milliarden aktiven Parametern in der Inferenz führt. Die Gewichte der regulären Veröffentlichung liegen überwiegend quantisiert in FP8 vor; einzelne Modellbestandteile bleiben in bfloat16. Daneben bietet Aleph Alpha eine BF16-Version an.

Die Architektur kann man durchaus als traditionell bezeichnen: Kolibri-1 verwendet zwar eine hybride Attention-Architektur mit vier Sliding-Window-Attention-Layern (SWA), die sich mit einem Layer mit voller Attention abwechseln. Für letztere nutzt das Modell aber Grouped Query Attention, die Anbieter wie DeepSeek oder Qwen schon seit einigen Generationen aussortiert haben. Möglicherweise führt das auch zu dem etwas kleineren Kontext von „nur“ 256K Token, den man bei der Inferenz auf rund eine Million Token extrapolieren kann.

Kolibri-1 beherrscht außerdem Reasoning; es kann also seine Antworten in einer Art „Denkprozess“ begründen. Dessen Länge lässt sich in drei Stufen steuern. So kann man verhindern, dass das Modell bei einfachen Fragen unnötig lange nachdenkt. Bis dahin bietet das Modell keine großen Überraschungen.

Trainingsdaten

Diese folgen allerdings bei den Trainingsdaten, die anders aufbereitet sind als die der Wettbewerber. Das fängt schon „ganz vorn“ im Modell an, nämlich im Tokenizer.

Der Tokenizer verantwortet die Aufteilung der Texte in Wörter beziehungsweise deren Bestandteile, die Token. Viele mehrsprachige Modelle, insbesondere die der chinesischen Anbieter, müssen hier Kompromisse eingehen, damit sich möglichst viele Wörter (oder Wortbestandteile) der unterschiedlichen Sprachen effizient darstellen lassen. Da Aleph Alpha sich auf Deutsch und Englisch konzentriert, gibt es dieses Problem hier so nicht. Daher kann Kolibri englische und insbesondere deutsche Wörter mit weniger Token darstellen. Das ist nicht nur interessant, wenn man nach Token bezahlen muss, sondern auch in der internen Verarbeitung. Spart man 10 Prozent der Token ein, kann das die Verarbeitung nahezu genauso stark beschleunigen.

Kolibri-1 eignet sich auch besonders für rechtliche und politische Inhalte. Spaßeshalber kann man ausprobieren, wie viele Token es für das gesamte Glossar des Bundestags benötigt. Kolibri-1 benötigt dafür 1137 Token, das zum Vergleich hinzugezogene sehr innovative DeepSeek-V4.1-Flash braucht 1910 Token – was für ein Unterschied! Hier kann man also viele Token sparen und mit kürzeren Kontexten arbeiten. Außerdem kann die Verarbeitung damit schneller werden, weil viele Wörter nicht mehr aus ihren Bestandteilen zusammengesetzt werden müssen. Dies erhöht gleichzeitig die Präzision der Vorhersagen.

Ausgestattet mit diesem Tokenizer hat Aleph Alpha das Modell mit 20 Billionen Token im Pre-Training trainiert und dabei Inhalte bis zum 18. Juni 2026 genutzt. Das ist also sehr aktuell, denn das Basis-Training dauert üblicherweise viele Wochen oder Monate. Wie viele andere Anbieter verwendet auch Aleph Alpha Common-Crawl-Daten, beschreibt dafür aber sehr ausführlich einen Deduplikationsprozess, für den die Entwickler neben statischen Tests zusätzlich andere LLMs wie Gemma-4-26B-A4B verwenden. Um auf den im Tech Report genannten Anteil von 21,3 Prozent zu kommen, genügen die darin enthaltenen Daten allerdings nicht. Stattdessen haben die Entwickler ein weiteres Modell (Mistral-NeMo-12B) verwendet, um englische Inhalte auf Deutsch neu formulieren zu lassen. Zusätzlich kamen auch übersetzte Daten zum Einsatz, die man teilweise manuell kuratiert hat, um bei der Übersetzung nicht zu wörtlich zu bleiben.

Viel Aufwand widmet Aleph Alpha der Qualitätssicherung, in der andere Modelle als „Judge“ zum Einsatz kommen. Damit und mithilfe daraus berechneter Korrelationen kann man besonders „gute“ Dokumente identifizieren, die anschließend in einen „Data-Mix“ kommen. Dabei erhalten unterschiedliche Quellen verschieden hohe Gewichte, die mit der Güte ihrer Dokumente zusammenhängen.

Diese eigene Datenpipeline erlaubt es dem Anbieter, später neuere Daten leichter über den Trainingsprozess in künftige Modellversionen zu integrieren.

Im sich anschließenden sogenannten Mid-Training verwendet Aleph Alpha 3,4 Billionen Token „höherwertiger“ Inhalte, darunter logische Schlussfolgerungen, mathematische Dokumente und Programmcode. Im Mid-Training verlängert sich der Kontext von 16K auf 64K, um in der letzten Pre-Training-Phase schließlich 256K zu erreichen. Das spart erhebliche Rechenkapazität in den aufwendigen ersten Trainingsphasen. Auch im Mid-Training nutzt Kolibri-1 Daten aus der Pipeline, die je nach Qualität gemischt werden. Dabei verwenden die Entwickler jeweils eine Variante von DeepSeeks Auxiliary Free Load Balancing, die sie Exact Quantile Balancing nennen, um alle Experten „gleichmäßig“ zu trainieren. Aleph Alpha nutzt daneben noch die sogenannte Load-Error Injection, um auch in den Micro-Batches alle Experten zu berücksichtigen. Unterschiedliche Weiterentwicklungen dieser „Balancier“-Methoden haben sich nun bei fast allen Anbietern durchgesetzt, insbesondere wenn sie viele Experten nutzen.

Im Post-Training muss das Modell lernen, Fragen richtig zu beantworten. Auch dafür verwenden die Entwickler deutsche und englische Daten aus unterschiedlichen Bereichen wie Toolnutzung, Instruction Following und Code. Auch diese Daten sind zum Teil von anderen Modellen generiert, nämlich von GLM-5.2, GLM-5.3 und Qwen3.8-27B. Letzteres erstaunt, denn das Modell steht erst seit Ende August zur Verfügung. Aleph Alpha bringt dem Modell bei, seine Denktiefe zu steuern und seine Gedankengänge auf Deutsch zu formulieren. In letzterem Punkt unterscheidet es sich damit von fast allen anderen verfügbaren Modellen, die immer Englisch denken. Eine weitere Besonderheit ist das Merlin-Arthur-Protokoll. Damit versucht man, dem Modell Halluzinationen abzutrainieren. Es funktioniert wie ein Spiel, bei dem man relevante und irrelevante Teile der Antwort verdeckt. Das Modell muss dann ohne dieses Wissen entscheiden, welche Antwort besser passt, und erhält für die richtige Wahl eine Belohnung. Offenbar zeigt das Verfahren Wirkung, denn in den Benchmarks kann man erkennen, dass das Modell spürbar seltener halluziniert.

Bei allen Trainingsdaten achtet Aleph Alpha darauf, den EU AI Act und die DSGVO einzuhalten. Außerdem passt der Anbieter das Modell auf den „demokratischen Konsens“ in Europa an. Man könnte die Formulierung so verstehen, dass es auch Antworten gibt, die chinesischen Modellen aus politischen Gründen nicht erlaubt sind.

Natürlich ist der Trainingsprozess enorm aufwendig. Er verwendet dazu den Muon-Optimizer, um die Modellgewichte anzupassen, für die Skalierungsfaktoren und Gewichte der Embeddings ist weiterhin der allgegenwärtige AdamW-Optimizer zuständig.

Die dafür notwendige Infrastruktur ist gewaltig: Das Pre-Training fand auf 768 Nvidia-B200-GPUs über 96 Knoten statt, dafür fielen laut Modellkarte rund 392.000 GPU-Stunden an (also etwa 45 GPU-Jahre). Für das Reinforcement Learning im Post-Training setzte Aleph Alpha einen Cluster aus 256 Nvidia-B300-GPUs ein. Besonders interessant daran ist, dass 144 GPUs nur für die Inferenz zuständig waren. Das liegt vermutlich daran, dass das GRPO-Verfahren unterschiedliche Antworten benötigt, die es dann gegeneinander bewertet. Es handelt sich um eine beachtliche Leistung, das alles nach dem Knowledge-Cutoff Mitte Juni bis Ende September zu erledigen. Sicher gab es dazu Vorarbeiten: Aleph Alpha hat zuvor das Modell Kolibri Origin trainiert.

Um das Training reproduzierbar zu machen, arbeitet Aleph Alpha mit einer sogenannten ModelFactory. Das kann man sich als eine Art Rezept (in Form von Code) vorstellen, das das Training des Modells genau beschreibt. Diese Rezepte sind einer Versionskontrolle unterworfen, sodass sich das gesamte Training reproduzieren lässt. Dies setzt voraus, dass man über die nötige Infrastruktur verfügt und bereit ist, entsprechend viel Rechenzeit zu investieren. Energiekosten darf man dabei auch nicht vernachlässigen, Aleph Alpha schätzt 950 MWh, was bei einem kWh-Preis von 0,30 Euro (der für solche Großkunden sicher niedriger ist) 285.000 Euro entspricht.

Ausprobieren

Da das Modell mit offenen Gewichten bereitsteht, kann man es problemlos ausprobieren. vLLM unterstützt das Modell mit einem Plugin, auch für llama.cpp gibt es schon Unterstützung mit einem kleinen Patch.

Erwartungsgemäß funktioniert das Modell sehr schnell. Das liegt an den nur knapp vier Milliarden aktiven Parametern. Es spielt damit fast in der gleichen Geschwindigkeitsliga wie Qwen3.5-35B-A3B. Die Antworten des Modells sind alle richtig. Besonders auffällig ist der (antrainierte) deutsche Reasoning-Prozess. Die Antwort zur Waschanlage ist zwar etwas umständlich, bei vielen anderen Modellen liegt jedoch der Verdacht nahe, dass diese Frage bereits in der Trainingsmenge enthalten ist, wenn die Antwort sehr kurz und teilweise auch noch mit Emojis ironisch formuliert ist.

Alles in allem funktioniert das Modell sehr gut. Ob es Halluzinationen wirklich besser vermeiden kann als andere, muss sich im Praxisbetrieb noch zeigen. Auch mit Fragen wie „Organisierte der in Hannover ansässige Heise Verlag, der viel zu Computern schreibt, auch die Computermesse CeBIT?“ ließ sich das Modell nicht durcheinanderbringen, sondern antwortete richtig, dass die Deutsche Messe AG die CeBIT bis 2018 organisierte. Versucht man es umgekehrt mit „Welche Messen organisiert der Heise Verlag aus Hannover?“, erhält man die Antwort, dass das Modell keine Antwort wisse und man auf die Website schauen solle – nicht schlecht!

Fazit

Kolibri-1 ist ein wirklich solides Modell, das sehr gut Deutsch spricht und auch auf Deutsch argumentiert. Damit ist es für die vorgesehenen Anwendungsfälle in Unternehmen und Behörden prädestiniert. Technisch ist es dafür gut gerüstet, denn man kann es autark und souverän auf eigener Infrastruktur betreiben.

Sehr interessant liest sich der technische Bericht, der auch dort nicht mit Details spart, die andere gern auslassen. So erfährt man nicht nur vom Design des Tokenizers, sondern auch, wie die Trainingsmenge entstand, welche anderen Modelle dabei eine Rolle spielten und wie alles zusammenfloss. Deutlich kann man erkennen, wie viel Engineering da eingeflossen ist. Das tröstet etwas über die „altbackene“ Architektur hinweg.

Spannend ist auch die ModelFactory, die aus einfachen, lesbaren Code-Bausteinen die Modelle entstehen lässt. Ein Muster an Nachvollziehbarkeit, das ein DSGVO- und EU-AI-Act-kompatibles Modell auszeichnet.

(fo)

Die Schaltsekunde wird zum 20. Mai 2027 abgeschafft. Beschlossen hat dies am Donnerstag die Generalkonferenz für Maß und Gewicht in Paris. Bis Mai wird es auch keine Schaltsekunde mehr geben. Stattdessen sind nun Schaltstunden vorgesehen. Bis eine Schaltstunde erforderlich ist, wird geraume Zeit verstreichen, jedenfalls mehr als 1.000 Jahre. heise online wird berichten.

Schaltsekunden wurden 1972 eingeführt, um die mit Atomuhren exakt bestimmte koordinierte Weltzeit (UTC) mit der auf der nicht ganz so exakten getakteten Rotation der Erde basierenden Weltzeit (UT1) zu synchronisieren. Ab 0,9 Sekunden Differenz wurde dem 30. Juni oder 31. Dezember eine Sekunde (23:59:60) hinzugefügt. 27 mal war das der Fall, zuletzt Ende 2016.

Doch in den letzten Jahren hat sich der Trend umgekehrt: Ungefähr seit Beginn des Jahrzehnts dauert eine Erdrotation im Durchschnitt nicht mehr länger, sondern kürzer als 86.400 Atomsekunden. Mit der Zeit könnte das eine negative Schaltsekunde erfordern, auf die technische Systeme nicht vorbereitet sind. 2025 haben Experten haben die Wahrscheinlichkeit der Notwendigkeit einer negativen Schaltsekunde bis 2035 auf 30 Prozent taxiert.

3.599 Sekunden sind OK

Nicht zuletzt Technikbetreiber mit Einfluss haben sich daher für die generelle Abschaffung von Schaltsekunden eingesetzt, seien sie nun negativ oder positiv. Daher hat 2022 die 27. Generalkonferenz für Maß und Gewicht beschlossen, mit der Internationalen Fernmeldeunion und anderen Betroffenen darüber zu diskutieren, wie die zulässige Abweichung spätestens 2035 erhöht werden soll. Mindestens 100 Jahre sollten keine Maßnahmen notwendig sein; gedacht wurde insbesondere an Schaltminuten.

Die Konsultationen haben zu einer drastischeren Maßnahme geführt: UTC und UT1 dürfen in Zukunft bis zu eine ganze Stunde abweichen, wie nun bei der 28. Generalkonferenz für Maß und Gewicht bestimmt worden ist (Resolution 5). Erst ab 3.600 Sekunden Abweichung soll eine Schaltstunde wieder für Ordnung sorgen. Bis dahin dürften mehr als 1.000, vielleicht sogar 3.000 Jahre vergehen, schätzen Experten.

Argument stete Sommerzeit

Wesentliches Argument für die theoretische Schaltstunde statt vielleicht echter Schaltminuten ist, dass viele Länder bereits Zeitzonen haben, die mehr als eine Stunde von der wahren Sonnenzeit abweichen. Der jüngste Trend zu ganzjährigen Sommerzeitzonen hat diese Fehler noch verstärkt. Da kommt es auf die Schwankung der Erdrotation auch nicht mehr an.

Außerdem haben verschiedene technische Systeme die bisherigen Schaltsekunden unterschiedlich umgesetzt. Beispielsweise ignorieren die Uhren in GPS-Satelliten Schaltsekunden und sind daher der UTC 18 Sekunden voraus. GLONASS hingegen übernimmt Schaltsekunden direkt in seine Zeitgeber.

Fortan sollen sich Programmierer darüber nicht mehr den Kopf zerbrechen müssen. Falsche Schaltsekundenbefehle gehören damit hoffentlich der Vergangenheit an.

(ds)