Kategorie: Erklärer

Du stehst an der Gepäckausgabe am Flughafen. Dein Koffer kommt auf dem Band, du greifst zu – aber zwischen deinem Koffer und dem nächsten liegen immer zwei andere Koffer. Du wartest jedes Mal, bis die anderen vorbeigezogen sind. Wären alle Koffer eines Typs direkt hintereinander, könntest du sie viel schneller einsammeln. Genauso arbeitet der Speicher deines Computers – und viele Entwickler ignorieren das, bis die Performance plötzlich einbricht.

Ein erfahrener Java-Entwickler hat sich dieses Phänomen genauer angesehen. Er berichtet von seiner Arbeit mit großen Klassen und vielen Attributen. Normalerweise denkt man bei Performance an Algorithmen und deren Komplexitätsklassen – O(n), O(log n) und so weiter. Doch selbst bei einem einfachen linearen Durchlauf (O(n)) können die Laufzeiten dramatisch variieren. Der Grund liegt tiefer: im Zusammenspiel zwischen CPU-Caches und der Anordnung der Daten im Arbeitsspeicher.

Wie der Computer seine Daten organisiert

Die CPU hat mehrere Cache-Ebenen: L1, L2 und L3. L1 ist klein und extrem schnell, L3 größer und langsamer. Das Betriebssystem teilt den Arbeitsspeicher in Seiten (Pages) ein, und die Hardware lädt Daten in sogenannten Cache-Lines. Eine Cache-Line ist typischerweise 64 Bytes groß. Wenn du auch nur ein einziges Byte aus dem Speicher anforderst, lädt die CPU gleich die gesamte Umgebung – 64 Bytes – in den Cache. Der Gedanke dahinter: Daten, die zeitlich oder räumlich nahe beieinander liegen, werden oft zusammen benötigt.

Der Entwickler hat auf seinem System die konkreten Werte ermittelt: L1d-Cache pro CPU-Kern etwa 35 KiB (nach Teilung durch die Anzahl der Instanzen), was 560 Cache-Lines entspricht. Diese Zahlen sind nicht nur Theorie – sie entscheiden darüber, wie schnell dein Programm läuft.

Array of Structs vs. Struct of Arrays – ein Beispiel

Angenommen, du modellierst ein Spiel mit Monstern. Jedes Monster hat einen Namen, eine Position, Lebenspunkte und einen booleschen Wert is_alive. In Java würdest du vermutlich eine Klasse Monster schreiben mit allen Feldern und dann ein Array von Monster-Objekten anlegen. Das nennt man Array of Structs (AoS). Jedes Objekt belegt im Speicher eine bestimmte Größe – sagen wir 64 Bytes. Wenn du jetzt alle Monster durchgehst und nur prüfen willst, ob sie noch leben, holst du trotzdem jedes Mal das gesamte Monster-Objekt in den Cache. Die Cache-Line wird mit den 64 Bytes eines Monsters gefüllt – und du nutzt nur ein einziges Byte daraus. Verschwendung.

Die Alternative: Lege die Daten spaltenweise an. Statt eines Arrays von Monstern hast du separate Arrays für jeden Feldtyp: ein boolean-Array für is_alive, ein float-Array für die x-Position, ein int-Array für Lebenspunkte. Das nennt sich Struct of Arrays (SoA). Nun liegen alle booleschen Werte hintereinander im Speicher. Eine Cache-Line fasst 64 boolesche Werte (1 Byte pro boolean in Java, wenn nicht optimiert). Du kannst also 64 Monster auf einmal auf ihren Lebensstatus prüfen, ohne unnötige Daten zu laden.

Der Entwickler hat einen Benchmark durchgeführt. Bei einer Monster-Struktur von 1 KiB Größe zeigte sich ein bis zu 30-facher Geschwindigkeitsvorteil für SoA. Bei kleineren Strukturen (z. B. 64 Bytes) ist der Unterschied geringer, weil mehrere Monster-Objekte noch in eine Cache-Line passen. Aber sobald die Struktur größer wird, explodiert der Performance-Unterschied. Die CPU kann die Daten viel effizienter vorausladen, wenn sie sequenziell angeordnet sind. Der sogenannte Prefetcher erkennt das Muster und holt die nächste Cache-Line, bevor du sie brauchst. Du wartest praktisch nie auf den Speicher.

Wenn der Zugriff zufällig wird

Nicht alle Programme durchlaufen Daten schön linear. Hash-Maps, Bäume, Graphen und viele andere Datenstrukturen springen wild im Speicher umher. Der CPU-Prefetcher kann dann nicht mehr vorhersagen, wo die nächste Anfrage hingeht. Jeder Zugriff wird zu einem Cache-Miss – die CPU muss auf den langsameren Hauptspeicher warten. Hier wird die Größe deiner gesamten Datenmenge zum entscheidenden Faktor: Passt sie in den L1-Cache, sind die Zugriffe blitzschnell. Für L2 dauert es länger, für L3 noch länger, und wenn du den Hauptspeicher brauchst, wird es richtig teuer.

Der Entwickler hat eine Pointer-Chasing-Benchmark gebaut: N Monster-ähnliche Knoten werden zufällig verlinkt, und dann wird der Kette gefolgt. Jeder Sprung trifft eine unvorhersehbare Adresse. Das Ergebnis: eine Treppenkurve, die zeigt, wie die Zugriffszeit in Stufen ansteigt, sobald die Datenmenge die nächste Cache-Grenze überschreitet. Die Tabelle im Originalartikel verdeutlicht das: Bei 512 Monstern mit je 64 Bytes (Arbeitsmenge 32 KiB) liegt die Latenz bei ~3 ns – alles in L1. Verdoppelst du die Strukturgröße auf 128 Bytes (64 KiB Arbeitsmenge), steigt die Latenz auf ~11 ns, weil die Daten bereits in L2 ausweichen. Bei großen Datenmengen (131.072 Monster, 8 MiB vs. 16 MiB) liegen die Latenzen bei über 160 ns. Das ist der Unterschied zwischen einem Wimpernschlag und einem spürbaren Warten.

Besonders bemerkenswert: Die Kurven für verschiedene Strukturgrößen zeigen das gleiche Treppenmuster, nur verschoben. Größere Strukturen treffen die Stufen früher. Das heißt: Wenn du die Kontrolle über die Gesamtgröße deines Working Sets behältst, kannst du die Performance massiv beeinflussen.

Was heißt das für dich?

Als Entwickler denkst du vielleicht zuerst an Algorithmen-Komplexität. Das ist wichtig, aber nicht alles. Der Weg zum Speicher ist oft der Flaschenhals. Wenn du eine Datenstruktur entwirfst, frage dich: Welche Felder werden gemeinsam genutzt? Wie groß ist mein Working Set? Passt es in den L1-Cache? Kann ich die Daten so anordnen, dass sie sequenziell gelesen werden? Besonders bei Java mit seinen Objekt-Overheads (Header, Padding) ist der Unterschied zwischen AoS und SoA eklatant. Moderne JVMs optimieren zwar, aber sie zaubern nicht – sie können keine Cache-Misses vermeiden, wenn die Daten falsch liegen.

Auch für KI- und Datenverarbeitungs-Pipelines ist das relevant. Viele Matrix-Operationen, Embedding-Lookups oder Graph-Traversals profitieren von cache-freundlichen Layouts. Das Wissen um Cache-Lines und Seiten ist keine Spielerei für Assembler-Programmierer – es ist ein Werkzeug für alle, die ernsthaft performante Software schreiben wollen.

Der Artikel des Entwicklers erinnert uns daran: Jedes Byte zählt. Nicht nur auf der Festplatte, sondern auch im Arbeitsspeicher. Die Hardware ist kein undurchschaubarer Kasten – sie folgt klaren Regeln. Wer sie versteht, kann aus demselben Algorithmus das Doppelte oder Dreifache an Leistung herausholen. Und manchmal reicht schon eine kleine Umstellung – von Array of Structs zu Struct of Arrays – um aus einer lahme Endlosschleife einen rasanten Durchlauf zu machen.

Quelle: fzakaria.com

Ein Architekt, der jahrelang Grundrisse von Hand zeichnete, bekommt plötzlich einen Assistenten, der in Minuten Baupläne entwirft. Softwareentwickler erleben Ähnliches mit Coding Agents. Ein erfahrener Open‑Source‑Entwickler hat seine Erfahrungen geteilt: Er schreibt kaum noch Code von Hand. Viele erleben diesen Wandel.

Seine Arbeitsweise hat sich fundamental verändert. Projekte wie Vite+ (Features in Rust, obwohl er die Sprache kaum beherrscht), fate 1.0 (Live Views, Drizzle‑ und GraphQL‑Support) und Codiff (eine schnelle Diff‑Review‑App) entstanden zu 90 % oder 100 % durch KI‑Codegenerierung. Für Athena Crisis, ein älteres, von Hand geschriebenes Spiel, ließ er die KI 70 Fehler beheben, Features implementieren und Tests schreiben – während er an anderen Projekten arbeitete. „Ich bin einfach nur erstaunt“, sagt er. Nie zuvor gab es eine solche Verbesserung der Entwicklererfahrung.

Wie der Workflow mit KI‑Agenten heute aussieht

Er nutzt die Codex CLI mit einem starken Modell (GPT‑Level). Er bevorzugt die Befehlszeile, weil sie mit einem leeren Blatt beginnt – keine alten Chats, keine Ablenkung. Sein Arbeitsplatz: ein Terminalfenster pro Projekt, links Codex, rechts die Konsole. So arbeitet er an drei bis sechs Projekten gleichzeitig. Der Flaschenhals ist nicht mehr das Schreiben von Code, sondern das Diskutieren und Reviewen der Ergebnisse. Er ordnet die Projekte räumlich auf einem großen Bildschirm: fate oben Mitte, void links, Athena Crisis rechts. Diese räumliche Zuordnung hilft beim Multitasking.

Seine Prompts sind knapp: „Ich will X bauen. Hol Kontext aus Y und Z, mach einen Vorschlag und frag mich, was noch unklar ist.“ Bevor der Agent startet, iteriert er mit ihm über den Plan. Bei Fehlerbehebungen schreibt der Agent zuerst einen Test, der den Fehler reproduziert. Das erhöht die Wahrscheinlichkeit, dass er das richtige Problem löst. Trotzdem: Die Modelle gehen oft in die falsche Richtung. Manchmal ist es besser, eine Sitzung abzubrechen und neu zu starten. Für größere Änderungen nutzt er /review-Zyklen. Sein Review‑Tool ist Codiff, das einen geführten Walkthrough der Änderungen liefert.

Die neuen Engineering Values

Der Autor leitet Werte ab, die für die Softwareentwicklung ab 2026 entscheidend sind. Die Art, Code zu produzieren, hat sich gewandelt, aber grundlegende Prinzipien bleiben – ihre Gewichtung verschiebt sich.

Starke Verantwortung

Gute Ingenieure zeichnen sich durch Domänenwissen und Eigentümerschaft aus. KI‑Agenten verstärken das: Wer sein Produkt kennt, liefert schneller. Wer keine Ahnung hat, erzeugt Lärm. Koordination wird teurer. Deshalb setzt er auf kleine Teams von zwei bis drei Personen mit klaren Zuständigkeiten und isolierten Repositories. Das tut weh, denn er war lange ein Verfechter von Monorepos. Starke Verantwortung bedeutet, Architektur, Anforderungen und langfristige Richtung zu verstehen, die Arbeit der Agenten zu reviewen und Entscheidungen zu treffen – manchmal direkt auf main zu pushen. Code‑Reviews in kleinen Teams dienen der Abstimmung, nicht dem Streit über Zeichensetzung.

Geschmack, Geschmack, Geschmack

Er hat eine geringe Toleranz für Bullshit – und mit Agenten könne jeder den ganzen Tag Bullshit produzieren. Sein Appell: „Hör einfach auf.“ Guter Geschmack bedeutet nicht nur, großartige Produkte zu bauen, sondern auch zu entscheiden, ob es sich lohnt, Zeit in etwas zu investieren. Sein Rat an Teams: Verbringt mehr Zeit damit herauszufinden, was die Zeit wirklich wert ist.

Strenge Leitplanken und schnelle Feedbackschleifen

Große Organisationen legen Code enge Beschränkungen auf, um Geschwindigkeit zu halten. Mit Coding Agents verhält es sich ähnlich: Jede Sitzung gleicht einem neuen Mitarbeiter ohne Kontext. Je mehr Regeln (Lint‑Regeln, automatisierte Tests, schnelle Verifikation), desto schneller iterieren Menschen und Agenten. Schnelle, skalierbare Werkzeuge sind wichtiger denn je. Enge Feedbackschleifen machen den Unterschied zwischen einer Minute und einer Stunde Bearbeitungszeit. Tools sollten nur geänderte Dateien prüfen und nicht mit der Codebasis wachsen.

Kontext im Repository

Kontext war bisher über viele Orte verteilt: Notion, Meetings, implizites Wissen, Commit‑Kommentare. Jede Agentensitzung ist wie ein neuer Mitarbeiter, der nicht an all diese Quellen herankommt. Die Lösung: den gesamten relevanten Kontext direkt im Repository ablegen – lokal, zugänglich für Agenten und Menschen. Das ist der Ort, um Geschmack, Werte und Denkweise zu injizieren. Agenten sollten keinen Schrott in die Codebasis spülen. Code wird noch stärker fürs Lesen optimiert: Weniger und einfacherer Code ist leichter zu verstehen und zu reparieren.

Den eigenen Stack besitzen

Früher bestand eine App zu 95 % aus Drittanbieter‑Abhängigkeiten. Externe Bibliotheken waren sinnvoll, weil eigenes Schreiben teuer war. Aber das machte abhängig von einem Stack ohne Kontrolle. Jede Abhängigkeit bringt Architektur, Einschränkungen und Entscheidungen mit. Agenten verschieben die Kosten: Sie machen es günstiger, eigene Lösungen zu bauen. Der Entwickler hat einen eigenen Open‑Source‑JavaScript‑Stack aufgebaut – für Daten, Internationalisierung, UI, Tool‑Konfigurationen. Das erlaubt ihm, neue Projekte schnell mit engen Vorgaben für Agenten zu starten und die volle Kontrolle zu behalten.

Was das für uns bedeutet

Der Autor weiß, dass dies nicht nur individuelle Arbeitsweisen betrifft, sondern ganze Organisationen umkrempelt. „Alle technischen Organisationen werden sich drastisch ändern müssen, wenn sie erfolgreich sein wollen.“ Wer heute noch in traditionellen Code‑Reviews und langen Genehmigungsprozessen denkt, verliert den Anschluss. Code und Programmierung werden nicht verschwinden. Englische Spezifikationen in Markdown sind eine furchtbare Programmiersprache – dynamischer Code mit Agenten erscheint sinnvoller.

Die Rolle des Ingenieurs verschiebt sich vom Code‑Schreiber zum System‑Dirigenten. Alte Werte wie Sorgfalt, Verantwortung und guter Geschmack bleiben zentral, müssen aber neu interpretiert werden. Statt selbst jede Zeile zu tippen, kuratierst du die Ausgabe von KI‑Assistenten. Statt jedes Detail zu wissen, musst du sicherstellen, dass die Leitplanken stimmen. Statt aufwändiger Koordinationsschleifen setzt du auf kleine, fokussierte Teams und klare Verantwortungen. Das passiert jetzt. Die Frage ist nicht, ob du mitziehst, sondern wie schnell du deine eigenen Engineering Values anpassen kannst.

Quelle: cpojer.net

Ein Klick auf einen präparierten Link in einem öffentlichen Repository kann innerhalb von Sekunden alle deine privaten Repositories kompromittieren. Ein Angreifer könnte Code lesen, ändern oder Push-Requests in deinem Namen ausführen. Das ermöglicht eine kürzlich entdeckte Sicherheitslücke in der browserbasierten Version von Visual Studio Code (VSCode), die der Sicherheitsforscher Ammar Askar veröffentlicht hat.

Was ist github.dev und warum ist es ein Ziel?

GitHub bietet mit github.dev eine praktische Funktion. Du kannst aus jedem Repository die URL von github.com auf github.dev ändern oder über das Menü auswählen. Du öffnest dann eine schlanke Version von VSCode im Browser. Diese Web-App kann auf alle Dateien des Repositories zugreifen – auch auf private – und ermöglicht Pull Requests, Commits und mehr. GitHub sendet ein OAuth-Token an github.dev, das dem Browser-Zugriff die vollen Rechte deines Kontos gibt. Dieses Token ist nicht auf das eine Repository beschränkt, sondern erlaubt Lese- und Schreibzugriff auf alle Repositories, auf die du Zugriff hast. Ein Angreifer, der an dieses Token gelangt, hat die Kontrolle über deine komplette GitHub-Präsenz. Die Schwachstelle setzt hier an.

Die Sicherheitsarchitektur von VSCode-Webviews

VSCode verwendet für die Darstellung von Inhalten wie Markdown-Vorschauen oder Jupyter-Notebooks sogenannte Webviews. Das sind Iframes mit einer eigenen Herkunft (vscode-webview://...), die vom Hauptfenster (vscode-file:// oder im Browser entsprechend) getrennt sind. So soll verhindert werden, dass schädlicher Code aus dem Webview auf die Node.js-APIs oder die VSCode-internen Funktionen zugreifen kann. Standardmäßig ist jede Kommunikation zwischen den beiden Fenstern nur über die window.postMessage()-API erlaubt. Das ist eine solide Maßnahme – wenn sie konsequent angewendet wird.

Der Fehler: Tastatureingaben werden ungefiltert weitergereicht

Es gibt eine Ausnahme für die Benutzererfahrung. Wenn du dich in einem Webview befindest und eine Tastenkombination wie Strg+Umschalt+P (Befehlspalette) drückst, erwartest du, dass die Aktion auch im Webview funktioniert. VSCode löst das, indem es standardmäßig einen Event-Handler namens did-keydown im Webview registriert. Dieser lauscht auf Tastatureingaben und leitet sie als Nachricht an das Hauptfenster weiter. Das Problem: Es gibt keine Prüfung, ob die Tastatureingaben tatsächlich vom Benutzer oder von einem Skript innerhalb des Webviews stammen. Ein Angreifer, der JavaScript im Webview ausführen kann – zum Beispiel über eine manipulierte Jupyter-Notebook-Zelle – kann also beliebige Tastatureingaben simulieren.

Der Angriffsablauf im Detail

Um die Lücke für eine Token-Exfiltration zu nutzen, mussten mehrere Hürden überwunden werden. Mit simulierten Tasten kann man die Befehlspalette öffnen und mit Pfeiltasten navigieren, aber Text lässt sich nicht eingeben – der Eingabefokus liegt auf einem HTML-Input-Element, das nicht auf programmatische Tastenevents reagiert. Also nutzt Askar einen anderen Trick: VSCode hat eine Standard-Tastenkombination Strg+Umschalt+A, die die primäre Schaltfläche einer Benachrichtigung bestätigt. Wenn das Webview eine Benachrichtigung auslöst, die zur Installation einer empfohlenen Erweiterung auffordert, kann der Angreifer diese mit Strg+Umschalt+A akzeptieren.

Die nächste Hürde: Seit VSCode 1.97 gibt es einen Vertrauensmechanismus für Verlage (Publisher). Bei der ersten Installation einer Erweiterung eines unbekannten Herausgebers erscheint ein Dialog, der die Zustimmung erfordert. Der Angreifer kann diesen Dialog nicht per Tastendruck bestätigen, weil die Schaltfläche „Publisher vertrauen & installieren“ nur auf direkte Klick-Events reagiert – nicht auf programmatische Tastatureingaben. Hier kommt eine andere VSCode-Funktion ins Spiel: lokale Arbeitsbereichserweiterungen. In einem vertrauenswürdigen Arbeitsbereich (github.dev-Arbeitsbereiche sind immer vertrauenswürdig) können Erweiterungen direkt aus dem Verzeichnis .vscode/extensions installiert werden, ohne den Publisher-Vertrauenscheck zu durchlaufen. Der Angreifer muss also lediglich eine eigene Erweiterung in das Repository des Opfers packen.

Ein weiteres Problem: Die Web-Version von VSCode erwartet Erweiterungen von vscode-cdn.net und schlägt bei lokalen Dateien eine Content Security Policy (CSP)-Verletzung. Askar umgeht das, indem er die Erweiterung so konfiguriert, dass sie selbst eine neue Tastenkombination (Strg+F1) definiert, die den Befehl workbench.extensions.installExtension aufruft – und diesen Befehl so parametrisiert, dass die Publisher-Prüfung übersprungen wird. Nachdem die lokale Erweiterung installiert ist und die neue Tastenkombination aktiv wird, simuliert das Angreifer-Skript ein weiteres Tastendruck-Ereignis für Strg+F1. Daraufhin wird die eigentliche bösartige Erweiterung installiert, die das OAuth-Token ausliest und an den Angreifer sendet.

Der Proof-of-Concept und was du tun kannst

Askar hat einen funktionierenden Proof-of-Concept veröffentlicht. Der Link führt direkt auf ein Jupyter-Notebook in github.dev. Nach einem Klick siehst du eine Statusmeldung, und innerhalb weniger Sekunden werden deine privaten Repositories und dein Token in einem Informationsfenster angezeigt. Wenn du den PoC selbst ausprobierst, solltest du anschließend die Erweiterung deinstallieren und die cookies/local storage von github.dev löschen, da die bösartige Erweiterung sonst auf allen github.dev-Seiten aktiv bleibt. Falls du noch nie github.dev genutzt hast, erscheint vor dem ersten Laden ein Anmeldedialog. Wenn du in diesem Moment den Link nicht klickst, sondern die Seite schließt, bist du sicher.

Was VSCode gut gemacht hat und was fehlt

Der Forscher meldete die Lücke verantwortungsvoll, und sie wurde innerhalb kurzer Zeit geschlossen. Die Version von github.dev erhielt einen Patch, der die Weitergabe von Tastatureingaben aus Webviews einschränkt. Die grundsätzliche Architektur bleibt anfällig, ähnliche Fehler könnten in Zukunft auftreten. Die Desktop-Version von VSCode ist ebenfalls betroffen, allerdings ist der Angriff dort schwieriger, da der Angreifer das Opfer erst dazu bringen muss, das Repository zu klonen und das Notebook zu öffnen.

Was das für dich bedeutet

Die Sicherheitslücke zeigt, wie ein kleiner Kompromiss bei der Benutzerfreundlichkeit schwerwiegende Konsequenzen haben kann. Sei vorsichtig mit Links, die dich auf github.dev öffnen, insbesondere wenn sie auf Jupyter-Notebooks oder andere interaktive Inhalte verweisen. Lösche regelmäßig die Browserdaten für github.dev, wenn du es nicht aktiv nutzt. Ein Klick kann ausreichen, um die Kontrolle über deine gesamte GitHub-Identität zu verlieren.

Quelle: blog.ammaraskar.com

Wenn ein Vermieter einen Generalschlüssel für jede Tür hätte, könnte er die Möbel umstellen oder den Strom abdrehen. Dieses Unbehagen verspüren viele europäische Organisationen bei US-Cloud-Anbietern. Die Sorge vor einem digitalen Kill Switch – dem Abschalten von Diensten durch US-Behörden – ist gewachsen. Die EU-Kommission hat nun Maßnahmen vorgestellt, die dieses Problem angehen sollen: Regulierung von Cloud-Diensten für den öffentlichen Sektor und Stärkung der heimischen Tech-Industrie.

Am 3. Juni 2026 veröffentlichte die EU-Kommission das „European Technological Sovereignty Package“ mit zwei Gesetzesvorschlägen: dem Cloud and AI Development Act (CAIDA) und dem überarbeiteten Chips Act 2.0, plus einer Open-Source-Strategie für den Energiesektor. Matthew Finnegan berichtet auf Computerworld darüber. US-Anbieter werden nicht verboten, aber öffentliche Auftraggeber müssen bei sensiblen Workloads bestimmte Kriterien beachten. Vizepräsidentin Henna Virkkunen: „Technologische Souveränität bedeutet nicht Protektionismus. Europa bleibt offen, partnerschaftlich und setzt auf fairen Wettbewerb.“ Ziel ist, Abhängigkeiten von einzelnen Anbietern zu vermeiden.

Ein Balanceakt zwischen Offenheit und Unabhängigkeit. Der CAIDA zielt darauf ab, die Rechenzentrumskapazität in der EU zu verdreifachen – in fünf bis sieben Jahren. Genehmigungsverfahren werden vereinfacht, Anreize geschaffen. Öffentliche Auftraggeber müssen in vier Stufen Souveränitätskriterien erfüllen. Stufe 1 verlangt nur Datenzentren in der Region – das erfüllen US-Anbieter bereits. Stufe 4 fordert vollständige Kontrolle über den Software-Stack, inklusive Cybersecurity-Zertifizierungen und Unabhängigkeit von der Eigentümerstruktur. Laut Finnegan fallen 70 Prozent der öffentlichen Workloads unter Stufe 1, 20 Prozent unter Stufe 2, 9 Prozent unter Stufe 3 und nur 1 Prozent unter Stufe 4. Die EU greift gezielt dort ein, wo die Risiken am größten sind.

Für private Unternehmen ändert sich vorerst nichts. Die Regulierung betrifft nur öffentliche Beschaffungen. Die Kriterien könnten aber als Standards dienen. Europäische Cloud-Anbieter könnten von den höheren Souveränitätsstufen profitieren. Der Chips Act 2.0 fördert die Halbleiterproduktion in Europa. Ziel ist eine widerstandsfähige Wertschöpfungskette von der Hardware bis zur Cloud-Infrastruktur.

Die Vorschläge müssen noch vom Europäischen Parlament und dem Rat der EU verhandelt werden. Die endgültigen Regeln könnten anders aussehen. Die EU will ihre technologische Souveränität stärken, ohne sich von der Welt abzukoppeln. Es ist ein vorsichtiger Schritt, kein radikaler Bruch. Für Tech-Anwender heißt das: Die Cloud-Landschaft in Europa wird sich verändern. Die Frage ist, wie schnell und ob der Preis in Form höherer Kosten oder geringerer Innovation zu hoch ist.

Quelle: computerworld.com

Sie wollen eine komplexe Aufgabe von einer KI erledigen lassen – Datenanalyse, Zusammenfassung eines langen Dokuments, kreative Schreibhilfe. Bisher brauchten Sie einen leistungsstarken Rechner mit teurer Grafikkarte oder mieteten überteuerte Cloud-Dienste. Die lokale KI-Nutzung war den meisten verwehrt, weil die Modelle zu groß und zu speicherhungrig waren. Google hat mit dem Gemma 4 12B ein Modell veröffentlicht, das dieses Problem elegant löst.

Das Modell zeichnet sich durch überraschende Effizienz aus. Viele große Sprachmodelle mit 70 Milliarden Parametern oder mehr laufen nur auf speziellen Servern. Der Gemma 4 12B kommt mit einem Bruchteil aus. Der Name verrät es: 12 Milliarden Parameter. Das ist kein Winzling, aber auch kein Monster. Google verspricht, dass das Modell auf jedem durchschnittlichen Laptop mit 16 Gigabyte RAM flüssig läuft. Ohne spezielle KI-Hardware. Das ist ein wichtiger Schritt zur Demokratisierung der KI.

Wie schafft Google das? Die technischen Tricks

Der Trick liegt in einer Kombination aus cleverem Encoding und smarter Vorhersage. KI-Modelle mussten bisher für jede Eingabe – Text, Bild oder Audio – einen eigenen, schwergewichtigen Kodierer durchlaufen. Das kostet Speicher und Zeit. Google hat beim Gemma 4 12B einen neuen Weg eingeschlagen. Für Bilder gibt es ein gestrafftes Embedding-Modul, das visuelle Informationen mit einer einzigen Matrixmultiplikation verarbeitet und direkt in den Sprachbereich überführt. Für Audiodaten wurde der Kodierer komplett gestrichen – das rohe Tonsignal wird direkt in die gleichen Vektoren projiziert wie für Text. Das spart Latenz und RAM.

Ein weiteres Highlight ist die Multi-Token Prediction (MTP). Die KI sagt nicht nur das nächste Wort vorher, sondern berechnet mehrere mögliche nächste Wörter parallel – in den Millisekunden, in denen sie auf die nächste Eingabe wartet. MTP nutzt ungenutzte Rechenzyklen, um mögliche Zukunftstoken zu berechnen und beschleunigt die gesamte Ausgabe. Google hat MTP optional auch für die größeren Gemma-Modelle verfügbar gemacht. Beim 12B gehört es ab Werk zur Grundausstattung.

Leistung im Vergleich: Fast so gut wie die Großen

Ein 12-Milliarden-Modell – wie gut ist es im Vergleich zu den großen Brüdern? Google hat Benchmarks veröffentlicht. Sie zeigen, dass der Gemma 4 12B in vielen Aufgaben fast das Niveau des 26-Milliarden-Mixture-of-Experts-Modells erreicht. Der Vorteil: Der Speicherbedarf des 12B ist nur halb so groß. Das ist Effizienz durch Architekturinnovation – mehr Leistung pro Byte RAM. Für komplexe, mehrschrittige Denkaufgaben und agentische Workflows, bei denen die KI nacheinander mehrere Tools ansteuert oder Entscheidungen trifft, reicht das 12B-Modell völlig aus.

Es geht nicht um reine Mathematik. Der Gemma 4 12B ist nativ multimodal – er kann Texte, Bilder und Audio als Eingabe verarbeiten. Das ermöglicht Anwendungen wie das Zusammenfassen eines Podcasts, das Erkennen von Objekten in einem Foto oder eine intelligente Konversation über mehrere Medien hinweg. Alles auf Ihrem Laptop, ohne Internetverbindung.

So nutzt du das Modell selbst

Der Gemma 4 12B ist einfach auszuprobieren. Google hat die Modellgewichte auf Kaggle und Hugging Face veröffentlicht. Die Datei ist knapp 18 Gigabyte groß – das passt auf jeden üblichen Laptop mit 16 GB RAM. Sie brauchen kein spezielles Setup. Tools wie LM Studio oder Google AI Edge Gallery laden das Modell und lassen es auf Ihrem Rechner laufen. Keine Cloud-Anmeldung, kein teurer KI-Chip nötig.

Die Bedienung ist simpel. Sie öffnen das Programm, laden die Gewichte, schon können Sie loslegen. Bitten Sie die KI, einen Geschäftsbrief zu entwerfen, eine E-Mail zusammenzufassen oder ein Rätsel zu lösen. Weil alles lokal läuft, bleiben Ihre Daten auf Ihrem Gerät – ein Vorteil für Datenschutz und Offline-Nutzung. Das unterscheidet den Gemma 4 12B von großen Cloud-KIs wie ChatGPT oder Gemini, bei denen Sie Ihre Daten an den Server senden müssen.

Was bedeutet das für die Zukunft der KI?

Googles Schritt mit dem Gemma 4 12B ist kein isolierter Trend. Immer mehr Unternehmen erkennen, dass nicht jedes Problem ein 100-Milliarden-Parameter-Modell braucht. Die Zukunft der KI liegt nicht nur in noch größeren Rechenzentren, sondern auch in kleinen, effizienten Modellen, die auf alltäglicher Hardware laufen. Das erinnert an die Entwicklung von PCs: Früher waren Computer riesige, klimatisierte Räume, heute hat jeder einen in der Tasche. Mit Modellen wie dem Gemma 4 12B kann die KI bald überall sein – in Ihrem Laptop, Ihrem Tablet, vielleicht sogar auf Ihrem Smartphone.

Der Gemma 4 12B ist ein Meilenstein für die lokale KI. Er zeigt, dass Sie keine High-End-Grafikkarte brauchen, um generative KI zu nutzen. Für Sie bedeutet das: Sie können KI dort einsetzen, wo es zählt – im täglichen Arbeitsablauf, ohne Kompromisse bei Geschwindigkeit oder Datenschutz. Laden Sie die Gewichte und legen Sie los.

Quelle: arstechnica.com