BSN-Chatsystem/ki_news_18_juni_2026.md

# KI/LLM-News — 18. Juni 2026

> **Hinweis:** Die neuesten verfügbaren Stories stammen vom 17. Juni 2026 (gestern). Am 18. Juni selbst wurden zum Recherchezeitpunkt noch keine neuen Blogposts auf HuggingFace oder anderen großen Plattformen veröffentlicht. HN Algolia und Reddit r/LocalLLaMA lieferten keine relevanten Treffer für die letzten 24 Stunden. Die folgenden 5 Stories repräsentieren die bedeutendsten KI-News der unmittelbaren Gegenwart.

---

## Story 1: GLM-5.2 — Open-Source-Flaggschiff mit 1M-Kontext auf Opus-Niveau

**Teaser (Deutsch):** Z.AI hat GLM-5.2 veröffentlicht, das erste Open-Source-Modell, das mit einer soliden 1-Million-Token-Kontextlänge arbeitet und in Long-Horizon-Coding-Benchmarks mit Claude Opus 4.8 konkurriert. Das Modell erscheint unter MIT-Lizenz, führt eine neuartige „IndexShare"-Architektur ein (2,9× weniger FLOPs pro Token bei 1M Kontext) und bietet flexible „Effort Level"-Steuerung für Coding-Agenten. Auf Terminal-Bench 2.1 erreicht GLM-5.2 81.0 Punkte — nur 4 Punkte hinter Opus 4.8 und vor Gemini 3.1 Pro.

**Source-URL:** https://huggingface.co/blog/zai-org/glm-52-blog

**Volltext (Deutsche Übersetzung):**

Wir stellen GLM-5.2 vor, unser neuestes Flaggschiff-Modell für Long-Horizon-Aufgaben. Es markiert einen erheblichen Sprung in der Long-Horizon-Fähigkeit gegenüber seinem Vorgänger GLM-5.1 und liefert diese Fähigkeit erstmals auf einem soliden 1M-Token-Kontext. Die neuen Fähigkeiten von GLM-5.2 umfassen:

- **Solider 1M-Kontext:** Ein stabiler 1M-Token-Kontext, der zuverlässig langfristige Arbeit unterstützt
- **Fortschrittliches Coding mit flexiblem Aufwand:** Stärkere Coding-Fähigkeiten mit mehreren Thinking-Effort-Stufen zur Balance zwischen Leistung und Latenz
- **Verbesserte Architektur:** Wir schlagen IndexShare vor, das denselben Indexer über jeweils vier Sparse-Attention-Schichten wiederverwendet und die FLOPs pro Token bei 1M Kontextlänge um das 2,9-fache reduziert. Wir verbessern auch die MTP-Schicht von GLM-5.2 für spekulative Dekodierung und erhöhen die Akzeptanzlänge um bis zu 20%
- **Pure Open:** Eine MIT-Open-Source-Lizenz — keine regionalen Beschränkungen, technischer Zugang ohne Grenzen

Long-Horizon-Aufgaben zu unterstützen beginnt damit, langen Kontext technisch nutzbar zu machen: Das Modell muss die Qualität über lange, unübersichtliche Coding-Agent-Trajektorien hinweg aufrechterhalten, nicht nur mehr Tokens akzeptieren. Ein 1M-Kontext ist leicht zu behaupten, aber viel schwieriger unter realem technischen Druck zuverlässig zu halten. Zu diesem Zweck haben wir das 1M-Kontext-Training für Coding-Agent-Szenarien erheblich erweitert, das groß angelegte Implementierung, automatisierte Forschung, Leistungsoptimierung und komplexes Debugging abdeckt. Das Ergebnis ist ein Long-Context-System, das nicht nur breit im Umfang, sondern auch solide in der Ausführung ist: ein praktisches Substrat für nachhaltige technische Arbeit.

Diese Fähigkeit spiegelt sich in GLM-5.2s Leistung auf drei Long-Horizon-Coding-Benchmarks wider. **FrontierSWE** misst, ob ein Agent offene technische Projekte im Maßstab von Stunden bis zu zehn Stunden abschließen kann, die Systemoptimierung, groß angelegte Codekonstruktion und angewandte ML-Forschung umfassen. Auf diesem Benchmark liegt GLM-5.2 nur 1% hinter Opus 4.8, während es GPT-5.5 um 1% und Opus 4.7 um 11% übertrifft. Auf **PostTrainBench**, wo jeder Agent eine H100-GPU erhält und danach bewertet wird, wie sehr er kleine Modelle durch Post-Training verbessern kann, übertrifft GLM-5.2 sowohl Opus 4.7 als auch GPT-5.5 und rangiert nur hinter Opus 4.8. Auf **SWE-Marathon**, einem Ultra-Long-Horizon-Software-Engineering-Benchmark, der Aufgaben wie das Bauen von Compilern, Kernel-Optimierung und die Entwicklung von Produktionsservices umfasst, hat GLM-5.2 noch Raum zum Wachsen, liegt 13% hinter Opus 4.8, bleibt aber Zweiter nur hinter der Opus-Serie. Über alle drei Benchmarks hinweg ist GLM-5.2 das höchstrangige Open-Source-Modell und zeigt, dass sein 1M-Kontext in praktische Long-Horizon-Lieferfähigkeit umgesetzt wurde.

Auf Standard-Coding-Benchmarks ist GLM-5.2 das stärkste Open-Source-Modell und verbessert sich gegenüber GLM-5.1 mit großem Abstand: 81,0 vs. 63,5 auf Terminal-Bench 2.1 und 62,1 vs. 58,4 auf SWE-bench Pro. Es schließt auch einen großen Teil der Lücke zur Closed-Source-Frontier — auf Terminal-Bench 2.1 (81,0) liegt es innerhalb weniger Punkte von Claude Opus 4.8 (85,0) — und bleibt vor Gemini 3.1 Pro.

GLM-5.2 führt auch **Effort-Level-Steuerung** ein, die es Benutzern ermöglicht, die Modellfähigkeit explizit gegen Aufgabenausführungsgeschwindigkeit und Rechenkosten abzuwägen. GLM-5.2 liefert wesentlich stärkere agentische Coding-Leistung als GLM-5.1 bei vergleichbaren Token-Budgets, wobei seine Fähigkeit etwa zwischen Claude Opus 4.7 und Claude Opus 4.8 bei ähnlichem Token-Verbrauch positioniert ist. Darüber hinaus ermöglicht das Max-Effort-Level den Benutzern, zusätzliche Berechnung zuzuweisen, wenn bei anspruchsvollen Aufgaben höhere Leistung erforderlich ist.

**Architektur für 1M-Kontext — IndexShare für DSA:** Um 1M-Kontextlänge zu unterstützen, wenden wir in GLM-5.2 IndexShare an, um die Rechenkosten des Indexers in DSA zu reduzieren. Konkret teilen sich in GLM-5.2 jeweils 4 Transformer-Schichten einen leichtgewichtigen Indexer. Der Indexer wird in der ersten von 4 Schichten platziert und TopK-Indizes werden für 4 Schichten verwendet. Dies reduziert die Berechnung des Indexer-Dot-Product und der TopK-Operation in 3/4 der Schichten.

**MTP mit IndexShare und KVShare:** Wir verbessern die MTP-Schicht von GLM-5.2 für spekulative Dekodierung mit zwei Zielen: 1) Minimierung der Kosten der MTP-Schicht als Draft-Modell; 2) Maximierung der Akzeptanzrate der spekulativen Dekodierung. Für das erste Ziel wenden wir IndexShare auch auf die MTP-Schicht an. In Multi-Step-MTP wird der Indexer im ersten Schritt platziert und TopK-Indizes werden für alle folgenden Schritte verwendet. Darüber hinaus führen wir, inspiriert von arXiv:2606.12370, Rejection Sampling für spekulative Dekodierung ein und verwenden End-to-End-TV-Loss für das Training. Die Tabelle zeigt die Ablation der Techniken nach Akzeptanzlänge in Coding-Szenarien. Im Vergleich zur Baseline erhöht sich die Akzeptanzlänge der finalen MTP-Schicht um 20% (von 4,56 auf 5,47).

**Effizientes Serving von 1M-Kontextlänge:** Da GLM-5.2 die maximale Kontextlänge von 200K auf 1M Tokens erweitert, wird erwartet, dass sich Coding-Workloads erheblich in Richtung längerer Prompts verschieben. Dies verlagert den primären Inference-Engpass von der Berechnung auf KV-Cache-Kapazität, Long-Context-Kernel-Overhead und CPU-seitigen Overhead. Um diese Herausforderung zu bewältigen, optimieren wir die Inference-Engine in drei Richtungen: feinere Speicherverwaltung und Parallelisierungsstrategien (aufbauend auf LayerSplit), optimierte Kernel und bessere Koordination mit der Cache-Transfer-Pipeline sowie CPU-seitige Cache-Verwaltung und Request-Scheduling.

**Slime für Agentic RL:** Das agentische RL-Post-Training von GLM-5.2 umfasst Aufgaben in größerem Maßstab, über mehr Domänen hinweg und mit komplexeren Ausführungsmustern. Slime dient als integrierte Infrastrukturschicht vom Training bis zum groß angelegten Inference-Rollout. Es unterstützt mehrere Trainings- und Aufgabenorganisationsmodi, einschließlich White-Box-Rollout, Black-Box-Rollout, Compact Trajectory und Sub-Agent-Workflow. Im Post-Training-Prozess von GLM-5.2 verwendeten wir das Slime-Framework, um paralleles OPD-Training durchzuführen und mehr als zehn Expertenmodelle effizient in das finale Modell zu fusionieren. Der gesamte OPD-Trainingsprozess dauerte etwa zwei Tage.

**RL für Long-Horizon-Aufgaben mit Anti-Hacking:** Für GLM-5.2 produzieren Long-Horizon-Aufgaben wesentlich längere Ausführungsspuren. Wir gehen daher von gruppenweiser Optimierung zu einer kritikerbasierten PPO-Formulierung über, die aus einzelnen Rollouts lernt. Coding-RL ist besonders anfällig für Reward-Hacking, da der Reward typischerweise ein verifizierbares Bestanden/Nicht-Bestanden-Signal ist. Wir stellen fest, dass GLM-5.2 mehr potenzielles Hacking-Verhalten zeigt als GLM-5.1. Um dem entgegenzuwirken, führen wir ein Anti-Hack-Modul sowohl für RL-Training als auch für Evaluation ein. Der Erkennungsprozess hat zwei Stufen: Ein regelbasierter Filter fängt zunächst potenzielle Hacks, um die Recall zu maximieren, und dann prüft ein LLM-Richter die Absicht dieser markierten Aktionen, um die Precision hoch zu halten.

**Vollständige Benchmark-Tabelle (Auszug):** GLM-5.2 erreicht 40,5 auf HLE, 99,2 auf AIME 2026, 91,2 auf GPQA-Diamond, 62,1 auf SWE-bench Pro, 81,0 auf Terminal-Bench 2.1, 74,4 auf FrontierSWE, 34,3 auf PostTrainBench, 13,0 auf SWE-Marathon und 76,8 auf MCP-Atlas.

**Lokale Nutzung:** Die Modellgewichte von GLM-5.2 sind öffentlich auf HuggingFace und ModelScope verfügbar. Für lokales Deployment unterstützt GLM-5.2 Inference-Frameworks wie transformers, vLLM, SGLang, xLLM und ktransformers.

---

## Story 2: Intel XPU Kernel Skill — LLM-getriebene Triton-Kernel-Optimierung für Intel Arc GPUs

**Teaser (Deutsch):** Intel und Hugging Face haben den „xpu-kernels skill" veröffentlicht — einen Agent-Skill, der es Coding-Agenten wie Claude Code ermöglicht, Triton-Kernel automatisch für Intel Arc Pro GPUs (Xe2) zu optimieren. Das zugrundeliegende Xe-Forge-System erreicht eine 1,26× geomean-Beschleunigung über 100 KernelBench-Level-2-Kernel, 2,8× auf vLLMs produktiven Attention- und MoE-Kerneln und bis zu 13,3× auf Flash Attention Forward. Der Skill ist als HuggingFace-Agent-Skill paketiert und kann ohne Klonen des vollständigen Projekts verwendet werden.

**Source-URL:** https://huggingface.co/blog/danf/intel-xpu-kernels-skill

**Volltext (Deutsche Übersetzung):**

Xe-Forge (Spoczynski et al., 2026) ist ein Intel-Projekt, das ein LLM verwendet, um Triton-Kernel für Intel Arc Pro GPUs (Xe2) zu optimieren. Es arbeitet durch eine Sequenz von Optimierungsstufen — Fusion, Dtype-Korrekturen, Speicherzugriff, Block Pointer, XPU-spezifisches Tuning, Autotuning — in einer Schleife namens CoVeR (Chain-of-Verification-and-Refinement), die jeden Kandidaten auf der GPU ausführt und iteriert, wenn einer fehlschlägt oder sich verschlechtert. Eine kleine Wissensbasis mit Xe2-spezifischen Mustern (Tensor-Deskriptoren, GRF-Modus 256, Tile-Swizzling) wird zu Beginn jeder Sitzung gelesen, da diese in LLM-Trainingsdaten nicht gut repräsentiert sind.

Auf der Arc Pro B70 liefert Xe-Forge eine **1,26× geomean-Beschleunigung** gegenüber PyTorch Eager über die gesamten 100 KernelBench-Level-2-Kernel (69% Gewinnrate), eine **2,8× geomean-Beschleunigung** gegenüber vLLMs produktiven Attention- und MoE-Triton-Kerneln und bis zu **13,3×** auf Flash Attention Forward.

Der **xpu-kernels skill** paketiert diese Engine — denselben Workflow, dieselben Tools und dieselbe Wissensbasis — als Agent-Skill, sodass ein Coding-Agent die Schleife ausführen kann, ohne das vollständige Projekt zu klonen. Man verweist ihn auf eine PyTorch-Referenz oder einen bereits handoptimierten Triton-Kernel, und er sucht nach XPU-bewussten Beschleunigungen.

**Warum ein Kernel-Skill:** Coding-Agenten und Compiler produzieren bereits zuverlässig *korrekte* Triton-Kernel. Die Lücke ist die Messen-Entscheiden-Neuschreiben-Schleife, die aus korrekt *schnell* macht — und, ebenso wichtig, aus schnell *schneller*, indem ein bereits optimierter Kernel als Baseline behandelt wird. Auf Xe2 ist diese Lücke aus zwei Gründen groß: Erstens sind die API-Entscheidungen, die auf Intel XPU wichtig sind (z.B. Tensor-Deskriptoren statt Block Pointer, grf_mode='256' für rechenintensive Kernel, GROUP_SIZE_M-Swizzling, die Regel gegen Autotuning von BLOCK_D), in LLM-Trainingsdaten unterrepräsentiert. Zweitens ist Kernel-Optimierung nicht eine Entscheidung — Tile-Größen, Dtype-Verträge, Fusionsgrenzen und Akkumulator-Präzision interagieren, sodass ein One-Shot-Rewrite normalerweise irgendwo Rückschritte macht.

**Die Trial-Schleife:** Die SKILL.md des Skills weist den Agenten an, scripts/config.yaml und die relevanten Referenzen zu lesen und dann eine strikte, tool-gesteuerte Schleife auszuführen. Der Agent schreibt ausschließlich Triton-Kernel-Dateien und muss alle max_trials aus config.yaml ausführen:
- **Analyze** — extrahiert Shapes, Dtypes, fusionierte Operationen und Fusionsmöglichkeiten
- **Initialize** — erstellt einen verzweigten Trial-Baum
- **Pro Trial: Validate** (nur CPU), **Save**, **Benchmark** (führt Baseline und Kandidat durch AI-Bench aus), **Profile** (optional, VTune), **Decide** (verbessert → auf diesem Zweig fortfahren; verschlechtert → zurück zum besten Trial; Plateau → grundlegend anderen Algorithmus versuchen)
- **Finalize** — der beste Trial wird als eigenständige `<name>_triton.py` kopiert

**Hardware:** Intel Arc Pro B70 (primär — Xe2, 32 Xe-Kerne, 32 GB GDDR6, 608 GB/s) und Battlemage G21 / Arc Pro B50 (ebenfalls verifiziert — Xe2).

**Evaluation:** Auf Flash Attention Forward (fp16) erreicht der Skill bis zu 13,3× Beschleunigung. Die optimierten Kernel erreichen konsistent ~60–80 TFLOPS, während die Original-Kernel bei langen Sequenzen auf ~5 TFLOPS abfallen. Auf vLLMs produktiven Triton-Kerneln (BatchedMoE, FusedMoE, UnifiedAttention) über 24 Konfigurationen aus Produktionsmodellen (Gemma2/3-27B, gpt-oss 20B, Llama3.1-8B, Llama3.3-70B, Llama4 Scout, Qwen2.5/3) ergibt sich eine **geometric-mean 2,8× Beschleunigung**. Der compute-gebundene Gemma3-27B-Prefill-Kernel erreicht die **160 TFLOPS-Spitze** auf der Arc Pro B70.

**Nutzung:** `pip install kernels`, dann `kernel-builder skills add --skill xpu-kernels --claude`. Der Agent optimiert den Kernel, und `kernel-builder` kompiliert und veröffentlicht ihn auf dem Hugging Face Kernel Hub. Geladen wird er mit `get_kernel(...)`.

---

## Story 3: Agentic Resource Discovery (ARD) — Neuer offener Standard für Agent-Tool-Discovery

**Teaser (Deutsch):** Microsoft, Google, GoDaddy, Hugging Face und weitere haben die „Agentic Resource Discovery" (ARD)-Spezifikation veröffentlicht — einen offenen Standard, der es KI-Agenten ermöglicht, zur Laufzeit dynamisch nach Tools, Skills und anderen Agenten zu suchen, statt sie vorinstalliert zu benötigen. Hugging Face hat mit dem „Discover Tool" eine Referenzimplementierung bereitgestellt, die Tausende von Skills, MCP-Servern und ML-Anwendungen durchsuchbar macht. Der Standard definiert ein statisches Manifest-Format (ai-catalog.json) und eine dynamische Registry-API (POST /search).

**Source-URL:** https://huggingface.co/blog/agentic-resource-discovery-launch

**Volltext (Deutsche Übersetzung):**

Wenn Sie heute mit Agenten bauen, kennen Sie wahrscheinlich drei Protokolle. MCP gibt Agenten eine standardisierte Möglichkeit, Tools aufzurufen. Skills geben Agenten eine Möglichkeit, Anweisungen zu konsumieren. A2A gibt Agenten eine Möglichkeit, andere Agenten aufzurufen. Alle drei setzen voraus, dass der Benutzer bereits weiß, welches Tool, welche Anweisung oder welchen Agenten er benötigt. Der Benutzer ist immer noch für das Entdecken, Integrieren und Warten dieser Fähigkeiten verantwortlich.

Die **Agentic Resource Discovery (ARD)**-Spezifikation ist die Discovery-Schicht, die davor sitzt. Es ist eine offene Draft-Spezifikation, entwickelt von Mitwirkenden von Microsoft, Google, GoDaddy, Hugging Face und anderen, mit breiter Beteiligung in der Industrie. Sie definiert, wie Agenten und Tools katalogisiert, indiziert und über föderierte Registries durchsucht werden, sodass ein Agent Fähigkeiten zur Laufzeit finden kann, statt sie vorinstalliert zu benötigen. Es ist kein Produkt oder Marktplatz. Es ist ein gemeinsamer Standard, den jedes Unternehmen unabhängig implementieren kann und an dem jeder Agent oder jedes Tool teilnehmen kann.

**Das Discovery-Problem:** Das aktuelle Modell für Agentenfähigkeiten ist „install-first, use-later". Ein Entwickler hardcodiert eine MCP-Server-URL in eine Config-Datei. Ein Benutzer verbindet einen Dienst mit seiner KI-App über ein Plugin und verwendet ihn wieder. Dies funktioniert für die Handvoll Tools, die ein Agent täglich nutzt, aber es skaliert nicht auf Tausende von Ad-hoc-Oberflächen. Der Fallback ist, jede verfügbare Tool-Beschreibung in das Kontextfenster des LLM zu werfen und das Modell auswählen zu lassen. Dies ist durch das Kontext-Budget begrenzt.

ARD verlagert die Auswahl aus dem LLM heraus. Eine Registry indiziert Fähigkeiten mit reichhaltigeren Signalen wie Publisher-Identität, repräsentativen Queries, Compliance-Bestätigungen und Tags. Sie exponiert einen REST-Endpunkt. Der Client sucht in natürlicher Sprache, und das Modell ruft auf, was auch immer die Suche zurückgibt. Der Wandel geht von manuell installierten, statischen Katalogen zu absichtsbasierter Suche.

Die Spezifikation definiert zwei Dinge:
- Ein statisches Manifest-Format namens **ai-catalog.json** ermöglicht es Publishern, ihre Fähigkeiten unter einer Well-Known-URL zu hosten.
- Eine dynamische Registry-API unter **POST /search** bietet live, gerankte Discovery.

**ARD auf dem Hugging Face Hub:** Das Hugging Face **Discover Tool** ist unsere Referenzimplementierung von ARD. Es bietet Suchzugriff auf Tausende von Skills, ML-Anwendungen und MCP-Servern — auf Hugging Face und über andere ARD-Discovery-Dienste hinweg. Es kombiniert die bestehende semantische Suche des Hubs über Spaces mit unseren Agent Skills und serviert die Ergebnisse als ARD-Katalogeinträge. Der Adapter wendet zwei Filter an: Nur Spaces im RUNNING-Stage werden zurückgegeben, und der Response-Medientyp wird durch den Request gesteuert. Drei Medientypen werden unterstützt: application/ai-skill (Standard), application/mcp-server+json und application/vnd.huggingface.space+json.

**Nutzung:** `discover` ist in die Hugging Face CLI (`hf`) integriert:
```bash
uv tool install huggingface_hub
hf discover search "Fine tune a language model"
hf discover search "Generate an image" --json --kind mcp
```

Die REST-API ist unter `POST https://huggingface-hf-discover.hf.space/search` verfügbar, und ein MCP-Endpunkt unter `https://huggingface-hf-discover.hf.space/mcp`.

**Bedeutung für die Spezifikation:** ARD trennt Discovery von Ausführung. Das statische Manifest-Format wird durch den Medientyp gesteuert, sodass jedes Artefakt-Protokoll denselben Umschlag ohne Änderungen auf Spezifikationsebene nutzen kann. Die Registry-API ist einfaches HTTP-REST, sodass jeder Client dagegen föderieren kann. Nächste Schritte sind engere Integration mit den Föderationsmodi der Spezifikation (auto, referrals, none) und Hub-seitige Unterstützung für statische ai-catalog.json-Manifeste auf Benutzer- und Organisationsprofilen.

---

## Story 4: MolmoMotion — Sprachgesteuerte 3D-Bewegungsvorhersage von Allen AI

**Teaser (Deutsch):** Allen AI (Ai2) hat MolmoMotion veröffentlicht, ein neues Modell zur sprachgesteuerten 3D-Bewegungsvorhersage. Basierend auf Molmo 2 sagt es aus einem Videobild, markierten 3D-Punkten und einer Textanweisung (z.B. „Bewege die Holzschale auf dem Tisch") präzise voraus, wie sich Objekte in den nächsten Sekunden im 3D-Raum bewegen werden. Zusammen mit dem Modell erscheint MolmoMotion-1M — der größte Datensatz von aktionsbeschriebenen 3D-Punkttrajektorien (1,16M Videos, 736 Bewegungstypen) — sowie PointMotionBench, ein menschlich validierter Benchmark. In Robotik-Simulationen erreicht eine auf MolmoMotion aufgebaute Steuerung 76,3% Erfolgsrate bei Pick-and-Place-Aufgaben (vs. 56,0% mit Molmo 2).

**Source-URL:** https://huggingface.co/blog/allenai/molmomotion

**Volltext (Deutsche Übersetzung):**

Maschinen sind bemerkenswert gut darin geworden, Bewegung wahrzunehmen. Mit einem Video können moderne Modelle verfolgen, wie sich Objekte und Punkte mit außergewöhnlich hoher Zuverlässigkeit durch eine Szene bewegen. Aber Wahrnehmung ist inhärent retrospektiv: Sie erklärt Bewegung, die bereits stattgefunden hat. Viele der Systeme und Anwendungen, die wir bauen wollen, müssen stattdessen *nach vorne schauen*. Ein Roboter, der nach einer Tasse greift, muss antizipieren, wie sich die Tasse bewegen wird, bevor er sie berührt. Ein Videogenerator muss wissen, welche realistische Bewegung als nächstes kommt.

Diese Idee war die Motivation hinter **MolmoMotion**, einem neuen Bewegungsvorhersagemodell, das wir heute veröffentlichen. Gegeben ein Videobild, 3D-Punkte, die auf einem Objekt markiert sind, und schriftliche Anweisungen, die die beabsichtigte Aktion beschreiben (z.B. „Bewege und rotiere die Holzschale mit Obst auf dem Tisch"), sagt MolmoMotion voraus, wohin sich diese Punkte in den nächsten Sekunden im 3D-Raum bewegen werden — und erreicht eine wesentlich stärkere Leistung als bestehende Vorhersagemethoden.

Zusammen mit dem Modell veröffentlichen wir **MolmoMotion-1M**, die größte Sammlung von 3D-Punkttrajektorien gepaart mit Aktionsbeschreibungen, aus 1,16M Videos. Wir veröffentlichen auch **PointMotionBench**, einen menschlich validierten Benchmark zur Messung der objektzentrierten 3D-Bewegungsvorhersagegenauigkeit mit 2,7K Videoclips.

**Unter der Haube:** MolmoMotion repräsentiert Bewegung auf eine bewusste, hocheffiziente Weise: als objektgebundene 3D-Punkte im Weltraum, die Bewegung ohne die Kosten des Renderns vollständiger Videos erfassen. Wir wählten dies, weil wir eine allgemeine Bewegungsrepräsentation mit drei Eigenschaften brauchten: klassenagnostisch (nicht an Templates für menschliche Körper, Hände, starre Objekte oder andere feste Kategorien gebunden), blickstabil (dieselbe physische Bewegung sollte konsistent über Kameras und Blickwinkel hinweg repräsentiert werden) und direkt nutzbar durch nachgelagerte Systeme.

Um diese Trajektorien vorherzusagen, verwendet MolmoMotion Molmo 2 als Backbone, was es ihm ermöglicht, Sprachanweisungen mit Objekten und Punkten in einem Bild zu verbinden. Wir trainieren zwei Varianten: Die autoregressive Variante (MolmoMotion-AR) sagt zukünftige Koordinaten Schritt für Schritt voraus und gibt die stärkste Genauigkeit, wenn der zukünftige Pfad gut definiert ist. Die Flow-Matching-Variante (MolmoMotion-FM) sagt Trajektorien im kontinuierlichen 3D-Raum voraus, indem sie Rauschen in Bewegung transformiert, was sie besser geeignet macht, Unsicherheit darzustellen.

**Datenpipeline:** Um MolmoMotion zu trainieren, brauchten wir Daten, die noch nicht existierten: groß angelegte Videos mit 3D-Punkttrajektorien, die auf bestimmte Objekte bezogen und mit Aktionsbeschreibungen gepaart sind. Wir bauten eine automatische Pipeline, die objektgebundene 3D-Trajektorien aus unbeschränktem Video extrahiert. Rohdaten aus unbeschränktem Video sind verrauscht — mit Tiefen- und Tracking-Fehlern. Um die Daten vertrauenswürdiger zu machen, filtern wir Punkte heraus, die sich nicht kohärent mit dem Rest des Objekts bewegen, glätten die verbleibenden Trajektorien und segmentieren jeden Clip auf das Fenster, in dem sich das Objekt tatsächlich bewegt. Die Pipeline im großen Maßstab ausgeführt ergab MolmoMotion-1M — unseres Wissens das größte Korpus von aktionsbeschriebenen, objektgebundenen 3D-Punkttrajektorien, das bisher zusammengestellt wurde, mit 736 Bewegungstypen und 5,6K verschiedenen Objekten.

**Experimente und Leistung:** Auf PointMotionBench übertrifft MolmoMotion alle existierenden 3D-Bewegungsvorhersagemethoden, die wir getestet haben. In der Robotik: Nach Fine-Tuning auf DROID, einem großen offenen Datensatz von realen Robotermanipulationsvideos, kann MolmoMotion sinnvolle Objektpfade über verschiedene Objekte, Kamerablickwinkel, Szenen und Aufgaben hinweg vorhersagen. In der Simulation erreicht eine auf MolmoMotion aufgebaute Steuerungspolitik 76,3% Erfolg bei Pick-and-Place-Aufgaben gegenüber 56,0% für dieselbe Politik, die auf Molmo 2 aufbaut — und sie lernt schneller. Auf echten Robotern (nach Fine-Tuning) erreicht MolmoMotion denselben Test-L2-Fehler, den die Molmo 2-Baseline nach 12K Trainingsschritten erreicht, in nur etwa 2K Schritten. In der Videogenerierung verbessert MolmoMotion die Bewegungsqualität gegenüber dem Basismodell auf allen fünf bewegungsbezogenen Metriken.

---

## Story 5: Strands Agents + LeRobot — Von HuggingFace-Datasets direkt auf Roboter-Hardware

**Teaser (Deutsch):** Amazon/AWS hat „Strands Robots" veröffentlicht, ein Open-Source-SDK (Apache 2.0), das Roboter-Abstraktionen, Simulation und den LeRobot-Stack als AgentTools in einem einzigen Strands-Agenten vereint. Der Clou: Ein Dataset auf dem Hugging Face Hub kann mit einem einzigen Keyword-Argument-Wechsel (mode="real" statt mode="sim") direkt auf physische Roboter (SO-101) deployed werden. Die Integration unterstützt GR00T- und MolmoAct2-Checkpoints sowie eine Peer-Mesh-Architektur zur Koordination ganzer Roboterflotten über Zenoh.

**Source-URL:** https://huggingface.co/blog/amazon/strands-lerobot-hub-to-hardware

**Volltext (Deutsche Übersetzung):**

Sie haben einen Roboter, einen Ordner mit Demonstrationsdaten auf dem Hugging Face Hub und eine neue Aufgabe, die er lernen soll. Heute braucht das fünf separate Tools: eines zum Aufzeichnen neuer Demonstrationen, ein anderes zum Trainieren, ein drittes zum Testen in der Simulation, benutzerdefinierten Code zum Deployment auf Hardware und noch ein weiteres zur Koordination, wenn Sie mehr als einen Roboter haben. Die Teile funktionieren für sich allein. Sie kommunizieren nicht miteinander.

**Strands Robots** ist ein Open-Source-SDK von AWS (Apache 2.0), das Roboter-Abstraktionen, Simulation und den LeRobot-Stack als AgentTools exponiert, die Sie zu einem einzigen Strands-Agenten zusammensetzen. Die Integration ist bewusst dünn: LeRobots eigene Skripte übernehmen Hardware-Aufzeichnung und Kalibrierung, und die Strands-AgentTools kommen für die Teile ins Spiel, die ein Agent tatsächlich orchestriert. Das Simulationstool zeichnet LeRobotDatasets im selben Format auf, das LeRobot auf Hardware schreibt. GR00T und LerobotLocal servieren Policy-Inference hinter einem gemeinsamen Interface, und MolmoAct2-Checkpoints laufen über den LerobotLocal-Pfad. Ein Peer-Mesh fächert den Agenten auf entfernte Roboter aus. Das Dataset-Format bleibt genau so, wie LeRobot es geschrieben hat; die Agent-Schleife ist der Kleber.

**Was Sie bauen werden:** Das Strands Robots SDK exponiert den LeRobot-Stack als AgentTools, die Sie zu einem Strands-Agenten zusammensetzen. Der Beispiel-Agent in diesem Post macht vier Dinge: neue Demonstrationen in Simulation aufzeichnen, das Ergebnis als LeRobotDataset auf den Hub pushen, eine Policy in Simulation gegen dasselbe Format ausführen und denselben Agent-Code mit einem Keyword-Argument-Wechsel auf einen physischen Roboter deployen. Wenn Sie mehr als einen Roboter haben, kann der Agent die gesamte Flotte durch ein eingebautes Peer-Mesh koordinieren.

**Schritt 1 — Beispiel einrichten:** Klonen Sie das Repository und richten Sie die Umgebung ein.
**Schritt 2 — Demonstrationen aufzeichnen und auf den Hub pushen:** `Robot("so100")` verwendet standardmäßig eine MuJoCo-gestützte Simulation; `mode="real"` gibt einen Hardware-Roboter zurück, der von LeRobot gesteuert wird. Beide Modi teilen sich denselben DatasetRecorder und dieselben Policy-Provider, sodass ein in Sim erfasstes Dataset und ein auf Hardware erfasstes Dataset dasselbe On-Disk-LeRobotDataset-Format verwenden.
**Schritt 3 — Policy in Simulation ausführen:** Policies werden über einen gemeinsamen `PolicyProvider` geladen, der GR00T-Checkpoints, MolmoAct2 und LerobotLocal-Policies unterstützt.
**Schritt 4 — Policy auf physische Hardware deployen:** Derselbe Agent-Code wird mit `mode="real"` auf einen physischen SO-101-Roboter deployed.
**Schritt 5 — Mehrere Roboter mit dem Mesh koordinieren:** Das Zenoh-basierte Peer-Mesh ermöglicht die Koordination einer Roboterflotte.

**Sicherheit:** Die Simulation läuft vollständig lokal. Für Hardware-Deployment sind LeRobot-Kalibrierungs- und Sicherheitsverfahren zu befolgen.

**Ausblick:** Die Integration zeigt, wie der Hugging Face Hub als zentrale Drehscheibe für Robotik-Daten und -Policies dienen kann — von der Aufzeichnung über das Training bis zum Deployment auf physischer Hardware, alles innerhalb einer einzigen Agent-Schleife.

---

## Zusammenfassung

| # | Story | Kategorie | Relevanz |
|---|-------|-----------|----------|
| 1 | **GLM-5.2** — Open-Source-Modell mit 1M-Kontext, MIT-Lizenz, konkurriert mit Claude Opus 4.8 | Modell-Release (lokal + Cloud) | 🔥🔥🔥🔥🔥 |
| 2 | **Intel XPU Kernel Skill** — LLM-gesteuerte Kernel-Optimierung für Intel Arc GPUs | Open-Source-Tooling für Consumer-Hardware | 🔥🔥🔥🔥 |
| 3 | **ARD-Spezifikation** — Offener Standard für Agent-Tool-Discovery (Microsoft, Google, HF) | Cloud-API / Agent-Infrastruktur | 🔥🔥🔥🔥 |
| 4 | **MolmoMotion** — Sprachgesteuerte 3D-Bewegungsvorhersage (Allen AI) | Modell-Release + Robotik | 🔥🔥🔥 |
| 5 | **Strands + LeRobot** — Hub-zu-Hardware-Robotik-Integration (AWS) | Cloud/Edge-Infrastruktur | 🔥🔥🔥 |

**Quellen:** HuggingFace Blog (5 Stories), HN Algolia API (keine relevanten Treffer für 17.-18. Juni), Reddit r/LocalLLaMA (durch Netzwerksicherheit blockiert), Anthropic/OpenAI/Meta/Mistral/DeepMind-Blogs (keine neuen Posts vom 17.-18. Juni gefunden).