Run #51
Wie schnell antwortet das Modell auf den ersten Token-Stream nach Aufruf?
KI-Bewertung anzeigen
Zusammenfassung
Der Cold-Start-TTFT-Benchmark wurde mit einer Pass-Rate von 100 % (1/1) fehlerfrei abgeschlossen. Das Modell reagierte korrekt und ohne Fehler auf die einzige gestellte Anfrage.
Stärken
- Vollständige Fehlerfreiheit: keine Errors, keine Failures
- Korrekte, präzise Antwort ohne Halluzination oder Format-Abweichung
Schwächen
- Stichprobengröße von n=1 erlaubt keine statistisch belastbare Aussage zur TTFT-Stabilität
- Kein numerischer Score (score: null) vorhanden, daher keine quantitative Latenz-Bewertung möglich
Auffälligkeiten
Keine Failure-Muster erkennbar, da ausschließlich ein einzelner Erfolgsfall vorliegt. Der Prompt war trivial kurz ("Antworte nur mit OK."), was keine Rückschlüsse auf das Verhalten bei komplexeren oder längeren Inputs zulässt. Die fehlende Score-Metrik deutet darauf hin, dass die eigentliche TTFT-Messung (in Millisekunden) nicht erfasst oder nicht weitergegeben wurde.
Empfehlung
Den Benchmark mit mindestens 20–50 Wiederholungen und variierenden Prompt-Längen erneut ausführen sowie die konkrete TTFT-Messung (z. B. in Millisekunden) als numerischen Score implementieren, um belastbare Aussagen zur Latenz und deren Stabilität unter Last treffen zu können.
Liefert der Endpoint überhaupt korrekte Antworten auf einfachste Fragen?
KI-Bewertung anzeigen
Zusammenfassung
Der Sanity-Benchmark wurde mit einer Pass-Rate von 100 % (3/3) fehlerfrei bestanden. Das Modell liefert auf triviale Fragen korrekte, formatgetreue Antworten.
Stärken
- Vollständige Trefferquote ohne Fehler oder Abweichungen
- Strikte Einhaltung der Formatvorgaben (nur Zahl, nur ein Wort, nur Großbuchstaben)
- Keine Inference-Fehler oder Timeouts aufgetreten
Schwächen
- Keine Schwächen identifizierbar auf diesem Niveau — der Test ist bewusst trivial gehalten
- Aussagekraft beschränkt sich auf grundlegende Funktionsfähigkeit des Endpoints
Auffälligkeiten
Keine Muster in Failures erkennbar, da ausnahmslos alle Antworten korrekt waren. Die Antworten sind minimal und exakt, es gibt keine Tendenz zu unnötigen Zusätzen oder Erklärungen — was bei Substring-Checks positiv ist.
Empfehlung
Den Sanity-Benchmark als bestanden abhaken und die Testtiefe erhöhen: komplexere Sub-Benchmarks mit mehrschrittiger Reasoning-Anforderung, längeren Kontexten oder nicht-trivialen Formatvorgaben ausführen, um belastbare Aussagen über die tatsächliche Modellqualität des gpt-oss:20b zu gewinnen.
Wie viele Tokens pro Sekunde liefert das Modell unter realistischer Last?
KI-Bewertung anzeigen
Zusammenfassung
Der Throughput-Benchmark wurde mit einer Pass-Rate von 100 % (6/6) fehlerfrei abgeschlossen. Alle Prompts — kurz, mittel und lang — wurden korrekt und vollständig beantwortet, ohne Fehler oder Timeouts.
Stärken
- Perfekte Erfolgsrate ohne Errors oder Failures über alle Schwierigkeitsstufen hinweg
- Inhaltlich korrekte und gut strukturierte Antworten auf diverse Prompt-Typen (Fakten, Erklärungen, technische Pseudocode-Aufgaben)
- Konsistente Ausgabequalität auch bei komplexeren Anfragen wie dem Quicksort-Pseudocode
Schwächen
- Eine längere Antwort (Quicksort) wurde abgeschnitten — der Pseudocode endet mitten im Satz, was auf ein Token-Limit oder ein Streaming-Abbruchproblem hindeutet
- Ebenso der REST/GraphQL-Vergleich bricht beim fünften Punkt ab, bevor der Resolver-Text vollständig ist
- Die Bewertungslogik scheint Antwortabschneidung nicht als Fehler zu werten, was die Pass-Rate verzerrt
Auffälligkeiten
Bei mindestens zwei der sechs Antworten (Quicksort, REST vs. GraphQL) wurden Antworten vorzeitig abgeschnitten. Dieses Muster tritt bei längeren, strukturierten Ausgaben auf — vermutlich durch ein zu niedriges `max_tokens`-Limit im Benchmark-Setup. Die Bewertungsfunktion erkennt dies nicht als Failure, was zu einer irreführend hohen Score führt.
Empfehlung
Das `max_tokens`-Limit im Benchmark-Adapter erhöhen (mindestens verdoppeln für mittlere und lange Prompts) und die Evaluierungslogik um eine Prüfung auf abgeschnittene Ausgaben erweitern, damit Truncation als partielle Failure gewertet wird.
Kann das Modell echte Bugs in echten Codebasen fixen?
KI-Bewertung anzeigen
Zusammenfassung
Das Modell gpt-oss:20b erreicht auf SWE-bench Lite eine Pass-Rate von 0 % — kein einziger Patch führt die zugehörigen Tests erfolgreich durch. Alle 10 Samples enden als Fehler oder Fehlschlag.
Stärken
- Das Modell erzeugt syntaktisch erkennbare Diff-Formate und arbeitet sich in relevante Codestellen vor.
- Einige Patches enthalten inhaltlich plausible Ansätze (z. B. fehlende Zuweisung bei `chararray.replace`, leere-Input-Behandlung in `wcs.py`).
Schwächen
- Vier von zehn Samples scheitern bereits am Patch-Anwenden (`patch_apply_failed`), d. h. die erzeugten Diffs sind strukturell ungültig oder referenzieren falsche Zeilennummern/Kontexte.
- Die verbleibenden sechs Patches sind inhaltlich nicht korrekt genug, um die Testsuite grün zu schalten — die Logik ist unvollständig oder falsch (z. B. abgeschnittene Ausgabe bei `rst.py`, falsches `block_diag`-Flattening bei `separable.py`).
Auffälligkeiten
- Mehrere Antworten sind abgeschnitten (Truncation-Muster: Patch endet mitten im Code), was auf ein Token-Limit-Problem oder unkontrollierte Generierung hindeutet.
- Alle `patch_apply_failed`-Fehler treten ohne sichtbaren Prompt auf — möglicherweise werden fehlerhafte Hunk-Header (`@@`-Zeilen ohne Zeilennummern) systematisch produziert.
- Das Django-Failure enthält syntaktisch kaputtes Python im entfernten Abschnitt, was auf Halluzination beim Diff-Erzeugen hindeutet.
Empfehlung
Vor weiteren Läufen das Diff-Format strikt per System-Prompt erzwingen (vollständige `@@`-Hunk-Header mit Zeilennummern) und das maximale Output-Token-Limit erhöhen, um Truncation zu verhindern; danach gezielt prüfen, ob `patch_apply_failed` abnimmt.
Live-View
KI-Bewertung
Generiert 2026-05-11 15:56 · claude-sonnet-4-6Gesamteindruck
Das Modell gpt-oss:20b besteht alle einfachen Basis-Tests zuverlässig, scheitert aber vollständig an anspruchsvollen Code-Repair-Aufgaben. Ein wiederkehrendes Truncation-Problem bei längeren Ausgaben deutet auf ein systemisches Token-Limit-Problem hin, das die Bewertung verzerrt.
Stärken
- Perfekte Pass-Rate bei trivialen bis mittleren Aufgaben (Sanity, Cold-Start, Throughput)
- Strikte Einhaltung von Formatvorgaben bei kurzen, strukturierten Antworten
- Syntaktisch erkennbare Diff-Erzeugung mit teils plausiblen Lösungsansätzen
Schwächen
- 0 % Erfolgsrate auf SWE-bench Lite; kein einziger Patch besteht die Testsuite
- Strukturell ungültige Diffs (fehlerhafte Hunk-Header, falsche Zeilennummern) bei 4 von 10 Patches
- Systematisches Abschneiden von Ausgaben bei längeren, komplexen Antworten
- Halluzinationen beim Diff-Erzeugen (syntaktisch kaputtes Python)
Empfehlung
Das Modell nicht für autonome Code-Repair- oder Issue-Fix-Workflows einsetzen, solange das Truncation-Problem nicht behoben und die Diff-Generierung durch strikte Prompt-Vorgaben nicht stabilisiert wurde.
Stärken & Schwächen
Auf Basis der Pass-Raten dieses RunsStärken
Keine Sub-Benchmarks im "good"-Bereich.
Schwächen
- SWE-bench Lite — Issue-Repair (0%)
Telemetrie
Snapshots
{
"name": "SWE-Bench-Quick",
"provider_id": null,
"model_id": null,
"benchmarks": [
{
"adapter_key": "baseline",
"sub_benchmarks": [
"cold_start",
"throughput",
"sanity"
],
"threshold_override": null
},
{
"adapter_key": "swe_bench",
"sub_benchmarks": [
"swe_bench_lite"
],
"threshold_override": null,
"params": {
"swe_bench_preset": "lite_smoke"
}
}
],
"tags": [],
"notes": null,
"model": {
"base_name": "gpt-oss:20b",
"quantization": "unknown",
"format": "other",
"source_url": null,
"build_notes": null,
"checksum": null
}
}
{
"name": "Ollama",
"type": "ollama",
"endpoint_url": "http://100.64.0.4:11434/",
"api_key_env_var": null,
"sampling_params": [],
"provider_specific": [],
"telemetry_sample_interval_ms": 1000
}
[
{
"name": "kim",
"hostname": "100.64.0.4",
"gpu_description": "RTX 5080 16GB",
"cpu": "Ryzen 9800 X3D",
"ram": "64GB DDR5",
"storage": "1TB+4TB SSD",
"network": null,
"notes": null
}
]
{
"php_version": "8.4.21",
"os": "Linux",
"os_release": "6.8.0-111-generic",
"symfony_version": "7.4.10",
"provider_version_hint": null,
"recorded_at": "2026-05-11T15:25:30+02:00"
}