Generative KI braucht nicht nur gewaltige Datenmengen, sondern auch reichlich Strom. Je nach Energiequelle kommen dazu dann noch CO₂-Emissionen. Manche Branchengrößen wie der OpenAI-Chef Sam Altman sehen das überaus entspannt – laut ihm steht der Menschheit ab 2030 ohnehin unbegrenzt Energie zur Verfügung. Ein KI-nutzendes Unternehmen, das schon heute über seine Umweltbilanz Rechenschaft ablegen muss, kann sich aber schlecht auf solche Prophezeiungen berufen. Boris Ruf, Titelautor der neuen iX 7/2025, erklärt die Lage und worauf man achten kann.

KI gilt derzeit als die Zukunftstechnologie schlechthin. Setzen wir unsere Hoffnung damit auf einen stromfressenden Klimakiller?

Generative KI ist tatsächlich eine sehr energieintensive Technologie. Zum einen benötigt das Erstellen der KI-Modelle viel Rechenleistung, aber auch ihr Betrieb verbraucht große Mengen an Strom. Marktbeobachter wie die Internationale Energieagentur rechnen deshalb für diese Branche mit massiv steigendem Energiebedarf.

Die Umweltauswirkungen dieser Entwicklung hängen natürlich davon ab, wie der zusätzlich benötigte Strom gewonnen wird. Die großen IT-Konzerne unterstützen den Ausbau erneuerbarer Energien, indem sie in zahlreiche neue Energieprojekte in diesem Bereich investieren. Allerdings ist der Energiebedarf von Rechenzentren bereits heute hoch, und sie benötigen Versorgungssicherheit rund um die Uhr. Wind- und Sonnenenergie stehen jedoch nicht permanent zur Verfügung, und die Batterietechnologie ist noch nicht ausgereift genug, um entsprechende Flauten zu überbrücken. Es wird daher eine große Herausforderung sein, die Auswirkungen des KI-Booms auf die Umwelt so gering wie möglich zu halten.

Was hat den größeren Stromhunger und CO₂-Fußabdruck: Inferenz oder Modell-Training?

Anfangs lag der Fokus vor allem auf dem Training von KI-Modellen. Dafür werden gigantische Datenmengen über Wochen hinweg in Rechenclustern verarbeitet, was einen erheblichen Ressourcenaufwand erfordert.

Mittlerweile ist aber der Energiebedarf der KI während des Betriebs ins Zentrum gerückt. Bei jeder Anfrage an ein KI-Modell werden Milliarden an Parametern aktiviert. Im Vergleich zu einer klassischen Datenbankabfrage ist das ein sehr rechenintensiver Vorgang. Angesichts des hohen Anfragevolumens – nicht zuletzt aufgrund der zunehmenden Integration von KI in unterschiedlichste Prozesse – summiert sich der Energieaufwand beträchtlich.

Die großen Anbieter der proprietären KI-Modelle präsentieren sich ja eher als Blackbox, auch bei Fragen des Energieverbrauchs und der Umweltauswirkungen. Was soll man als Unternehmen machen, wenn man trotzdem Zahlen für sein Nachhaltigkeits-Reporting braucht? Und welche Tools gibt es für die quelloffenen Modelle?

Was den Energieverbrauch und die Emissionen von proprietären Modellen betrifft, ist die offizielle Datenlage tatsächlich leider sehr dünn. Trotzdem sollte man versuchen, die Umweltauswirkungen der eigenen KI-Projekte wenigstens zu überschlagen. Wir haben für diverse KI-Modelle entsprechende CO₂-Schätzungen modelliert und einen Online-Rechner zu diesem Thema veröffentlicht. Das Projekt EcoLogits stellt ebenfalls Tools zur Verfügung, mit denen sich der geschätzte CO₂-Fußabdruck proprietärer KI-Modelle loggen lässt.

Wer offene KI-Modelle nutzt, hat bei der Erfassung der Klimabilanz bessere Karten. Zum einen gibt es Benchmarks wie das Projekt AI Energy Score von Salesforce. Durch systematische Messung des jeweiligen Stromverbrauchs lassen sich hiermit eine Reihe frei verfügbarer KI-Modelle effektiv vergleichen. Läuft die KI in der eigenen Infrastruktur, kann man mit einem Tool wie CodeCarbon den Stromverbrauch sogar direkt selbst ermitteln.

Boris, vielen Dank für die Antworten! Einen Überblick zum KI-Energiehunger gibt es in der neuen iX. Außerdem zeigen wir, was der Einsatz großer KI-Modelle kostet und wie sich die CO₂-Bilanz von KI-Projekten ermitteln lässt. All das und viele weitere Themen finden Leser im Juli-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)

Angreifer attackieren mehrere Sicherheitslücken in freier Wildbahn, warnt die US-amerikanische IT-Sicherheitsbehörde CISA. Am gefährlichsten sind laufende Angriffe auf die Fernwartungsfirmware in AMI MegaRAC, die etwa in Servern von Asus, Asrock Rack, HPE oder Lenovo steckt. Zudem laufen Angriffe auf Sicherheitslecks in D-Links DIR-859-Routern sowie auf eine uralte FortiOS-Firmware-Hintertür.

In einer Sicherheitsmeldung warnt die CISA vor den laufenden Attacken und erklärt, sie dem „Known Exploited Vulnerabilities“-Katalog, kurz KEV, hinzugefügt zu haben. Für US-Behörden ist das ein Handlungsbefehl, aber auch für IT-Verantwortliche in Deutschland, Österreich und der Schweiz sollte das ein Weckruf sein, Gegenmaßnahmen wie Firmware- und Software-Updates auszuführen.

Angegriffene Fernwartungs-Firmware-Lücke

Die bereits attackierte Sicherheitslücke in der Fernwartungsfirmware AMI MegaRAC wurde Mitte März bekannt. Diese Firmware läuft auf Baseboard Management Controllern (BMCs) von Servern unter anderem von Asus, Asrock Rack, HPE und Lenovo. Sie hat den maximalen CVSS-Wert 10.0 von 10 erreicht, gilt daher als höchst kritisches Risiko. Sie steckt dort in einem Modul für die Fernwartungs-API Redfish und wurde daher als „Redfish Authentication Bypass“ bezeichnet: Es lässt sich die Anmeldung der Fernwartung umgehen (CVE-2024-54085 / EUVD-2024-54252, CVSS 10.0, Risiko „kritisch„). AMI hat den Serverherstellern Informationen und Patches bereitgestellt, diese mussten sie jedoch erst in ihre Firmwares einbauen und Admins die Aktualisierungen schließlich auch anwenden.

Das ist offenbar zumindest in Teilen nicht geschehen, sodass Server-Systeme mit AMI MegaRAC auch jetzt noch verwundbar sind. Möglicherweise haben Admins auch die „Best Practices“ ignoriert oder übersehen, dass die BIOS-Einstellungen die Fernwartung standardmäßig aktivieren und zugleich Zugriff über die für Nutzdaten gedachten Netzwerkbuchsen aktivieren, anstatt sie lediglich für ein separates Wartungsnetzwerk einzuschränken. Diese sind zudem in vielen Fällen sogar im Internet exponiert.

Außerdem steht eine Schwachstelle in den D-Link-Routern DIR-859 unter Beschuss, die der Hersteller abweichend vom CVSS-Wert Anfang 2024 als kritisch eingestuft hat (CVE-2024-0769 / EUVD-2024-16557, CVSS 5.3, Risiko „mittel„). Sicherheitslücken in diesen Routern wurden jedoch bereits Mitte 2023 attackiert, vom Mirai-Botnet. Erschreckende Erkenntnis: Bereits damals waren die Geräte am End-of-Life angelangt und sollten durch noch vom jeweiligen Hersteller unterstützte Hardware ersetzt werden. Offenbar setzen einige Organisationen sie aber immer noch ein.

Das können beobachtete Angriffe auf eine Fortinet-FortiOS-Schwachstelle aber noch übertreffen: Bereits seit 2019 war bekannt, dass ein hartkodierter kryptografischer Schlüssel sensible Daten in Konfigurations-Backups verschlüsselt, wodurch Angreifer diese leicht mit Kenntnis des Schlüssels entschlüsseln können – und dadurch an Nutzer-Passwörter (außer dem des Admins), Passphrasen für private Schlüssel sowie High-Availability-Passwörter gelangen (CVE-2019-6693 / EUVD-2019-16251, CVSS 6.5, Risiko „mittel„). Firmware-Updates, die das korrigieren, stehen seit November 2019 bereit.

Die CISA erläutert keine Details zu den Angriffen, etwa über Art und Umfang. Dennoch sollten IT-Verantwortliche prüfen, ob sie möglicherweise die nun attackierten Systeme in ihrer Organisation im Betrieb haben und gegebenenfalls Gegenmaßnahmen ergreifen.

(dmk)

Linus Torvalds hat durchblicken lassen, die experimentelle Unterstützung für das noch junge Dateisystem Bcachefs bei Linux 6.17 entfernen zu wollen. Ob es tatsächlich so kommt, bleibt noch abzuwarten; sicher ist aber, dass nach zahlreichen Reibereien mit dem Bcachefs-Entwickler Kent Overstreet jetzt eine neue, beim Linux-Kernel in der Form extrem seltene Eskalationsstufe erreicht wurde.

Neues Feature gegen den ausdrücklichen Willen von Torvalds

Der Linux-Erfinder und leitende Entwickler erwähnte die Intention zum Rauswurf in einer Antwort auf einen Merge Request von Overstreet für Linux 6.16. Diese Version befindet sich derzeit in der Stabilisierungsphase, in der Entwickler nur Fehlerkorrekturen und keine neuen Features zur Aufnahme an Torvalds einsenden sollen. Dennoch enthielten die von Overstreet eingereichten Änderungen neben Korrekturen auch Code, der eine neue und noch rudimentäre Mount-Option für Notfall-Reparaturen nachrüstet.

Torvalds hatte das schon eine Woche zuvor als neues Feature bezeichnet und die Aufnahme rigoros abgelehnt. Nach einer teilweise auf nicht-öffentlichen Mailinglisten geführten Diskussion zeigte sich Overstreet uneinsichtig und sandte den Code jetzt ein zweites Mal ein. Torvalds nahm ihn diesmal an, sagte dabei: Ich glaube, unsere Wege werden sich bei 6.17 trennen.

Wiederholte Schwierigkeiten

Sehr ähnliche Reibereien hatte es vor einigen Monaten schon mal zwischen Torvalds und Overstreet gegeben, wobei der Rauswurf damals noch nicht in Reichweite kam. Darüber hinaus war Overstreet schon zuvor mehrfach Entwickler aus anderen Bereichen des Kernels unschön oder gar rüpelhaft angegangen; dabei hatte er zahlreiche Leute verschreckt, die vorher gewillt waren, ihm zu helfen. In einem Fall beleidigte Overstreet jemanden so stark, dass er wegen Code-of-Conduct-Verletzung für einen Entwicklungszyklus suspendiert wurde – ein Novum. Auch im Umfeld der eigentlichen Bcachefs-Entwicklung kam es mehrfach zu Zank, durch die Mitentwickler das Handtuch warfen.

All das dürfte größere Unternehmen und Linux-Distributionen verschreckt haben, die vielleicht mit dem Einstieg in die Entwicklung und dem Einsatz von Bcachefs geliebäugelt haben. Aber es wurde mehr und mehr deutlich, dass hier eine kooperative Zusammenarbeit unmöglich ist – eben die, wie sie sonst beim Linux-Kernel üblich ist und ihn samt seines Dateisystemcodes oft erheblich verbessert hat. Wie überall im Leben kam und kommt es natürlich auch dabei immer wieder zu Meinungsverschiedenheiten sowie hin und wieder auch zu kleineren Machtspielen; diese waren aber längst nicht so krass und häufig wie bei Bcachefs.

Rauswurf wäre normalerweise nicht drin

Ein Entfernen eines Features wie Bcachefs liegt normalerweise gar nicht im Bereich des Denkbaren, denn „keine Rückschritte, die Workflows der Nutzer kaputt machen“ ist eine der wichtigsten Regeln bei der Entwicklung des Linux-Kernels. Im Fall von Bcachefs greift die aber nicht, denn der Anfang 2024 bei Linux 6.7 angenommene Code gilt als hochexperimentell.

(dmk)