Warum teure KI beim Praxistest versagt
Ein Fehler, der nur auf dem teuersten iPhone auftrat — gelöst nicht vom teuersten KI-Modell, sondern vom günstigsten. Die Audio-Fassung unserer Modellvergleichs-Serie: der iPhone-16-Bug, ein Modellwechsel im richtigen Moment, sechs KIs mit einer Frage — und drei Regeln für den KI-Einsatz.
📄 Transkript anzeigen
Willkommen auf dem MVX Deep Dive Podcast. Der Autor und Entwickler ist Marco von MVXLabs.
Hallo und herzlich willkommen auch von mir. In dieser Folge sprechen wir über eine Frage, die aktuell viele Entwickler, Unternehmen und KI-Nutzer beschäftigt: Ist ein teures und bekanntes KI-Modell automatisch besser als ein günstigeres Modell?
Oder anders gefragt: Was zählt am Ende mehr? Ein guter Platz in einer öffentlichen KI-Rangliste? Ein hoher Preis? Ein bekannter Hersteller? Oder die Fähigkeit, eine ganz konkrete Aufgabe tatsächlich zu lösen?
Die Erfahrungen von Marco Fuhrmann und MVXLabs zeigen: Die Antwort ist deutlich komplizierter, als man zunächst vermuten würde.
Bevor wir in die Geschichte einsteigen, stellen wir den Entwickler hinter dem Projekt kurz vor. Marco Fuhrmann ist Softwareentwickler, Motorradfahrer und Daten-Enthusiast. Sein Schwerpunkt liegt auf mobilen Anwendungen, Sensordaten, GPS-Analysen und dem praktischen Einsatz künstlicher Intelligenz.
Und bei MVXLabs geht es nicht nur um theoretische Konzepte. Marco entwickelt Anwendungen, die reale Probleme lösen sollen. Dazu gehören beispielsweise Kurvenfokus, MotionRecord und ArchivBlick.
Kurvenfokus beschäftigt sich mit der Analyse von Motorradtouren und Kurven. MotionRecord zeichnet GPS- und Sensordaten auf. Und ArchivBlick soll dabei helfen, große private Foto-, Video- und Dokumentenarchive mithilfe künstlicher Intelligenz durchsuchbar zu machen.
Ein wichtiger Grundsatz zieht sich dabei durch viele seiner Projekte: Technik soll den Menschen unterstützen. Möglichst ohne unnötigen Cloud-Zwang, ohne versteckte Abonnements und ohne den Verlust der Kontrolle über die eigenen Daten.
Der Ausgangspunkt unserer heutigen Geschichte ist eine App zur lokalen Spracherkennung. Die Idee klingt zunächst einfach: Man spricht einen Gedanken ein, und die App wandelt die Aufnahme automatisch in Text um.
Das kennen wir doch eigentlich schon von unseren Smartphones. Man drückt auf das Mikrofon, spricht einen Satz und sieht kurz danach den fertigen Text. Was ist daran also besonders?
Der entscheidende Unterschied liegt darin, wo die Verarbeitung stattfindet. Bei vielen Diensten wird die Sprachaufnahme an einen Server im Internet übertragen. Dort wird sie analysiert und anschließend als Text an das Gerät zurückgeschickt.
Bei einer Einkaufsliste ist das vielleicht noch unproblematisch. Aber bei persönlichen Gedanken, geschäftlichen Informationen, medizinischen Themen oder vertraulichen Gesprächen kann das ganz anders aussehen.
Genau deshalb sollte die MVXLabs-Anwendung vollständig lokal arbeiten. Die Aufnahme sollte das Gerät nicht verlassen. Kein Upload. Keine Verarbeitung auf einem fremden Server. Und nach dem Herunterladen des Sprachmodells sollte die App sogar ohne Internetverbindung funktionieren.
Also beispielsweise auch im Zug, im Flugzeug, in einer Tiefgarage oder irgendwo unterwegs, wo es gerade kein Mobilfunknetz gibt.
Richtig. Lokale Spracherkennung bietet drei wesentliche Vorteile. Die Daten bleiben auf dem eigenen Gerät. Die Anwendung funktioniert offline. Und bei frei verfügbaren Modellen entstehen keine laufenden Kosten pro Audiominute.
Welches KI-Modell wird für so etwas verwendet?
Ein bekanntes Modell für diese Aufgabe heißt Whisper. Whisper wurde darauf trainiert, gesprochene Sprache zu erkennen und in Text umzuwandeln. Das Modell existiert in verschiedenen Größen. Kleine Varianten benötigen weniger Rechenleistung und arbeiten schneller. Größere Varianten können bei schwierigen Aufnahmen oder komplexeren Begriffen genauer sein.
Und für Marco war diese Technik besonders interessant, weil er viele Ideen als Sprachnotizen festhält. Ein Gedanke unterwegs. Eine neue Funktion für ein Produkt. Oder eine Lösung, die man schnell einsprechen muss, bevor man sie wieder vergisst.
Eine Audiodatei besitzt jedoch einen großen Nachteil. Sie lässt sich nicht so einfach durchsuchen, überfliegen oder weiterverarbeiten. Ein Text kann dagegen sortiert, zusammengefasst und als Grundlage für weitere Arbeit verwendet werden. So entstand die Idee einer lokalen Transkriptions-App.
Bis hierhin klingt alles nachvollziehbar. Aber dann kam offenbar ein Problem, mit dem niemand gerechnet hatte.
Genau. Die App funktionierte auf mehreren iPhones bereits erstaunlich gut. Auf älteren und teilweise schwächeren Geräten wurden die Aufnahmen korrekt in Text umgewandelt. Doch ausgerechnet auf dem leistungsstärksten Testgerät erschien kein Text.
Auf welchem Gerät trat der Fehler auf?
Auf einem iPhone 16 Pro Max. Der Fortschrittsbalken lief bis ungefähr fünfundneunzig Prozent. Dann schien der Vorgang stehenzubleiben. Die Transkription blieb leer.
Das ist zunächst völlig unlogisch. Man würde doch erwarten, dass eine Anwendung auf einem leistungsfähigeren Smartphone mindestens genauso gut funktioniert wie auf einem älteren Gerät.
Genau das machte den Fehler so ungewöhnlich. Auf schwächeren Geräten funktionierte die App. Auf dem leistungsfähigeren Gerät nicht. Zusätzlich erschien im Systemprotokoll eine schwer verständliche Fehlermeldung der KI-Recheneinheit.
Wurde der Programmcode vorher nicht von einer KI geprüft?
Doch. Ein etabliertes und leistungsfähiges KI-Modell hatte den Code bereits analysiert. Es lieferte auch sinnvolle allgemeine Verbesserungsvorschläge. Die Anwendung ließ sich übersetzen und starten. Aber die eigentliche Ursache des Gerätefehlers wurde nicht erkannt.
Das zeigt bereits einen wichtigen Punkt. Ein Modell kann gute Antworten liefern und trotzdem genau das eine Problem übersehen, das für das Projekt entscheidend ist.
Richtig. Der Fehler befand sich nicht sichtbar in einer einzelnen Codezeile. Er entstand erst durch das Zusammenspiel verschiedener Faktoren: der Größe des Sprachmodells, dem verfügbaren Arbeitsspeicher, der parallelen Verarbeitung und der speziellen KI-Hardware des Geräts.
Was war der nächste Schritt?
Marco entschied sich dafür, ein anderes KI-Modell zu testen. In seiner Entwicklungsumgebung kann er zwischen verschiedenen Modellen wechseln. Man kann sich das wie einen Werkzeugkasten vorstellen. Nicht jeder Schraubendreher passt zu jeder Schraube. Und nicht jedes KI-Modell eignet sich gleich gut für jede Aufgabe.
Welches Modell wurde diesmal ausgewählt?
Kimi K3. Dieses Modell war deutlich günstiger als viele bekannte Premiummodelle. Doch zunächst gab es ein weiteres Problem. Der erste Aufruf scheiterte. Dann der zweite. Der dritte, der vierte und auch der fünfte Versuch funktionierten ebenfalls nicht.
Dann war das Modell also doch nicht besonders gut?
Das wäre eine vorschnelle Schlussfolgerung. Das Modell lieferte keine falsche Antwort. Es wurde technisch überhaupt nicht geladen. Es handelte sich wahrscheinlich um ein Problem beim Anbieter, bei der Verbindung oder bei der verwendeten Modellkennung.
Ein wichtiger Unterschied. Wenn ein Modell gar nicht startet, sagt das nichts über seine inhaltliche Qualität aus.
Genau. Beim sechsten Versuch funktionierte der Zugriff. Und das Modell ging anders vor als erwartet. Es begann nicht sofort mit einer langen Liste möglicher Ursachen. Stattdessen las es zunächst den vollständigen relevanten Programmcode. Danach entwickelte es eine Hypothese und stellte gezielte Fragen.
Was hatte das Modell herausgefunden?
Die Ursache war eine ungewöhnliche Kette mehrerer technischer Entscheidungen. Das iPhone 16 Pro Max verfügte über besonders viel Arbeitsspeicher. Deshalb wählte die App automatisch das größte verfügbare Sprachmodell.
Das klingt zunächst sinnvoll. Mehr Speicher bedeutet: größeres Modell und möglicherweise bessere Ergebnisse.
Grundsätzlich ja. Aber längere Aufnahmen wurden zusätzlich in mehrere Abschnitte aufgeteilt. Vier dieser Abschnitte sollten gleichzeitig verarbeitet werden.
Also vier parallele Transkriptionsprozesse?
Genau. Alle vier Prozesse griffen jedoch gleichzeitig auf dieselbe KI-Recheneinheit des Smartphones zu. Dadurch entstand ein Engpass. Einzelne Verarbeitungen lieferten leere Ergebnisse zurück, ohne dass die Anwendung einen klaren und sofort erkennbaren Fehler ausgab.
Und warum trat das Problem nur auf dem leistungsfähigsten Gerät auf?
Weil nur dieses Gerät automatisch die größte Modellvariante und die parallele Verarbeitung auswählte. Die schwächeren Geräte verwendeten eine kleinere und stabilere Konfiguration.
Das ist wirklich paradox. Das stärkere Gerät scheiterte nicht trotz seiner Leistung, sondern indirekt wegen seiner Leistung.
Genau. Zusätzlich waren bestimmte Qualitätssicherungen des Sprachmodells deaktiviert worden. Fehlerhafte oder leere Resultate wurden deshalb nicht zuverlässig erkannt und erneut verarbeitet. Das günstigere KI-Modell hatte damit die entscheidende Ursachenkette identifiziert.
Dann musste das Modell nur noch die Lösung liefern.
Das war zumindest der Plan. Doch kurz vor dem konkreten Lösungsvorschlag brach die Antwort ab.
War das Modell überfordert?
Nein. Das Prepaid-Guthaben beim Anbieter war aufgebraucht. Die Fehlermeldung erklärte, dass für die vollständige Antwort mehr Guthaben oder eine kürzere Ausgabe benötigt werde.
Das ist fast schon tragisch. Die schwierige Analyse war erledigt. Die Ursache war verstanden. Und genau vor der Lösung war Schluss.
Am folgenden Tag wurde dasselbe Modell über einen zweiten Anbieter gestartet. Dasselbe KI-Modell, aber ein anderer Zugang und ein separates Guthaben. Das Modell untersuchte das Problem erneut und kam unabhängig zum gleichen Ergebnis.
Das erhöht natürlich das Vertrauen in die Analyse.
Anschließend wurde der kritische Verarbeitungspfad verändert. Für diesen Anwendungsfall kam eine kleinere und stabilere Modellkonfiguration zum Einsatz. Außerdem wurde die problematische Verarbeitung über die KI-Recheneinheit umgangen.
Und die App funktionierte danach?
Ja. Die Anwendung wurde direkt auf dem angeschlossenen iPhone getestet. Eine echte Sprachaufnahme wurde erstellt. Die Geräteprotokolle wurden ausgewertet. Und die Lösung wurde anhand des realen Verhaltens angepasst.
Damit hätte man das Problem eigentlich abhaken können.
Ja, aber die Entwicklung ging noch weiter. In derselben Sitzung wurden zusätzliche Tests geschrieben und weitere Teile der App verbessert. Außerdem entstand eine Vergleichsfunktion. Mit ihr konnten zwei unterschiedliche Transkriptionen direkt nebeneinander dargestellt werden.
Aus dem ursprünglichen Fehler entstand also ein neues Produktmerkmal.
Genau. Und damit kommen wir zur ersten zentralen Erkenntnis dieser Folge: Ein hoher Preis sagt nicht zuverlässig voraus, ob ein Modell eine konkrete Aufgabe lösen kann.
Das bedeutet aber nicht, dass teure Modelle grundsätzlich schlecht sind.
Natürlich nicht. Viele Premiummodelle sind leistungsfähig und für zahlreiche Aufgaben hervorragend geeignet. Aber der Preis ist kein Beweis dafür, dass ein Modell bei jedem speziellen Problem die beste Wahl ist.
Nach der erfolgreichen iPhone-Version entstand eine weitere Herausforderung. Die Anwendung sollte auch auf Android übertragen werden.
Dafür musste eine neue technische Architektur entwickelt werden. Und diesmal wurde die Frage nicht nur an ein einziges Modell gestellt. Sechs verschiedene KI-Modelle erhielten denselben ausführlichen Rechercheauftrag.
Darunter verschiedene Modelle und Modellfamilien, beispielsweise Minimax, GPT O S S, Gemma, Qwen und GLM.
Bei vielen Themen lagen die Antworten relativ nah beieinander. Zum Beispiel beim Aufbau der Benutzeroberfläche, bei der lokalen Datenbank, bei Übersetzungen und bei der automatischen Zusammenfassung von Texten.
Wenn mehrere Modelle dasselbe empfehlen, klingt das zunächst nach einer sicheren Entscheidung.
Ja. Doch beim wichtigsten Bestandteil der App gingen die Meinungen auseinander. Bei der Spracherkennung entstanden drei verschiedene Gruppen. Drei Antworten empfahlen einen komfortablen Standardweg über Google. Zwei Modelle empfahlen eine bekannte Open-Source-Lösung. Ein Modell schlug einen dritten, weniger offensichtlichen Weg vor.
Warum war die Entscheidung so schwierig?
Weil die App nicht nur einen vollständigen Text erzeugen sollte. Während der Wiedergabe einer Aufnahme sollte genau das Wort hervorgehoben werden, das gerade gesprochen wird. Der Text sollte der Aufnahme sichtbar folgen.
Dafür braucht man genaue Zeitangaben für jedes einzelne Wort.
Richtig. Die Spracherkennung muss wissen: Wann beginnt ein Wort? Wann endet es? Und an welcher Stelle der Audioaufnahme wurde es ausgesprochen?
Und genau dieses Detail hatten einige Modelle nicht ausreichend geprüft?
Ja. Ein Teil der Modelle empfahl einen technisch bequemen Standardweg. Sie prüften aber nicht sorgfältig genug, ob diese Lösung zuverlässige Zeitstempel auf Wortebene bereitstellt.
Die Antwort war also grundsätzlich plausibel, passte aber nicht vollständig zur wichtigsten Produktfunktion.
Genau. GLM 5.2 ging anders vor. Dieses Modell erkannte, dass fehlende oder unzuverlässige Wort-Zeitstempel ein Ausschlusskriterium sein könnten. Es fragte sinngemäß: Kann diese Lösung wirklich das zentrale Wiedergabefeature der App ermöglichen?
Und deshalb folgte Marco nicht einfach der Mehrheit?
Richtig. Die Architekturentscheidung orientierte sich nicht daran, welche Empfehlung die meisten Stimmen erhalten hatte. Sie orientierte sich an der Antwort, die die konkrete Produktanforderung am genauesten untersucht hatte.
Das klingt nach einer wichtigen Warnung. Mehrere KI-Modelle können sich einig sein und trotzdem gemeinsam einen entscheidenden Punkt übersehen.
Genau. Ein KI-Konsens ist kein automatischer Beweis für Korrektheit. Modelle können ähnliche Trainingsdaten, ähnliche Standardlösungen und ähnliche blinde Flecken besitzen.
Dann geht es bei einem Multi-Modell-Vergleich also nicht nur darum, Stimmen zu zählen.
Richtig. Der eigentliche Nutzen liegt darin, Unterschiede sichtbar zu machen. Welche Annahmen trifft ein Modell? Welche Anforderungen werden berücksichtigt? Welche Fragen stellt ein Modell? Welche Fragen übersieht es? Und warum kommt ein Modell zu einer anderen Empfehlung?
Gerade die einzelne Gegenstimme kann besonders wertvoll sein.
Ja. Natürlich hat eine Minderheitenmeinung nicht automatisch recht. Auch sie muss technisch geprüft und auf realer Hardware getestet werden. Aber sie kann auf einen Aspekt hinweisen, den alle anderen Modelle übersehen haben.
Wie könnte ein sinnvolles Multi-Modell-Setup im Alltag aussehen? Benötigt man dafür zehn oder zwanzig verschiedene KI-Zugänge?
Nein. Für viele Entwickler reicht ein pragmatischer Ansatz. Man verwendet ein leistungsfähiges Standardmodell für die tägliche Arbeit. Zusätzlich richtet man ein oder zwei alternative Modelle ein, die ein anderes Profil besitzen.
Ein Modell kann beispielsweise besonders gut Programmcode erstellen. Ein anderes ist stärker bei Fehlersuche und Ursachenanalyse. Und ein drittes stellt vielleicht bessere Rückfragen oder erkennt unvollständige Anforderungen.
Genau. Wenn ein Modell nach mehreren Versuchen immer wieder dieselben Vorschläge macht und das Problem nicht löst, kann ein Modellwechsel sinnvoller sein als die zwanzigste Anpassung desselben Prompts.
Denn ein anderes Modell bringt andere Trainingsschwerpunkte und möglicherweise einen völlig neuen Blickwinkel mit.
Für besonders wichtige Modelle kann zusätzlich ein zweiter Anbieter eingerichtet werden. Damit erhält man zwei unabhängige Zugänge zum selben Modell. Fällt ein Anbieter aus oder ist ein Guthaben aufgebraucht, kann die Arbeit über den zweiten Zugang fortgesetzt werden.
Auch die Fehlermeldungen sollten dabei richtig interpretiert werden. Wenn ein Modell gar nicht geladen wird, handelt es sich häufig um ein technisches Zugangsproblem. Wenn es eine ausführliche, aber falsche Antwort liefert, ist es dagegen ein inhaltlicher Fehlschlag.
Diese Situationen müssen klar voneinander getrennt werden.
Damit kommen wir zu den bekannten KI-Benchmarks. Was sagen solche Ranglisten eigentlich aus?
Benchmarks sind nicht grundsätzlich schlecht. Sie helfen dabei, Modelle bei standardisierten Aufgaben zu vergleichen. Zum Beispiel bei Mathematik, logischem Denken, Programmierung oder Wissensfragen.
Aber ein Benchmark kennt nicht unbedingt das konkrete Projekt.
Genau. Ein Benchmark kennt nicht dein spezielles Smartphone. Er kennt nicht deine individuelle Softwarearchitektur. Er kennt nicht die Vorgeschichte eines Fehlers. Und er weiß nicht, welches kleine Produktmerkmal für deine Anwendung unverzichtbar ist.
Die bessere Frage lautet deshalb nicht: Welches KI-Modell steht auf Platz eins?
Sondern: Welches Modell hat meine reale Aufgabe gelöst? Hat es den vollständigen Zusammenhang berücksichtigt? Hat es seine Annahmen offengelegt? Hat es die wichtigsten Anforderungen geprüft? Und lässt sich die vorgeschlagene Lösung auf einem echten Gerät reproduzieren?
Dabei sollte man aber auch vorsichtig bleiben. Einige praktische Fälle sind noch keine wissenschaftliche Großstudie.
Richtig. Die hier beschriebenen Erfahrungen sind wertvoll, besitzen aber methodische Grenzen. Die Modelle wurden nicht immer zur exakt gleichen Zeit und unter vollständig identischen Bedingungen getestet. Auch technische Empfehlungen müssen weiterhin auf realen Zielgeräten überprüft werden.
Trotzdem zeigen die Beispiele einige wichtige Grundprinzipien.
Preis und Eignung sind nicht dasselbe. Mehrheit und Korrektheit sind nicht dasselbe. Und ein hoher Benchmarkwert ersetzt keinen realen Praxistest.
Fassen wir die wichtigsten Erkenntnisse in drei Regeln zusammen.
Regel Nummer eins: Bewerte ein KI-Modell an deiner echten Aufgabe und nicht ausschließlich anhand einer Rangliste.
Regel Nummer zwei: Prüfe abweichende Antworten besonders sorgfältig. Der Ausreißer kann genau die Anforderung entdeckt haben, die alle anderen übersehen haben.
Und Regel Nummer drei: Behandle den Preis eines Modells nur als schwaches Signal. Ein teureres Modell kann leistungsfähiger sein. Es muss aber nicht für jedes Problem das passendere Werkzeug darstellen.
Die vielleicht wichtigste Erkenntnis reicht weit über Softwareentwicklung hinaus. Künstliche Intelligenz sollte nicht als allwissende Instanz betrachtet werden.
KI ist ein Werkzeug. Oder genauer gesagt: Eine Sammlung sehr unterschiedlicher Werkzeuge.
Der entscheidende Vorteil entsteht nicht dadurch, dass man immer das vermeintlich beste Modell verwendet. Er entsteht dadurch, dass man Ergebnisse vergleichen kann.
Dass man Annahmen überprüft. Dass man Gegenstimmen ernst nimmt. Und dass man im richtigen Moment das Werkzeug wechselt.
Gute KI-Arbeit bedeutet also nicht, einer Antwort blind zu vertrauen.
Sie bedeutet, bessere Fragen zu stellen. Ergebnisse an der Realität zu messen. Und die endgültige Entscheidung weiterhin selbst zu treffen.
Genau dafür steht MVXLabs: Nicht nur über künstliche Intelligenz sprechen, sondern sie an echten Aufgaben ausprobieren. Mit realen Geräten. Mit realen Daten. Und mit nachvollziehbaren Ergebnissen.
Vielleicht löst am Ende nicht das bekannteste Modell dein Problem. Vielleicht ist es nicht das teuerste Modell. Vielleicht ist es sogar die einzelne Gegenstimme, die eine entscheidende Anforderung erkennt, die alle anderen übersehen haben.
Deshalb gilt: Vertraue nicht nur dem Preisschild.
Vertraue nicht nur der Mehrheit.
Und vertraue nicht nur einem Benchmark.
Teste die reale Aufgabe. Vergleiche die Ergebnisse. Und entscheide anschließend, welches Modell tatsächlich zu deinem Projekt passt.
Dieser Podcast wurde mit Hilfe von künstlicher Intelligenz erstellt. Die Stimmen wurden mit ElevenLabs synthetisiert.
Die inhaltliche und redaktionelle Grundlage stammt von Marco Fuhrmann und MVXLabs.
Weitere Informationen über die Projekte, Entwicklungen und Praxistests findet ihr auf MVXLabs.de.
Herzlichen Dank fürs Zuhören.
Bis zum nächsten Podcast von MVXLabs und Marco Fuhrmann.
Macht es gut.
Und bis zum nächsten Deep Dive.