Connect with us

Entwicklung & Code

Model-Schau: TurboQuant, Gemma und DeepSeek v4


In den letzten Wochen passierte in kurzer Zeit wieder enorm viel in der Welt der großen Sprachmodelle. Neben der neu eingeführten TurboQuant-Methode hat Google mit Gemma 4 eine weitere Serie von Sprachmodellen mit offenen Gewichten veröffentlicht. Deutlich später kam das lang erwartete DeepSeek v4 zumindest in einer Vorabversion auf den Markt.

Weiterlesen nach der Anzeige




Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.

Derweil macht Anthropic ein großes Geheimnis um sein Sprachmodell Mythos, und Qwen veröffentlicht ein inkrementelles Update zu seiner erfolgreichen Qwen3.5-Serie.

Neuer Algorithmus TurboQuant

Viele feierten das Folgende als Revolution, mit der große Modelle endlich auch auf kleineren und erschwinglichen Grafikkarten laufen können: Google hat mit TurboQuant eine neue Quantisierungsmethode erfunden, die fast keine Qualitätseinbußen mit sich bringt.

Was man dabei leicht übersehen kann: Google hat den Algorithmus auf den Key-Value-Cache ausgerichtet, der in der Inferenzphase der LLMs sehr viel Speicher erfordert, denn die dazu notwendigen Daten wachsen quadratisch mit der Kontextlänge. Und der Algorithmus selbst ist auch nicht ganz neu.

Den Key-Value-Cache kann TurboQuant nahezu verlustfrei komprimieren: Wo man vorher sechzehn Bit brauchte, sind nur noch vier Bit – oder in Ausnahmefällen sogar nur drei Bit – notwendig. Das spart viel Platz und erlaubt größere Kontextlängen. Der Algorithmus nutzt dafür eine trickreiche Rotation der Vektoren, um sie verlustärmer zu komprimieren.

Google zeigt in dem Blogbeitrag zu TurboQuant, dass die Quantisierung des KV-Cache die Perplexität, also die Unsicherheit des Modells, kaum erhöht. Damit sollten auch im täglichen Gebrauch der Sprachmodelle kaum Unterschiede auftreten. Tatsächlich erschien die erste Abhandlung zu TurboQuant bereits im April 2025, aber es gab bisher keine brauchbaren Implementierungen, und es fehlten vor allem die Testfälle.

Weiterlesen nach der Anzeige

Inzwischen unterstützen viele Softwarepakete wie llama.cpp oder transformers von Hugging Face den TurboQuant-Cache. Teilweise muss man noch etwas basteln und zusätzliche Pakete installieren, aber die Speichereinsparungen sind deutlich messbar. Auch für das MLX-Framework von Apple gibt es die ersten Implementierungen.

Spannend wird, wofür sich TurboQuant jenseits des KV-Cache eignet. Google spricht von Vektordatenbanken, aber dafür gibt es bereits andere effektive Quantisierungsmethoden. Ob sich die Gewichte der Sprachmodelle mit TurboQuant so quantisieren lassen, dass sie auch in der Inferenz effektiv funktionieren, muss sich zeigen.

Neue Gemma-Modelle mit offenen Gewichten

Google war nicht nur methodisch aktiv, sondern hat auch neue Modelle mit offenen Gewichten veröffentlicht. Die lang erwartete Gemma-4-Serie enthält viele Neuerungen und steht in Größen von effektiv 2, 4 und echten 31 Milliarden Parametern zur Verfügung, dazu kommt noch ein MoE-Modell (Mixture of Experts) mit 26 Milliarden Parametern, von denen jeweils 4 Milliarden aktiv sind. Google trickst hier etwas, denn die Zahl der effektiven Parameter ist deutlich geringer als die der tatsächlich im Speicher benötigten. So hat das kleinere Modell nicht zwei, sondern etwa fünf Milliarden Parameter, das größere statt vier in Wahrheit acht Milliarden.

Alle Gemma-4-Modelle sind multimodal und für agentische Aufgaben optimiert, außerdem können sie Bilder interpretieren. Was man heute fast schon als Standard annimmt, ist bei Weitem nicht immer so, wie der Blick auf DeepSeek v4 gleich zeigen wird. Auch Reasoning beherrschen die Gemma-4-Modelle. Um zu viele Token in der Antwort zu vermeiden, lässt sich die Reasoning-Intensität einstellen.

Wie viele andere Anbieter dreht auch Google an der Attention, um Speicherplatz und Rechenzeit zu sparen. Der hybride Attention-Mechanismus in Gemma 4 nutzt abwechselnd Layer mit voller Attention und solche mit Sliding Window Attention, bei der das Modell immer nur ein bestimmtes Fenster von Token verwendet.

Mit Gemma 4 ist Google zweifellos ein großer Wurf gelungen. Besonders bei den offenen Modellen in der Größenordnung von 30 bis 40 Milliarden Parametern war bisher Alibabas Qwen3.5 der unangefochtene Platzhirsch. So eindeutig ist die Lage nun nicht mehr, denn Gemma 4 kann hier definitiv punkten.

Lang erwartet: DeepSeek v4

Über ein Jahr ist seit der Veröffentlichung von DeepSeek-R1 im Januar 2025 vergangen. So lange hat die Community auf DeepSeek v4 gewartet. Nach einigen verfrühten Falschmeldungen über das Release ist das Modell endlich als Preview erschienen. Das Warten hat sich gelohnt, denn DeepSeek hat mit v4 gleich zwei Modelle veröffentlicht, die durch einen aufwendigen Trainingsprozess (Pre-Training mit 32 Billionen Token, aufwendiges mehrstufiges Post-Training) entstanden. Eines ist mit 1,6 Billionen Parametern sehr groß: Die Größe hat sich im Vergleich zum Vorgänger mehr als verdoppelt, auch wenn hier „nur“ 49 Milliarden aktiv sind. Flankiert wird dieses Pro-Modell von einem Flash-Modell mit lediglich 284 Milliarden Parametern, von denen 13 Milliarden aktiv sind. Das ist immer noch sehr groß, man kann es aber auf leistungsfähigen PCs mit genügend Arbeitsspeicher ausführen. Besonders eignen sich die (derzeit nicht erhältlichen) Mac-Studio-Rechner.

DeepSeek hat erneut an der Attention gebastelt. Nachdem das Vorgängermodell die Multi-Head Latent Attention brachte, kombiniert DeepSeek v4 gleich zwei neue Attention-Mechanismen. Die Details zu Compressed Sparse Attention (CSA) und Heavily Compressed Attention (HCA) bleiben aktuell noch etwas im Dunkeln, aber DeepSeek soll damit im Vergleich zum Vorgängermodell nur 27 Prozent der Gleitkommaoperationen bei der Single-Token-Inferenz benötigen. Der KV-Cache schrumpft sogar um 90 Prozent. Es wäre spannend zu untersuchen, ob sich das auch noch mit TurboQuant kombinieren lässt.

DeepSeek trickst noch weiter an der Architektur und führt die sogenannten Manifold-Constrained Hyper-Connections (mHC) ein, bei denen bestimmte Verbindungen zwischen den Layern stärker ausgeprägt sind, um die Stabilität in der Vorwärtspropagation zu erhöhen. Ähnlich wie Moonshot bei Kimi nutzt DeepSeek nun auch den Muon-Optimizer statt des sonst gebräuchlichen AdamW, um die Gewichte im Trainingsprozess noch schneller zu optimieren. Dass diese neuerdings gemischt als FP4 und FP8 abgespeichert sind, spart zusätzlich viel Speicher. Das große Modell benötigt nur wenige Byte mehr als das v3.2-Modell, und das Flash-Modell kommt sogar mit 158 GByte aus, was für ein Modell mit 284 Milliarden Parametern sonst nur über starke Post-Training-Quantisierung möglich ist.

Erstaunlicherweise ist DeepSeek v4 kein multimodales Modell, sondern kann ausschließlich mit Text umgehen. Vielleicht legt DeepSeek bis zum endgültigen Release hier noch nach, es gibt aber leider bisher auch keine Prognosen, wann es so weit sein könnte. DeepSeek hält sich mit weiteren Informationen ohnehin ungewohnt bedeckt, Details über Training und Architektur stehen noch nicht öffentlich bereit.

Spannend ist der Vergleich zwischen dem kleinen und großen (oder besser zwischen dem riesigen und dem gigantischen) Modell. Das kleinere Flash-Modell erzeugt wohl ähnlich gute Resultate, wenn man ihm mehr Reasoning zugesteht. Man tauscht somit die Zahl der Parameter gegen die Länge der Antwort bei Logikfragen. Wie gut das funktioniert, muss ein ausführlicher Test noch zeigen. Bei Wissensfragen ist das kleinere Modell erwartungsgemäß unterlegen.

DeepSeek v4 unterstützt drei unterschiedliche Thinking-Modi, von abgeschaltetem Reasoning bis zu sehr intensivem. Im Performance-Vergleich zu v3.2 sind die Fortschritte moderat. Erstaunlich ist allerdings, dass das Flash-Modell fast so gut funktioniert wie v3.2 mit immerhin doppelt so vielen Parametern (in früher deutlich höherer Genauigkeit, DeepSeek v3 hat noch überall FP8 benutzt).

DeepSeek v4 ist ein interessantes Modell, aber enttäuschend ist, dass der Hersteller entgegen seiner sonstigen Gepflogenheiten deutlich weniger technische Details veröffentlicht hat. Hoffentlich erscheint ein Artikel dazu zum endgültigen Release.

Was sonst noch war

Anthropic findet sich ebenfalls in den Schlagzeilen, allerdings nicht nur positiv. Im März geriet dem Unternehmen der Sourcecode zu Claude aus den Händen. Unabhängig davon forscht Anthropic an immer leistungsfähigeren Modellen – so leistungsfähig, dass die damit (automatisch) zu entdeckenden Sicherheitslücken gefährlich werden können. Daher wurde Mythos nicht öffentlich zur Verfügung gestellt, war aber wohl doch für Unbefugte zugänglich. Wie leistungsfähig das Modell tatsächlich ist, zeigt sich unter anderem darin, dass es über 270 Lücken in Firefox aufgedeckt hat. Gut möglich, dass sich daraus eine völlig neue Richtung in der Cybersecurity entwickelt.

Auch die chinesischen Anbieter jenseits von DeepSeek schlafen nicht. Qwen hat ein kleineres Update für einige der Qwen3.5-Modelle veröffentlicht. Qwen3.6 steht als Max Preview nur via API zur Verfügung, kleinere Modelle wie das MoE mit 35 Milliarden Parametern, von denen drei Milliarden aktiv sind, und das dichte mit 27 Milliarden Parametern stehen ebenfalls offen zur Verfügung. Besonders letzteres Modell zeigt sich als extrem leistungsfähig und schlägt deutlich größere Modelle. Wie gut das funktioniert, müssen genauere Analysen zeigen.

Qwen3.5 nutzt bei der Hybrid-Attention sogenannte Mamba-Layer. Für die State-Space-Modelle gibt es nun mit Mamba-3 eine neue Architektur. Möglicherweise lassen sich dadurch in den entsprechenden Layern weitere Verbesserungen erzielen, so dass sich längere Kontexte abbilden lassen. Leistungsfähige Modelle mit dieser Architektur gibt es allerdings noch nicht.

Die Firma Tesslate hat basierend auf Qwen3.5-9B ein Modell mit von Claude Opus generierten Daten auf Coding-Aufgaben feingetuned. Daraus entstand das OmniCoder-Modell, das sich äußerst gut für Coding-Aufgaben eignet und dabei das Basismodell in allen Dimensionen schlägt. Dabei ist es klein genug, um in einer quantisierten Version lokal zu laufen.

Moonshot hat mit Kimi K2.6 nachgelegt. Das Modell fokussiert sich besonders auf Coding- und agentische Aufgaben, die es in Schwärmen aus bis zu 300 Agenten erledigen kann. Wie gewohnt ist das Modell mit einer Billion Parametern sehr groß und lässt sich nur mit Mühe auf bezahlbarer Hardware ausführen.

Von MiniMax gibt es eine neue Version 2.7 des MoE-Modells. Bemerkenswert daran ist, dass das Modell für sein eigenes Update zum Einsatz kam. Dabei hat es seinen Speicher aktualisiert, mehrere Dutzend Skills für Reinforcement Learning „erfunden“ und autonom seinen eigenen Optimierungsprozess verbessert. Dabei behauptet MiniMax AI, dass es bis zu 30 Prozent Performanceverbesserung erreicht hat. Es wird spannend zu beobachten, ob andere Anbieter einen ähnlichen Weg gehen und allein dadurch ihre Modelle verbessern können.

Da die Modelle immer größer werden, erforschen Anbieter neben dem allgegenwärtigen Attention-Mechanismus auch neue Quantisierungsverfahren. Ein interessanter Kandidat ist die JANG-Quantisierung, die dynamisch die optimale Quantisierungsstufe auswählt und dadurch enorm Platz spart. Aktuell ist die Software allerdings nur auf Macs verfügbar. Dort ist es dann möglich, ein Modell mit 397 Milliarden Parametern mit 128 GB RAM zu betreiben. Meine eigenen Tests haben gezeigt, dass das erstaunlich gut funktioniert und mit MLX Studio auch relativ einfach zu installieren ist. Die dazu passenden Python-Tools sind allerdings nicht immer ganz up to date.

Open AI hat GPT-5.5 öffentlich bereitgestellt. Es glänzt insbesondere beim Coding mit neuen Bestwerten und kann auch mehrstufige Aufgaben gut erledigen. Im Gegensatz zu GPT 5.4 kommt es auch mit Fremdsprachen offenbar besser zurecht, denn der erste Satz des vorherigen Blogartikels klang auf Deutsch zumindest merkwürdig: „Heute veröffentlichen wir GPT‑5.4 in ChatGPT (als GPT‑5.4 Thinking), der API und Codex.“

Auch wenn bei den Sprachmodellen das meiste in China und den USA passiert, gibt es Neuigkeiten aus dem Rest der Welt, darunter aus Europa. So planen Cohere aus Kanada und das deutsche Unternehmen Aleph Alpha einen Zusammenschluss. Gemeinsam wollen sie einen Sprachmodell-Champion schaffen. Vor einer ganzen Weile waren die Cohere-Modelle ganz vorn mit dabei, sind aber in der Zwischenzeit fast unbedeutend. Vielleicht braucht es einen Restart, der möglicherweise durch die Fusion gelingt.

Clevere Mechanismen und Optimierungen

Was für ein Frühling! Bei den Sprachmodellen kann man große Fortschritte beobachten. Wenn man die Ideen der letzten Wochen wie clevere Attention-Mechanismen, verbesserte Quantisierung und optimiertes Training zusammennimmt, kann man davon ausgehen, dass in der nächsten Zeit deutlich bessere Modelle und weitere Neuerungen auf uns warten.

Besonders spannend dabei ist, dass die Wachstumskurve beim Speicherbedarf abflacht. Das lässt darauf hoffen, dass sich zumindest einige dieser Modelle künftig auf leistungsfähiger eigener Hardware souverän nutzen lassen.


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Kestra: Ops-Automation jenseits von CI/CD


close notice

This article is also available in
English.

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

.

Montag, 9 Uhr. Ein Entwickler braucht einen Testserver. Er öffnet das Ticketsystem, trägt Hostname, Betriebssystem und Kostenstelle ein und wartet. Einen Tag, manchmal drei. Irgendwann landet die VM in seiner Inbox, konfiguriert nach dem Stand von vor zwei Wochen, weil niemand das Template seitdem angefasst hat.

Weiterlesen nach der Anzeige


Philip Lorenz

Philip Lorenz

Philip Lorenz ist als DevOps- und Cloud-Engineer tätig. Zudem hält er Schulungen zu den Themen PowerShell, Automatisierung und Cloud-Computing.

Der Reflex, dieses Problem mit vorhandenen Werkzeugen zu lösen, ist verständlich. Eine Pipeline in Azure DevOps oder GitHub Actions ist schnell geschrieben. Doch CI/CD-Tools sind für etwas anderes gebaut: Code bauen, testen, deployen. Sie folgen einem Commit, laufen durch und sind fertig. Langlebige Workflows, Retry-Logik und State-Management sind nicht ihr Revier.

Genau diese Lücke füllt Kestra. Das Tool wird seit 2021 von Kestra Technologies entwickelt und ist seit Februar 2022 – im Kern als Open-Source-Projekt unter der Apache-2.0-Lizenz – öffentlich verfügbar. Kommerzielle Enterprise-Funktionen ergänzen den OSS-Kern. Kestra versteht sich als universeller Orchestrator: für Ops-Automatisierung, Data Pipelines, Event-driven Workflows und zunehmend auch für KI-Agenten und -Workflows; alles deklarativ in YAML, alles versionierbar in Git. Dieser Artikel zeigt anhand eines konkreten Beispiels, wie das in der Praxis aussieht: Ein Entwickler oder eine Entwicklerin fordert per Formular eine Hetzner-VM an, Kestra provisioniert sie vollautomatisch per Terraform. Der gesamte Code für Terraform, das Kestra-Setup sowie die Kestra Flows sind im GitHub-Repository des Autors zu finden.




Die auf Developer Experience (DX) und Platform Engineering spezialisierte CLC-Konferenz findet vom 11. bis 12. November 2026 in Mannheim statt. Ein besonderer Fokus liegt darauf, wie Agentic AI die Arbeit von Developern, Software-Architekten, DevOps- und Platform Engineers verändert und wie sich digitale Souveränität nachhaltig erreichen lässt.

Ab sofort sind Tickets zum Frühbucherpreis verfügbar.

Orchestrierung ist nicht dasselbe wie Automatisierung

Wer zum ersten Mal von Kestra hört, denkt unweigerlich, es handele sich um ein weiteres Tool, das Shell-Skripte in ein hübsches UI verpackt. Das trifft es nicht. Der Unterschied liegt im Konzept: Ein Shell-Skript oder eine CI/CD-Pipeline sind sequenziell: auf Schritt A folgt B, dann C, und am Ende ist der Status entweder fertig oder fehlgeschlagen. Was dazwischen passiert, interessiert das Tool nicht. Kestra hingegen orchestriert: Es kennt den Zustand jedes einzelnen Schritts, kann auf externe Ereignisse warten, Fehler gezielt behandeln, Schritte parallelisieren und einen Workflow nach Stunden oder Tagen an exakt der Stelle fortsetzen, an der er unterbrochen wurde.

Das ist keine rein akademische Unterscheidung. In der Praxis bedeutet es, dass Kestra Workflows abbilden kann, die mit klassischen Pipeline-Tools nicht darstellbar sind: ein Provisionierungs-Job, der wartet, bis ein externes System bereit ist, eine Daten-Pipeline, die bei einem HTTP-Fehler drei Minuten pausiert und es dann erneut versucht, ein Deployment, das erst nach einer manuellen Freigabe weiterläuft. Was andere Tools „Pipeline“ nennen, ist in Kestra ein Flow.

Weiterlesen nach der Anzeige

Das Entwicklungsteam hinter dem Projekt positioniert Kestra bewusst für ein breites Einsatzspektrum. Im Vordergrund stehen dabei:

  • Ops Automation: Infrastruktur bereitstellen, Cluster provisionieren, wiederkehrende Betriebsaufgaben automatisieren.
  • Data Pipelines: Kestra tritt hier in direkten Wettbewerb mit Apache Airflow und Prefect
  • Event-driven Workflows: Flows, die auf Webhooks, Queue-Nachrichten oder Dateiänderungen reagieren.
  • KI-Workflows: Kestra orchestriert KI-Agenten genauso wie klassische Ops-Tasks.

Die vier Grundbausteine

Kestra kennt vier Konzepte, die Entwickler zunächst verinnerlichen sollten, um den Gesamtansatz des Tools leichter zu verstehen.

Ein Flow ist die oberste Einheit, vergleichbar mit einer Pipeline-Definition, aber mit deutlich mehr Ausdruckskraft. Jeder Flow hat eine ID, einen Namespace zur Strukturierung und eine Liste von Tasks. Er lebt als YAML-Datei in Git und lässt sich darüber versionieren und deployen.

Tasks sind die einzelnen Schritte innerhalb eines Flows. Kestra bringt eine umfassende Bibliothek an eingebauten Task-Typen mit: HTTP-Requests, Dateioperationen, Shell-Kommandos, Container-Ausführung, Schleifen, Bedingungen und Parallelisierung. Tasks können Outputs produzieren, die nachfolgende Tasks als Inputs verwenden. Dadurch entsteht ein nachvollziehbarer Datenfluss zwischen den einzelnen Schritten des Flows.

Trigger definieren, wann ein Flow startet. Zur Auswahl stehen Zeitpläne (Cron), Webhooks, andere Flows als Auslöser oder manuelle Ausführung über das UI. Der manuelle Trigger ist dabei nicht zu unterschätzen: Er öffnet im Kestra-UI automatisch ein Eingabeformular für alle deklarierten Inputs.

Plug-ins erweitern Kestra um externe Integrationen. Das offizielle Plug-in-Ökosystem umfasst unter anderem Terraform, Kubernetes, AWS, Azure, GCP, Slack, dbt und Airbyte. Plug-ins sind versionierte JARs, die Kestra beim Start lädt, ohne separates Dependency-Management oder pip install.

Das folgende Listing zeigt einen minimalen Flow:


id: hello-kestra
namespace: demo

inputs:
  - id: message
    type: STRING
    defaults: "Hallo von Kestra"

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "{{ inputs.message }}"


Dieser Flow zeigt das Wesentliche: Der Namespace demo strukturiert Flows im UI ähnlich wie Ordner. Der Input message erscheint bei der manuellen Ausführung als Textfeld. Der Task referenziert den Input per Pebble-Template-Syntax {{ inputs.message }}. Dieselbe Syntax funktioniert überall im Flow für Secrets, für Outputs vorheriger Tasks sowie für Metadaten der Execution.

Kein Ersatz, sondern Ergänzung

Die Frage kommt verlässlich: Haben wir nicht schon Azure DevOps? Brauchen wir das wirklich? Die Antwort ist ja und nein. Azure DevOps oder GitHub Actions bleiben für das, was sie können, ungeschlagen: Code kompilieren, Tests ausführen, Container bauen, Artefakte deployen. Wer diese Aufgaben ersetzen will, hat das falsche Problem, denn Kestra setzt an einer anderen Stelle an.

CI/CD bleibt die richtige Schicht für alles, was aus dem Repository kommt: bauen, testen, ausliefern. Viele Betriebsprozesse beginnen jedoch mit einer Anfrage statt mit einem Commit: Eine Umgebung soll entstehen, ein Change muss geprüft, eine Ressource freigegeben oder ein externer Dienst eingebunden werden. Genau dort ergänzt Kestra die vorhandene CI/CD-Landschaft.

Ein konkretes Beispiel: Ein Entwickler will einen Kubernetes-Cluster provisionieren. In einer Azure-DevOps-Pipeline lässt sich das technisch abbilden, mit terraform apply als Skript-Task. Was fehlt, ist alles drumherum: Es gibt kein strukturiertes Eingabeformular für Entwickler und keine saubere Retry-Logik, wenn der Cloud-Provider einmal nicht antwortet. Es gibt auch kein Log, das zeigt, wer wann welche Ressource angefordert hat. Vor allem aber behandelt eine Pipeline Terraform im Stil von „fire and forget“: Skript starten, durchlaufen lassen, auf ein Ergebnis hoffen – was dazwischen passiert, ist nicht greifbar. Kestra kapselt dagegen jede Execution vollständig mit ihren Parametern: State, Logs und Retry-Verhalten sind eindeutig einer konkreten Execution zugeordnet und im UI nachvollziehbar. Schlägt ein Schritt fehl, weiß Kestra, an welcher Stelle, mit welchen Eingaben und in welchem Zustand, und kann gezielt darauf reagieren, statt blind von vorne zu beginnen.

Vergleich mit Airflow und Prefect: Der Blickwinkel ist entscheidend

Welche Alternativen zu Kestra infrage kommen, hängt vom Blickwinkel ab, der sich etwa zwischen Data Engineering und Platform Engineering erheblich unterscheidet. Wer aus dem Data-Engineering-Umfeld kommt, denkt meist zuerst an Apache Airflow, heute ein Top-Level-Projekt der Apache Software Foundation, oder an Prefect, das vom gleichnamigen Unternehmen entwickelt wird. Airflow ist der etablierte Standard für DAG-basierte Daten-Pipelines mit Abhängigkeiten, Scheduling und Retry-Logik. Prefect ist eine modernere Alternative, die mit geringerem Betriebsaufwand und einer schlankeren API punktet. Kestra besetzt denselben Raum, ist aber weniger Python-zentrisch: Flows sind in YAML definiert, Tasks sind Plug-in-Aufrufe, Python-Wissen ist nicht erforderlich. Das macht Kestra vor allem für gemischte Teams zugänglicher.

Im Platform Engineering kommen hingegen ganz andere Werkzeuge zum Einsatz. Verbreitet sind unter anderem Argo Workflows als Kubernetes-nativer Orchestrator, die Ansible Automation Platform für Betriebsaufgaben und Configuration Management oder Terraform Cloud für Infrastructure-as-Code-Workflows. All diese Tools lösen echte Probleme, aber jedes ist fest in seinem Paradigma verankert. Terraform Cloud macht Terraform, Argo macht Kubernetes-Workflows, die Ansible Automation Platform macht Ansible. Kestra gibt sich hier bewusst universeller: Ein Flow kann einen Terraform-Container starten, danach ein PowerShell-Skript ausführen, eine HTTP-API aufrufen und das Ergebnis in Slack melden – in einem einzigen YAML-Flow, ohne dass das Tool Rücksicht auf die darunter liegenden Technologien nehmen müsste.

Aus Entwicklersicht bleiben Azure DevOps und GitHub Actions erste Wahl für die CI/CD-Schicht. Airflow oder Prefect können in datengetriebenen Umgebungen weiter ihren Dienst tun. Kestra ergänzt aber dort, wo keines dieser Tools zu Hause ist: als Orchestrierungsschicht, die heterogene Toollandschaften zusammenhält, gleichzeitig aber auch als Ersatz für einzelne Tools dienen kann.

Lokal testen, im Cluster betreiben

Kestra lässt sich lokal per Docker Compose starten. Die vollständige docker-compose.yml liegt im begleitenden GitHub-Repository. Der Befehl docker compose up -d genügt, danach ist das UI unter sofort erreichbar:


Kestra-Dashboard mit Plugins-Menü und Suchleiste

Kestra-Dashboard mit Plugins-Menü und Suchleiste

Kestra bringt bereits über 1300 Plug-ins mit (Abb. 1).

Für den produktiven Betrieb auf Kubernetes gibt es ein offizielles Helm-Chart. Die Komponenten (Server, Scheduler, Executor und Worker) laufen als separate Deployments und lassen sich unabhängig skalieren. Worker übernehmen die eigentliche Task-Ausführung und sind der primäre Skalierungshebel: Mehr parallele Executions bedeuten mehr Worker-Replicas, der Rest der Infrastruktur bleibt stabil. Wer Kestra-Ressourcen (Flows, Namespaces, Secrets, User und Rollen) ebenfalls als Code verwalten will, greift zum offiziellen Terraform-Provider: Er bildet die gesamte Kestra-Konfiguration als Terraform-Ressourcen ab und lässt sich nahtlos in bestehende Infrastructure-as-Code-Pipelines integrieren.



Source link

Weiterlesen

Entwicklung & Code

AMD und Intel spezifizieren KI-Befehlssatz „ACE“ für x86-Prozessorkerne


Seit Herbst 2024 kooperieren AMD und Intel in der x86 Ecosystem Advisory Group, auch um sich gegen Konkurrenten wie ARM und RISC-V zu stärken. Nun ist die gemeinsam erarbeitete Spezifikation für neue x86-Prozessorbefehle erschienen, die die Verarbeitung von KI-Algorithmen beschleunigen sollen: Die AI Compute Extensions, kurz „ACE“.

Weiterlesen nach der Anzeige

Bei ACE geht es vor allem um Matrix-Multiplikationen mit KI-Datenformaten für das Inferencing mit quantisierten Gewichten.

Konkurrent ARM hat bereits Scalable Matrix Extensions (SME2) spezifiziert, die auf die Scalable Vector Extensions (SVE2) aufbauen. SME-Rechenwerke lassen sich auf unterschiedliche Art in ARM-SoCs integieren. Apple baut SME2 seit dem M4 ein, Qualcomm ab dem Snapdragon X2.

Eng mit AVX verknüpft

Die AI Compute Extensions (ACE) Specification steht in Version 1.15 auf der Website der x86 Ecosystem Advisory Group zum Download bereit. Die Spezifikation beschreibt nur die Befehle, nicht die konkrete Implementierung.

Kommende ACE-Rechenwerke sind eng mit den Advanced Vector Extensions (AVX) gekoppelt und nutzen beispielsweise dieselben Register. Konkret nennt die Spezifikation AVX10. Sie erwähnt zudem die bisher nur von Intel in aktuellen Xeon-Serverprozessoren eingebauten Advanced Matrix Extensions (AMX).

Prozessoren mit ACE-v1-Rechenwerken müssen auch einen bestimmten Teil des Befehlsumfangs von AVX10.2 beherrschen.

Weiterlesen nach der Anzeige

Viele KI-Datenformate

ACE v1 beschreibt 11 Datenformate, einige in unterschiedlichen Darstellungen. Mit Daten in diesen Formaten müssen ACE-Rechenwerke nicht nur rechnen können, sondern die Spezifikation legt auch eine Fülle von Formatumwandlungen fest.

Datenformate der AI Compute Extensions ACE v1
Format Beschreibung
INT8 Ganze Zahlen mit 8 Bit (Integer)
INT32 Ganze Zahlen mit 32 Bit
FP32 Gleitkommazahlen mit 32 Bit laut IEE-754 (SE8M32)
FP16 SE5M10
BF16 SE8M7
E8M0 8-Bit-Zahl mit vorzeichenlosem Exponent
FP8 nach OCP-Spezifikation (OFP8): E4M3 oder E5M2
MX FP8 Microscaling-Formate (MX) SE5M2 oder SE4M3
MX FP6 SE3M2 oder SE2M3
MX FP4 SE2M1
MX INT8 Bruchformat

Seit 2023 sind x86-Prozessoren mit zusätzlich eingebauter Neural Processing Unit (NPU) im Handel. Die verarbeiten bestimmte Datenformate besonders schnell und effizient, sind aber wenig flexibel und belegen relativ viel Chip-Fläche.

Microsoft macht seit 2024 eine NPU mit einer Leistung von mindestens 40 Billionen INT8-Operationen pro Sekunde (40 Tops) zur Voraussetzung für das Marketing-Label Copilot+. Mittlerweile weicht Microsoft diese Vorgabe auf und ermöglicht auch GPUs. Mit kommenden ACE-tauglichen Prozessoren dürften weitere Änderungen nötig werden.

Nach bisherigen Informationen dürften ACE-v1-kompatible x86-Prozessoren frühestens 2028 erscheinen. Denn bisher haben weder AMD für Zen 6 noch Intel für Nova Lake ACE erwähnt. AMD nennt erst für Zen 7 eine neue „Matrix Engine“, vermutlich ACE-kompatibel.

Hören Sie dazu auch:


(ciw)



Source link

Weiterlesen

Entwicklung & Code

Open VSX: Version 1.0 der Microsoft-Alternative von Eclipse erschienen


close notice

This article is also available in
English.

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

.

Die Eclipse Foundation hat Open VSX in Version 1.0 veröffentlicht. Damit erreicht die Registry für Visual Studio Code Extensions einen stabilen Stand.

Weiterlesen nach der Anzeige

Open VSX ist eine Plattform zum Veröffentlichen und Herunterladen von Extensions und Werkzeugen, die kompatibel zu der VS-Code-Extensions-API sind. Einige Entwicklungsumgebungen und Tools können die Extensions integrieren, und manche Entwicklungsumgebungen bauen auf Forks von Visual Studio Code auf.

Das Projekt besteht aus einer Serveranwendung mit einer Datenbank für die Extensions sowie einer Webanwendung und einem Kommandozeilenwerkzeug zum Hoch- und Herunterladen der Erweiterungen.

Deutsche Wurzeln mit Open-Source-Basis

Das deutsche Start-up-Unternehmen TypeFox hatte Open VSX ursprünglich entwickelt und 2021 an die Eclipse Foundation übergeben. Mike Milinkovich, Geschäftsführer der Eclipse Foundation, wollte die Plattform als offene Alternative zum Visual Studio Marketplace betreiben, zumal dieser in den Nutzungsbedingen den Einsatz der Extensions auf Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server sowie nachfolgende Microsoft-Produkte beschränkt.

Die Eclipse Foundation entwickelt Open VSX als Open-Source-Projekt über ein GitHub-Repository. Seit Juni 2023 kümmert sich eine eigene Arbeitsgruppe um den Fortbestand. Im April 2026 startete die Eclipse Foundation eine Initiative, um Bugs und Schwachstellen in Open VSX aufzuspüren.

Stabilität und Security

Weiterlesen nach der Anzeige


Open VSX 1.0.0, celebration image

Open VSX 1.0.0, celebration image

(Bild: Eclipse Foundation)

Version 1.0 setzt vor allem auf Stabilität und Security: Das Release bringt unter anderem einen Read-Only-Modus und TLS-geschützte Redis-Verbindungen. Außerdem spricht der Blogbeitrag zur Veröffentlichung von Open VSX 1.0 von zusätzlichen Maßnahmen für eine verbesserte Sicherheit.

Plattformen, die Erweiterungen für Entwicklungswerkzeuge und Programmiersprachen anbieten, sind ein beliebtes Ziel für Supply-Chain-Attacken. Im Oktober 2025 traf die GlassWorm-Attacke neben Microsofts Marktplatz auch Open VSX. Damals reagierte die Eclipse Foundation zügig mit zusätzlichen Schutzmaßnahmen.

Weitere Details lassen sich der Ankündigung von Open VSX 1.0.0 im Eclipse-Blog entnehmen. Die Eclipse Foundation betreibt die öffentliche Open VSX Registry und bietet zudem eine verwaltete Plattform auf Open-VSX-Basis für Unternehmen und Organisationen als Open VSX Managed Registry an.


(rme)



Source link

Weiterlesen

Beliebt