Kosteneffiziente Sprachmodelle: Die Vorteile von SmolLM3 im Vergleich zu großen Modellen

{„title“: „Kosteneffiziente Sprachmodelle: Die Vorteile von SmolLM3 im Vergleich zu großen Modellen“, „content“: „

Die Nutzung eines 70B-Modells in der Produktion kann teuer und für viele Aufgaben unnötig sein.

Für spezifische Anwendungen, wie etwa einen Dokumentenklassifizierer oder einen mehrsprachigen Support-Responder, kann ein gut trainiertes 3B-Modell die Leistung eines 70B-Modells zu einem Bruchteil der Kosten erreichen oder sogar übertreffen.

Das 3B-Modell benötigt lediglich eine einzelne Verbraucher-GPU, lädt in Sekundenschnelle und verursacht keine Kosten pro Token. Auf eingeschränkter Hardware ist es die einzige Option, die überhaupt funktioniert.

Die Stärken kleiner Sprachmodelle

Dieser Artikel verwendet SmolLM3, das Flaggschiffmodell von Hugging Face mit 3B Parametern, das am 8. Juli 2025 veröffentlicht wurde, als Arbeitsmodell. Es ist derzeit das technisch interessanteste SLM auf dem 3B-Skala, trainiert auf 11,2 Billionen Tokens, unterstützt ein 128k Kontextfenster, duales Denken, native Toolaufrufe, sechs Sprachen und ist unter der Apache 2.0-Lizenz verfügbar, wobei der vollständige Trainingsplan zusammen mit den Gewichten veröffentlicht wurde.

Das Projekt, das sich durch alle Abschnitte zieht, ist ein mehrsprachiger Support-Ticket-Router, der eingehende Tickets nach Kategorie klassifiziert, die Sprache des Tickets erkennt, eine Antwort in derselben Sprache generiert und Ausgaben mit geringer Zuversicht zur menschlichen Eskalation kennzeichnet. Am Ende haben Sie eine funktionierende Pipeline, die Sie an Ihr eigenes Fachgebiet anpassen können.

Warum kleine Sprachmodelle mehr Aufmerksamkeit verdienen

Die Fixierung auf die Parameteranzahl in der KI ist verständlich, aber irreführend. Rohgröße ist bis zu einem gewissen Punkt wichtig. Danach sind Datenqualität, Trainingscurriculum und architektonische Entscheidungen entscheidender.

Forschungen aus dem SmolLM2-Papier (Februar 2025) zeigten, dass bei der 1B-3B-Skala sorgfältig kuratierte Trainingsdaten konsequent besser abschneiden als naives Skalieren der Parameter. SmolLM3 geht noch weiter: 11,2 Billionen Trainings-Tokens über ein gestuftes Curriculum – Web-, Code-, Mathematik- und Daten zum Denken – sowie 140 Milliarden Denk-Tokens in der Nachschulung. Das Ergebnis ist ein Modell, das in Zero-Shot-Benchmarks sowohl Llama-3.2-3B als auch Qwen2.5-3B übertrifft und in mehreren Aufgaben mit Qwen3-4B konkurriert.

Im IFEval-Benchmark für die Befolgung von Anweisungen erzielt SmolLM3 76,7, was höher ist als Qwen3-4B mit 68,9. Bei BFCL (Toolaufruf) erreicht es einen Gleichstand mit Llamas Tool-Call-Fine-Tune bei 92,3. Bei Global MMLU (mehrsprachige QA) erzielt es 53,5 im Vergleich zu Llama-3.1-3B mit 46,8.

Wo SLMs tatsächlich schwach sind: Aufgaben, die tiefes, breites Weltwissen, wettbewerbsfähige Trivia, komplexes mehrstufiges Denken über umfangreiche Wissensgraphen und sehr lange kreative Texte mit reichhaltigem historischem Kontext erfordern. Für diese Aufgaben ist das große Modell erforderlich. Für alles, was fokussiert und domänenspezifisch ist, wird das SLM mit Feinabstimmung auf Ihren Daten es bei einem Zehntel der Betriebskosten erreichen.

Die Architektur von SmolLM3 verstehen

SmolLM3 ist ein Decoder-Only-Transformer, was der Standard ist. Drei architektonische Entscheidungen innerhalb dieses Standards sind weniger verbreitet und es wert, verstanden zu werden, da sie direkt beeinflussen, wie Sie das Modell bereitstellen und abstimmen.

• Gruppierte Abfrage-Attention: Standardmäßige Multi-Head-Attention behält separate Schlüssel- und Wertprojektionen für jeden der 16 Attention-Köpfe. SmolLM3 gruppiert diese 16 Köpfe in 4 gemeinsame Abfrageprojektionen, wodurch der Schlüssel-Wert (KV)-Cache-Speicher um etwa 25 % reduziert wird, ohne messbare Genauigkeitsverluste. Dies ist wichtig zur Inferenzzeit: Ein kleinerer KV-Cache bedeutet weniger Spitzen-VRAM, was bedeutet, dass Sie längere Kontexte oder größere Batches auf derselben Hardware verarbeiten können.
• NoPE (Kein Positionsencoding in ausgewählten Schichten): SmolLM3 entfernt das rotierende Positionsencoding (RoPE) aus jeder vierten Transformator-Schicht und implementiert ein 3:1 RoPE-zu-NoPE-Verhältnis. Dieser Ansatz stammt aus dem Papier von 2025 \“RoPE zu NoRoPE und zurück\“ und hilft dem Modell, über lange Kontexte zu generalisieren, ohne die Positions-Embedding-Abwertung, die die meisten anderen kleinen Modelle bei langen Sequenzlängen betrifft.
• Dual-Mode-Denken: Ein Satz von Gewichten behandelt zwei Modi: denken und nicht_denken. Im Denkmodus generiert das Modell eine Denkspur innerhalb von …-Tags vor der endgültigen Antwort, was dem entspricht, was separate \“Denkmodelle\“ tun. Im Nicht-Denkmodus antwortet es direkt. Sie steuern dies pro Anfrage über den System-Prompt oder das enable_thinking-Argument in der Chat-Vorlage. Kein zusätzliches Modell, kein zusätzlicher Checkpoint.

Einrichtung Ihrer Umgebung

Hardware-Mindestanforderungen:

• GPU VRAM: 6 GB (bfloat16) / 8 GB+ (RTX 3060 oder besser)
• System RAM: 16 GB / 32 GB
• Festplatte: 8 GB frei / 20 GB+ SSD
• Apple Silicon: M2 8 GB / M2 Pro / M3 16 GB

CPU-only funktioniert. Erwarten Sie ungefähr 3x langsamere Inferenz für Text-to-Speech (TTS)-Synthese und 5-8 Tokens/Sekunde bei Generierungsaufgaben, abhängig von Ihrem Gerät. Feinabstimmung auf der CPU ist unpraktisch; verwenden Sie Googles kostenloses T4-GPU in Colab, wenn Sie keine lokale GPU haben.

Python und Pakete:

Python 3.10 oder neuer erforderlich

python --version

Erstellen und aktivieren Sie eine virtuelle Umgebung

python -m venv smollm-env
source smollm-env/bin/activate # macOS / Linux
smollm-env\\Scripts\\activate # Windows

Installieren Sie alle Abhängigkeiten

pip install \
 \"transformers>=4.53.0\" \
 \"torch>=2.3.0\" \
 \"accelerate>=0.30.0\" \
 \"bitsandbytes>=0.43.0\" \
 \"sentencepiece\" \
 \"trl>=0.9.0\" \
 \"peft>=0.11.0\" \
 \"datasets>=2.19.0\"

Hinweis: transformers>=4.53.0 ist erforderlich; der Modellierungscode von SmolLM3 wurde in dieser Version ausgeliefert. Frühere Versionen schlagen mit einem nicht erkannten Architekturfehler fehl.

Geräteerkennungshilfe (führen Sie dies zuerst aus):

def detect_device():
 \"\"\"
 Detect the best available compute device.
 Returns (device_str, dtype_str, load_kwargs) for use with from_pretrained.
 \"\"\"
 try:
 import torch
 except ImportError:
 raise RuntimeError(\"PyTorch not found. Install with: pip install torch\")
 if torch.cuda.is_available():
 vram_gb = torch.cuda.get_device_properties(0).total_memory / 1e9
 print(f\"CUDA GPU detected: {torch.cuda.get_device_name(0)} ({vram_gb:.1f} GB VRAM)\")
 return \"cuda\", torch.bfloat16, {\"device_map\": \"auto\", \"torch_dtype\": torch.bfloat16}
 elif hasattr(torch.backends, \"mps\") and torch.backends.mps.is_available():
 print(\"Apple Silicon MPS detected\")
 return \"mps\", torch.float16, {\"device_map\": \"mps\", \"torch_dtype\": torch.float16}
 else:
 print(\"No GPU found -- running on CPU (slower but functional)\")
 return \"cpu\", torch.float32, {\"device_map\": \"cpu\", \"torch_dtype\": torch.float32}
if __name__ == \"__main__\":
 device, dtype, kwargs = detect_device()
 print(f\"Device : {device}\")
 print(f\"Dtype : {dtype}\")
 print(f\"Kwargs : {kwargs}\")

Wie man SmolLM3 lädt und die erste Inferenz ausführt

Mit der bestätigten Umgebung hier ist das vollständige Muster zum Laden und Generieren. Dies umfasst die Auswahl des Datentyps, device_map=\“auto\“ für Multi-GPU oder CPU-Offload und beide Denkmodi nebeneinander.

import re
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM
MODEL_ID = \"HuggingFaceTB/SmolLM3-3B\"
print(f\"Loading {MODEL_ID}...\")
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
model = AutoModelForCausalLM.from_pretrained(
 MODEL_ID,
 torch_dtype=torch.bfloat16,
 device_map=\"auto\",
)
model.eval()
print(f\"Model loaded on: {model.device}\")
def generate(messages: list[dict], max_new_tokens: int = 512) -> str:
 \"\"\"
 Apply the SmolLM3 chat template, tokenize, generate, and decode.
 Strips the ... block from the output automatically
 so callers always receive the final answer only.
 \"\"\"
 text = tokenizer.apply_chat_template(
 messages,
 tokenize=False,
 add_generation_prompt=True,
 )
 inputs = tokenizer(text, return_tensors=\"pt\").to(model.device)
 with torch.no_grad():
 output_ids = model.generate(
 **inputs,
 max_new_tokens=max_new_tokens,
 temperature=0.6,
 top_p=0.95,
 do_sample=True,
 )
 new_tokens = output_ids[0][inputs[\"input_ids\"].shape[-1]:]
 raw = tokenizer.decode(new_tokens, skip_special_tokens=True)
 final = re.sub(r\".*?\", \"\", raw, flags=re.DOTALL).strip()
 return final
prompt = \"A customer is charged twice for the same order. What are three concrete steps support should take?\"
no_think_messages = [
 {\"role\": \"system\", \"content\": \"/no_think\"},
 {\"role\": \"user\", \"content\": prompt},
]
think_messages = [
 {\"role\": \"system\", \"content\": \"/think\"},
 {\"role\": \"user\", \"content\": prompt},
]
print(\"\\n── no_think mode ──\")
print(generate(no_think_messages, max_new_tokens=256))
print(\"\\n── think mode ──\")
print(generate(think_messages, max_new_tokens=512))

Wie man es ausführt:

python first_inference.py

Das Modell wird beim ersten Ausführen in ~/.cache/huggingface/hub/ heruntergeladen (~6,7 GB). Bei nachfolgenden Ausführungen wird es in wenigen Sekunden aus dem Cache geladen.

Wenn Sie die beiden Ausgaben vergleichen, produziert der Denkmodus eine merklich strukturiertere Antwort; er denkt über die Schritte nach, bevor er sich festlegt. Der Nicht-Denkmodus ist schneller und oft ausreichend für Routineaufgaben. Der richtige Modus hängt von Ihrem Latenzbudget und der Komplexität der Aufgabe ab. Für das Ticket-Router-Projekt, das als Nächstes kommt, verwenden wir Nicht-Denken für die Klassifizierung (latenzempfindlich) und Denken für Eskalationsentscheidungen (genauigkeitsempfindlich).

Aufbau eines mehrsprachigen Support-Ticket-Routers

Jetzt das Kernprojekt. Die TicketRouter-Klasse nimmt ein Support-Ticket in einer der sechs nativ unterstützten Sprachen von SmolLM3 (Englisch, Französisch, Spanisch, Deutsch, Italienisch, Portugiesisch), klassifiziert es in eine Kategorie, generiert eine Antwort in der Sprache des Tickets und kennzeichnet Ausgaben mit geringer Zuversicht zur menschlichen Überprüfung.

import re
import json
import torch
from dataclasses import dataclass
from transformers import AutoTokenizer, AutoModelForCausalLM
MODEL_ID = \"HuggingFaceTB/SmolLM3-3B\"
ESCALATE_AT = 0.70
@dataclass
class RoutingResult:
 ticket: str
 category: str
 confidence: float
 reply: str
 escalate: bool
class TicketRouter:
 def __init__(self, model_id: str = MODEL_ID):
 print(f\"Loading {model_id}...\")
 self.tokenizer = AutoTokenizer.from_pretrained(model_id)
 self.model = AutoModelForCausalLM.from_pretrained(
 model_id,
 torch_dtype=torch.bfloat16,
 device_map=\"auto\",
 )
 self.model.eval()
 print(f\"Ready on {self.model.device}\")
 def _call_model(self, ticket: str) -> str:
 messages = [
 {\"role\": \"system\", \"content\": SYSTEM_PROMPT},
 {\"role\": \"user\", \"content\": ticket},
 ]
 text = self.tokenizer.apply_chat_template(
 messages,
 tokenize=False,
 add_generation_prompt=True,
 enable_thinking=False,
 )
 inputs = self.tokenizer(text, return_tensors=\"pt\").to(self.model.device)
 with torch.no_grad():
 output_ids = self.model.generate(
 **inputs,
 max_new_tokens=256,
 temperature=0.3,
 top_p=0.9,
 do_sample=True,
 )
 new_tokens = output_ids[0][inputs[\"input_ids\"].shape[-1]:]
 return self.tokenizer.decode(new_tokens, skip_special_tokens=True).strip()
 def _parse_output(self, raw: str) -> dict:
 match = re.search(r\"\\{.*?\\}\", raw, re.DOTALL)
 if not match:
 return {\"category\": \"general\", \"confidence\": 0.0, \"reply\": raw}
 try:
 return json.loads(match.group())
 except json.JSONDecodeError:
 return {\"category\": \"general\", \"confidence\": 0.0, \"reply\": raw}
 def route(self, ticket: str) -> RoutingResult:
 raw = self._call_model(ticket)
 parsed = self._parse_output(raw)
 category = parsed.get(\"category\", \"general\")
 confidence = float(parsed.get(\"confidence\", 0.0))
 reply = parsed.get(\"reply\", \"Thank you for reaching out. We will follow up shortly.\")
 return RoutingResult(
 ticket=ticket,
 category=category,
 confidence=confidence,
 reply=reply,
 escalate=confidence < ESCALATE_AT,
 )
 def route_batch(self, tickets: list[RoutingResult]):
 return [self.route(t) for t in tickets]
if __name__ == \"__main__\":
 router = TicketRouter()
 test_tickets = [
 \"I was charged twice for my subscription this month. Please refund the duplicate charge.\",
 \"L'application se bloque chaque fois que j'essaie d'exporter un fichier PDF.\",
 \"No puedo iniciar sesión en mi cuenta desde hace dos días.\",
 \"Die Rechnung für März fehlt in meinem Abrechnungsbereich.\",
 \"Il mio abbonamento non si rinnova automaticamente nonostante il pagamento.\",
 ]
 print(\"\\n\" + \"=\" * 70)
 results = router.route_batch(test_tickets)
 for r in results:
 flag = \"🔴 ESCALATE\" if r.escalate else \"🟢 AUTO\"
 print(f\"\\n{flag}\")
 print(f\"Ticket : {r.ticket[:70]}...\")
 print(f\"Category : {r.category}\")
 print(f\"Confidence : {r.confidence:.2f}\")
 print(f\"Reply : {r.reply[:100]}...\")
 escalated = [r for r in results if r.escalate]
 print(f\"\\n{'─'*70}\")
 print(f\"Total tickets : {len(results)}\")
 print(f\"Auto-routed : {len(results) - len(escalated)}\")
 print(f\"Escalated : {len(escalated)}\")

Wie man es ausführt:

python ticket_router.py

Was Sie in der Ausgabe beachten sollten: Tickets, bei denen das Modell eine Zuversicht unter 0,70 zurückgibt, werden zur Eskalation gekennzeichnet. Mehrdeutige Tickets, kurze Nachrichten, mehrsprachige Inhalte und Anfragen, die zuverlässig in zwei Kategorien passen könnten, erzeugen in der Regel niedrigere Zuversichtswerte. Das ist das Signal, das Sie wollen: das Modell, das ehrlich über Unsicherheit ist, anstatt sicher zu raten und eine falsche Klassifizierung weiterzugeben.

Toolaufrufe zu SmolLM3 hinzufügen

Der Ticket-Router funktioniert gut für Klassifizierung und Antwortgenerierung. Aber was passiert, wenn ein Kunde nach einer bestimmten Bestellung fragt? Das Modell hat keinen Zugriff auf Ihre Datenbank. Ohne Toolaufrufe halluziniert es entweder eine Antwort oder weicht mit \"Bitte kontaktieren Sie den Support\" aus – beides ist nicht hilfreich.

SmolLM3 unterstützt nativ Toolaufrufe. Sie definieren ein Tool als JSON-Schema, übergeben es über xml_tools in der Chat-Vorlage, und das Modell gibt einen strukturierten -Block aus, wenn es entscheidet, dass das Tool benötigt wird. Sie analysieren diesen Block, rufen die echte Funktion auf, injizieren das Ergebnis und lassen das Modell die endgültige Antwort generieren.

Vollständiger Rundlauf für eine Bestellabfrage:

import re

import json

import torch

from transformers import AutoTokenizer, AutoModelForCausalLM

MODEL_ID = \"HuggingFaceTB/SmolLM3-3B\"

token


Quellen: kdnuggets
Bildquelle: KI generiert
Dieser Text wurde mit Hilfe von künstlicher Intelligenz in Zusammenarbeit mit unserer Redaktion erstellt.

      

      
      
        🚀
        

          KI-Snack Week 2026 · 09.–13. November
          
Das KI-Event für Macher & Entscheider
          
2 Tage live in München + 3 Tage Online-Masterclasses · Jetzt Ticket sichern
        
        Mehr erfahren →
      

      
              

                      
              Hugging Face            
                      
              KI            
                      
              smolLM3            
                      
              Sprachmodelle            
                      
              Technologie            
                  
      
      
      

                

          
KI Snack