Zum Inhalt springen
Zum Inhalt springen

Docs / Anleitungen

Maschinell übersetzte Seite

Diese Seite wurde automatisch übersetzt und kann daher Fehler oder seltsame Formulierungen enthalten. Die englische Version ist die maßgebliche Quelle. Das englische Original lesen.

Kosten vor einem Lauf schätzen

Schätze einen Übersetzungslauf ab, bevor du Geld ausgibst: Zähl die Keys mit einem Dry Run, lass verbatra die Kosten berechnen und begrenze dann den Lauf.

Nutze das vor dem ersten Lauf auf einem echten Projekt oder vor jedem Lauf, den jemand freigeben muss. verbatra veröffentlicht keine Preise, weil die Tarife dem Provider gehören und sich ohne Ankündigung ändern. Es zählt, wofür du bezahlst, und rechnet das in Geld um, sobald du ihm die aktuellen Tarife deines Providers gibst.

Bei einem typischen Projekt kostet vor allem der erste Lauf etwas, und der nächste Lauf kostet fast nichts, weil nur geänderte Keys gesendet werden.

Zähl die Arbeit

verbatra translate --dry-run
Ausgabe
verbatra translate (dry run)
  de: 400 would translate, 0 unchanged
  es: 400 would translate, 0 unchanged
  fr: 400 would translate, 0 unchanged
3 succeeded, 0 partial, 0 failed (dry run: nothing written)

would translate ist die Zahl der Keys, die ein echter Lauf senden würde: die in der Zieldatei fehlenden plus die, deren Quelltext sich geändert hat. Ein Dry Run erzeugt keinen Provider, liest keinen Key und schreibt nichts. Betrachte die Zahl als Obergrenze: Sie lässt den Cache aus, der wiederholte Strings in einem echten Lauf kostenlos liefert, und sie fasst identische Quellstrings nicht zusammen, die ein echter Lauf nur einmal sendet.

Schätz die Ausgaben

verbatra translate --estimate
Ausgabe
verbatra translate (estimate)
  de: 400 would translate, 0 unchanged
  es: 400 would translate, 0 unchanged
  fr: 400 would translate, 0 unchanged
  estimate: 1200 keys in 24 requests, ~40944 input + ~30720 output tokens
  estimated spend: no rate on file for gemini/gemini-2.5-flash; add rates.table["gemini/gemini-2.5-flash"] to your config to see a currency figure
  estimate excludes: cache hits, duplicate source strings, provider-side retries, translation length, tokenizer differences, repair requests
3 succeeded, 0 partial, 0 failed (dry run: nothing written)

--estimate schließt --dry-run ein und gibt also nichts aus. Es meldet die Einheit, die dein Provider abrechnet: Tokens bei einem LLM, Quellzeichen bei DeepL und Google Cloud Translation und keine API-Kosten bei einem selbst betriebenen openai-compatible- oder libretranslate-Server. Mit --json stehen dieselben Zahlen unter result.estimate, pro Locale und insgesamt, sodass ein Skript darauf reagieren kann.

Um Geldbeträge zu sehen, schlag den aktuellen Tarif deines Modells auf der Preisseite des Providers nach:

ProviderAbgerechnet nachPreise
GeminiEin- und Ausgabe-Tokens (mit kostenlosem Kontingent)Gemini API pricing
AnthropicEin- und Ausgabe-TokensAnthropic pricing
OpenAIEin- und Ausgabe-TokensOpenAI API pricing
OpenCodeEin- und Ausgabe-TokensOpenCode Zen pricing
DeepLQuellzeichenDeepL API pricing
Google Cloud TranslationQuellzeichenCloud Translation pricing
openai-compatible, LibreTranslatenichts: dein eigener Serverkeine API-Kosten

Trag ihn dann mit dem Datum, an dem du ihn gelesen hast, in die Konfiguration ein:

verbatra.config.ts
export default defineConfig({
  // ...
  rates: {
    asOf: "2026-01-15",
    currency: "USD",
    table: {
      // placeholders: copy the current rates from https://ai.google.dev/gemini-api/docs/pricing
      "gemini/gemini-2.5-flash": { inputPerMillionTokens: 1, outputPerMillionTokens: 2 },
    },
  },
});

Die Tarife oben sind Platzhalter, keine zitierten Preise. Jede daraus berechnete Zahl trägt das asOf-Datum, sodass eine alte Preistabelle sichtbar alt ist. verbatra erfindet nie einen fehlenden Tarif und druckt nie 0.00 für ein Modell, das es nicht bepreisen kann; stattdessen nennt es den fehlenden Eintrag. Schlüsselformat und Einheiten stehen unter rates.

Wisse, was die Zahl abdeckt

Die Schätzung erledigt die Rechnung, die du sonst von Hand machen würdest:

  • Anfragen. Die Keys jeder Locale werden in Stapel von höchstens maxBatchSize (Standard 50) aufgeteilt, eine Anfrage pro Stapel, dazu die Stapel, die generatePlurals senden würde.
  • Eingabe. Jede LLM-Anfrage enthält feste Systemregeln (etwa 550 Tokens) und ein Antwortschema (etwa 100 Tokens), dann die Keys, ihre Beschreibungen, den Ton und das vollständige Glossar der Ziel-Locale. Der Prompt wird gemessen, indem die Nutzlast serialisiert wird, die gesendet würde, sodass ein großes Glossar bei jeder Anfrage zählt, die es mitführt.
  • Ausgabe. Eine Übersetzung gibt es noch nicht, also wird sie als Quelltext plus 50 Prozent angesetzt, weil Deutsch, Französisch und Russisch oft ein Drittel bis die Hälfte länger sind als Englisch.
  • Tokens. Zeichen werden mit etwa vier pro Token umgerechnet, was zu englischem Fließtext passt; andere Schriften sind dichter.

Ein echter Lauf kostet meist weniger, aus denselben zwei Gründen, aus denen die Dry-Run-Zahl eine Obergrenze ist. Er kann auch mehr kosten, und die Zeile estimate excludes nennt jeden Weg dorthin. Zwei zählen am meisten:

  • Wiederholungen. Eine gescheiterte Anfrage wird wiederholt: bis zu zwei zusätzliche Versuche bei Anthropic, OpenAI, OpenCode, openai-compatible und Gemini, fünf bei DeepL, keine bei Google Cloud Translation und LibreTranslate. Ein Versuch, der das Modell erreicht hat, wird abgerechnet.
  • Reparaturen. Wenn Keys fehlend zurückkommen, sendet verbatra eine Reparaturanfrage, die Systemregeln, Glossar und Ton noch einmal vollständig enthält.

Plane mit der Zahl, versprich sie aber nicht als Obergrenze. Die Schätzung deckt außerdem nur translate ab: Ein einzelner Eintrag, den du aus Studio oder mit einem Agent-Tool neu übersetzt, verursacht Kosten auf eigenem Weg.

Begrenze den Lauf

Gib dem vereinbarten Lauf einen harten Stopp knapp über der Summe aus geschätzten Ein- und Ausgabe-Tokens:

verbatra translate --max-tokens 80000

Eine Anfrage, die die Grenze überschreiten würde, wird zurückgehalten statt gesendet, und ihre Keys bleiben für den nächsten Lauf offen. Setzt die Konfiguration auch maxTokens, gilt der niedrigere Wert. DeepL, Google Cloud Translation und LibreTranslate melden keine Tokens, also wird die Grenze bei ihnen gegen verbatras eigene Hochrechnung durchgesetzt. Siehe Token-Obergrenze und für ein Budget, das für jeden Lauf gilt, maxTokens und budgetBehavior.

Kalibriere an einer Locale

Die genaue Zahl liefert ein echter Lauf. Übersetze eine Locale und lies den Verbrauch ab:

verbatra translate --locales de
Ausgabe
verbatra translate
  de: 400 translated, 0 unchanged, 18400 tokens (10800 in, 7600 out)
  total: 18400 tokens (10800 in, 7600 out)
1 succeeded, 0 partial, 0 failed

Multipliziere mit der Zahl der übrigen Locales. Mit --json heißen die Werte usage.inputTokens und usage.outputTokens. Der Lauf kostet echtes Geld, aber die Arbeit bleibt: Diese Locale ist fertig.

Lies, was frühere Läufe gekostet habenneu

Die Overview von Studio listet aufgezeichnete Läufe mit ihren Kosten, eingefroren beim Ende des Laufs, sodass eine spätere Änderung an rates sie nie umschreibt. Ein Betrag sind die vom Dienst gemeldeten Tokens mal dem damals hinterlegten Preis. Estimated ist ein Wert aus Quellzeichen für einen Dienst, der keinen Verbrauch meldet. At least ist eine Untergrenze, weil eine Locale keine Tokens gemeldet hat. No rate heißt, kein Preis passte zu diesem Modell, und unknown heißt, Schlüssel wurden gesendet, aber es kamen keine Tokens zurück; beides ist nicht kostenlos. Selbst gehostete Dienste zeigen not billed. Der Eintrag ist unter runHistory dokumentiert; Review in Studio zeigt die Seite.

Maschinelle Übersetzungsdienste

DeepL und Google Cloud Translation rechnen Quellzeichen ab, keine Tokens, und LibreTranslate zählt Quellzeichen, ohne etwas abzurechnen. verbatra schickt ihnen den Quelltext mit Platzhaltern als kurzen nummerierten Markierungen, ohne Systemregeln, Key-Namen oder JSON drumherum. Die Schätzung zählt nur Quellzeichen. DeepL rechnet die Tags um seine Markierungen nicht ab; ob Google das Span-Markup um sie abrechnet, ist nicht dokumentiert. Ein Wert, den diese Provider zurückhalten (PLACEHOLDER_UNSUPPORTED), wird nicht gesendet, sodass weniger Zeichen gesendet werden können als die Rohsumme.

Google Cloud Translation

Google Cloud Translation wird wie DeepL gezählt: Quellzeichen in der Schätzung und eine hochgerechnete Token-Zahl für ein maxTokens-Budget, in der Laufzusammenfassung als geschätzt markiert.

Schätze aus einem Agenten heraus

Zwei Agent-Tools liefern, was translate --estimate --json ausgibt, für alle Locales oder eine Teilmenge, und rufen nie einen Provider auf:

ToolWo
translation.estimateder MCP-Server
verbatra_translation_estimateStudios Agent-Tools

Im Rahmen der Schätzung ausgeben

translation.translatePending nimmt danach dieselben locales und eine maxTokens-Grenze. Siehe Erst schätzen, dann ausgeben.

Warum der nächste Lauf weniger kostet

Die Zahlen oben sind die Kosten des ersten Laufs. Danach sendet verbatra nur Keys, die fehlen oder deren Quelle sich seit der Baseline in der Lock-Datei geändert hat, und der Cache verwendet frühere Übersetzungen identischer Strings wieder. Im Alltag bezahlst du für die Strings, die du bearbeitet hast. Um kostenlos zu proben, nutze das kostenlose Kontingent von Gemini oder richte openai-compatible auf ein lokales Modell; siehe Provider.

Siehe auch

Auf GitHub bearbeiten

Auf dieser Seite