Ich habe 3 KI-Modelle getestet, ob sie in der Stimme einer Marke schreiben können. Auf das Modell kam es kaum an.

Zuerst der Aufbau, denn genau da ist die Sache aus dem Ruder gelaufen. Ich habe den exakten Prompt genommen, der hinter unserer Brand-Voice-Demo auf der Landingpage steckt, also der, der ein paar deiner Posts liest und einen neuen in deiner Stimme schreibt, und ihn durch drei Modelle gejagt: Claude Sonnet 4.6 (das, was bei uns in der Produktion läuft), DeepSeek und GLM. Sechs verschiedene Stimmproben, jede zweimal, jeder anonymisierte Output von einer blinden Jury bewertet. Hinter der Frage stand echtes Geld: Könnte ein günstigeres Modell den Job genauso gut wie Sonnet erledigen, oder sogar besser?

Ich habe es auf drei Arten durchgespielt, und die drei Durchläufe widersprachen sich so vollständig, dass sich "welches Modell" als die falsche Frage herausstellte. Runde für Runde.

Runde 1: nur den Modellnamen austauschen

Das ist der Test, den die meisten Leute tatsächlich machen. Dieselben Einstellungen wie in der Produktion, nur ein anderer Modellname.

GLM lieferte null brauchbare Outputs. DeepSeek lieferte vier. Nicht weil sie schlechte Modelle wären, sondern weil beide reasoning-first sind: Innerhalb des Token-Budgets der Produktion denken sie laut vor sich hin ("1. Lass mich die Posts analysieren...") und es geht ihnen der Platz aus, bevor sie das JSON ausspucken, das die Seite braucht. Der naive Tausch beschert dir keine schlechtere Demo. Er beschert dir eine kaputte. Hätte ich vorher eine kurze Stichprobe mit zwei Outputs gemacht, hätte ich das gewusst, statt es erst von den Nutzern zu erfahren.

Runde 2: gib ihnen Platz

Dieselben Modelle, aber mit aktiviertem JSON-Modus und einem größeren Token-Budget, damit die Reasoning-Modelle ihren Gedanken zu Ende bringen können.

Das Bild kippt. Mit genug Platz zum Fertigdenken liefern beide Herausforderer gültiges JSON, und die Jury bewertet ihre Treffsicherheit bei der Stimme gleichauf mit Sonnet oder besser. Die Modelle selbst waren also nie das Problem, der erste Test war es. Aber schau dir die Latenz an. Über vierzig Sekunden. Niemand wartet 44 Sekunden auf eine Landingpage-Demo. Top-Output, unbrauchbares Feature.

Runde 3: die Version, die du tatsächlich ausliefern würdest

JSON-Modus an, Reasoning aus, DeepSeek auf seinem schnellen Endpoint.

Mit der richtigen Technik drumherum werden beide echt brauchbar. DeepSeeks schneller Endpoint kam in 2,8 Sekunden zurück, schneller als Sonnet, zu etwa einem Fünfzigstel der Kosten, und jedes einzelne Mal mit gültigem JSON. GLM zog mit Sonnets Tempo gleich, zu einem Fünftel der Kosten, und holte sich den höchsten Jury-Score. Die Proben deckten sich mit den Zahlen. GLM traf den Schlusssatz einer Creatorin punktgenau ("romantisiere gerade meinen überteuerten Matcha, und Fragen dazu beantworte ich nicht"), und die zweisprachigen Proben kamen bei allen drei Modellen korrekt auf Italienisch zurück.

Was ich wirklich gelernt habe

Das Modell war die langweiligste Variable. Dieselben drei Modelle gingen von kaputt zu besser-als-der-Platzhirsch, ohne dass sich am Modell irgendetwas änderte, nur an der Technik drumherum. Token-Budget, JSON-Modus und ob Reasoning an oder aus war, zählten mehr als die Frage, welches Labor das Ding trainiert hat. Die ganze Übung war eine Erinnerung daran, dass "wechsel einfach zum günstigeren Modell" ein Satz ist, der die gesamte eigentliche Ingenieursarbeit unter den Teppich kehrt.

Eine Einschränkung, denn auch die Jury war nicht perfekt. Sie erkannte richtig, dass Sonnet sein JSON in Markdown-Fences einpackt, was tatsächlich stimmt und der Grund ist, warum die Produktion einen Fence-Stripper hat. Aber sie halluzinierte auch Gedankenstrich-Verstöße in Outputs, die null Gedankenstriche enthielten. Deshalb traue ich den per Auge geprüften Proben mehr als den exakten Dezimal-Scores. Die Richtung stimmt, die dritte Nachkommastelle nicht.

Die praktische Entscheidung? Für diese eine Demo ist der Aufwand winzig, also bleibt Sonnet die sichere Standardwahl, und DeepSeeks schneller Endpoint ist das Upgrade, nach dem ich zuerst greifen würde. Die echten Einsparungen liegen ohnehin nicht hier. Sie liegen in den Features mit hohem Volumen, die tausende Male am Tag laufen, wo 50x günstiger aufhört, ein Rundungsfehler zu sein. Das ist der Test, den es als Nächstes zu fahren lohnt.

Wenn du eine Sache hieraus mitnimmst: Bevor du ein Modell tauschst, um Geld zu sparen, jag es durch genau die Technik, in der es später leben wird. Das Modell, von dem du denkst, du testest es, ist nicht das, das deine Nutzer bekommen.