Unser A/B-Benchmark, offen einsehbar. Messen Sie uns.

Was gemessen wird, und wie

• Zwei Arme, dieselbe Anfrage. A geht direkt zum Anbieter, ohne die Schicht; B läuft durch die Schicht mit ihrer Standardkonfiguration. Gleicher Prompt, gleiches Sampling, gleiche Ausgabeobergrenze.
• Die Kosten zählt der Anbieter. Jeder Arm wird anhand des usage-Werts bepreist, den die API bei jedem Aufruf zurückgibt, zum Listenpreis. Die Ersparnis ist 1 − Kosten(B) / Kosten(A) desselben Laufs, nicht das, was die Schicht über sich selbst sagt.
• Intervalle zum 95 %. Jeder Testharness berechnet sie (Resampling ganzer Fragefamilien, Wilson für Ablehnungsraten). Ein Intervall, das die Null überschreitet, bedeutet „nicht von null unterscheidbar“, und das sagen wir dann auch.
• Das Paket, das Sie installieren. Arm B läuft mit der Quelle des Tags 0.4.31; dessen dist/index.js ist byteidentisch mit dem des npm-Tarballs (sha256 b52f99cacf9804ecd3153e56f26ec3adcdc2510d52a8446a369ecf914e0b5731).
• Keine Abkürzungen. Jeder Testharness überwacht die Hosts, mit denen er spricht, und trägt ein im Code festgelegtes Ausgabenlimit pro Modell. Ein Modell, das nicht gemessen werden konnte, wird als „nicht gemessen“ ausgewiesen, mit Begründung.

Vier Testreihen, öffentliche Datensätze, festgelegt

Gemessene Ersparnis pro Modell

GSM8K, mit einem Anfragestrom, in dem 30 % exakte Wiederholungen sind und 20 % Umformulierungen. Das ist die Testreihe mit wiederholtem Traffic: Ihre Ersparnis hängt davon ab, wie stark sich Ihrer wiederholt. Ohne Wiederholungen siehe „Was nicht einspart“.

Woher die Ersparnis stammt, Position für Position: „aus dem exakten Cache“ ist das, was A für die Anfragen bezahlt hat, die die Schicht bedient hat, ohne den Anbieter aufzurufen; „in den Aufrufen“ ist die Differenz bei denen, die ihn tatsächlich erreicht haben, meist der Präfix-Cache des Anbieters (plus etwas Variation in der Ausgabe). Beide zusammen ergeben die Gesamtersparnis.

Die Genauigkeit wird anhand der Fragen mit veröffentlichter Antwort gemessen; die Varianten mit einer geänderten Zahl dienen nur dazu zu prüfen, dass die Schicht niemals die Antwort einer anderen Frage zurückgibt.

Garantien, gezählt

Was nicht einspart

Ohne Wiederholungen liegt die Ersparnis bei ≈ 0 %. Wir veröffentlichen es trotzdem, weil es das ist, was Sie sehen werden, wenn sich Ihr Traffic nicht wiederholt.

MT-Bench ist ein Chat mit zwei Runden mit einer frischen Schicht pro Frage: Es gibt nichts, was der Cache wiederverwenden könnte, und der Prompt erreicht fast nie das Minimum, das der Anbieter verlangt, um einen Präfix zu cachen. Bei BFCL ist jeder Tool-Aufruf anders. Was diese beiden Testreihen messen, ist, dass die Schicht nichts verschlechtert; die verbleibende Kostendifferenz ist Rauschen in der Ausgabe des Modells, nicht die Schicht.

Status nach Modell und Testreihe

Jede Zelle zeigt den Lauf mit der höchsten Version der Schicht. Wenn ein Modell nicht gemessen werden konnte, sagen wir, warum, statt eine Lücke zu lassen.

Fehler, die der Benchmark gefunden hat

Der Benchmark ist nicht dazu da, gut auszusehen: Er ist dazu da, die Fehler zu finden, bevor Sie es tun. Er hat diese gefunden, mit der Version, in der sie auftraten, und der, die sie behebt.

1. Der unkalibrierte semantische Cache lieferte die Antwort einer anderen Frage 0.4.30 → 0.4.31

   Bei unkalibriertem semantischem Cache konnte eine Variante mit einer anderen Zahl („three baskets“ gegenüber „two baskets“) die Antwort der ursprünglichen Frage erhalten. Gezählt über die GSM8K-Varianten.

   • Gefunden in 0.4.30: 15 von 111. gsm8k.json
   • Behoben in 0.4.31 (#383).
   • Live verifiziert mit 0.4.31: 0 von 198.

2. Die Schicht kürzte den Tool-Katalog ohne jedes Signal dafür 0.4.30 → 0.4.31

   In mehrteiligen Unterhaltungen sendete Arm B weniger Tools als Arm A, obwohl nichts darauf hindeutete, welche unnötig waren. Gezählt über die mehrteiligen BFCL-Unterhaltungen.

   • Gefunden in 0.4.30: 20 von 20. bfcl.json
   • Behoben in 0.4.31 (#382).
   • Live verifiziert mit 0.4.31: 0 von 83.

3. Manche als Text geschriebenen Ablehnungen wurden gecacht 0.4.31 → 0.4.32

   Eine Ablehnung, die das Modell als Text schreibt (ohne das Signal der API), konnte gecacht, wiederholt und als Ersparnis angerechnet werden. Gezählt in XSTest-Prompts.

   • Gefunden in 0.4.31: 39 von 2.824. xstest-0431-claude.jsonxstest-0431-gama-alta.jsonxstest-0431.json
   • Behoben in 0.4.32 (#393, #401).
   • Wartet auf erneute Live-Messung mit 0.4.32.

4. Ein Gemini-Inhaltsfilter wurde als Antwort gecacht 0.4.31 → 0.4.32

   Gemini kennzeichnet seinen Filter mit einem eigenen Stop-Grund, den die Schicht nicht als Ablehnung erkannte, sodass sie ihn cachen und wiederholen konnte. Gezählt in XSTest-Prompts.

   • Gefunden in 0.4.31: 6 von 508. xstest-0431-gama-alta.json
   • Behoben in 0.4.32 (#402).
   • Wartet auf erneute Live-Messung mit 0.4.32.

5. Gemini lief nicht über die Schicht 0.4.31 → 0.4.32

   Die Schicht sendete ein für die OpenAI-API spezifisches Feld an jeden kompatiblen Endpunkt, und Gemini lehnt es ab: Jede Anfrage in Arm B schlug fehl. Gezählt in GSM8K-Anfragen.

   • Gefunden in 0.4.31: 504 von 504. gsm8k-0431-gama-alta.json
   • Behoben in 0.4.32 (#402).
   • Wartet auf erneute Live-Messung mit 0.4.32.

6. Bei Gemini 3 schlug die zweite Runde mit Tools fehl 0.4.31 → 0.4.32

   Die Schicht gab die Thought-Signatur nicht zurück, die Gemini 3 bei jedem Tool-Aufruf verlangt, sodass die nächste Runde abgelehnt wurde. Gezählt in mehrteiligen BFCL-Fortsetzungen.

   • Gefunden in 0.4.31: 50 von 50. bfcl-0431-gama-alta.json
   • Behoben in 0.4.32 (#402).
   • Wartet auf erneute Live-Messung mit 0.4.32.

Wie man es reproduziert

Der Code des Benchmarks ist noch nicht öffentlich; die Methode schon, und sie passt in fünf Schritte. Mit Ihren eigenen Anbieter-Schlüsseln können Sie ihn wiederholen und Zahl für Zahl mit unseren Berichten vergleichen.

1. Der Datensatz. Laden Sie jeden öffentlichen Datensatz beim Commit aus der Tabelle oben herunter und prüfen Sie vor der Nutzung den sha256 jeder Datei. Stimmt er nicht, ist es nicht derselbe Datensatz.
2. Die Schicht. Installieren Sie @bivelio/savings-layer von npm in der Version, die der Bericht nennt, und prüfen Sie den sha256 von dist/index.js: Jeder Bericht enthält seinen.
3. Zwei Arme pro Prompt. A geht direkt zum Anbieter; B schickt denselben Prompt an dasselbe Modell mit demselben Ausgabelimit durch die Schicht in ihrer Standardkonfiguration. Ein Teil der Prompts wird wiederholt oder umformuliert, wie im echten Verkehr, und die Reihenfolge A/B wird ausgelost.
4. Die Kosten nennt der Anbieter. Summieren Sie, was jeder Arm laut dem vom Anbieter gelieferten usage zum veröffentlichten Preis kostet. Die Ersparnis ist 1 − Kosten B / Kosten A, mit ihrem Intervall.
5. Die Qualität, im selben Lauf. Bewerten Sie die Antworten beider Arme gleich (exakte Antwort bei GSM8K, Tool-Aufruf bei BFCL, Ablehnung oder nicht bei XSTest, ein Richter bei MT-Bench) und vergleichen Sie sie mit dem JSON-Bericht derselben Batterie und Version.

Die Berichte

Jeder Lauf hinterlässt einen JSON-Bericht mit seinem Design, seinen Grenzen und jedem gemessenen Aufruf: usage, Kosten pro Arm und Einstufung der Antwort. Sie werden von dieser Website ausgeliefert.

Die Berichte werden so ausgeliefert, wie der Benchmark sie geschrieben hat, mit einer Ausnahme: Angaben zur Umgebung der messenden Person (Dateipfade, E-Mail-Adressen) werden entfernt. Von XSTest wird kein Antworttext veröffentlicht, nur seine Einstufung.