Canonical hat LXD 6.7 veröffentlicht: Die neue Version des Container- und VM-Managers erweitert den GPU-Support auf AMD-Hardware und bringt Verbesserungen für den Betrieb in Clustern.

Mit der neuen Version können Nutzer AMD-Grafikkarten an Container durchreichen. LXD unterstützt dazu das AMD Container Device Interface (CDI), das im Snap-Paket enthalten ist. Der Befehl lxc config device add gpu gputype=physical id=amd.com/gpu=0 bindet eine einzelne GPU ein, mit id=amd.com/gpu=all lassen sich alle verfügbaren AMD-Grafikkarten durchreichen. Das AMD CDI funktioniert analog zum bereits bekannten Nvidia Container Device Interface.

LXD 6.7 integriert QEMU 10.2 und die EDK2-Firmware 2025.02 – zuvor waren QEMU 8.2.2 und EDK2 2023.11 an Bord. Die aktualisierte Virtualisierungsschicht unterstützt dynamische MMIO-Window-Größen, was die Kompatibilität mit modernen Grafikkarten erhöht.

Für Prozessoren mit x86-64-v3-Befehlssatz können Admins nun optimierte Container-Images verwenden. Die als amd64v3 bezeichneten Varianten nutzen moderne CPU-Instruktionen wie AVX, AVX2, BMI1, BMI2 und FMA. Das steigert die Performance auf CPUs der letzten zehn Jahre, funktioniert aber nicht auf älteren Prozessoren. Ob ein System die Architekturvariante unterstützt, zeigt der Befehl ld.so --help | grep '\-v[0-9]' an.

Cluster-Recovery und Placement Groups

Für Cluster-Umgebungen führt LXD 6.7 einen Recovery-Mechanismus für Storage Pools ein. Die neue Option source.recover beim Erstellen von Storage Pools erlaubt es, existierende Pools zu scannen, ohne Daten zu modifizieren. Das erweitert das bereits vorhandene lxd recover-Kommando um Cluster-Funktionen und hilft beim Disaster Recovery.

Mit Placement Groups lässt sich die Verteilung von Instanzen in Clustern steuern. Die Funktion lässt sich auf zwei Wegen einsetzen: „spread“ verteilt Instanzen über verschiedene Cluster-Member (Hochverfügbarkeit), „compact“ gruppiert sie auf einem einzelnen Member (minimale Latenz). Admins können die Platzierung strikt erzwingen oder permissiv gestalten. Der Befehl lxc placement-group create my-pg policy=spread rigor=strict erzeugt eine solche Gruppe. Die LXD-Weboberfläche unterstützt die Konfiguration und Nutzung von Placement Groups.

Die API ermöglicht nun das erzwungene Löschen von Projekten und Instanzen – auch wenn diese noch laufen oder eingefroren sind. Der asynchrone DELETE-Befehl zeigt an, welche Entities betroffen sind. Diese Funktion ist nur vorwärtskompatibel.

Vereinfachter Zugang zur Weboberfläche

Der initiale Zugang zur LXD-Weboberfläche erfolgt nun über einen temporären Link mit Bearer-Token, der einen Tag gültig ist. Die Befehle lxd init oder lxd init --ui-initial-access-link generieren den Zugangslink. Nach dem ersten Login richtet man eine permanente Authentifizierung über Browser-Zertifikate mit Trust-Token oder über mTLS beziehungsweise OIDC ein. Browser warnen bei selbstsignierten Zertifikaten – was zumindest für lokale oder geschützte Installationen akzeptabel ist.

LXD 6.7 führt außerdem Bearer-Authentifizierung als neuen Identity-Typ ein. Der API-Endpoint /1.0/auth/identities/current zeigt für Bearer- und TLS-Identities das Ablaufdatum an. Die neue Authentifizierungsmethode orientiert sich an OAuth-Standards.

Bei der Abfrage des Instance-Status können Admins nun einzelne Felder abrufen. Der Parameter recursion in Kombination mit fields – etwa ?recursion=2;fields=state.disk – vermeidet teure Disk- oder Network-Abfragen und reduziert die Last auf dem System.

Die Weboberfläche hat diverse Verbesserungen erhalten: Konfiguration von Placement Groups, Netzwerkkonfiguration mit IP-Reservierung und ACLs, Cloud-init-Editor im Vollbildmodus, aussagekräftige Tooltipps für Cluster-Member und Netzwerke sowie eine Liste der Cluster-Member mit Speicherinformationen. Hinzu kommen lokale Peerings für OVN-Netzwerke, vereinheitlichte Fehlerbildschirme und die Option, Storage Volumes zwischen Cluster-Membern zu migrieren.

LXD 6.7 steht ab sofort im Snap-Kanal 6/candidate zur Verfügung und wird nächste Woche in 6/stable übernommen. Die Installation erfolgt mit snap install lxd --channel=6/stable. Unter macOS können Anwender brew install lxc nutzen, unter Windows choco install lxc. Weitere Details finden sich in der offiziellen Ankündigung.

(fo)

Burger King testet derzeit in rund 500 US-Filialen einen KI-Assistenten namens „Patty“ für Angestellte mit Headset. Das System unterstützt bei verschiedenen Aufgaben, ist aber auch darauf trainiert, Formulierungen wie „Willkommen bei Burger King“, „Bitte“ und „Danke“ zu erkennen, sagt Digitalchef Thibault Roux dem US-Techmagazin The Verge. Diese Daten fließen in eine Metrik, die Filialleitern Aufschluss darüber geben soll, wie ihr Standort in puncto „Freundlichkeit“ abschneidet.

In einem weiteren Interview beschwichtigt Roux: Die Daten würden anonymisiert und nicht zur Bewertung einzelner Mitarbeiter eingesetzt. Zudem werde „Patty“ den Beschäftigten nicht vorgeben, was oder wie sie etwas sagen sollen. Stattdessen erhielten Filialleiter aggregierte Werte, die sie für persönliche Coachinggespräche mit ihren Teams nutzen könnten, sagt Roux dem US-Wirtschaftsmagazin Fast Company.

Wie „Freundlichkeit“ genau berechnet wird, bleibt offen. Roux deutet jedoch an, dass das Unternehmen daran arbeitet, künftig nicht nur bestimmte Worte, sondern auch den Tonfall von Gesprächen zu erfassen.

Deutschland: Mitbestimmung und DSGVO als zentrale Hürden

Derzeit basiert „Patty“ auf einem angepassten KI-Modell von OpenAI. Laut Roux ist die Technologie jedoch so ausgelegt, dass sie künftig auch mit anderen Partnern wie Anthropic oder Google integriert werden könnte.

Neben der Freundlichkeitsanalyse erfüllt „Patty“ eine Reihe weiterer Funktionen. Mitarbeiter können per Headset Arbeitsanweisungen zu Rezepturen und Reinigungsprozessen abrufen, ohne Handbücher konsultieren zu müssen. Das System informiert Manager zudem automatisch über ausgefallene Geräte oder fehlende Zutaten und aktualisiert digitale Menüs, Kioske und Apps entsprechend. Erkennt die KI wiederkehrende Muster, kann sie proaktiv Hinweise an Verantwortliche senden.

Nach aktuellen Plänen soll das System bis Ende 2026 flächendeckend eingeführt werden. „Patty“ ist eine Kurzform von Patricia oder Patrick, bezeichnet im Englischen aber zugleich die Fleischscheibe im Burger.

In Deutschland wäre ein System, das den Wortlaut von Angestellten erfasst und auswertet, nur mit erheblichen Hürden umsetzbar. Als technische Einrichtung zur Leistungs- und Verhaltenskontrolle dürfte ein solches System ohne Zustimmung des Betriebsrats nicht eingeführt werden. Beim Einsatz von Künstlicher Intelligenz ist zudem die Hinzuziehung eines Sachverständigen gesetzlich vorgesehen. Zusätzlich wären die Vorgaben der DSGVO zu beachten, da Sprachaufzeichnungen personenbezogene Daten darstellen können.

(tobe)

Google hat mit Meta offenbar einen großen Fisch an Land gezogen, der die eigenen Tensor Processing Units (TPUs) kaufen und in Rechenzentren einsetzen will. TPU nennt Google seine KI-Beschleuniger, die als Alternative unter anderem zu Nvidias und AMDs GPUs dienen. Aktuell ist die Version TPU v7.

Laut The Information ist das Abkommen zwischen Google und Meta auf mehrere Jahre ausgelegt. Im Vergleich zu den Millionen von Beschleunigern, die Meta von AMD und Nvidia für Dutzende Milliarden US-Dollar kauft, geht es beim Google-Deal um deutlich kleinere Summen. Von mehreren Milliarden US-Dollar ist die Rede. Insbesondere der Preis pro Beschleuniger dürfte niedriger sein als bei der Konkurrenz.

Google bekommt so als Hardware-Zulieferer einen Fuß in die Tür. Angeblich will der Konzern künftig zehn Prozent von Nvidias Marktanteil abhaben. Das wären voriges Jahr rund 16 Milliarden US-Dollar gewesen, rein auf KI-Beschleuniger bezogen: Mit solchen machte Nvidia 162,4 Milliarden US-Dollar Jahresumsatz, mit Netzwerk-Hardware weitere 31,4 Milliarden, Tendenz weiter steigend.

Google-Joint-Ventures für mehr Verbreitung

Um die Verbreitung von TPUs voranzutreiben, will Google mit einem nicht genannten, großen Investor angeblich ein Joint-Venture gründen. Darüber könnte der Konzern die KI-Beschleuniger an weitere Betreiber von Rechenzentren leasen. Weitere Joint-Ventures mit anderen Investoren könnten folgen. Alternativ zum Leasing könnten diese Tochterunternehmen auch ganze Rechenzentren für Kunden betreiben.

Google muss derweil die Vermarktung der eigenen TPUs und den Einsatz von Nvidia-Hardware ausbalancieren. Mindestens für die Vermietung innerhalb der eigenen Cloud ist Google weiter auf Nvidias KI-Beschleuniger angewiesen, weil viele Kunden mit Nvidias Software arbeiten.

Nvidia-Chef Jensen Huang schließt laut The Information gezielt Abkommen ab, um vielversprechende Firmen an sich zu binden, darunter zuletzt Anthropic. Solche Tendenzen zeigten sich schon früher, etwa bei Nvidias Einstieg bei Groq, womit die Firma einem Deal zwischen OpenAI und Groq zuvorkam. Huang sei nur allzu bewusst, dass mit Gemini und Claude manche der besten KI-Modelle mit Google-Hardware trainiert wurden.

TPU v7 als Alternative

Googles TPU v7 ist auf dem Papier mit 4,6 FP8-Petaflops langsamer als Nvidias Blackwell Ultra (B300) mit 5 Pflops beziehungsweise 10 mit Sparsity (Wegfall von Nullen in den Matrizen). Auch die Speicherkapazität ist mit 192 statt 288 GByte HBM3e geringer.

Allerdings ist die TPU v7 mit geschätzt 1000 statt 1400 Watt sparsamer. Dafür setzt Google auf den modernen 3-Nanometer-Fertigungsprozess N3P vom Chipauftragsfertiger TSMC, während Nvidia auf den verbesserten 5-nm-Prozess 4NP zurückgreift. Effizienz entwickelt sich zur wichtigsten Metrik, da alle Hyperscaler bei der Stromzufuhr zu ihren Rechenzentren limitiert sind. Zudem wollen sich Hyperscaler offensichtlich nicht von Nvidia als alleinigen Zulieferer abhängig machen.

(mma)