Connect with us

Entwicklung & Code

AI für SRE: Warum Automatisierung das Ziel ist und KI nur ein Werkzeug


Das Schlagwort „AI SRE“ suggeriert, dass künstliche Intelligenz künftig die Menschen im Site Reliability Engineering ersetzt. Genau daran stört sich Severin Neumann, Head of Community bei Bronto und Mitglied des OpenTelemetry Governance Committee. In seinem Vortrag „AI für SRE richtig einsetzen: Von klassischer Automation bis LLMs“ bei der Mastering Observability im April 2026 plädiert er für eine andere Sichtweise: KI ist nicht das Ziel, sondern eines von vielen Werkzeugen, um Reliability-Arbeit schrittweise zu automatisieren.

Weiterlesen nach der Anzeige

Neumann bevorzugt daher die Formulierung „AI for SRE“ – also KI für SRE statt SRE. Die Unterscheidung ist mehr als Wortklauberei. Sie verweist darauf, dass Site Reliability Engineering weit mehr umfasst als die Reaktion auf Störungen. Zu SRE gehören Instrumentierung, Kapazitätsplanung, die Prävention von Vorfällen, in Code gegossene Resilienz durch Timeouts, Retries oder Circuit Breaker, Post-Mortems und kontinuierliche Verbesserung. Incident Response ist in dieser Lesart der letzte Ausweg, nicht der Kern der Disziplin.




Mehr zu SRE, Observability, aber auch zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim.

Jetzt Tickets zum Frühbucherpreis sichern.

Wichtig ist Neumann eine zweite Klarstellung: KI ist nicht gleich Large Language Model. LLMs seien nur eine Teilmenge dessen, was unter künstliche Intelligenz fällt – und sie bringen erhebliche Grenzen mit. Halluzinationen, fehlendes Kausalverständnis, begrenzte Kontextfenster, mangelndes Echtzeit-Bewusstsein, fehlende Reproduzierbarkeit von Antworten, die Abhängigkeit von der Prompt-Qualität und die hohen Kosten für Inferenz und GPU-Rechenzeit sprechen dagegen, LLMs als Universalwerkzeug für jedes Problem zu nutzen. Daneben stünden klassische Machine-Learning-Modelle für Anomalieerkennung, Trendanalyse und Forecasting sowie deterministische Automatisierung durch Regeln, Linter, Operatoren und Runbooks. Die Leitfrage laute deshalb nicht „Wo können wir ein LLM einsetzen?“, sondern „Welches Werkzeug passt hier?“.

Um diese Frage systematisch zu beantworten, entsteht innerhalb der CNCF TAG Operational Resilience ein Referenzmodell mit dem Titel „Levels of Service Reliability Automation“. In einem CNCF-Blog beschreibt Mario Fahlandt, ehemaliger Leiter der TAG, das Whitepaper als Versuch, operative Autonomie von reaktivem Firefighting bis hin zu selbstheilenden Systemen abzubilden. Das Framework soll Teams eine gemeinsame Landkarte an die Hand geben, die zeigt, wie Reliability-Arbeit über alle Domänen hinweg vom rein manuellen Vorgehen zu wachsender Autonomie fortschreiten kann.

Eine Matrix statt eines Organisationslevels

Das Modell ist als zweidimensionale Matrix aufgebaut. Die horizontale Achse beschreibt den Automatisierungsgrad in fünf Stufen: Manual, Automatic, Assisted, Guided und Autonomous. Auf der vertikalen Achse stehen die Reliability-Aktivitäten – Instrumentation, Reliability Implementation, Incident Prevention beziehungsweise Risk Prevention sowie Incident Response. In den einzelnen Zellen werden konkrete Werkzeuge, Anforderungen und Fähigkeiten je Aktivität und Level beschrieben.

Weiterlesen nach der Anzeige

Darin unterscheidet sich der Ansatz von klassischen Reifegradmodellen, wie sie aus SRE- oder Observability-Frameworks bekannt sind. Statt eine ganze Organisation einem Level wie „Initial“ oder „Optimizing“ zuzuordnen, kartiert das Modell jede Aktivität einzeln. Ein Team kann bei der Instrumentierung noch komplett manuell arbeiten, bei der Incident Response aber bereits auf der Stufe Guided sein. Das bildet die Praxis realistischer ab, weil Teams in verschiedenen Bereichen unterschiedlich weit sind. Der Fokus liegt dabei explizit auf operativer Autonomie – ähnlich den SAE-Levels des autonomen Fahrens, übertragen auf Reliability-Arbeit.

Am Beispiel der Instrumentierung wird die Spannweite deutlich. Auf der Stufe Manual binden Entwicklerinnen und Entwickler Telemetrie selbst über die OpenTelemetry-SDKs ein und annotieren Spans, Metriken und Logs von Hand. Automatic bedeutet automatische Injektoren über Agents oder Sidecars. Auf der Stufe Assisted schlagen Tools fehlende Spans oder Metriken vor, während der Mensch entscheidet. Guided umfasst KI-gestützte Skills, die während Code-Reviews auf fehlende Trace-Kontexte oder unvollständige Semantic Conventions hinweisen. Auf der Stufe Autonomous bringen Systeme Telemetrie selbstständig an oder ändern sie – etwa durch dynamische Instrumentierung anhand von Laufzeitsignalen.

Ähnlich verhält es sich bei der Reliability Implementation, also den Schutzmechanismen im Code. Manuell designen Entwicklerinnen jedes Timeout, jeden Retry und jeden Circuit Breaker selbst. Regelbasierte Linter prüfen automatisch, ob HTTP-Calls überhaupt ein Timeout besitzen. Service-Mesh-Sidecars erzwingen Standard-Patterns global per Policy. Auf höheren Stufen schlagen Tools Retry-Strategien anhand von Traffic-Analysen vor, und LLM-basierte Code-Reviews identifizieren fehlende Timeouts, unbehandelte Promise Rejections oder Retry-Schleifen ohne Jitter.

Prävention vor Reaktion – und die Sache mit dem Alert Noise

Zentral ist für Neumann die Trennung von Prävention und Reaktion. Prävention bedeutet, ein Risiko zu erkennen, bevor Nutzer betroffen sind; bei der Response sind sie es bereits. Den Beginn eines Vorfalls zu erkennen, sei schwer – das Risiko vorher zu erkennen, noch schwerer. Daraus folgt eine klare Ansage: Ohne funktionierende Risiko-Prävention könnten „AI SREs“ nur assistieren und begleiten, aber nie die höchste Automatisierungsstufe erreichen. Hohe Autonomie in der Incident Response ohne starke Prävention führe lediglich zu effizienterem, aber nicht nachhaltigeren KI-Firefighting.

Auf die Frage, ob es also gutes Alerting brauche, antwortet Neumann mit einem gedehnten „Ja – naja…“. Sein Kritikpunkt: Alerting werde oft mit Detection vermischt, sodass alles gemeldet wird, was erkannt wird. Das Ergebnis ist Alert Noise. LLMs als Alert-Prozessoren lösen dieses Problem nicht, sondern erhöhen die Komplexität – schon die Auswertung von viel Alert Noise ist teuer, und es stellt sich die Frage, welche Alerts überhaupt in den Prompt gelangen: alle, aggregierte oder gefilterte.

Neumann fordert stattdessen gute Telemetrie mit niedrigem Rauschanteil und fortgeschrittene ML-Methoden jenseits reiner LLMs für Detection und Klassifikation. Eine Schlüsselrolle spielen dabei Semantic Conventions, wie sie OpenTelemetry definiert: Einheitliche Daten senken die Verarbeitungskosten, verbessern die Signalqualität und erhöhen das Verständnis – für Menschen wie für KI-Systeme. Für eine autonome Incident Response und Prävention brauche es solide Telemetrie und gute Erkennung. Neumann lädt ausdrücklich zur Mitarbeit am CNCF-Whitepaper ein.

Wenn KI ohne Telemetrie mehr schadet als nützt

Wie berechtigt diese Vorsicht ist, zeigen typische Fehlerbilder aus dem AIOps-Umfeld. Ein häufiges Muster: Ein KI-basiertes Event-Correlation-Tool gruppiert Alerts nach Ähnlichkeit und unterdrückt vermeintliche Duplikate. Ist die Telemetrie uneinheitlich und die historische Alert-Historie mit False Positives durchsetzt, lernt das Modell, bestimmte Muster zu ignorieren. Beginnt ein neuer Vorfall mit einem ähnlichen Muster, werden relevante Alerts unterdrückt – die mittlere Reparaturzeit steigt, SLOs werden verletzt. Das Tool agierte dabei korrekt im Rahmen seiner Trainingsdaten; die Telemetrie war das Problem.

Ein zweites Muster betrifft automatische Mitigation. Deckt Telemetrie nur Teilsysteme ab, kann ein ML-gestützter Auto-Mitigation-Loop falsche Korrelationen ziehen, eine scheinbare Ursache identifizieren und aggressiv Traffic abziehen. War der betroffene Service nicht die eigentliche Ursache, erzeugt die Maßnahme zusätzliche Last andernorts und löst eine Kettenreaktion aus. Auch LLM-Co-Piloten im On-Call können trügerische Sicherheit vermitteln: Bei lückenhafter Telemetrie liefert das Modell eine plausible, aber falsche Erklärung samt Mitigationsvorschlag, dem Menschen folgen, weil er detailliert und smart wirkt. Das Problem ist selten die KI allein, sondern die Kombination aus schlechter Observability, fehlender Prävention und mangelnder Governance.

Der EU AI Act als Rahmen für autonome SRE-Tools

Wer KI-Komponenten in kritischer Infrastruktur einsetzt, muss den EU AI Act im Blick behalten. Er definiert Hochrisiko-KI-Systeme, unter die auch Bereiche kritischer Infrastruktur fallen. SRE- und Monitoring-Systeme, die autonom in die Funktionsfähigkeit etwa von Energie-, Verkehrs- oder Finanzmarkt-Infrastruktur eingreifen, können als Bestandteil eines solchen Hochrisiko-Systems gelten – die juristische Einordnung muss projektspezifisch erfolgen.

Besonders relevant ist Artikel 14 zur menschlichen Aufsicht: Hochrisiko-Systeme müssen so gestaltet sein, dass natürliche Personen sie wirksam überwachen und bei Bedarf eingreifen können. Menschen müssen die Kapazitäten und Grenzen des Systems verstehen, Anomalien und Fehlfunktionen erkennen und sich der Gefahr von Automation Bias bewusst sein. Für die Stufe Autonomous im Neumann-Modell bedeutet das: Es muss klar definiert sein, wer die Aufsicht führt, und es braucht Not-Aus-Mechanismen sowie Governance-Prozesse wie Rollback-Policies. LLM-Plattformen können zudem als General-Purpose AI mit systemischem Risiko gelten, was Risiko-Evaluation, adversariales Testen und die Meldung schwerwiegender Vorfälle an das EU AI Office nach sich zieht. In Deutschland kommen DSGVO sowie sektorspezifische Regulierung durch BaFin oder BNetzA hinzu.

Neumanns Fazit bleibt konsistent: Alle Tätigkeiten, die zur Reliability beitragen, müssen adressiert werden. Automatisierung ist das Ziel, KI nur ein Werkzeug. Ob eine autonome Stufe über LLMs, klassische ML-Modelle oder SLO-basierte Control-Loops erreicht wird, ist zweitrangig – entscheidend sind solide Telemetrie, saubere Prävention und eine klare Rollenverteilung zwischen Mensch und Maschine.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.

Mastering Observability 2026: AI für SRE richtig einsetzen: Von klassischer Automation bis LLMs (Severin Neumann)



Severin Neumann ist Head of Community bei Bronto. Er beschäftigt sich seit vielen Jahren mit Observability, verteilten Systemen und der Frage, wie Engineering-Teams komplexe Softwarelandschaften zuverlässig betreiben können. Severin ist Mitglied des OpenTelemetry Governance Committees sowie Co-Maintainer der OpenTelemetry-Dokumentation und engagiert sich aktiv in der Open-Source- und Cloud-Native-Community.


(map)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

AWS Emulator im Detail: Die ganze Cloud auf dem eigenen Rechner?


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Amazon Web Services (AWS) hat einen eigenen AWS Emulator veröffentlicht. Er bildet die AWS-APIs auf dem eigenen Rechner nach, AWS CLI, SDKs und Coding-Agenten schicken ihre Aufrufe an einen lokalen HTTPS-Endpunkt. Mit seinem Stolz darauf, dass der Emulator vollständig von KI-Agenten entwickelt wurde, setzte sich AWS aber direkt in die Nesseln: Die Rezeption fiel kritisch aus – wie bei hundertprozentig KI-generierter Software zurzeit üblich – und dem Vergleich mit etablierten Drittanbieter-Tools wie LocalStack hält der Emulator wohl noch nicht stand.

Weiterlesen nach der Anzeige

Entwickler könnte er dennoch interessieren: AWS-Anwendungen lassen sich ohne Deployment lokal testen, CI/CD-Pipelines brauchen keine AWS-Zugangsdaten mehr und – was AWS besonders unterstreicht – Coding-Agenten können schneller und risikoärmer Ressourcen anlegen und Ergebnisse prüfen. AWS bringt also agentisch entwickelte Software für die Entwicklung mit Agenten. Es fällt keine Servicegebühr an, ein AWS-Konto braucht es nicht und der Quellcode steht unter der CC0-Lizenz auf GitHub.

iX-plore ist die Online-Serie des iX-Magazins für alle, die neue Tools und Technologien entdecken möchten. In kurzen Beiträgen stellen wir vor, was sie können, wofür sie sich eignen und warum sich ein genauerer Blick lohnen könnte.

Realismus dank Fidelity-Tests

Der Emulator ist in Rust geschrieben, die Dienste erzeugt AWS aus denselben API-Modellen, aus denen auch die SDKs entstehen. Kommt ein Dienst oder eine API hinzu, tauchen sie im Emulator auf. Alle Dienste, für die ein Modell im öffentlichen Repository AWS API Models liegt, werden auch unterstützt.

Wie genau der Emulator AWS nachbildet, misst AWS mit Fidelity-Tests. Jeder Test ist ein kurzes Python-Programm, das über das AWS-SDK boto3 einen Ablauf durchspielt, etwa ein Objekt zu speichern, zu lesen und wieder zu löschen. Die Abläufe werden dann gegen die echte Cloud geprüft, als Referenz dient die Region US West (Oregon), während globale Dienste in US East (N. Virginia) geprüft werden. Der Emulator besteht einen Test nur, wenn bei jedem Aufruf Statuscode, Antwort, Fehlercode und Fehlermeldung mit der Cloud übereinstimmen, dasselbe gilt für die Ressourcen und Daten, die der Ablauf erzeugt. Die Testsuite umfasst Zehntausende Tests, ist öffentlich und enthält auch die, die noch scheitern. Mit dem Python-Programm fidelity_tests_runner können Nutzer die Tests lokal gegen den Emulator laufen lassen.

Trotz der hohen API-Abdeckung hat die Emulation aber bewusste Grenzen: Für Sicherheitstests eignet sich das Tool laut AWS nicht, da es weder IAM- noch ressourcenbasierte Richtlinien wie die echte Cloud auswertet. Auch Cross-Account- und Cross-Region-Szenarien bildet es nicht ab, sämtliche Aufrufe laufen unter einer festen Dummy-Konto-ID.

Jede Instanz des Emulators bekommt einen eigenen Port, eigene Schlüssel und einen eigenen Zustand im Arbeitsspeicher. Mehrere Agenten oder CI-Jobs teilen sich also keine Buckets, Tabellen oder Queues und arbeiten parallel, ohne sich gegenseitig Ressourcen zu überschreiben. Nutzer des AWS SDK for Rust können den Emulator außerdem im Embedded-Modus betreiben, wobei er direkt ins Test-Binary kompiliert wird. Er läuft dann im selben Prozess und der Test übergibt dem SDK einen HTTP-Client des Emulators statt des Netzwerk-Connectors. Auch hier sind die Instanzen voneinander isoliert, sodass Tests parallel laufen können.

Weiterlesen nach der Anzeige

Installation und Betrieb

Coding-Agenten können den Emulator mit dem Skill aws-emulator direkt installieren, starten und verbinden, dafür braucht es allerdings die AWS CLI ab Version 2.35.0. Solche Skills sind im Prinzip Markdown-Anleitungen, die der Agent bei Bedarf lädt. Der Befehl aws agent-toolkit add-skill in der AWS CLI installiert sie für alle Agenten, die es auf dem Rechner findet. Unter Linux gibt es RPM- und Debian-Pakete, unter Windows und macOS einen Docker-Container. Ein fertiges Docker-Image gibt es nicht, das müssen Nutzer aus einem kurzen Dockerfile aus der Dokumentation zusammenbauen. Standardmäßig sendet der Emulator anonymisierte Nutzungsdaten an AWS, was sich jedoch per Start-Flag oder Umgebungsvariable abschalten lässt.

Wer den Emulator selbst kompiliert, braucht Linux auf x86_64 oder aarch64, eine Rust-Toolchain, einen C-Compiler und mindestens 100 GByte freien Speicherplatz für die Build-Artefakte. Jeder emulierte Dienst ist ein eigenes Rust-Paket (Crate), weshalb schon ein Debug-Build sehr groß wird. Das gilt auch für den Embedded-Modus, denn der erste cargo test-Lauf kompiliert sämtliche Service-Crates des Emulators mit. AWS empfiehlt, das Build-Verzeichnis in der CI zu cachen und den Emulator auf einen Release-Commit festzulegen.

„Vibecode“ von AWS?

Matthew Goldberg, Senior Principal Engineer im Developer-Tools-Team von AWS, setzt mit dem Emulator eine KI-Duftnote: Nicht nur ist die Software vor allem auf das schnelle Testen von agentischer KI zugeschnitten, sondern sie ist laut Amazons Firmenblog auch ausschließlich von autonomen Agenten geschrieben. Das Team hat den Code weder verfasst noch geprüft. Goldberg beschreibt, wie ihn der autonome Bau eines C-Compilers von Agenten dazu inspirierte und der Emulator aus einem simplen Wochenendprojekt hervorging. Ein Team von Agenten pflegt die Testsuite, ein zweites sucht Abweichungen von der echten Cloud, ein drittes setzt die Korrekturen um. Jede Änderung muss zudem vor dem Merge ein automatisiertes Quality Gate passieren, an dem weitere Agenten unter anderem die Sicherheit des Codes kontrollieren.

Die autonome Entwicklung lässt sich in den Repository-Verzeichnissen issues/things-that-now-work und issues/things-that-do-not-work nachvollziehen, in die die Agenten hineinschreiben. Menschliche Hilfe von außen ist dabei nicht vorgesehen: Zwar können Nutzer auf GitHub Fehler melden, Pull-Requests nimmt AWS für das Projekt aber nicht an. Ganz unabhängig von dem Tool an sich ist hier also anschaulich zu sehen, in welche Richtung Softwareentwicklung gerade steuert – und wie die großen Systemhäuser versuchen, Vibe-Coding sinnvoll anzugehen.


(kki)



Source link

Weiterlesen

Entwicklung & Code

Gestohlene Token: Secret-Stealer in Tausenden GitHub-Repositories


Mit gestohlenen Zugriffstoken für GitHub-Konten schleusen unbekannte Angreifer seit Dienstag Schadcode in Repositories ein, der die Secrets aus GitHub Actions und Cloudzugangsdaten abgreift.

Weiterlesen nach der Anzeige

Das Sicherheitsunternehmen Aikido zählt im Rahmen der auf den Namen wfx-loot getauften Kampagne bereits 4837 übernommene Konten, über die die Angreifer 61.764 Repositories attackiert haben. In mehr als 1800 Fällen sollen Workflows den Schadcode bereits ausgeführt haben.

Die Angreifer nutzen anscheinend keine Lücke in GitHub Actions aus, sondern missbrauchen die Schreibrechte gestohlener Token. Woher diese stammen, ist nur teilweise geklärt. Laut Fly.io wurden Token seiner GitHub-App missbraucht, die aus öffentlich erreichbaren .git/config-Dateien stammten; der Hoster widerruft sie. Eine Stellungnahme von GitHub liegt noch nicht vor.

Das Sicherheitsunternehmen SafeDep hat Schadcode-Commits bereits in über 8000 öffentlichen Repositories gefunden. Noch am Donnerstagmittag listete die GitHub-Suche mehr als 66.000 der typischen Test-Pull-Requests, rund 4300 davon vom selben Tag.

Ähnlich wie zuletzt beim Wurm testmetest erreichen Angreifer laut Aikido über Mitwirkenden- und Organisationsrechte mit über 10.000 Test-Pull-Requests auch Repositories, die den übernommenen Konten nicht selbst gehören. Damit können auch Organisationen betroffen sein, deren eigene Zugangsdaten gar nicht gestohlen wurden. Dürfen die Workflows eines Repositorys auf AWS oder Azure zugreifen, nutzt der Schadcode die erbeuteten Zugänge, um Hintertüren in den Cloudkonten einzurichten.

Spuren oft binnen einer Minute verwischt

Die Angreifer lassen ihren Opfern kaum Zeit zu reagieren. Sie öffnen zunächst einen Pull Request, um die Schreibrechte zu bestätigen. Dann folgt der eigentliche Schadcode: ein Shellskript, das die Angreifer in einen bestehenden Workflow einfügen, als neuen Workflow ablegen oder in npm-Projekten bei jeder Installation starten lassen.

Meist schon innerhalb einer Minute machen die Angreifer die Änderungen rückgängig und löschen den Workflow-Lauf samt Logs. Oft weist nur eine fehlende Laufnummer auf den Angriff hin. Eine Branch-Protection für vorgeschriebene Status-Checks kann das Skript mit gefälschten Erfolgsmeldungen aushebeln. Aikido zufolge setzt das Skript solche gefälschten Status-Checks tatsächlich ab; in den von SafeDep untersuchten Proben war diese Funktion dagegen nicht aktiviert.


Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.

Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.

Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.

(Bild: SafeDep)

Neben Token für KI-Dienste wie OpenAI, Anthropic oder Cursor fischt das eingeschleuste Skript insbesondere die Secrets aus GitHub Actions ab, außerdem Zugangsdaten für Clouddienste, Container-Umgebungen, Paketregister und SSH.

Weiterlesen nach der Anzeige

Haben die Bedrohungsakteure erst einmal Zugang zu Sitzungen bei AWS, Google Cloud und Azure, geht der Angriff weiter: Bei AWS öffnet das Skript eine IAM-Rolle für jedes AWS-Konto, in Azure trägt es zusätzliche Anmeldewege für Workflows aus dem kompromittierten Repository ein. Erbeutete Daten schickte das Skript laut Aikido in dieser Kampagne per HTTP an Server der Angreifer. SafeDep fand in untersuchten Payloads zudem eine Exfiltration über Telegram.

Selbsttest: Ein Pull Request verrät das gekaperte Konto

Entwicklerinnen und Entwickler, die seit Dienstag einen Branch wfx-docs, den Pull-Request docs: dependency audit notes oder Commits wie ci: refresh build cache, chore: add ci helper und chore: add dependency audit workflow in ihren Repositories finden, sollten das zugehörige Konto als kompromittiert ansehen, auch wenn noch kein Schadcode folgte. Verdächtig sind laut den Sicherheitsforschern von Aikido zudem kurzlebige Branches, die mit chore/ beginnen und auf acht Zufallszeichen enden. Betroffene sollten Token, OAuth-Freigaben und SSH-Schlüssel ihres Kontos widerrufen.

Wurde bereits Schadcode ausgeführt, müssen Betroffene neben dem Austausch der Secrets auch die Hintertüren eigens entfernen, etwa AWS-Rollen, die jedem Konto vertrauen, oder in Azure Federated Credentials mit dem Präfix wfx-ci-. Wer npm install auf einem betroffenen Commit ausgeführt hat, muss auch den eigenen Rechner als kompromittiert betrachten.

Der Schadcode gelangte auch in Paketdistributionen. Aikido nennt das Packagist-Paket digitalelvis/neuronai-studio 3.14.3 sowie die Go-Modul-Versionen github.com/onuragtas/docker-env v1.0.278 und v1.0.280. SafeDep führt darüber hinaus github.com/onuragtas/redock, eine weitere docker-env-Version und eine über den Go-Modul-Proxy verfügbare Pseudo-Version von github.com/vkuznet/gocurl auf. Bei den Go-Modulen liegt der Schadcode in einer GitHub-Actions-Workflow-Datei; ein gewöhnlicher Go-Build führt diese nicht aus. Wer ein solches Modul lediglich als Go-Abhängigkeit einbindet, ist dadurch wahrscheinlich nicht betroffen.


(mro)



Source link

Weiterlesen

Entwicklung & Code

htop für die Grafikkarte: GPU Taskman leuchtet den Grafikspeicher aus


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Mit GPU Taskman hat Microsoft-Vizepräsident und Softwareentwickler Scott Hanselman einen quelloffenen Task-Manager für Grafikkarten veröffentlicht. Das auf GitHub entwickelte Programm läuft unter Windows, Linux einschließlich WSL und macOS auf Apple Silicon. Seine Terminaloberfläche verbindet eine Prozessliste mit Gerätedaten zu Speicherbelegung, Auslastung, Temperatur, Leistungsaufnahme und Taktraten. Zu einzelnen Prozessen liefert es außerdem Hinweise auf erkannte Runtimes und Modelle. Welche Messwerte verfügbar sind, hängt von Betriebssystem, GPU, Treiber und Zugriffsrechten ab.

Weiterlesen nach der Anzeige

GPU-Metriken treffen auf Modellinformationen

GPU Taskman liest dafür nicht beliebige Inhalte des Grafikspeichers aus, sondern kombiniert mehrere Informationsquellen. Unter Windows stammen die prozessbezogenen Speicher- und Aktivitätswerte aus den Performance-Countern des Betriebssystems, Nvidias NVML und AMDs ADL ergänzen Gerätedaten. Geladene Bibliotheken geben Hinweise auf die Runtime. Per Memory-Mapping eingebundene Dateien und Kommandozeilenargumente helfen bei der Modellerkennung. Unterstützte lokale Server-APIs liefern zusätzliche Angaben.

Bei Modellen im GGUF-Format kann das Programm unter anderem Modellname, Parameterzahl und Quantisierung anzeigen sowie den Speicherbedarf von Gewichten und KV-Cache abschätzen. Der KV-Cache hält bereits berechnete Key- und Value-Vektoren der Attention-Schichten vor. Ein größeres Kontextfenster kann deshalb mehr Speicher erfordern, obwohl die Modellgewichte unverändert bleiben. GPU Taskman stellt solche Schätzungen dem gemessenen Speicherverbrauch des Prozesses gegenüber.

Dabei kennzeichnet das Tool die Herkunft seiner Angaben: Messungen, Schlussfolgerungen, Schätzungen und Angaben einer Laufzeitumgebung sind nicht gleichzusetzen. Eine Modelldatei auf der Festplatte beweist beispielsweise noch nicht, dass ein Prozess sie gerade verwendet. Nicht verfügbare Zähler erscheinen als unbekannt, nicht als null Speicherverbrauch. In Summen gehen nur gemessene Speicherwerte ein.

Mehr Hardware und Messwertaufzeichnung

Laut den Release Notes ergänzte Version 0.3.5 die Unterstützung für Intel-GPUs unter Linux mit den Treibern i915 und xe. Hinzu kamen eine Übersicht für CPU- und RAM-Auslastung sowie entsprechende Spalten je Prozess. Der Befehl gputaskman record zeichnet in regelmäßigen Abständen JSON-Snapshots auf. Damit lässt sich zum Beispiel verfolgen, wie sich die Speicherbelegung während eines Testlaufs verändert.

Version 0.4.0 ergänzt unter Linux weitere Intel-Messwerte: die Auslastung der GPU und ihrer Video-Engine sowie die Leistungsaufnahme integrierter Intel-GPUs. Für diese zusätzlichen Messwerte benötigt das Programm unter Linux Root-Rechte. Ohne sie zeigt es die betreffenden Werte als nicht verfügbar an und nennt den Grund. Außerdem bringt das jüngste Update ein Linux-Backend für Huaweis Ascend-NPUs vom Typ 310P. Über npu-smi erfasst es jetzt Geräte- und Prozessspeicher sowie Aktivitätsdaten der KI-Beschleuniger.

Python-Paket und portable Windows-Versionen

GPU Taskman ist in Python geschrieben und steht unter der MIT-Lizenz. Für die Installation als Python-Paket setzt es Python 3.11 oder neuer voraus. Mit uv tool install gputaskman oder pipx install gputaskman lässt es sich in einer isolierten Umgebung installieren. Anschließend startet es mit gputaskman oder gtm.

Weiterlesen nach der Anzeige

Für Windows bietet das Projekt außerdem portable ZIP-Pakete für x64 und ARM64, die keine separate Python-Installation benötigen. Beim Entpacken muss das vollständige Paket einschließlich des Verzeichnisses _internal erhalten bleiben. Die Entwickler bezeichnen das Programm ausdrücklich als frühe, experimentelle Software – insbesondere die Modellzuordnungen und berechneten Speicheraufteilungen sind keine direkten Messungen.


(fo)



Source link

Weiterlesen

Beliebt