Google stellt Gemini 4 Argon vor: Code-Modernisierung braucht den richtigen Vergleich
Kurzfassung
Gemini 4 Argon erhöht das Ausgabelimit auf 1M Tokens und startet bei vertrauenswürdigen Cyberverteidigern. Das libgav1-Beispiel zeigt eine schnellere Rust-Portierung; der Faktor 2,7 bezieht sich jedoch nicht auf das optimierte C++-Original.
Google hat Gemini 4 Argon vorgestellt und gezeigt, wie Agenten eine Rust-Portierung des Videodecoders libgav1 verbessern. Daraus ergibt sich eine konkrete Prüfbedingung: Wer ein bestehendes C++-System ersetzen möchte, sollte dessen Leistungs- und Kompatibilitätsanforderungen beibehalten. Eine Beschleunigung gegenüber der ersten Portierung rechtfertigt allein noch keinen Austausch der produktiven Implementierung.Offizielles Beispiel
Die Ankündigung trägt das Datum 2026-09-30, nennt aber weder Uhrzeit noch Zeitzone. VentureBeat: 30. September, 13:23 PDT; in Taipeh 1. Oktober, 04:23. Dieser Artikel erscheint zum Taipeh-Datum 1. Oktober mit Rechercheschluss um 09:12. Er behandelt eine über Nacht neu bekannt gewordene Entwicklung; die Veröffentlichungszeit des Berichts ist kein Nachweis für den genauen Beginn des Modellzugangs.Ankündigungsdatum Berichtszeit
Argon erhöht das Ausgabelimit von 64K auf 1M Tokens und schafft damit mehr Raum für Denken und Generierung innerhalb eines Durchlaufs. Diese Kapazität bedeutet nicht, dass jede Anfrage eine Million Tokens brauchbaren Codes liefert. Zunächst erhalten vertrauenswürdige Cyberverteidiger im Fairwind-Programm Zugang. Zahlende API-Kunden und Abonnenten von Google AI Ultra müssen noch warten; ein konkreter Termin fehlt.Spezifikationen und Zugang Unabhängige Bestätigung
Google nennt API-Einführungspreise von 2 Dollar je Million Eingabe-Tokens und 10 Dollar je Million Ausgabe-Tokens. Danach sollen 4 beziehungsweise 20 Dollar gelten; die Dauer des Angebots bleibt offen. Bei langen Aufgaben bestimmt die tatsächliche Nutzung die Rechnung. Aus einem höheren Ausgabelimit lässt sich kein Migrationsbudget ableiten.Preise Preisabgleich
Der libgav1-Vergleich beginnt bei einer bestehenden Rust-Portierung
Laut Google führten die Agenten wiederholt Profiling-Experimente durch, untersuchten die Compilerausgabe und ersetzten 32K Zeilen SIMD-Code durch sicheren Rust-Code, den der Compiler automatisch vektorisieren konnte. Bei identischer Videoausgabe lief das Ergebnis 2,7-mal so schnell wie die bisherige Rust-Portierung und näherte sich dem optimierten C++ an. Das Anbieterbeispiel belegt weder einen Vorsprung gegenüber C++ noch denselben Gewinn auf jeder Hardware.Vorgehen Abgleich des Beispiels
Für Produktteams ist daran die Optimierung nach einer bereits erfolgten Portierung interessant. Angenommen, eine Neufassung ist fertig, aber zu langsam, um die alte Implementierung zu ersetzen. Ein Agent, der Messwerte wiederholt auswertet und den Code anpasst, könnte diese festgefahrene Arbeit wieder voranbringen. Mehr Ausgabekapazität bietet zusätzlichen Arbeitsraum. Ob die Experimente den Leistungsabstand tatsächlich verkleinern, entscheidet über dessen Nutzen.
Ich würde diese Fähigkeit für Komponenten erwägen, deren Verhalten klar beschrieben ist und deren Neufassung einen Wartungs- oder Speichersicherheitsgrund hat. Das Original liefert den Vergleich; vorhandene Tests bewahren die vom Produkt geforderten Nutzungsszenarien. Ohne definiertes Sollverhalten erschwert mehr erzeugter Code die Entscheidung, welche Abweichungen akzeptabel sind. Diese Produktentscheidung folgt aus dem Beispiel. Google hat damit nicht bewiesen, dass jedes Altsystem neu geschrieben werden sollte.
Die produktive Implementierung bleibt der Maßstab
Auch Googles Bewertungstabelle zeigt Unterschiede je nach Aufgabe: Argon erreicht 77,9 Prozent auf DeepSWE v1.1, aber 55,0 Prozent auf FrontierSWE v2, gegenüber 65,5 Prozent für GPT-6 Astra. Das sind unterschiedliche Tests. Keine dieser Zahlen ist eine Fertigstellungsquote für ein vollständiges Softwareprojekt.Offizielle Bewertungstabelle
Eine flächendeckende Neufassung würde ich deshalb nicht mit einer einzelnen Beschleunigungszahl begründen. Wenn die Beseitigung bestimmter Speicherrisiken Vorrang hat, sollten die Produktanforderungen festlegen, welche Leistungseinbußen akzeptabel wären. Liegt die Latenz bereits nahe an der Grenze, muss die derzeit produktive Version als Vergleich dienen. Zum Nutzen einer Migration gehört außerdem die spätere Wartung. Für typische Teams nennt die Ankündigung keine langfristigen Wartungskosten.
Google zufolge durchlaufen größere Neufassungen vor dem Produktiveinsatz weiterhin automatische und manuelle Audits, Emulationstests und Prüfungen. Als Nächstes wären Daten darüber hilfreich, ob migrierte Komponenten unter unveränderten Kompatibilitätsanforderungen ihre Leistung in produktiven Arbeitslasten halten und weniger Wartungsaufwand verursachen. Libgav1 demonstriert Verbesserungen nach einer Portierung. Für den Austausch eines vollständigen Systems müssen diese Bedingungen noch geklärt werden.Grenzen des Einsatzes
Quellen:
Verwandte Artikel
Google startet Gemini 3.8 Live: Gesprochene Fortschrittsmeldungen müssen helfen
Gemini 3.8 Live und die Variante mit erweitertem Denken sind über die API allgemein verfügbar und unterstützen 97 Sprachen. Hintergrunddenken kann Stille verkürzen; hilfreiche Meldungen, Aufgabenstatus und Audiokosten bestimmen den Nutzen.
Google veröffentlicht Gemini 3.7 Flash: Halbpreis bis Jahresende, Agentenkosten hängen weiter von Wiederholungen ab
Google positioniert Gemini 3.7 Flash als Arbeitsmodell für Programmierung und KI-Agenten, mit höheren Anbieter-Benchmarks und vorübergehend halbiertem Preis; Architektur, Training und Wiederholungsraten im Betrieb bleiben offen.