AesCode 8B: So schätzen Sie die Kosten einer Aufgabe zur ästhetischen Codegenerierung

Warum die Kosten pro Token nicht ausreichen

Die Kosten für die Erzeugung einer Seite mit AesCode 8B lassen sich nicht unbedingt auf die Ein- und Ausgabetokens reduzieren. Das Modell erzeugt strukturierte visuelle Artefakte in HTML und CSS. Der vom Projekt beschriebene Ablauf rendert das Ergebnis außerdem in einem Browser und prüft Eigenschaften des Codes und der Seite. Erfüllt ein Ergebnis die festgelegten Kriterien nicht, kann ein Team es korrigieren oder eine neue Version erzeugen lassen.

Deshalb sollten Sie die Kosten für Inferenz, Verifikation und Iterationen getrennt betrachten. Bei einer lokalen Bereitstellung können dafür unterschiedliche Ressourcen anfallen: Für die Inferenz kann eine GPU nötig sein, während Rendering und bestimmte Prüfungen CPU, Arbeitsspeicher und einen Browser beanspruchen können. Die wirtschaftlichen Kosten hängen davon ab, wie diese Ressourcen zugeordnet werden und welche Wiederholungsstrategie zum Einsatz kommt.

Die AesCode-Dokumentation beschreibt das Verfahren und die Verifikatoren, veröffentlicht aber weder Preise noch die Latenz einzelner Prüfungen oder eine allgemeingültige Erfolgsrate beim ersten Versuch. Die Zahlen in diesem Leitfaden sind Variablen für eine eigene Berechnung, keine Messwerte für AesCode 8B. Auch die aggregierte Projektauswertung entspricht nicht der Wahrscheinlichkeit, dass eine bestimmte Aufgabe sämtliche Produktkriterien erfüllt.

Kostenkomponenten

Eine aussagekräftige Schätzung trennt die einzelnen Phasen des Ablaufs, statt jeder Generierung einen einzigen Kostenwert zuzuordnen. Die Inferenz umfasst die Verarbeitung des Prompts und die Erzeugung von HTML und CSS. Ihre Dauer hängt unter anderem von der Hardware, der Modellkonfiguration, der Länge der Eingabe und der Zahl der erzeugten Tokens ab.

Bei der im Projekt beschriebenen Verifikation wird das HTML in einem Playwright-Browser gerendert und mit deterministischen Prüfungen ausgewertet. Dabei werden unter anderem Ausführung, Text, Begrenzungen der Elemente, Tabellen- und Diagrammdaten, semantisches Layout und Weißraum geprüft. Das Repository dokumentiert die Funktionsweise dieser Prüfungen, aber weder ihren Ressourcenverbrauch noch ihre Latenz pro Aufgabe.

Eine Iteration wird nötig, wenn der Ablauf nach einem Fehler eine weitere Generierung oder eine Korrektur vorsieht. Teams gehen dabei unterschiedlich vor: Manche setzen eine Höchstzahl an Versuchen fest, andere korrigieren nur den Code, wieder andere beziehen eine menschliche Prüfung ein. Die durchschnittlichen Kosten hängen von dieser Strategie, den Ressourcen der einzelnen Phasen und den Ergebnissen bei repräsentativen Aufgaben ab.

Berechnungsmodell und Annahmen

Für die Schätzung der Inferenzkosten pro Versuch teilen Sie die Anzahl der erzeugten Tokens durch die tatsächliche Generierungsgeschwindigkeit. Das Ergebnis ist eine ungefähre Dauer. Ist der GPU-Kostensatz pro Stunde angegeben, können Sie die Dauer in Stunden umrechnen und mit dem Tarif oder den internen Kosten multiplizieren. Diese Näherung bildet nicht die gesamte Systemauslastung ab, insbesondere dann nicht, wenn Anfragen gleichzeitig laufen oder Ressourcen gemeinsam genutzt werden.

Die Verifikation sollten Sie entsprechend den tatsächlich eingesetzten Ressourcen bewerten. Wenn Playwright und die Verifikatoren CPU verbrauchen, spiegeln GPU-Stundensätze ihre Kosten nicht unbedingt wider. Für eine genauere Schätzung sollten Sie die jeweiligen Ressourcentypen separat messen und bewerten. Das Codebeispiel verwendet einen einheitlichen Kostensatz lediglich zur Veranschaulichung des Berechnungsaufbaus.

Der Faktor 1/p kann die durchschnittliche Zahl der Versuche nur unter bestimmten Annahmen schätzen: Die Versuche sind unabhängig, die Erfolgswahrscheinlichkeit bleibt konstant, und der Ablauf wird bis zum Erfolg ohne Begrenzung der Wiederholungen fortgesetzt. Unter diesen Bedingungen werden zunächst die Inferenz- und Verifikationskosten pro Versuch addiert und anschließend einmal mit dem erwarteten Faktor multipliziert. Die Erfolgsrate des ersten Versuchs allein belegt nicht, dass diese Annahmen zutreffen. Ändern sich Strategie, Kosten oder Erfolgswahrscheinlichkeit bei späteren Versuchen, oder gilt eine Höchstzahl an Versuchen, muss das Modell angepasst werden.

def tco_berechnen(tokens_ausgabe, tokens_pro_sekunde, gpu_kosten_stunde, verifikation_sekunden, erfolgsrate):
    if tokens_pro_sekunde <= 0 or gpu_kosten_stunde < 0 or verifikation_sekunden < 0:
        raise ValueError("Zeiten und Kosten müssen gültig sein")
    if not 0 < erfolgsrate <= 1:
        raise ValueError("erfolgsrate muss zwischen 0 und 1 liegen")

    inferenzzeit = tokens_ausgabe / tokens_pro_sekunde
    inferenzkosten = (inferenzzeit / 3600) * gpu_kosten_stunde
    verifikationskosten = (verifikation_sekunden / 3600) * gpu_kosten_stunde
    iterationsfaktor = 1 / erfolgsrate

    return (inferenzkosten + verifikationskosten) * iterationsfaktor

Hypothetisches Beispiel: 100 Präsentationen

Nehmen wir zur Veranschaulichung eine durchschnittliche Ausgabe von 5.000 Tokens an, die mit 50 Tokens pro Sekunde erzeugt wird. Außerdem setzen wir 10 Sekunden für die Verifikation pro Versuch und Kosten von 2 USD pro Stunde an. Das Beispiel verwendet denselben Tarif für Inferenz und Verifikation, um die Rechnung zu vereinfachen. Es behauptet weder, dass die Verifikation GPU-Ressourcen verbraucht, noch dass diese Werte einer realen AesCode-8B-Installation entsprechen.

Unter diesen Annahmen dauert die Inferenz 100 Sekunden, die Verifikation weitere 10 Sekunden pro Versuch. Zusammen kosten beide Phasen 110/3600 × 2 = 0,061111 USD pro Versuch. Nehmen wir zusätzlich eine Erfolgsrate von 80 Prozent beim ersten Versuch an, unabhängige Versuche, eine konstante Wahrscheinlichkeit und unbegrenzte Wiederholungen bis zur Abnahme. Der durchschnittliche Faktor beträgt dann 1/0,8 = 1,25. Die geschätzten Kosten pro abgenommener Aufgabe belaufen sich somit auf 0,061111 × 1,25, also ungefähr 0,076389 USD. Für 100 Aufgaben ergibt das eine Schätzung von 7,64 USD.

Das Beispiel ist weder ein Tarif noch ein gemessenes Ergebnis. Ändern sich Generierungsgeschwindigkeit, Verifikationsdauer, Ressourcenkosten, Erfolgsrate oder Wiederholungsstrategie, ändert sich auch das Ergebnis. Unter diesen Annahmen verhält sich der erwartete Aufwand umgekehrt zur Erfolgswahrscheinlichkeit; er wächst nicht exponentiell.

Eine eigene Schätzung erstellen

Eine betriebliche Schätzung sollte auf derselben Hardware, Konfiguration und demselben Ablauf beruhen, die für die Bereitstellung vorgesehen sind. Legen Sie vor der Messung fest, wann eine Aufgabe als abgenommen gilt: etwa welche Inhaltsanforderungen erfüllt sein müssen und welche visuellen Mängel zur Ablehnung führen. Ohne gleichbleibende Kriterien lässt sich die Erfolgsrate nicht zuverlässig zum Vergleich verschiedener Konfigurationen verwenden.

Erfassen Sie Inferenz, Rendering und jede Prüfung getrennt. Notieren Sie pro Aufgabe die Ein- und Ausgabetokens, die Dauer und die verwendeten Ressourcen bei jedem Versuch, die erkannten Fehler und die Zahl der Wiederholungen. Wenn der Ablauf eine Höchstzahl von Versuchen vorgibt, Teilkorrekturen zulässt oder eine menschliche Prüfung verlangt, sollten Sie diese Regeln in die Berechnung aufnehmen, statt unbegrenzte Wiederholungen desselben Prozesses anzunehmen.

Eine Testsammlung sollte die Prompts, Referenzbilder und Seitentypen abbilden, die in der Anwendung zu erwarten sind. Ein kleiner Test kann eine erste Näherung liefern, doch seine Erfolgsrate ist keine Garantie für andere Aufgaben. Unterschiede bei der Komplexität, der gleichzeitigen Auslastung, der Browserkonfiguration und der Hardware können sowohl Dauer als auch Kosten verändern.

Geltungsbereich der Ergebnisse und Grenzen der Schätzung

Die veröffentlichte Projektauswertung umfasst aggregierte Ergebnisse für 300 Infografik-Beispiele, mit drei Generierungen pro Prompt und ohne Auswahl zwischen den Ergebnissen. Diese Kennzahlen beschreiben die Benchmark-Leistung und die bewerteten Dimensionen. Sie geben keine allgemeingültige Erfolgsrate beim ersten Versuch für beliebige Anwendungen, Prompts oder Abnahmekriterien an. Ebenso belegen sie nicht, dass eine Seite, die deterministische Prüfungen besteht, ohne visuelle Prüfung auslieferungsbereit ist.

Das Repository beschreibt das Rendering mit Playwright und sechs deterministische Verifikatoren sowie Kanäle zur visuellen Bewertung. Es veröffentlicht jedoch weder Kosten noch Dauer der einzelnen Prüfungen, den CPU- oder GPU-Verbrauch pro Aufgabe noch eine universelle Erfolgsrate beim ersten Versuch. Aus der Konfiguration einer Auswertung lassen sich auch nicht ohne Weiteres der Speicherbedarf oder die Leistung auf anderer Hardware ableiten.

Das Ergebnis der Berechnung ist daher eine Schätzung, die von den gewählten Messwerten und Annahmen abhängt. Wenn Sie GPU- und CPU-Kosten getrennt erfassen, die Wiederholungsstrategie offenlegen und reproduzierbare Abnahmekriterien verwenden, lassen sich Bereitstellungen besser vergleichen. Damit ist jedoch nicht garantiert, dass Kosten oder Qualität bei anderer Hardware, Auslastung oder anderen Prompts gleich bleiben.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.