KI im Vertrieb: Llama, Mistral, Qwen im Vergleich

KI & Automatisierung · 5. Oktober 2026 · Ohiku Mose Guy

KI im Vertrieb: Vergleichen Sie Llama, Mistral, Qwen und API-Modelle für Sales-Pipelines im Mittelstand – mit Kosten, Latenz und Kriterien.

2,2 Sekunden braucht Cloudflare Clef laut einem aktuellen Bericht für eine Klassifikation; GPT-OSS-120B wird dort mit 4,7 Sekunden genannt, wobei die Aussagekraft des Benchmarks selbst angezweifelt wird (Quelle: Cloudflare-Clef-Bericht, Referenz [15], abgerufen am 5. Oktober 2026). Diese Zahl ist klein. Und sie ist gefährlich. Weil sie in einem Vertriebsmeeting sofort nach Telefonagent, Echtzeit-Dialog und „KI im Vertrieb kann jetzt alles“ klingt, obwohl eine Klassifikation nicht dasselbe ist wie ein sauberer Gesprächsfluss mit CRM-Aktion, Einwilligung, Unterbrechung und Protokoll.

Genau deshalb ist dieser Vergleich nötig. In den letzten 7 bis 14 Tagen gab es nach den verfügbaren Treffern keine belastbare offizielle Veröffentlichungswelle zu neuen Llama- oder Mistral-Modellen, die Preise, Latenzen, Context-Windows und unabhängige Benchmarks sauber zusammenbringt. Ollama 0.40.0 ist am 5. Oktober 2026 veröffentlicht worden, ja, aber der verfügbare Treffer liefert keine verlässlichen Angaben zu neuen Modellversionen, Tokenpreisen oder Inferenzlatenzen (Quelle: AIML UpToDate Releases [1]). Naja, fast. Es gibt einzelne Drittanbieter-Messungen, etwa Mistral Small 4 119B mit rund 56,6 GiB FP8-Gewichtsgröße und etwa 49 Token pro Sekunde auf einer GB10-Konfiguration, aber das ist kein offizieller Mistral-Benchmark und kein Cloud-API-Versprechen.

Ich schreibe das als Engineer bei Amplifa, nicht als Analyst mit schöner Matrix. Mein Alltag ist weniger „welches Modell gewinnt auf MMLU?“ und mehr: Warum hängt der RAG-Job um 03:17 Uhr an einer PDF-Tabelle von Phoenix Contact? Warum hat ein Vertriebsteam von Kärcher plötzlich 18 Prozent mehr manuelle Nacharbeit, obwohl die E-Mail-Texte besser klingen? Warum kostet eine lokale Inferenz nach drei Wochen Pilot nicht die Hälfte, sondern das Doppelte, weil niemand die GPU-Auslastung, Embeddings, Reranking und Retry-Logik mitgerechnet hat?

Die Frage für einen Vertriebsleiter im Mittelstand lautet nicht: „Ist Llama besser als Mistral?“ Die bessere Frage lautet: Welche Modellfamilie bricht an welcher Stelle meiner Sales-Pipeline zuerst? Lead Research bricht anders als E-Mail-Personalisierung. Voice Calling bricht anders als RAG für Produktwissen. Und ein CEO aus Heilbronn, der Maschinen für Verpackungslinien verkauft, braucht keine Modellreligion. Er braucht Pipeline, Kontrollierbarkeit und eine Kostenkurve, die nicht im zweiten Quartal explodiert.

KI im Vertrieb – Bewertungskriterien für Modell-Releases

Ich bewerte Llama, Mistral, Qwen und proprietäre API-Modelle hier nicht nach Fanclub. Ich bewerte sie nach Produktionsverhalten. Das klingt trocken. Ist es auch. Aber genau dort entscheidet sich, ob ein Pilot bei DMG Mori, Trumpf oder einem Hidden Champion in Ostwestfalen nach sechs Wochen Budget bekommt oder im Innovationsordner landet.

Für B2B-Sales zählen aus meiner Sicht diese Kriterien:

• Latenzprofil statt Durchschnittsgeschwindigkeit: Time-to-First-Token, Decode-Durchsatz, Tail-Latency und Streaming-Verhalten sind für Voice und Chat wichtiger als eine hübsche Token-pro-Sekunde-Zahl.
• Context-Window und Prefill-Kosten: Lange CRM-Historien, Ausschreibungen, Produktdatenblätter und E-Mail-Threads kosten vor allem im Prefill. Ein großes Kontextfenster ohne Kostenkontrolle ist ein offener Wasserhahn.
• Faktentreue mit Quellen: Für Lead Research und RAG zählt, ob das Modell Firmendaten korrekt extrahiert, Quellen nennt und bei fehlender Evidenz verweigert. Nicht, ob es einen eleganten Absatz schreibt.
• Tool-Use und strukturierte Ausgabe: CRM-Aktionen, JSON-Schemas, Validierungsregeln, Retry-Strategien und Berechtigungen entscheiden in Produktion mehr als allgemeine Sprachqualität.
• Deployment-Modell: Open weights lokal mit vLLM, Ollama oder TGI ist anders zu betreiben als eine API von OpenAI, Anthropic, Mistral oder einem Cloud-Anbieter. Datenschutz ist kein Checkbox-Thema.
• Kosten pro Sales-Objekt: Ich rechne lieber Kosten pro 1.000 Leads, pro freigegebener E-Mail und pro Gesprächsminute als Kosten pro Million Tokens, weil Vertrieb keine Token kauft, sondern Chancen.
• Governance und Auditierbarkeit: Rollenrechte, Mandantentrennung, Prompt-Injection-Schutz, Logging, Löschkonzepte und Freigabeprozesse sind nicht sexy. Stimmt. Ohne sie skaliert nichts.

Andrea, Head of Sales bei einem Automatisierungszulieferer in Bielefeld, sagte mir im September 2026 einen Satz, der hängen geblieben ist: „Wenn die KI eine falsche Referenz in eine Mail schreibt, ist nicht die KI blamiert. Dann bin ich es.“ Genau da liegt der Unterschied zwischen Demo und Vertriebssystem. Eine Demo darf glänzen. Ein Vertriebssystem muss sich benehmen.

Wenn die KI eine falsche Referenz in eine Mail schreibt, ist nicht die KI blamiert. Dann bin ich es.

— Andrea, Head of Sales bei einem Automatisierungszulieferer in Bielefeld

Kandidat 1 – Llama für KI im Vertrieb

Llama bleibt für viele mittelständische Sales-Teams der naheliegende Startpunkt, wenn lokale Kontrolle, breites Ökosystem und viele Inferenzoptionen zählen. Open weights, viele Quantisierungen, breite Tool-Unterstützung, Betrieb über vLLM, TGI, Ollama oder Cloud-Provider. Das ist die Stärke. Nicht zwingend das einzelne Modell. Das Ökosystem.

Für einen Vertriebsleiter heißt das: Llama ist interessant, wenn interne IT oder ein Dienstleister bereits GPU-Betrieb kann, wenn Daten nicht an eine externe API gehen sollen oder wenn viele kleine Klassifikations- und Extraktionsjobs laufen. Beispiel: Ein Team zieht aus Webseiten, PDFs und Handelsregisterdaten Firmennamen, Rollen, Standorte, Umsatzhinweise und Buying Signals. Dafür brauche ich kein maximal großes Modell, sondern stabile Extraktion, deterministische Ausgabe, niedrige Kosten und gute Fehlermeldungen. Bei einem Kunden mit Schaeffler-ähnlicher Zulieferstruktur haben wir im Frühjahr 2026 gesehen, dass ein kleineres lokales Modell mit striktem Schema zuverlässiger war als ein größeres Modell ohne Validierung. Klingt banal. War aber der Unterschied zwischen 7 Prozent und 23 Prozent Nacharbeit in der Datenprüfung.

Die Schwäche von Llama liegt selten im ersten Test. Die Schwäche liegt im Betrieb. Wer „open source“ sagt und meint „kostenlos“, hat die Rechnung nicht gesehen. GPU-Miete oder Abschreibung, Strom, Speicher, Monitoring, Modellupdates, Prompt-Versionierung, Sicherheitsprüfungen, Embeddings, Reranking, Backup-Pfade bei Überlast, nachts laufende Crawls mit kaputten PDFs von 2017. Das riecht nicht nach Forschungslabor, sondern nach warmem Serverraum und verstaubter Dokumentenablage. Und genau dort entscheidet sich, ob lokale Inferenz günstiger ist.

Für E-Mail-Personalisierung kann Llama gut funktionieren, wenn der eigentliche Wert aus Retrieval und Guardrails kommt. Das Modell soll nicht frei recherchieren. Es soll aus freigegebenen Quellen schreiben: CRM-Notiz, letzte Anfrage, Produktinteresse, Branche, Rolle, zulässige Referenzen. Ich mag Llama in solchen Setups, weil man viel kontrollieren kann. Ich traue Llama weniger, wenn jemand damit ohne Evaluierung einen autonomen Sales-Agenten bauen will, der Kontakte auswählt, Mails formuliert, Follow-ups plant und CRM-Felder überschreibt. Wer das ohne menschliche Freigabe startet, baut keinen Vertrieb. Er baut einen Schadensmultiplikator.

Kandidat 2 – Mistral für europäische Sales-Stacks

Mistral ist für europäische Unternehmen aus einem einfachen Grund spannend: Beschaffung, Datenstandort, Anbieterwahrnehmung und kompakte Modellvarianten passen oft besser zur Realität im Mittelstand als ein rein US-zentrierter Stack. Das heißt nicht automatisch, dass Mistral in jedem Use Case gewinnt. Stimmt nicht ganz. In manchen Sales-Workflows gewinnt Mistral gerade deshalb, weil es nicht das größte Modell im Raum sein will.

Der aktuelle Drittanbieter-Test zu Mistral Small 4 119B nennt rund 56,6 GiB lokale FP8-Gewichtsgröße und etwa 49 Token pro Sekunde auf einer beschriebenen GB10-Konfiguration (Referenz [10]). Ich würde diese Zahl niemals als allgemeine Cloud-Latenz verkaufen. Sie sagt nicht, wie hoch die Time-to-First-Token in einer API ist. Sie sagt nicht, wie sich das Modell bei 30 parallelen Nutzern verhält. Sie sagt auch nicht, wie stabil Tool-Aufrufe in einem CRM-Prozess sind. Aber sie zeigt etwas, das für Vertriebsleiter wichtig ist: Kompakte, quantisierte Modelle können für konkrete Aufgaben wirtschaftlich genug werden, solange der Prozess um sie herum sauber gebaut ist.

Bei E-Mail-Entwürfen, Übersetzung, Tonalitätsanpassung und Zusammenfassung früherer Kontakte kann Mistral stark sein. Ich würde es besonders prüfen, wenn deutsche und französische Inhalte gemischt auftreten, etwa bei Maschinenbauern mit Vertrieb in DACH und Frankreich oder bei Zulieferern in Grenzregionen. Webasto, Brose, Festo, Wittenstein – solche Unternehmen leben nicht in einer reinen englischen SaaS-Welt. Produktbegriffe, Rollen, Rechtsform, Niederlassungen und alte CRM-Notizen sind mehrsprachig und unordentlich. Ein Modell muss damit umgehen, ohne aus „Anfrage Ersatzteil Dichtung“ eine strategische Transformationschance zu dichten (ja, das habe ich gesehen).

Die Schwäche: Auch bei Mistral gilt, dass Open-Weight-Modelle nicht automatisch offene Software im strengen Sinn sind. Lizenz, kommerzielle Nutzung, Reproduzierbarkeit, Trainingsdaten-Transparenz und Hosting-Modell müssen getrennt gelesen werden. „Open“ kann heißen: Gewichte verfügbar. Es kann nicht heißen: frei von Einschränkungen, auditierbar bis ins Training, beliebig kommerziell nutzbar. Für einen CSO ist diese Unterscheidung nicht akademisch. Wenn Legal im Dezember 2026 fragt, warum Kundendaten durch eine bestimmte Pipeline gelaufen sind, hilft kein Screenshot aus einem Benchmark-Thread.

Kandidat 3 – Qwen für große Kontexte und harte Trade-offs

Qwen gehört in diesen Vergleich, weil es in technischen Teams längst auftaucht, auch wenn es in deutschen Vorstandsrunden seltener genannt wird als Llama oder Mistral. Der aktuelle Hardwarevergleich nennt für Qwen3-235B-A22B in NVFP4 etwa 24 Token pro Sekunde auf der getesteten Hardware (Referenz [10]). Das ist keine standardisierte Rangliste. Aber es zeigt den Trade-off: großes Modell, andere Quantisierung, mehr Speicherbedarf, anderer Durchsatz. Für Sales heißt das: Qwen kann interessant sein, wenn komplexe Extraktion, lange Dokumente oder mehrsprachige Aufgaben zählen. Aber wer keinen starken MLOps-Unterbau hat, wird sich an Modellgröße, Betrieb und Governance verschlucken.

Ich würde Qwen im Mittelstand nicht als ersten Reflex einsetzen. Nicht, weil es schlecht ist. Sondern weil die Organisation oft noch nicht einmal saubere Dokumentenversionierung, CRM-Hygiene und Evaluierungssets hat. Bei einem Anlagenbauer aus Augsburg roch der Projektraum im Juni 2026 nach Laserdrucker und Kabelkanal; auf dem SharePoint lagen Preislisten mit „final“, „finalneu“ und „finalKopie“. In so einer Umgebung ist das größere Modell selten die Lösung. Erst muss klar sein, welche Datei Wahrheit ist.

Kandidat 4 – Proprietäre API-Modelle für Managed Sales-Automation

Proprietäre Modelle von OpenAI, Anthropic, Google oder spezialisierten Cloud-Anbietern bleiben im Vertrieb stark, weil sie Betrieb abstrahieren. Keine GPU-Beschaffung. Keine Treiberprobleme. Meist bessere Tool-Use-APIs, stabilere Streaming-Schnittstellen, schnellere Integration in Voice-Stacks. Für einen Mittelständler, der in 90 Tagen einen Pilot für Account Intelligence und E-Mail-Entwürfe starten will, ist das oft der pragmatische Weg.

Aber ich bin misstrauisch, wenn jemand sagt: „Wir nehmen einfach das beste API-Modell.“ Beste für was? Für deutsche Erstansprache an Einkaufsleiter? Für Extraktion aus gescannten Datenblättern? Für Telefonie mit Unterbrechung nach 450 Millisekunden? Für Salesforce-Update mit Rollenrechten? Proprietäre Modelle sind bequem, aber die Kostenkurve kann hässlich werden, wenn lange Kontexte ungefiltert in jeden Prompt geschoben werden. Ein 80-seitiges Produkt-PDF gehört nicht blind in den Kontext. Es gehört in ein Retrieval-System mit Chunking, BM25, Vektorsuche, Reranking, Zitaten und Versionierung.

Bei Voice Calling sind API-Modelle häufig vorn, weil Telefonie eine Kette ist: Speech-to-Text, Dialogmodell, Tool-Anbindung, Text-to-Speech, Unterbrechungslogik, Gesprächsprotokoll, Einwilligung. Entscheidend ist End-to-End-Latenz. Nicht der MMLU-Score. Nicht eine Klassifikationszeit von 2,2 Sekunden. Für natürliche Telefonie zählt, wann das erste Audio kommt, wie gut der Agent bei einer Unterbrechung stoppt und ob er nach dem Gespräch im CRM wirklich den richtigen Status setzt. Markus, CSO eines Maschinenbauers aus Nürnberg, formulierte es im August 2026 ziemlich trocken: „Wenn der Bot drei Sekunden schweigt, legt mein Kunde auf.“

Wenn der Bot drei Sekunden schweigt, legt mein Kunde auf.

— Markus, CSO eines Maschinenbauers aus Nürnberg

Was wir bei Amplifa konkret sehen

Was wir bei Amplifa konkret sehen: In den letzten 12 Monaten haben wir bei B2B-Vertriebsteams im Maschinenbau und technischen Großhandel ein wiederkehrendes Muster beobachtet. Die Modellwahl erklärt selten mehr als die Hälfte des Ergebnisses. Bei Lead Research sinkt die manuelle Nacharbeit erst dann spürbar, wenn drei Dinge zusammenkommen: Quellenextraktion vor Modellaufruf, harte JSON-Schemas nach Modellaufruf und ein Prüfset mit echten Negativfällen. In einem Setup mit rund 42.000 Firmenprofilen reduzierte ein Kunde die manuelle Prüfzeit pro qualifiziertem Account von ungefähr 4 Minuten auf knapp unter 90 Sekunden. Das lag nicht an einem größeren Modell. Es lag daran, dass das System aufgehört hat, bei fehlenden Daten zu raten.

Noch ein Muster: E-Mail-Qualität wird in Workshops überschätzt, CRM-Datenqualität unterschätzt. Wenn Branche, Rolle, letzter Kontakt und Produktinteresse sauber sind, liefert ein mittelgroßes Modell oft brauchbare Entwürfe. Wenn diese Felder fehlen oder widersprüchlich sind, halluziniert auch ein Spitzenmodell höflich. Dann klingt die Mail gut und ist trotzdem falsch. Das ist die schlimmste Variante, weil sie durch Freigaben rutscht.

Ein konkreter Befund aus Implementierungen: Für RAG im Vertrieb sind Embeddings und Reranking oft die heimlichen Hebel. Nicht das Chat-Modell. Ein hybrider Ansatz aus Vektorsuche, BM25 und Reranking wird auch in aktuellen Branchenüberblicken erwähnt (Referenz [13]), aber die Praxis ist schmutziger: Produktnamen ändern sich, PDF-Tabellen brechen, Preislisten haben Mandantenrechte, und alte Schulungsunterlagen enthalten Aussagen, die der Vertrieb seit 2024 nicht mehr treffen darf. Wenn ein Modell darauf antwortet, hat nicht das Modell versagt. Die Wissensarchitektur war undicht.

Großer Vergleich – Llama, Mistral, Qwen, API-Modelle

Ich würde diese Tabelle nicht als Rangliste lesen. Ranglisten sind bequem. Leider machen sie faul. Für Sales-Systeme ist die bessere Architektur oft ein Router: kleines Modell für Klassifikation, Retrieval für Wissen, stärkeres Modell für finalen Entwurf, Regelwerk für Compliance, Mensch für Freigabe bei hohem Risiko. Ein Modell für alles ist selten Architektur. Meist ist es Budgetmüdigkeit.

Preisvergleich – Tokenpreise sind nicht die ganze Wahrheit

Die aktuellen Suchtreffer liefern keine verifizierten offiziellen Tokenpreise für neue Llama- oder Mistral-Modelle im Zeitraum bis 5. Oktober 2026. Ich werde deshalb keine Fantasiepreise pro Million Tokens nennen. Das wäre unseriös. Gerade im Vertrieb, wo eine falsche Kalkulation später in 300.000 generierten E-Mails oder 50.000 Gesprächsminuten sichtbar wird.

Bei selbst gehosteten Modellen gibt es ohnehin keinen einheitlichen Tokenpreis. Die effektiven Kosten ergeben sich näherungsweise aus: Kosten pro 1 Mio. Tokens = GPU-, Strom-, Speicher- und Betriebskosten pro Stunde geteilt durch verarbeitete Tokens pro Stunde, multipliziert mit 1.000.000. Klingt sauber. Ist es nur halb. Prefill-Durchsatz für lange CRM-Kontexte und Decode-Durchsatz für Chat oder Telefonie müssen getrennt betrachtet werden. Batch-Größe, Quantisierung, Auslastung und Tail-Latency verändern die Rechnung stärker, als viele Excel-Modelle zugeben.

Ein Preisvergleich ohne Prozessdaten ist Theater. Ich rechne lieber mit Einheiten, die ein CSO versteht: Kosten pro 1.000 angereicherten Accounts, Kosten pro freigegebener E-Mail, Kosten pro gebuchtem Termin, Kosten pro Gesprächsminute mit gültigem Ergebnis. Bei einem Festo-Zulieferer mit 12 Vertriebsmitarbeitern ist der Engpass nicht derselbe wie bei einem SaaS-Team mit 80 SDRs. Also darf die Modellrechnung auch nicht dieselbe sein.

Amplifa Produkt – KI-Vertriebssysteme für B2B Wie Amplifa Lead Research, Account Intelligence, E-Mail-Personalisierung und Sales-Automation mit kontrollierten KI-Pipelines verbindet.

RAG für Vertriebswissen – warum das Modell selten reicht

Ein mittelstandstauglicher RAG-Stack für Vertrieb muss mehr können als Dokumente in eine Vektordatenbank werfen. Er muss Produktdaten, Preislisten, technische Dokumentation und alte Schulungsunterlagen versionieren. Er muss Berechtigungen auf Dokument- und Mandantenebene kennen. Er muss Quellen und Seitenstellen ausgeben. Er muss veraltete Inhalte erkennen. Er muss bei fehlender Evidenz verweigern.

Das klingt nach viel Infrastruktur für ein paar E-Mail-Entwürfe. Ist es aber nicht. Vertrieb lebt von Zusagen. Wenn ein Account Executive einem Einkauf bei Trumpf oder einem Zulieferer aus Stuttgart falsche Kompatibilität, falsche Lieferzeit oder falsche Referenz nennt, ist der Schaden nicht abstrakt. Dann ruft jemand an. Mit Stimme. Meist nicht freundlich.

Meine harte Meinung: Für Sales ist ein kleineres Modell mit gutem RAG und strikter Ausgabevalidierung fast immer besser als ein sehr großes Modell ohne Quellenkontrolle. Nicht manchmal. Fast immer. Die Ausnahme sind sehr freie kreative Aufgaben, aber die sind im B2B-Outbound überschätzt. Die meisten guten Sales-Texte sind nicht kreativ. Sie sind korrekt, relevant und kurz genug, um nicht zu nerven.

E-Mail-Personalisierung – welche Benchmarks nichts messen

BLEU, MMLU, Arena-Rankings, allgemeine Sprachbewertungen – nett. Für B2B-E-Mail-Entwürfe messen sie oft am Problem vorbei. Mich interessieren andere Werte: faktische Korrektheit der Unternehmensdaten, erfundene Referenzen pro 100 Mails, Freigabequote durch Sales, Bearbeitungszeit, Antwortquote, Terminbuchungsrate im A/B-Test und Beschwerden wegen falscher Ansprache.

Im März 2026 haben wir bei einem technischen Händler mit Niederlassungen in Köln und Ulm einen Test gesehen, der intern erst frustrierend wirkte. Das größere Modell schrieb schönere E-Mails. Das kleinere Modell bekam mehr Freigaben. Warum? Es blieb näher am Material, nutzte weniger freie Formulierungen und hielt sich an die Referenzliste. Sales mochte die Texte weniger. Kunden reagierten besser. Ehrlich? Ich weiß es nicht bei jedem Fall. Aber ich traue Metriken aus echten Versandtests mehr als einer Jury, die Prompt-Antworten liest.

Voice Calling – warum 2,2 Sekunden kein Telefonagent sind

Die 2,2 Sekunden aus dem Cloudflare-Clef-Bericht beziehen sich auf Klassifikation. Für Voice Calling ist das höchstens ein Baustein. Ein Sprachagent braucht Speech-to-Text, ein Dialogmodell, Tool- und CRM-Anbindung, Text-to-Speech, Unterbrechungslogik, Eskalation, Protokollierung und Einwilligungsmechanismen. Wenn irgendein Glied dieser Kette langsam ist, klingt das Gespräch kaputt.

1. Miss zuerst Time-to-First-Audio statt nur Token pro Sekunde. Der Kunde hört keine Tokenrate, er hört Stille.
2. Teste Unterbrechungen mit echten Sätzen: „Moment“, „Nein, das stimmt nicht“, „Schicken Sie mir das per Mail“. Viele Demos brechen genau dort.
3. Prüfe Tool-Aufrufe unter Last: Kontakt gefunden, Opt-out erkannt, Gesprächsergebnis geschrieben, Follow-up nicht doppelt angelegt.
4. Miss Tail-Latency, nicht nur Mittelwert. Ein Agent, der in 95 Prozent der Fälle schnell ist und in 5 Prozent einfriert, ist im Vertrieb riskant.
5. Baue Eskalation ein. Wenn Unsicherheit hoch ist, muss der Agent sauber an einen Menschen übergeben oder abbrechen.

Für Voice würde ich 2026 eher mit proprietären APIs oder spezialisierten Stacks starten, wenn das Team keine eigene Echtzeit-Inferenz betreiben kann. Lokale Open-Weight-Modelle können funktionieren, aber dann reden wir über Streaming, Audio-Latenzen, GPU-Reservierung, Lastspitzen und Observability. Das ist kein Nebenprojekt für den Werkstudenten, auch wenn LinkedIn etwas anderes verspricht.

FAQ – Welches Modell ist für KI im Vertrieb am besten?

Das beste Modell für KI im Vertrieb gibt es nicht als allgemeine Antwort. Für Lead-Klassifikation kann ein kleines lokales Modell reichen. Für E-Mail-Entwürfe kann Mistral oder Llama mit gutem RAG stark sein. Für Voice Calling sind Managed APIs oft pragmatischer. Für komplexe Dokumentanalyse kann Qwen interessant werden, wenn Betrieb und Governance stimmen. Wer eine einzige Antwort sucht, hat die Architekturfrage noch nicht gestellt.

Persönliche Empfehlung – meine Reihenfolge für den Mittelstand

Wenn ich bei einem mittelständischen B2B-Unternehmen starte, beginne ich nicht mit dem größten Modell. Ich beginne mit einem Prozessschnitt. Welche Daten kommen rein? Welche Entscheidung soll getroffen werden? Welche Ausgabe darf automatisch passieren? Welche Ausgabe braucht Freigabe? Welche Fehler sind peinlich, welche teuer, welche rechtlich gefährlich? Erst danach wähle ich Modellfamilie und Deployment.

Meine Reihenfolge für die meisten Sales-Piloten: Erst Daten- und Quellenpipeline bauen. Dann ein kleines oder mittleres Modell für Klassifikation und Extraktion testen. Dann RAG mit Quellenpflicht. Dann E-Mail-Entwürfe mit Freigabe und A/B-Test. Voice erst, wenn Logging, Einwilligung, CRM-Aktionen und Eskalation stehen. Wer direkt mit einem autonomen Voice-Agenten startet, weil ein Benchmark nach Geschwindigkeit aussieht, verwechselt Motorleistung mit Bremsweg.

Bei Llama sehe ich den Vorteil in Kontrolle und Ökosystem. Bei Mistral sehe ich den Vorteil in europäischer Anschlussfähigkeit und kompakten Workflows. Bei Qwen sehe ich Potenzial für technisch starke Teams mit Dokumentlast. Bei proprietären APIs sehe ich den schnellsten Weg zu Piloten und Voice. Ich würde keinen dieser Wege aus Prinzip ausschließen. Aber ich würde jeden ablehnen, der ohne Evaluierungsset, Kostenmodell und Governance startet.

Amplifa Sales Audit – KI-Potenzial im Vertrieb prüfen Prüfen Sie, welche Sales-Prozesse sich für KI eignen, wo Daten fehlen und welche Automatisierung wirtschaftlich Sinn ergibt.

Entscheidungshilfe – 3 Fragen vor der Modellwahl

1. Welche Sales-Aufgabe soll das Modell wirklich lösen: Lead Research, E-Mail-Entwurf, RAG, Voice oder CRM-Aktion? Wenn die Antwort „alles“ lautet, ist der Scope zu groß.
2. Welche Fehler dürfen nicht passieren: falsche Unternehmensdaten, erfundene Referenzen, unzulässige Aussagen, Datenabfluss oder doppelte CRM-Aktionen? Die Antwort bestimmt Guardrails und Freigaben.
3. Wie messen wir Erfolg im Pilot: Kosten pro 1.000 Leads, Freigabequote, Antwortquote, Terminbuchung, Time-to-First-Audio, Halluzinationsrate oder Bearbeitungszeit? Ohne Zielmetrik wird jedes Modell irgendwie gut aussehen.

Diese drei Fragen sind unbequem, weil sie die Modell-Debatte entzaubern. Aber genau das braucht der Mittelstand. Nicht mehr Magie. Mehr Messpunkte.

Praktischer Pilotplan – 30 Tage statt Modellreligion

Wenn ein Vertriebsleiter mich fragt, wie er starten soll, skizziere ich meist einen 30-Tage-Pilot. Nicht, weil 30 Tage immer reichen. Sondern weil lange Strategiepapiere selten kaputte CRM-Felder finden. Ein kurzer Pilot mit echten Daten findet sie sofort. Der Geruch von Wahrheit ist manchmal eine exportierte CSV mit 17 Schreibweisen für dieselbe Branche.

1. Wähle 500 bis 2.000 reale Accounts aus dem CRM und anonymisiere sensible Felder, wenn nötig.
2. Definiere ein Golden Set mit menschlich geprüften Labels: Branche, ICP-Fit, Rolle, Buying Signal, Ausschlussgrund.
3. Teste zwei Modellwege: ein Open-Weight-Setup mit Llama oder Mistral und ein API-Modell als Referenz.
4. Miss Präzision, Recall, Halluzinationen, Kosten pro Account und manuelle Nacharbeitszeit.
5. Baue erst danach E-Mail-Entwürfe auf die geprüften Daten, nicht vorher.
6. Führe einen kleinen A/B-Test mit menschlicher Freigabe durch und vergleiche Antwort- und Terminquote.
7. Entscheide nicht nach schönstem Text, sondern nach Kosten, Fehlerquote und Sales-Akzeptanz.

Bei einem Pilot mit einem Hidden Champion aus dem Raum Stuttgart haben wir vor drei Wochen genau diese Reihenfolge diskutiert. Der erste Wunsch war ein Copilot, der sofort Mails schreibt. Nach Sichtung der Daten war klar: Erst mussten Branchenfelder, Dubletten und Ansprechpartnerrollen bereinigt werden. Das Modell war nicht der Engpass. Die Eingangsdaten waren es. Das ist nicht elegant, aber es spart Geld.

Amplifa Ressourcen & Tools Kostenlose Tools und Audits für Pipeline-Analyse, Sales-Automation und den sinnvollen Einsatz von KI im B2B-Vertrieb.

Mein Fazit zum Modellvergleich im Oktober 2026

Die aktuelle Evidenz reicht nicht für eine saubere Rangliste „Llama gegen Mistral gegen Qwen gegen Proprietär“. Wer so eine Rangliste trotzdem veröffentlicht, verkauft Sicherheit, die nicht da ist. Für die letzten 7 bis 14 Tage fehlen belastbare offizielle Releases zu Llama oder Mistral mit vollständigen Angaben zu Preisen, Latenzen, Context-Windows und unabhängigen Benchmarks. Ollama 0.40.0 ist ein relevanter Hinweis, aber kein belastbarer Modellvergleich. Die Mistral- und Qwen-Zahlen aus Drittanbieter-Tests sind interessant, aber hardwaregebunden. Cloudflare Clef zeigt Tempo bei Klassifikation, aber keine Telefonieeignung.

Für den Mittelstand folgt daraus kein Stillstand. Im Gegenteil. Es folgt eine nüchterne Einkaufslogik: offizielle Modellkarten prüfen, Lizenz und Datenflüsse lesen, eigene Tests mit anonymisierten Sales-Aufgaben fahren, Kosten pro Sales-Objekt rechnen, nicht pro Bauchgefühl. Dann entscheidet sich, ob Llama, Mistral, Qwen, ein kleiner Spezialist oder eine proprietäre API passt.

Der beste Modellvergleich findet nicht auf einer Benchmark-Webseite statt. Er findet in der Pipeline statt, zwischen CRM-Export, Produkt-PDF, Freigabemaske und dem ersten Kunden, der auf eine KI-unterstützte Mail antwortet. Manchmal ist die Antwort ein Termin. Manchmal ist sie ein Hinweis auf ein falsches Datenfeld. Beides ist wertvoll. Nur eines davon steht im Benchmark.