Anaconda Platform bringt geprüfte Pakete und Modelle in jeden Flow-Schritt
Anaconda hat im Rahmen von AI Orchestration in der Anaconda Platform kontrollierte Pakete und Modelle veröffentlicht, sodass jeder Schritt eines Flows nur auf Paketen und Modellen läuft, die eine Organisation freigegeben hat. Laut dem Unternehmen fügen Entwickler einem Flow Anaconda-Decorators hinzu, und die Sicherheitsprüfung, die sonst oft erst spät im Projekt stattfindet, läuft automatisch ab.
- Die Anaconda Platform führt jeden Flow-Schritt nun auf Paketen und Modellen aus, die durch die Richtlinien einer Organisation freigegeben sind.
- Der Decorator @anaconda_base baut OCI-kompatible Images aus kontrollierten Channels und greift dabei auf mehr als 19.000 geprüfte Pakete zurück.
- Der Modellkatalog umfasst mehr als 77 kuratierte Modelle mit AIBOM, Lizenzdokumentation und Benchmark-Ergebnissen.
- Administratoren legen pro Perimeter Regeln zu CVE, Lizenzen und Modellmetadaten fest, sodass die Produktion strenger sein kann als die Entwicklung.
- Die Flows basieren auf Metaflow, das Anaconda durch die Übernahme von Outerbounds im April 2026 erhielt.
Freigegebene Pakete über einen einzigen Decorator
Flows in der Anaconda Platform sind Python-Klassen, in denen jede Methode einen Schritt darstellt. Sie basieren auf Metaflow, dem Open-Source-Framework, das mit der Übernahme von Outerbounds im April 2026 zu Anaconda kam. Um die vertrauenswürdigen Pakete von Anaconda zu nutzen, fügt ein Entwickler dem Flow den Decorator @anaconda_base hinzu und listet die Python-Version sowie die benötigten Pakete auf. In Anacondas Beispiel deklariert ein Flow Python 3.12 zusammen mit pytorch 2.6.* und pandas 2.2.*.
Laut Anaconda erstellt die Plattform daraufhin OCI-kompatible Images aus ihren kontrollierten Channels, sodass keine Umgebung von Hand eingerichtet werden muss. Jeder Schritt greift auf kuratierte, sicherheitsgeprüfte Channels zu, die Paketrichtlinien der Organisation werden angewendet, bevor etwas installiert wird, und die Pakete sind durch Sicherheitsmetadaten und Software Bills of Materials (SBOMs) abgesichert, die Komponenten, Lizenzen und Herkunft dokumentieren. Die Channels speisen sich aus Anacondas Trusted Distribution, die das Unternehmen als mehr als 19.000 geprüfte Pakete beschreibt, die von Anaconda-Ingenieuren gebaut, getestet und digital signiert werden.
Die Plattform löst Abhängigkeiten gegen die Channels eines Perimeters auf und überführt das Ergebnis in ein Container-Image, sodass dieselbe Umgebung lokal oder in der Produktion läuft. Ein Flow lässt sich lokal mit --environment=anaconda oder auf einem Cluster mit --environment=fast-bakery ausführen.
Richtlinien legen Administratoren fest, Flows erben sie
Administratoren legen Paketrichtlinien für die Channels jedes Perimeters fest. Eine Richtlinie ist ein Satz von Ausschlussregeln auf Basis der Sicherheitsmetadaten von Anaconda, etwa dem Score der Common Vulnerabilities and Exposures (CVE), dem Status oder der Lizenzfamilie. Jeder Channel bietet eine empfohlene Standardrichtlinie, die sich anpassen lässt. Beim Speichern einer Richtlinie wird der Paketindex des Channels ohne die ausgeschlossenen Pakete neu aufgebaut, sodass diese für keinen Flow im Perimeter mehr verfügbar sind und Entwickler keinen Code ändern müssen.
Da jeder Perimeter eigene Channels hat, kann eine Produktionsumgebung strengere Richtlinien durchsetzen als die Entwicklung. Die Überführung eines Flows in die Produktion läuft über die bestehende CI/CD-Pipeline des Teams, einschließlich Freigabeschritten wie Code-Review, Testläufen oder Abnahmen. Der Code bleibt derselbe, und ab diesem Zeitpunkt gelten die Richtlinien des Produktionsperimeters.
Ein Modellkatalog, gefiltert nach Richtlinien
Schritte, die ein Modell benötigen, beziehen es aus Anacondas Modellkatalog, der mehr als 77 kuratierte Modelle umfasst. Laut dem Unternehmen wird jedes automatisch beschafft, quantisiert und per Benchmark getestet und vor der Veröffentlichung vom Team von Anaconda validiert. Zu den Modellen gehören eine AI Bill of Materials (AIBOM), Lizenzdokumentation und Benchmark-Ergebnisse.
Administratoren formulieren Regeln anhand der Modellmetadaten: Herausgeber, Lizenz, Herkunftsland, Modellgröße und erwarteter Speicherbedarf. Eine Beispielregel lautet, dass die Produktion nur Modelle verwendet, deren Lizenz kommerzielle Nutzung erlaubt. Freigegebene Modelle lassen sich mit dem Decorator @anaconda_models in einem Flow-Schritt einsetzen, für die lokale Arbeit herunterladen oder als dedizierte Inferenz-Bereitstellung mit eigenem API-Endpunkt betreiben.
- Jedes Modell ist in mehreren Quantisierungsstufen verfügbar, die etwas Präzision gegen einen geringeren Platzbedarf und schnellere Antworten tauschen.
- Modelle lassen sich auf einem Endpunkt mit GPU-Autoscaling in der Cloud bereitstellen oder lokal mit Desktop laden.
- Beide Wege bieten dieselbe API, sodass sich der aufrufende Code zwischen Test und Produktion nicht ändert.
- Einige Modelle bringen eine integrierte Chat-Oberfläche mit.
Reaktion auf Sicherheitswarnungen und was das bedeutet
Die Channels jedes Perimeters listen ihre Pakete und die jeweils bekannten CVEs auf. Als Beispiel nennt Anaconda CVE-2025-32434: Die Lücke betraf, wie PyTorch Modelldateien lädt, in Versionen bis 2.5.1 und wurde in 2.6.0 behoben. Da Flows ihre Pakete im Code deklarieren, besteht das Auffinden betroffener Flows in einer Suche in den Repositories, und die Korrektur ist eine einzeilige Änderung an der Versionsfestlegung mit anschließendem erneutem Lauf. Die Plattform bewahrt die Artefakte jedes Laufs auf, sodass sich Ergebnisse vor und nach der Änderung mit dem Run-Objekt von Metaflow vergleichen lassen.
Für Teams lautet das Versprechen: Entwickler deklarieren, was ein Flow braucht, Administratoren legen Richtlinien einmalig fest, und die Plattform löst jeden Schritt gegen diese Regeln auf. Anaconda zufolge laufen bestehende Flows unverändert weiter. Das Unternehmen bietet Demos im eigenen Cloud-Konto eines Kunden an und hat eine Dokumentation veröffentlicht.
