Die Revision 1.6 ist die neuere Variante. Wenn Sie heute ein Embodied-Reasoning-Projekt gegen die Google Gemini API starten, ist dies das Modell, das Sie evaluieren sollten; Version 1.5 bleibt hauptsächlich verfügbar, weil einige Forschungscodebases darauf fixiert sind. Gleiches Einsatzgebiet — Robotik, szenenbasierte Planung, Intent-to-Plan-Übersetzung — unterschiedliche Revision, unterschiedliches praktisches Profil.
Die zentrale Änderung in 1.6 gegenüber 1.5 ist das Kontextfenster. Google hat das Fenster von 1.048.576 Token auf 131.072 reduziert. Das wirkt wie ein Rückschritt und auf dem Papier ist es das auch, aber in der Praxis nutzen ER-Anwendungsfälle selten einen Millionen-Token-Kontext, und das kleinere Fenster liefert messbar besseres Recall und schnellere Durchlaufzeiten. Der Trade-off, den Sie bekommen.
Was ist neu in 1.6
Engerer Kontext, schärfere Aufmerksamkeit. Das 128K-Fenster reicht problemlos für einen mehrsekündigen Wahrnehmungspuffer, mehrere Scene-Memory-Turns und eine ausführliche Zielvorgabe. Die Recall- und Grounding-Qualität über die gesamte Spanne ist stärker als bei 1.5, was die Neuausrichtung war, die Google anstrebte.
Besseres Instruction-Following bei mehrstufigen Plänen. Das 1.5-Modell produzierte häufig vernünftige erste Schritte und driftete dann bei späteren Schritten in verketteten Abläufen ab — 1.6 ist konsistenter über längere Planhorizonte hinweg.
Saubererer strukturierter Output. JSON-Schema-Durchsetzung bei Planausgaben ist zuverlässiger. Teams, die Schema-validierte Adapter um 1.5 herum gebaut hatten, berichteten von niedrigeren Retry-Raten nach der Migration auf 1.6.
Andere Prompt-Muster. Googles empfohlene Prompting-Strategien rund um Szenenbeschreibung, Action-Space-Deklaration und Constraint-Spezifikation haben sich zwischen den Revisionen geändert. Dokumentation, die für 1.5 funktionierte, muss beim Portieren auf 1.6 überprüft werden.
Was sich nicht geändert hat
Das Modell ist immer noch auf Preview-Niveau. Output-Strukturen können sich zwischen Revisionen verschieben; die Produktionshaltung sollte mit Drift rechnen.
Es ist immer noch keine Regelschleife. ER arbeitet oberhalb von Motion-Planning, nicht innerhalb. Die Latenz-Untergrenze im 100ms-Bereich macht das unvermeidbar.
Es ist immer noch auf Embodied-Reasoning spezialisiert. Allzweck-Aufgaben werden schlechtere Ergebnisse liefern als das, was gemini-pro-latest Ihnen für denselben Prompt geben würde.
Die Integrationskosten sind immer noch hoch. Der Perception-to-Prompt-Formatter, der Plan-to-Controller-Adapter und der Safety-Verifier müssen immer noch von Ihnen gebaut werden.
Wofür es gedacht ist
Die gleichen drei Kategorien, die 1.5 rechtfertigten, gelten weiterhin.
Forschung. Embodied-AI-Labore, die gegen Frontier-Modelle benchmarken, Instruction-Following-Evaluierungen in Simulation (Habitat, RoboCasa, BEHAVIOR), Long-Horizon-Manipulationsarbeit.
Industrielle Pilot-Deployments, wo die Wahrnehmungsschicht ausgereift ist und die Variation zielgetrieben ist. Pick-and-Place oberhalb von skriptgesteuerter Automatisierung. Bin-Picking, wo die Objekte variieren, die Arbeitszelle aber nicht.
Telerobotics und Human-in-the-Loop-Steuerung. Operatoren drücken Intent in natürlicher Sprache aus; das Modell konvertiert zu Constraints, gegen die die Autonomie-Schicht planen kann.
Wo es Schwächen zeigt
Neuartige Verkörperungen. Trainiert auf einem kuratierten Robotik-Datenmix, der in Richtung Arm-und-Greifer-Morphologien tendiert. Vierbeinige Roboter, Humanoide, Soft-Roboter — die Qualität sinkt, manchmal stillschweigend.
Dynamische Multi-Agent-Szenen. Überfüllte Lagerhallen, Küchen mit sich bewegenden Menschen, überall wo sich die Szene schneller ändert als die Wahrnehmungsschleife sie meldet — die Pläne des Modells setzen mehr Determinismus voraus als die Realität bietet.
Sicherheit. Wie bei 1.5: nichts im Modell grenzt den Output formal ein. Der Verifier sitzt in Ihrem Stack, nicht bei Google.
Plattformübergreifende Portabilität. Pläne werden in einem generalisierten Koordinatenraum ausgedrückt, der Adapter-Code pro Roboter benötigt. Die Demos verbergen das.
Preview-Risiko. Google hat Preview-Endpoints in anderen Gemini-Linien mit begrenzter Vorankündigung eingestellt. Planen Sie für eine Migration, wenn 1.7 oder dessen Nicht-Preview-Nachfolger erscheint.
Wann 1.6 statt 1.5 verwenden
Standard für neue Arbeiten sollte 1.6 sein. Die Verbesserungen bei Planhorizont-Konsistenz und Structured-Output-Zuverlässigkeit sind in der Praxis wichtiger als die 1M-Token-Obergrenze es war. Bleiben Sie nur bei 1.5, wenn:
- Ihre Codebasis darauf fixiert ist und die Migrationskosten das Qualitätsdelta überwiegen.
- Sie einen spezifischen Anwendungsfall haben, der tatsächlich das Millionen-Token-Fenster ausreizt (selten in der Robotik).
- Reproduzierbarkeit gegenüber veröffentlichten Forschungsergebnissen die ältere Revision erfordert.
Wann ER überhaupt nicht verwenden
Wenn die Aufgabe nicht embodied ist — physische Weltziele, Sensorinputs, Aktionsoutputs — greifen Sie zu gemini-pro-latest oder einem anderen Allzweck-Modell. ER ist bei allem, was nicht Robotik ist, schlechter als Pro, absichtlich.
Wenn das Deployment sicherheitskritisch ist und Sie keine Verhaltensänderungen auf Preview-Niveau akzeptieren können, schauen Sie sich selbst gehostete Alternativen an, wo Sie die Modellversion kontrollieren. OpenVLA ist der offensichtliche Startpunkt; Physical Intelligence-Modelle, wenn Sie über Partnerschaft Zugang bekommen können.
Wenn Sie On-Device- oder Near-Device-Inferenz für Latenzanforderungen in einer steuerungsnahen Schleife brauchen, hat ER die falsche Form. Destillierte VLA-Modelle, die auf einem Jetson oder einem äquivalenten Edge-Accelerator laufen, sind das Gespräch.
Erwähnenswerte Alternativen
OpenVLA. 7B Parameter, offene Weights, lauffähig auf einer einzelnen H100, trainiert auf dem Open X-Embodiment-Dataset. Die Referenz-Open-Baseline für VLA-Forschung.
Physical Intelligence pi0-Familie. Stärkste öffentlich diskutierte proprietäre Alternative bei Manipulationsbreite.
NVIDIA Project GR00T. Foundation-Modelle für humanoide Robotik; anderer Morphologie-Fokus, überlappender technischer Ansatz.
Figure Helix. Geschlossenes Modell von Figure, demonstriert auf ihrer Humanoid-Plattform. Kein vergleichbares API-Angebot, aber verfolgungswürdig als Capability-Marker.
Praktische Hinweise
Lesen Sie die Prompting-Anleitung neu, wenn Sie von 1.5 auf 1.6 wechseln. Das empfohlene Szenenbeschreibungsformat und das Action-Space-Schema haben sich geändert.
Revalidieren Sie Ihren Structured-Output-Adapter. Selbst mit den Schema-Following-Verbesserungen können Edge-Cases, die auf 1.5 funktionierten, auf 1.6 andere Strukturen produzieren.
Loggen Sie die Modellrevision bei jedem Aufruf. Wenn Google den Preview-Endpoint rotiert, ist die Korrelation zwischen Verhaltensänderung und Revisionsänderung die einzige Möglichkeit zum Debuggen.
Die ehrliche Zusammenfassung: Robotics-ER 1.6 Preview ist die bessere der beiden Preview-Revisionen für neue Robotik-Arbeit, mit den gleichen Vorbehalten hinsichtlich Spezialisierung, Preview-Risiko und Integrationskosten, die für die gesamte Familie gelten.
