Vom 24. bis 26. März 2026 war Amsterdam zum zweiten Mal das Zentrum des (europäischen) Cloud-Native-Universums. Über 13.000 Teilnehmende hatten sich nach offizieller Verlautbarung der CNCF auf den Weg zur KubeCon EU in die niederländische Metropole gemacht, um die neuesten Infos von Kubernetes und Co. zu erfahren. Der erste Tag war – wenig überraschend – dem Thema KI gewidmet.

Im Frühjahr 2026 kann man keine Open-Source-Konferenz in Europa ausrichten, ohne das Thema (Daten-)Souveränität deutlich anzusprechen. In diesem Punkt hat die KubeCon EU jedoch Potenzial verspielt. Es gab im Vorfeld lediglich eine kleine Satelliten-Veranstaltung zu dem Thema. Zwar stellten europäische Kubernetes-Anwender wie der IT-Dienstleister der Bundeswehr BWI oder die französische Eisenbahngesellschaft SNCF ihre Cloud-Native-Reise auf der großen Hauptbühne vor, es bleibt aber der Eindruck einer eher stiefmütterlichen Behandlung des Themas zurück. Die Thesen: „Global zusammenarbeiten und lokal installieren“ und „You can always fork“ sind nur bedingt hilfreich.

Neue Laufzeiten und Plattformen: Lima, urunc und die BSD-Welt

Obwohl Kubernetes bereits 12 Jahre existiert und sich zu einem Standard gemausert hat, sind noch wichtige Arbeiten an fundamentalen Bauteilen notwendig. Technisch ist die Container-Orchestrierung zu weiten Teilen mit Linux verknüpft. Das betrifft sowohl die darunterliegende Infrastruktur als auch die Applikationen in den Containern. Bei Letzteren gibt es gute Neuigkeiten für die BSD-Freunde und auch für macOS-Anwender: das Projekt Lima (Linux Machines). Dieses ist schon seit 2022 Teil der CNCF-Familie. Das ursprüngliche Ziel war eine bessere Unterstützung von Containern auf macOS-Rechnern. Inzwischen ist es unter anderem auch für Linux verfügbar und fokussiert sich auf leichtgewichtige virtuelle Maschinen.

Im Vorfeld der KubeCon EU 2026 ist Version 2.1 des Projekts erschienen, die nun auch macOS und FreeBSD als Gäste unterstützt. Das Feature ist allerdings noch im experimentellen Stadium. Anwender können mit Lima leichtgewichtige virtuelle Maschinen nutzen – vergleichbar mit Containern. Letztere und auch Kubernetes-Pods lassen sich ebenfalls mit Lima verwalten. In der Dokumentation finden sich Beispiele für K3s, k0s und RKE2. Alternativ gibt es aber noch weitere Projekte wie KubeVirt, die ebenfalls virtuelle Maschinen und Container gleichwertig behandeln.

Neuigkeiten wurden auch für OpenBSD verkündet. Das Projekt urunc liefert eine weitere Laufzeitumgebung für Container, die auf das Unikernel-Konzept zurückgreift. Daraus leitet sich auch der Name des Projekts ab. Das runc für Unikernels: urunc. Anstatt eines Prozesses in einem Container startet hier quasi ein kleiner Betriebssystemkern in abgeschotteter Umgebung. Das ist mit einer speziellen virtuellen Maschine vergleichbar und bereits von den Kata-Containern und Nabla bekannt. Das urunc-Projekt will einen speziellen Unikernel liefern, der mit BSD kompatibel ist. Dazu kommt ein minimalistisches Basissystem, um eine Anwendung ausführen zu können. Damit entfällt das Portieren von BSD-Anwendungen für Container. Sie müssen nicht mehr Linux-kompatibel sein. Es ist lediglich der Mehraufwand zum Verwalten der zusätzlichen Laufzeitumgebung urunc zu erbringen. Seit knapp einem Jahr ist das Projekt Teil der CNCF-Familie.

mTLS ohne Sidecars: Cilium integriert ztunnel

Ein wichtiges Thema im Netzwerkbereich der Container ist noch immer mTLS (mutual Transport Layer Security). Das Schlüsselwort dabei lautet CNI (Container Network Interface). Eine bekannte Größe hier ist Cilium. Das Projekt startete vor zehn Jahren und steht seit 2021 unter der Obhut der CNCF. Seit Version 1.19 beherrscht Cilium auch mTLS, und zwar ohne die Verwendung sogenannter Sidecars oder die Notwendigkeit zur Anpassung der Container-Anwendungen. Ein wesentlicher Baustein ist eBPF. Das Format erlaubt einerseits umfassende Einblicke in die Vorgänge in Containern und Pods, darüber hinaus lassen sich damit Sicherheitsrichtlinien implementieren und durchsetzen.

Der andere Baustein ist ztunnel, das man vom Service Mesh Istio kennt. Im sogenannten Ambient-Modus hat hier jeder Knoten einen kleinen Proxy, der sich um die TLS-Vorgänge kümmert. Diese in Rust geschriebene Komponente hat Cilium nun ebenfalls integriert. Damit ließen sich ein paar bekannte Probleme aus dem eBPF-Ansatz lösen. Die Authentisierung ist spezifisch für jede Sitzung und nicht nur per Knoten. Es gehen nun keine initialen Pakete beim Handschlag verloren. Außerdem steigt der Durchsatz insgesamt, da ztunnel größere Datenmengen zusammenfasst und verschlüsselt. Das Loslegen ist recht einfach und erfolgt in drei Schritten. Zunächst muss man das ztunnel-Feature in den Helm-Charts für Cilium einschalten. Danach gilt es den ztunnel auszurollen. Am Schluss muss man das Label io.cilium/mtls-enabled=true auf den entsprechenden Namensraum setzen. Alle Pods, die dann dort landen, verwenden automatisch mTLS.

Resümee und der Blick nach vorn

Nach drei Tagen KubeCon-Konferenz lässt sich festhalten, dass es zwar auch im 12. Jahr noch sehr viel Energie und Leidenschaft für Kubernetes und Co. gibt, allerdings auch noch recht grundlegende Probleme in verschiedenen Bereichen zu lösen sind – und das auch ganz ohne den KI-Hype.

Angesichts weiter wachsender Besucherzahlen muss die CNCF die Planung ihrer Hausmessen entsprechend langfristig vorbereiten: Die nächste KubeCon EU findet vom 15. bis 18. März 2027 in Barcelona statt. Auch der Termin für 2028 steht bereits fest: Berlin soll vom 24. bis 27. April zum Mittelpunkt des Cloud-Native-Universums werden.

(map)

Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps. Man kann ihr über die Kommandozeile zusätzliche Parameter mitgeben.

Die Übergabe der Parameter ist sowohl in Verbindung mit class Program und der Main()-Methode möglich als auch bei der Verwendung von Top-Level-Statements, da der Compiler diesen ebenfalls die Variable args zur Verfügung stellt.

Folgendes Codebeispiel zeigt ein erweitertes Hello World mit Parametern:

using System; // nicht notwendig, Standardnamensräume sind immer dabei, da enable gesetzt ist

var conf = args.FirstOrDefault() ?? "diesem Vortrag";
Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
Console.WriteLine($"Hallo liebe Teilnehmerinnen und Teilnehmer bei \e[4;33;5m{conf}\e[0m!");
Console.WriteLine($"Kompilierungsmodus: {(System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported ? "JIT" : "AOT")}");

(rme)

Google Research hat neue technische Details zu seinem Kompressionsalgorithmus TurboQuant veröffentlicht. Er solle den Key-Value-Cache großer Sprachmodelle auf bis zu 3 Bit pro Wert komprimieren – ohne messbare Einbußen bei der Modellgenauigkeit, teilten die Forscher mit. Auf Nvidia-H100-GPUs erreicht das Verfahren laut Google eine bis zu achtfache Beschleunigung bei der Berechnung von Attention-Logits gegenüber unquantisierten 32-Bit-Keys. Unquantisierte Key-Values sind in modernen Anwendungen jedoch normalerweise nicht anzutreffen. Viele Ansätze versuchen unter 4 Bit pro Wert zu erreichen, Google kombiniert für seine Herangehensweise die Verfahren PolarQuant und QJL.

Hintergrund

Der Key-Value-Cache, in dem Transformer-Modelle bereits berechnete Kontext-Informationen für den schnellen Zugriff zwischenspeichern, erfordert große Mengen Arbeitsspeicher. Bei langen Eingabesequenzen wächst dieser Cache stark an und wird zum Flaschenhals. Bisherige Vektorquantisierung lindert das zwar, erzeugt aber selbst einen Speicher-Overhead: Für jeden kleinen Datenblock müssen Quantisierungskonstanten in voller Präzision gespeichert werden, was den Kompressionsgewinn um 1 bis 2 Bit pro Wert wieder schmälert. Dieses Problem soll TurboQuant mit der Kombination von PolarQuant und QJL TurboQuant beseitigen.

PolarQuant: Kompression über Polarkoordinaten

PolarQuant weicht vom üblichen Ansatz ab, Vektoren in kartesischen Koordinaten zu verarbeiten. Stattdessen rotiert das Verfahren die Datenvektoren zufällig und wandelt sie anschließend in Polarkoordinaten um. Die Daten werden also nicht mehr als Abstände entlang einzelner Achsen gespeichert, sondern als Kombination aus einem Radius, der die Signalstärke beschreibt, und Winkeln, die die Bedeutung kodieren. Da die entstehenden Winkelverteilungen stark konzentriert und vorhersagbar sind, entfällt der sonst nötige Normalisierungsschritt mitsamt seinem Speicher-Overhead. PolarQuant übernimmt in TurboQuant den Großteil der Kompressionsarbeit.

QJL: Fehlerkorrektur mit einem Bit

Die zweite Stufe adressiert den kleinen Restfehler, den PolarQuant hinterlässt. QJL (Quantized Johnson-Lindenstrauss) nutzt die in der theoretischen Informatik bekannte Johnson-Lindenstrauss-Transformation, um die verbleibenden hochdimensionalen Fehlerdaten auf ein einziges Vorzeichen-Bit pro Wert zu reduzieren. Die wesentlichen Abstände und Relationen zwischen den Datenpunkten bleiben dabei erhalten. QJL fungiert so als mathematische Fehlerkorrektur: Sie eliminiert systematische Verzerrungen in den Attention-Scores, ohne zusätzlichen Speicher-Overhead zu verursachen.

Vielversprechende Benchmarks

Google hat alle drei Algorithmen mit den Open-Source-Modellen Llama-3.1-8B-Instruct und Ministral-7B-Instruct auf gängigen Long-Context-Benchmarks getestet, darunter LongBench, Needle in a Haystack, ZeroSCROLLS, RULER und L-Eval. Die Ergebnisse: In den Needle-in-a-Haystack-Tests reduzierte TurboQuant den KV-Speicher laut Google um mindestens den Faktor 6; in den im ICLR-Paper gezeigten LongBench-Ergebnissen liegen die Kompressionsraten je nach Bitbreite darunter oder darüber. Dabei sollen die Modelle in den getesteten Aufgaben – Frage-Antwort-Szenarien, Code-Generierung und Zusammenfassungen – nicht an Qualität verloren haben. In den Needle-in-a-Haystack-Tests, bei denen ein Modell eine einzelne Information in großen Textmengen finden muss, erzielte TurboQuant über alle Benchmarks hinweg die gleiche Genauigkeit wie die Vollpräzisions-Basis (Score: 0,997).

Ein Training oder Feintuning der Modelle ist für den Einsatz von TurboQuant nicht erforderlich. Google vergleicht TurboQuant in der Vektorsuche mit Product Quantization (PQ) und RabitQ: Im Paper kritisieren die Autoren an PQ vor allem den datensatzabhängigen Trainingsaufwand und die Notwendigkeit großer Codebooks. An RaBitQ bemängelt Google die fehlende Vektorisierung, fehlende GPU-Unterstützung und zusätzliche Overheads.

Einsatz in Gemini und der Google-Suche

Google sieht die Hauptanwendung von TurboQuant in der Beseitigung von KV-Cache-Engpässen in Modellen wie Gemini. Darüber hinaus soll das Verfahren die semantische Vektorsuche beschleunigen, bei der nicht nach Schlüsselwörtern, sondern nach inhaltlicher Ähnlichkeit in Milliarden von Vektoren gesucht wird. Durch die geringe Speicheranforderung und den nahezu wegfallenden Preprocessing-Aufwand ließen sich große Vektorindizes deutlich effizienter aufbauen und abfragen.

TurboQuant wird auf der ICLR 2026 vorgestellt, PolarQuant und QJL auf der AISTATS 2026. Weitere Informationen finden sich im Google-Research-Blog.

(fo)