Asana senkt die Kosten für KI-Ausführungen auf ein Sechsundsiebzigstel – die Verlaufsverwaltung ist entscheidend

Asana hat bekannt gegeben, dass die geschätzten Modellkosten bei einem Test zur Optimierung der Browser-KI von StackAI mit einer Konfiguration auf Basis von GPT‑6.1 Sol durchschnittlich 0,47 US-Dollar pro Durchlauf betrugen. Die Ausführung dauerte etwa 4 Minuten. Gegenüber der ursprünglichen Produktivkonfiguration sanken die Kosten auf rund ein Sechsundsiebzigstel, während die Verarbeitung etwa fünfmal schneller wurde.

Die Senkung auf ein Sechsundsiebzigstel lag nicht allein am Modellwechsel

Eine Webseite öffnen, die benötigten Informationen finden und ein Formular ausfüllen: Browser-Agenten, die solche Aufgaben übernehmen, rufen während der Arbeit wiederholt ein Modell auf – anders als eine KI, die eine Antwort nur einmal generiert. Bei StackAI, das Asana übernommen hat, können Kunden Automatisierungsabläufe über mehrere Geschäftsanwendungen hinweg erstellen, ohne Code zu schreiben.

Wichtig bei diesen Zahlen ist, dass in der Kostensenkung auf rund ein Sechsundsiebzigstel sowohl Verbesserungen des Ablaufs als auch der Modellwechsel stecken. Schon mit dem zunächst verwendeten Modell B sanken die geschätzten Modellkosten pro Durchlauf durch Optimierungen von mehr als 36,21 US-Dollar auf 1,24 US-Dollar. Mit GPT‑6.1 Sol gingen sie anschließend auf 0,47 US-Dollar zurück. Ein großer Teil der Einsparung wurde also bereits vor dem Modellwechsel erzielt.

Bei den Kosten handelt es sich um geschätzte Ausgaben für die Modellnutzung. Das bedeutet nicht, dass die Gesamtkosten im gleichen Verhältnis gesunken sind – darin sind etwa Serverkosten sowie Personalaufwand für Entwicklung und Betrieb nicht enthalten.

Wird der Verlauf zu stark gekürzt, liest die KI dieselbe Seite erneut

Frank Hidalgo, CTO von StackAI, beauftragte GPT‑6 Astra in Codex mit der Analyse des Codes und der Überprüfung von Verbesserungsvorschlägen. Dabei fiel unter anderem auf, dass der Seiteninhalt und der Verlauf der Screenshots bei jeder Anfrage an das Modell erneut übermittelt wurden. Feste Anweisungen und ähnliche Angaben ließen sich zwar wiederverwenden, für den stetig wachsenden Browserverlauf galt das jedoch nicht.

Außerdem wurden fast bei jedem Schritt alte Bilder gelöscht und der Text gekürzt. Wird der Verlauf häufig verändert, kann der Cache bereits verarbeitete Eingaben schlechter wiederverwenden, um Kosten zu senken. Werden zu viele Informationen entfernt, könnte die KI bereits gelesene Seiten erneut aufrufen. Der Versuch, Eingaben zu verkürzen, konnte so paradoxerweise zusätzlichen Aufwand verursachen.

Bilder nicht jedes Mal löschen, sondern erst nach 20 gespeicherten Screenshots aufräumen

Im Test wurde die Obergrenze für den gespeicherten Verlauf auf 120.000 beziehungsweise 480.000 Zeichen festgelegt. Außerdem änderte das Team die Einstellungen für Cache und Bildverwaltung und führte insgesamt 144 Durchläufe mit vier Modellen aus. Die Aufgabe war jeweils dieselbe: Aus einem öffentlichen Demo-Katalog sollten zu 32 Büchern jeweils sechs Angaben gesammelt werden.

In der optimierten Konfiguration mit GPT‑6.1 Sol wurden zunächst bis zu 20 Screenshots gespeichert; danach blieb nur der neueste erhalten. Statt die Bilder bei jedem Schritt zu löschen, wurden sie gebündelt aufgeräumt. So ließ sich der Zeitraum verlängern, in dem der Verlauf unverändert wiederverwendet werden konnte.

Auch im direkten Vergleich mit GPT‑6.1 Sol sanken die geschätzten Modellkosten von 1,97 auf 0,47 US-Dollar, als bei einer höheren Verlaufsobergrenze Cache und Bildverwaltung angepasst wurden. Nach der Optimierung liefen 89 Prozent der Eingaben über den Cache; für diesen Anteil fielen nur fünf Prozent der Kosten regulärer Eingaben an. Entscheidend war nicht, einfach Informationen zu reduzieren, sondern die verbleibenden Informationen so zu gestalten, dass sie sich leichter wiederverwenden ließen.

Nicht nur die Kosten, auch die Abschlussrate änderte sich

Die Verlaufsverwaltung wirkte sich auch darauf aus, ob die Aufgabe abgeschlossen werden konnte. Mit GPT‑6.1 Sol wurde bei einer niedrigeren Obergrenze nur in drei von 18 Durchläufen eine Antwort generiert. Bei einer höheren Obergrenze gelang dies in allen 18 Durchläufen; laut Angaben waren sämtliche Ergebnisse korrekt.

Bei den Vergleichen von rund einem Sechsundsiebzigstel der Kosten und etwa fünffacher Geschwindigkeit ist jedoch Vorsicht geboten. In der ursprünglichen Konfiguration erreichten einige Durchläufe die Schrittbegrenzung, bevor die Aufgabe abgeschlossen war. Die Werte von mehr als 36,21 US-Dollar und mehr als 22,5 Minuten sind daher Untergrenzen. Auch die zentralen Vergleichswerte sind Durchschnittswerte aus jeweils drei Durchläufen pro Konfiguration und beziehen sich auf die hier getestete Rechercheaufgabe. Daraus lässt sich nicht ableiten, dass sich bei anderen Websites oder Arbeitsabläufen dieselbe Einsparung erzielen lässt.

Auch die Stärken unterscheiden sich je nach Modell. Das optimierte Modell C kostete 0,66 US-Dollar und benötigte 3,5 Minuten. Damit war es teurer als GPT‑6.1 Sol mit 0,47 US-Dollar und etwa 4 Minuten, aber schneller. Bei der Einführung sollten Kosten und Geschwindigkeit daher getrennt verglichen werden.

Die KI führt die Experimente durch, Menschen prüfen die Änderungen

GPT‑6 Astra machte nicht nur Verbesserungsvorschläge, sondern änderte auch den Code, um die Versuchsbedingungen anzugleichen, und führte die Tests aus. Eine separate Modellsitzung überprüfte die Arbeit; Anfragen und Ergebnisse wurden in Asanas Entwicklungsplattform Command protokolliert. Hidalgo zufolge nahm eine Untersuchung, für die bei manueller Arbeit ein bis zwei Monate veranschlagt worden wären, etwa eine Woche in Anspruch. Diese Zeitangabe beruht auf der Einschätzung des Verantwortlichen und nicht auf einem Vergleichsexperiment mit menschlicher Arbeit.

Der Fall zeigt, dass es bei den Betriebskosten von KI neben dem Preis pro Modellaufruf auch Spielraum gibt, die Art der Aufrufe und die Verwaltung des Verlaufs zu untersuchen. Asana hat die Änderungen in die Browserbedienungsfunktion von StackAI übernommen. Künftig sollen Tests in die Evaluierungsfunktion integriert werden, damit Kunden und interne Teams Kosten, Ausführungszeit und Antwortqualität je nach Konfiguration vergleichen können.