[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-offering-angebot-leistungen":3,"reazon-offering-angebot-zielgruppen":20,"reazon-angebot-subnav":21,"reazon-mainnav":22,"reazon-page-\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt":32,"reazon-footernav":58,"reazon-articles-\u002Fde\u002Fwissen":75},[4,8,12,16],{"title":5,"href":6,"description":7},"DGX Spark mieten","\u002Fde\u002Fdgx-spark","Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":9,"href":10,"description":11},"Bare Metal GPU","\u002Fde\u002Fbare-metal","DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":13,"href":14,"description":15},"Managed Inference","\u002Fde\u002Fmanaged-inference","LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":17,"href":18,"description":19},"Hermes Agents","\u002Fde\u002Fagents","Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben.",[],[],[23,26,29],{"title":24,"href":25},"Preise","\u002Fde\u002Fpreise",{"title":27,"href":28},"Wissen","\u002Fde\u002Fwissen",{"title":30,"href":31},"Über Twentyone","\u002Fde\u002Fueber-uns",{"data":33},{"id":34,"path":35,"slug":36,"published_at":37,"page_type":38,"no_index":41,"fields":42,"blocks":57},1451,"\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt","fine-tuning-rag-prompt","2026-07-07T12:09:45.563Z",{"identifier":39,"name":40},"article","Blog Post",false,{"title":43,"summary":44,"publication_date":45,"big5_category":46,"primary_service":47,"meta_title":53,"meta_description":54,"body":55,"body_html":56},"Fine-Tuning, RAG oder besserer Prompt? Die klare Entscheidungsregel","Fine-Tuning ist meistens nicht die Antwort auf „das Modell kennt unsere Daten nicht“. Wann Prompting, RAG oder Fine-Tuning wirklich das richtige Werkzeug sind und wie du die Eskalationsleiter korrekt durchläufst.","2026-07-07T00:00:00Z","comparisons",{"id":48,"slug":49,"path":14,"page_type":50,"published":51,"type":52},676,"managed-inference","service",true,"Cms::Page","Fine-Tuning, RAG oder Prompt? Die Entscheidungsregel | Twentyone","Fine-Tuning löst kein Wissensproblem. Die klare Entscheidungsregel zwischen besserem Prompt, RAG und Fine-Tuning, mit Faustregeln und versteckten Kosten.","## Das Meeting, in dem \"Fine-Tuning\" fällt\n\nEin Produktteam sitzt zusammen, die Demo des internen Chatbots stockt: Die AI kennt die neue Preisliste nicht, verwechselt zwei Produktlinien und zitiert eine Garantiefrist, die seit drei Monaten nicht mehr gilt. Jemand sagt den Satz, der in solchen Meetings fast reflexhaft fällt: **„Wir müssen das Modell fine-tunen, damit es unsere Daten kennt.“** Alle nicken, ein Trainingslauf wird budgetiert, jemand exportiert Support-Tickets als Trainingsdaten. Das Problem: Was hier beschrieben wird, ist gar kein Verhaltens- oder Stilproblem, sondern ein **Wissensproblem**. Das Modell kennt die aktuelle Preisliste nicht, weil sie nirgendwo in seinem Kontext steht, nicht weil es „falsch trainiert“ wurde. Und ein Wissensproblem löst du fast nie mit Fine-Tuning. Du löst es mit **RAG**. Dieser Verwechslung begegnen wir bei praktisch jedem zweiten Kundengespräch, und sie kostet Teams Wochen und Budget, das an der falschen Stelle landet.\n\n## Drei Werkzeuge, drei völlig verschiedene Probleme\n\nDer Grund für die ständige Verwechslung ist, dass alle drei Werkzeuge irgendwie „das Modell besser machen“, aber eben an völlig unterschiedlichen Stellen ansetzen. Wer sie nicht sauber trennt, wählt zwangsläufig das falsche.\n\n**Prompting und Few-Shot** verändern nichts am Modell selbst, sondern nur, was du ihm bei jedem Aufruf mitgibst. Du gibst klare Anweisungen, zeigst zwei oder drei Beispiele für das gewünschte Format, und das reicht überraschend oft, um Ton, Struktur und einfache Verhaltensregeln zuverlässig zu steuern. Kein Training, keine Infrastruktur, Ergebnis in Minuten sichtbar. Das macht Prompting zur **immer ersten Stufe**, bevor du auch nur über Alternativen nachdenkst.\n\n**RAG** (Retrieval-Augmented Generation) holt zur Laufzeit relevante Informationen aus deinen eigenen Quellen, etwa einer Wissensdatenbank oder einem Dokumentenindex, und packt sie in den Kontext des Prompts. Das Modell selbst bleibt unverändert, es bekommt nur bei jeder Anfrage frisches Material zum Nachschlagen. Genau deshalb ist RAG das richtige Werkzeug für **aktuelles, faktisches oder unternehmensspezifisches Wissen**: Preislisten, Vertragsklauseln, Produktdaten, interne Prozesse. Ändert sich die Preisliste, aktualisierst du den Index, nicht das Modell.\n\n**Fine-Tuning** verändert dagegen die Gewichte des Modells selbst, durch zusätzliches Training auf eigenen Beispielen. Es prägt, **wie** das Modell antwortet, nicht **was** es weiss: Stil, Ton, Format-Treue, Fachjargon einer Domäne, konsistentes Verhalten über hunderte ähnliche Anfragen hinweg. Fine-Tuning ist damit ein Werkzeug für **Verhalten**, nicht für **Fakten**. Und genau diese Verwechslung ist der teuerste Fehler, den Teams in diesem Feld machen.\n\n## Warum Fakten nicht ins Gewicht gehören\n\nDer technische Grund, warum Fine-Tuning für Faktenwissen fast immer die falsche Wahl ist, liegt in der Natur des Verfahrens. Wenn du ein Modell auf einem Datensatz feintunst, werden die Fakten darin **in den Gewichten des Modells eingebrannt**, verteilt über Millionen von Parametern, ohne dass du im Nachhinein gezielt „diese eine Zahl“ ändern oder zurückverfolgen kannst, woher eine Antwort kommt. Ändert sich die Realität, veraltet das Wissen im Modell **stillschweigend**, und du merkst es erst, wenn ein Kunde eine falsche Garantiefrist genannt bekommt. Es gibt keinen Mechanismus, mit dem du „nur die Preisliste“ aktualisierst, du müsstest komplett neu trainieren.\n\nRAG hat dieses Problem grundsätzlich nicht, weil das Wissen **ausserhalb des Modells** liegt und bei jedem Aufruf frisch gezogen wird. Zusätzlich bekommst du bei RAG etwas, das Fine-Tuning dir strukturell nicht geben kann: **Nachvollziehbarkeit**. Du kannst zeigen, aus welchem Dokument eine Antwort stammt, und dieses Dokument gezielt korrigieren. Bei einem feingetunten Modell ist die Antwort ein Destillat aus dem gesamten Trainingsdatensatz, es gibt keine Quellenangabe, die du nachträglich reparieren könntest. Wer sein Wissensproblem trotzdem mit Fine-Tuning angehen will, kauft sich also nicht nur unnötigen Aufwand ein, sondern auch ein System, das schlechter wartbar ist als die Alternative. Die Grundüberlegung, welches Setup für dein konkretes Problem angemessen ist, deckt sich übrigens mit der Frage, [ob du überhaupt einen Agenten oder nur einen Endpoint brauchst](\u002Fde\u002Fwissen\u002Fagent-oder-endpoint): In beiden Fällen zahlst du für Komplexität, die dein Problem oft gar nicht verlangt.\n\n## Was Fine-Tuning tatsächlich kann\n\nDas heisst nicht, dass Fine-Tuning nutzlos ist, im Gegenteil: Für die richtige Aufgabe ist es unersetzbar. **Konsistenter Stil und Ton über tausende Antworten** lässt sich mit Prompting allein selten stabil halten, ein Modell driftet über lange Sessions oder bei Edge Cases ab. Fine-Tuning prägt dieses Verhalten strukturell ins Modell ein, statt es bei jedem Aufruf neu zu erbitten. Ähnlich bei **striktem Ausgabeformat**: Wenn dein System auf ein exaktes JSON-Schema oder ein bestimmtes Dokumentenformat angewiesen ist und Prompting trotz sorgfältiger Anweisungen gelegentlich abweicht, kann ein feingetuntes Modell diese Formattreue deutlich zuverlässiger liefern. Auch **hohe Domänensprache**, etwa Rechts- oder Medizinjargon mit sehr spezifischer Terminologie und Argumentationsstruktur, lässt sich über viele kuratierte Beispiele besser einprägen als über einen noch so langen Prompt.\n\nTechnisch läuft heute kaum noch jemand ein **Full-Fine-Tuning**, bei dem alle Milliarden Parameter neu trainiert werden. **LoRA und QLoRA** trainieren stattdessen nur kleine, zusätzliche Adapter-Gewichte und lassen den Rest des Modells eingefroren, das senkt Rechenaufwand und Speicherbedarf drastisch und macht Fine-Tuning für weit mehr Teams praktisch machbar. Das ändert aber nichts an der Grundfrage: Ob Fine-Tuning **überhaupt das richtige Werkzeug für dein Problem** ist, entscheidet sich vorher, nicht durch die Wahl der Trainingsmethode. Als Faustregel für die Datenmenge gilt: Rechne eher mit **hunderten bis niedrigen tausenden sauber kuratierten Beispielen** statt mit ein paar Dutzend Zeilen aus einer Excel-Tabelle, denn zu wenige oder inkonsistente Beispiele bringen dir oft weniger als ein guter Prompt.\n\n## Die versteckten Kosten, die niemand einplant\n\nWer Fine-Tuning budgetiert, kalkuliert meistens die GPU-Stunden und vergisst den Rest. **Datenaufbereitung ist in der Praxis der grösste Aufwand**, nicht das Training selbst: Beispiele sammeln, bereinigen, konsistent formatieren, doppelte oder widersprüchliche Fälle rauswerfen, das frisst oft mehr Personentage als der eigentliche Trainingslauf. Dazu kommt, dass ein feingetuntes Modell **an ein bestimmtes Basismodell gebunden** ist. Wechselst du auf eine neuere, bessere Basisversion, wovon es inzwischen mehrmals im Jahr eine gibt, musst du den gesamten Prozess wiederholen. Fine-Tuning ist damit kein einmaliges Projekt, sondern eine **wiederkehrende Betriebskosten-Position**, die du in deine Gesamtrechnung einplanen musst, wie wir sie in [den Kosten eigener LLMs](\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten) im Detail durchrechnen.\n\nZwei weitere Risiken tauchen erst spät auf, wenn sie schon teuer sind: **Overfitting**, wenn das Modell die Trainingsbeispiele fast auswendig lernt statt zu generalisieren, und **catastrophic forgetting**, wenn das Modell durch das Fine-Tuning Fähigkeiten verliert, die es vorher problemlos beherrschte, etwa allgemeines Sprachverständnis oder Reasoning ausserhalb der Trainingsdomäne. Beides zeigt sich nicht im Trainingsloss, sondern erst in echter Nutzung, wenn Kunden auf einmal seltsame Antworten bekommen. Deshalb braucht jedes Fine-Tuning eine **echte Evaluation** gegen einen Testdatensatz und im besten Fall gegen das ursprüngliche Basismodell, sonst merkst du Regressionen erst, wenn Nutzer sich beschweren. All das ist Arbeit, die weit über den eigentlichen Trainingslauf hinausgeht, und die in vielen Angeboten stillschweigend unter den Tisch fällt.\n\n## Die Eskalationsleiter: Nimm immer die niedrigste Stufe, die reicht\n\nStatt dich zu fragen „Prompting, RAG oder Fine-Tuning?“, denk in einer **Leiter** und steig nur eine Stufe höher, wenn die darunterliegende **nachweislich nicht reicht**:\n\n1. **Besserer Prompt \u002F Few-Shot**: klare Instruktionen, zwei bis drei Beispiele. Löst Format- und einfache Verhaltensfragen fast immer, ohne einen einzigen Trainingslauf.\n2. **RAG**: Wissen zur Laufzeit ergänzen. Löst „das Modell kennt unsere Fakten nicht“, egal ob Preise, Verträge oder Produktdaten, ohne dass du je wieder trainieren musst, wenn sich diese Fakten ändern.\n3. **Fine-Tuning**: Verhalten, Stil und Format über viele Beispiele hinweg prägen. Erst hier, wenn Stufe eins und zwei ausprobiert und dokumentiert an ihre Grenzen gestossen sind.\n\nDer Punkt, den keiner gern hört: **Rund 90 Prozent der Fälle, in denen Teams „wir brauchen Fine-Tuning“ sagen, sind bei genauerem Hinsehen RAG- oder Prompt-Fälle.** Wer dennoch zurecht bei Fine-Tuning landet, kombiniert es meistens ohnehin mit RAG, ein feingetuntes Modell für Ton und Format, gespeist mit aktuellem Wissen aus deinem Index; die beiden Stufen schliessen sich nicht aus, sie ergänzen sich. Auch ein legitimer, oft unterschätzter Grund für Fine-Tuning ist **Latenz- und Kostenoptimierung**: Ein kleines, feingetuntes Modell ersetzt ein grosses generisches Modell für eine eng umrissene Aufgabe, günstiger im Betrieb und schneller in der Antwort. Wenn du an dem Punkt bist, dass diese Rechnung für dich aufgeht, lohnt sich ein Blick auf die passende [Auswahl offener Basismodelle](\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl) für dein Vorhaben, und wer erste Trainingsläufe lokal testen will, bevor er in produktive Infrastruktur investiert, findet in unserem [Erfahrungsbericht zum DGX Spark](\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht) einen guten Ausgangspunkt.\n\n## Wo du wirklich anfangen solltest\n\n**Fang unten an, nicht oben.** Bevor irgendjemand in deinem Team „Fine-Tuning“ sagt, prüf zuerst, ob ein besserer Prompt mit ein paar Beispielen reicht, und wenn das Problem eigentlich heisst „das Modell kennt unsere Daten nicht“, ist die Antwort so gut wie immer RAG, nicht Training. Fine-Tuning ist ein mächtiges, aber teures Werkzeug für **Stil, Format und konsistentes Verhalten**, mit echten Vorlaufkosten in der Datenaufbereitung und wiederkehrendem Aufwand bei jedem Modellwechsel. Wenn du an diesem Punkt wirklich angekommen bist, lohnt es sich, das Training souverän auf eigener Infrastruktur in der Schweiz durchzuführen, mit voller Kontrolle über deine Trainingsdaten und ohne dass sie je ein Rechenzentrum im Ausland durchlaufen. Wir sagen dir vorher klar, auf welcher Stufe der Leiter dein Problem wirklich liegt, und begleiten dich über [Managed Inference](\u002Fde\u002Fmanaged-inference) von der ersten RAG-Pipeline bis zum sauber evaluierten, feingetunten Modell, wenn es tatsächlich so weit ist.","\u003Ch2>Das Meeting, in dem \u003Cq>Fine-Tuning\u003C\u002Fq> fällt\u003C\u002Fh2>\n\n\u003Cp>Ein Produktteam sitzt zusammen, die Demo des internen Chatbots stockt: Die AI kennt die neue Preisliste nicht, verwechselt zwei Produktlinien und zitiert eine Garantiefrist, die seit drei Monaten nicht mehr gilt. Jemand sagt den Satz, der in solchen Meetings fast reflexhaft fällt: \u003Cstrong>„Wir müssen das Modell fine-tunen, damit es unsere Daten kennt.“\u003C\u002Fstrong> Alle nicken, ein Trainingslauf wird budgetiert, jemand exportiert Support-Tickets als Trainingsdaten. Das Problem: Was hier beschrieben wird, ist gar kein Verhaltens- oder Stilproblem, sondern ein \u003Cstrong>Wissensproblem\u003C\u002Fstrong>. Das Modell kennt die aktuelle Preisliste nicht, weil sie nirgendwo in seinem Kontext steht, nicht weil es „falsch trainiert“ wurde. Und ein Wissensproblem löst du fast nie mit Fine-Tuning. Du löst es mit \u003Cstrong>RAG\u003C\u002Fstrong>. Dieser Verwechslung begegnen wir bei praktisch jedem zweiten Kundengespräch, und sie kostet Teams Wochen und Budget, das an der falschen Stelle landet.\u003C\u002Fp>\n\n\u003Ch2>Drei Werkzeuge, drei völlig verschiedene Probleme\u003C\u002Fh2>\n\n\u003Cp>Der Grund für die ständige Verwechslung ist, dass alle drei Werkzeuge irgendwie „das Modell besser machen“, aber eben an völlig unterschiedlichen Stellen ansetzen. Wer sie nicht sauber trennt, wählt zwangsläufig das falsche.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Prompting und Few-Shot\u003C\u002Fstrong> verändern nichts am Modell selbst, sondern nur, was du ihm bei jedem Aufruf mitgibst. Du gibst klare Anweisungen, zeigst zwei oder drei Beispiele für das gewünschte Format, und das reicht überraschend oft, um Ton, Struktur und einfache Verhaltensregeln zuverlässig zu steuern. Kein Training, keine Infrastruktur, Ergebnis in Minuten sichtbar. Das macht Prompting zur \u003Cstrong>immer ersten Stufe\u003C\u002Fstrong>, bevor du auch nur über Alternativen nachdenkst.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>RAG\u003C\u002Fstrong> (Retrieval-Augmented Generation) holt zur Laufzeit relevante Informationen aus deinen eigenen Quellen, etwa einer Wissensdatenbank oder einem Dokumentenindex, und packt sie in den Kontext des Prompts. Das Modell selbst bleibt unverändert, es bekommt nur bei jeder Anfrage frisches Material zum Nachschlagen. Genau deshalb ist RAG das richtige Werkzeug für \u003Cstrong>aktuelles, faktisches oder unternehmensspezifisches Wissen\u003C\u002Fstrong>: Preislisten, Vertragsklauseln, Produktdaten, interne Prozesse. Ändert sich die Preisliste, aktualisierst du den Index, nicht das Modell.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Fine-Tuning\u003C\u002Fstrong> verändert dagegen die Gewichte des Modells selbst, durch zusätzliches Training auf eigenen Beispielen. Es prägt, \u003Cstrong>wie\u003C\u002Fstrong> das Modell antwortet, nicht \u003Cstrong>was\u003C\u002Fstrong> es weiss: Stil, Ton, Format-Treue, Fachjargon einer Domäne, konsistentes Verhalten über hunderte ähnliche Anfragen hinweg. Fine-Tuning ist damit ein Werkzeug für \u003Cstrong>Verhalten\u003C\u002Fstrong>, nicht für \u003Cstrong>Fakten\u003C\u002Fstrong>. Und genau diese Verwechslung ist der teuerste Fehler, den Teams in diesem Feld machen.\u003C\u002Fp>\n\n\u003Ch2>Warum Fakten nicht ins Gewicht gehören\u003C\u002Fh2>\n\n\u003Cp>Der technische Grund, warum Fine-Tuning für Faktenwissen fast immer die falsche Wahl ist, liegt in der Natur des Verfahrens. Wenn du ein Modell auf einem Datensatz feintunst, werden die Fakten darin \u003Cstrong>in den Gewichten des Modells eingebrannt\u003C\u002Fstrong>, verteilt über Millionen von Parametern, ohne dass du im Nachhinein gezielt „diese eine Zahl“ ändern oder zurückverfolgen kannst, woher eine Antwort kommt. Ändert sich die Realität, veraltet das Wissen im Modell \u003Cstrong>stillschweigend\u003C\u002Fstrong>, und du merkst es erst, wenn ein Kunde eine falsche Garantiefrist genannt bekommt. Es gibt keinen Mechanismus, mit dem du „nur die Preisliste“ aktualisierst, du müsstest komplett neu trainieren.\u003C\u002Fp>\n\n\u003Cp>RAG hat dieses Problem grundsätzlich nicht, weil das Wissen \u003Cstrong>ausserhalb des Modells\u003C\u002Fstrong> liegt und bei jedem Aufruf frisch gezogen wird. Zusätzlich bekommst du bei RAG etwas, das Fine-Tuning dir strukturell nicht geben kann: \u003Cstrong>Nachvollziehbarkeit\u003C\u002Fstrong>. Du kannst zeigen, aus welchem Dokument eine Antwort stammt, und dieses Dokument gezielt korrigieren. Bei einem feingetunten Modell ist die Antwort ein Destillat aus dem gesamten Trainingsdatensatz, es gibt keine Quellenangabe, die du nachträglich reparieren könntest. Wer sein Wissensproblem trotzdem mit Fine-Tuning angehen will, kauft sich also nicht nur unnötigen Aufwand ein, sondern auch ein System, das schlechter wartbar ist als die Alternative. Die Grundüberlegung, welches Setup für dein konkretes Problem angemessen ist, deckt sich übrigens mit der Frage, \u003Ca href=\"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint\">ob du überhaupt einen Agenten oder nur einen Endpoint brauchst\u003C\u002Fa>: In beiden Fällen zahlst du für Komplexität, die dein Problem oft gar nicht verlangt.\u003C\u002Fp>\n\n\u003Ch2>Was Fine-Tuning tatsächlich kann\u003C\u002Fh2>\n\n\u003Cp>Das heisst nicht, dass Fine-Tuning nutzlos ist, im Gegenteil: Für die richtige Aufgabe ist es unersetzbar. \u003Cstrong>Konsistenter Stil und Ton über tausende Antworten\u003C\u002Fstrong> lässt sich mit Prompting allein selten stabil halten, ein Modell driftet über lange Sessions oder bei Edge Cases ab. Fine-Tuning prägt dieses Verhalten strukturell ins Modell ein, statt es bei jedem Aufruf neu zu erbitten. Ähnlich bei \u003Cstrong>striktem Ausgabeformat\u003C\u002Fstrong>: Wenn dein System auf ein exaktes JSON-Schema oder ein bestimmtes Dokumentenformat angewiesen ist und Prompting trotz sorgfältiger Anweisungen gelegentlich abweicht, kann ein feingetuntes Modell diese Formattreue deutlich zuverlässiger liefern. Auch \u003Cstrong>hohe Domänensprache\u003C\u002Fstrong>, etwa Rechts- oder Medizinjargon mit sehr spezifischer Terminologie und Argumentationsstruktur, lässt sich über viele kuratierte Beispiele besser einprägen als über einen noch so langen Prompt.\u003C\u002Fp>\n\n\u003Cp>Technisch läuft heute kaum noch jemand ein \u003Cstrong>Full-Fine-Tuning\u003C\u002Fstrong>, bei dem alle Milliarden Parameter neu trainiert werden. \u003Cstrong>LoRA und QLoRA\u003C\u002Fstrong> trainieren stattdessen nur kleine, zusätzliche Adapter-Gewichte und lassen den Rest des Modells eingefroren, das senkt Rechenaufwand und Speicherbedarf drastisch und macht Fine-Tuning für weit mehr Teams praktisch machbar. Das ändert aber nichts an der Grundfrage: Ob Fine-Tuning \u003Cstrong>überhaupt das richtige Werkzeug für dein Problem\u003C\u002Fstrong> ist, entscheidet sich vorher, nicht durch die Wahl der Trainingsmethode. Als Faustregel für die Datenmenge gilt: Rechne eher mit \u003Cstrong>hunderten bis niedrigen tausenden sauber kuratierten Beispielen\u003C\u002Fstrong> statt mit ein paar Dutzend Zeilen aus einer Excel-Tabelle, denn zu wenige oder inkonsistente Beispiele bringen dir oft weniger als ein guter Prompt.\u003C\u002Fp>\n\n\u003Ch2>Die versteckten Kosten, die niemand einplant\u003C\u002Fh2>\n\n\u003Cp>Wer Fine-Tuning budgetiert, kalkuliert meistens die GPU-Stunden und vergisst den Rest. \u003Cstrong>Datenaufbereitung ist in der Praxis der grösste Aufwand\u003C\u002Fstrong>, nicht das Training selbst: Beispiele sammeln, bereinigen, konsistent formatieren, doppelte oder widersprüchliche Fälle rauswerfen, das frisst oft mehr Personentage als der eigentliche Trainingslauf. Dazu kommt, dass ein feingetuntes Modell \u003Cstrong>an ein bestimmtes Basismodell gebunden\u003C\u002Fstrong> ist. Wechselst du auf eine neuere, bessere Basisversion, wovon es inzwischen mehrmals im Jahr eine gibt, musst du den gesamten Prozess wiederholen. Fine-Tuning ist damit kein einmaliges Projekt, sondern eine \u003Cstrong>wiederkehrende Betriebskosten-Position\u003C\u002Fstrong>, die du in deine Gesamtrechnung einplanen musst, wie wir sie in \u003Ca href=\"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten\">den Kosten eigener LLMs\u003C\u002Fa> im Detail durchrechnen.\u003C\u002Fp>\n\n\u003Cp>Zwei weitere Risiken tauchen erst spät auf, wenn sie schon teuer sind: \u003Cstrong>Overfitting\u003C\u002Fstrong>, wenn das Modell die Trainingsbeispiele fast auswendig lernt statt zu generalisieren, und \u003Cstrong>catastrophic forgetting\u003C\u002Fstrong>, wenn das Modell durch das Fine-Tuning Fähigkeiten verliert, die es vorher problemlos beherrschte, etwa allgemeines Sprachverständnis oder Reasoning ausserhalb der Trainingsdomäne. Beides zeigt sich nicht im Trainingsloss, sondern erst in echter Nutzung, wenn Kunden auf einmal seltsame Antworten bekommen. Deshalb braucht jedes Fine-Tuning eine \u003Cstrong>echte Evaluation\u003C\u002Fstrong> gegen einen Testdatensatz und im besten Fall gegen das ursprüngliche Basismodell, sonst merkst du Regressionen erst, wenn Nutzer sich beschweren. All das ist Arbeit, die weit über den eigentlichen Trainingslauf hinausgeht, und die in vielen Angeboten stillschweigend unter den Tisch fällt.\u003C\u002Fp>\n\n\u003Ch2>Die Eskalationsleiter: Nimm immer die niedrigste Stufe, die reicht\u003C\u002Fh2>\n\n\u003Cp>Statt dich zu fragen „Prompting, RAG oder Fine-Tuning?“, denk in einer \u003Cstrong>Leiter\u003C\u002Fstrong> und steig nur eine Stufe höher, wenn die darunterliegende \u003Cstrong>nachweislich nicht reicht\u003C\u002Fstrong>:\u003C\u002Fp>\n\n\u003Col>\n\u003Cli>\u003Cstrong>Besserer Prompt \u002F Few-Shot\u003C\u002Fstrong>: klare Instruktionen, zwei bis drei Beispiele. Löst Format- und einfache Verhaltensfragen fast immer, ohne einen einzigen Trainingslauf.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>RAG\u003C\u002Fstrong>: Wissen zur Laufzeit ergänzen. Löst „das Modell kennt unsere Fakten nicht“, egal ob Preise, Verträge oder Produktdaten, ohne dass du je wieder trainieren musst, wenn sich diese Fakten ändern.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fine-Tuning\u003C\u002Fstrong>: Verhalten, Stil und Format über viele Beispiele hinweg prägen. Erst hier, wenn Stufe eins und zwei ausprobiert und dokumentiert an ihre Grenzen gestossen sind.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>Der Punkt, den keiner gern hört: \u003Cstrong>Rund 90 Prozent der Fälle, in denen Teams „wir brauchen Fine-Tuning“ sagen, sind bei genauerem Hinsehen RAG- oder Prompt-Fälle.\u003C\u002Fstrong> Wer dennoch zurecht bei Fine-Tuning landet, kombiniert es meistens ohnehin mit RAG, ein feingetuntes Modell für Ton und Format, gespeist mit aktuellem Wissen aus deinem Index; die beiden Stufen schliessen sich nicht aus, sie ergänzen sich. Auch ein legitimer, oft unterschätzter Grund für Fine-Tuning ist \u003Cstrong>Latenz- und Kostenoptimierung\u003C\u002Fstrong>: Ein kleines, feingetuntes Modell ersetzt ein grosses generisches Modell für eine eng umrissene Aufgabe, günstiger im Betrieb und schneller in der Antwort. Wenn du an dem Punkt bist, dass diese Rechnung für dich aufgeht, lohnt sich ein Blick auf die passende \u003Ca href=\"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl\">Auswahl offener Basismodelle\u003C\u002Fa> für dein Vorhaben, und wer erste Trainingsläufe lokal testen will, bevor er in produktive Infrastruktur investiert, findet in unserem \u003Ca href=\"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht\">Erfahrungsbericht zum DGX Spark\u003C\u002Fa> einen guten Ausgangspunkt.\u003C\u002Fp>\n\n\u003Ch2>Wo du wirklich anfangen solltest\u003C\u002Fh2>\n\n\u003Cp>\u003Cstrong>Fang unten an, nicht oben.\u003C\u002Fstrong> Bevor irgendjemand in deinem Team „Fine-Tuning“ sagt, prüf zuerst, ob ein besserer Prompt mit ein paar Beispielen reicht, und wenn das Problem eigentlich heisst „das Modell kennt unsere Daten nicht“, ist die Antwort so gut wie immer RAG, nicht Training. Fine-Tuning ist ein mächtiges, aber teures Werkzeug für \u003Cstrong>Stil, Format und konsistentes Verhalten\u003C\u002Fstrong>, mit echten Vorlaufkosten in der Datenaufbereitung und wiederkehrendem Aufwand bei jedem Modellwechsel. Wenn du an diesem Punkt wirklich angekommen bist, lohnt es sich, das Training souverän auf eigener Infrastruktur in der Schweiz durchzuführen, mit voller Kontrolle über deine Trainingsdaten und ohne dass sie je ein Rechenzentrum im Ausland durchlaufen. Wir sagen dir vorher klar, auf welcher Stufe der Leiter dein Problem wirklich liegt, und begleiten dich über \u003Ca href=\"\u002Fde\u002Fmanaged-inference\">Managed Inference\u003C\u002Fa> von der ersten RAG-Pipeline bis zum sauber evaluierten, feingetunten Modell, wenn es tatsächlich so weit ist.\u003C\u002Fp>\n",[],[59,66],{"title":60,"links":61},"Leistungen",[62,63,64,65],{"title":5,"href":6},{"title":9,"href":10},{"title":13,"href":14},{"title":17,"href":18},{"title":67,"links":68},"Unternehmen",[69,70,71,72],{"title":30,"href":31},{"title":27,"href":28},{"title":24,"href":25},{"title":73,"href":74},"Kontakt","\u002Fde\u002Fkontakt",[76,85,97,107,115,123,125,132,138,144,150,157,163,169,175,181,187,194],{"path":77,"slug":78,"title":79,"summary":80,"image":81,"publication_date":82,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":83},"\u002Fde\u002Fwissen\u002Fazure-openai-bedrock-alternative-schweiz","azure-openai-bedrock-alternative-schweiz","Souveräne Inferenz gegen Azure OpenAI und AWS Bedrock: was sich im Alltag ändert","Azure OpenAI und AWS Bedrock gegen einen souverän betriebenen Endpoint: warum der Schweizer Serverstandort der Hyperscaler das Kernproblem nicht löst und was der Unterschied im Betrieb bedeutet.",null,"2026-07-13T00:00:00Z",[84],{"slug":49,"title":13},{"path":86,"slug":87,"title":88,"summary":89,"image":81,"publication_date":82,"big5_category":90,"primary_hub":81,"cluster":81,"pillar":81,"hubs":91},"\u002Fde\u002Fwissen\u002Fbeste-gpu-llm-inferenz","beste-gpu-llm-inferenz","Die beste GPU für LLM-Inferenz: DGX Spark, H100, L40S und RTX im Vergleich","Welche GPU für eigene Inferenz? DGX Spark, H100, L40S und RTX 4090 nach dem, was zählt: wie viel Modell hineinpasst, wie viel Durchsatz herauskommt und was der Monat kostet.","bestof",[92,95],{"slug":93,"title":94},"bare-metal","Bare Metal GPU mit Root-Zugriff",{"slug":96,"title":5},"dgx-spark",{"path":98,"slug":99,"title":100,"summary":101,"image":81,"publication_date":82,"big5_category":102,"primary_hub":81,"cluster":81,"pillar":81,"hubs":103},"\u002Fde\u002Fwissen\u002Fhermes-agent-erfahrungsbericht","hermes-agent-erfahrungsbericht","Hermes-Agent im Realbetrieb: was ein souveräner Agent wirklich leistet","Ein Erfahrungsbericht statt Hochglanzprospekt: wie sich ein souverän betriebener Hermes-Agent im täglichen Einsatz verhält, wo er glänzt und wo die Begleitung anfängt.","reviews",[104],{"slug":105,"title":106},"agents","Hermes Agents as a Service",{"path":108,"slug":109,"title":110,"summary":111,"image":81,"publication_date":82,"big5_category":112,"primary_hub":81,"cluster":81,"pillar":81,"hubs":113},"\u002Fde\u002Fwissen\u002Fki-regulierte-daten-schweiz","ki-regulierte-daten-schweiz","KI mit regulierten Daten: LLMs nutzen, ohne dass die Daten die Schweiz verlassen","Für Branchen, in denen Daten das Land nicht verlassen dürfen: was revDSG, Berufsgeheimnis und der CLOUD Act für KI-Projekte bedeuten, und wie souveräne Inferenz den Rahmen einhält.","problems",[114],{"slug":49,"title":13},{"path":116,"slug":117,"title":118,"summary":119,"image":81,"publication_date":82,"big5_category":120,"primary_hub":81,"cluster":81,"pillar":81,"hubs":121},"\u002Fde\u002Fwissen\u002Fopenai-api-kosten-vs-eigener-endpoint","openai-api-kosten-vs-eigener-endpoint","Ab welchem Volumen sich ein eigener Endpoint gegen die API rechnet","Die Pay-per-Token-API ist günstig, bis sie es nicht mehr ist. Wo genau der Break-even zu einem reservierten Endpoint mit fester Monatspauschale liegt, an einem konkreten Beispiel durchgerechnet.","cost",[122],{"slug":49,"title":13},{"path":35,"slug":36,"title":43,"summary":44,"image":81,"publication_date":45,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":124},[],{"path":126,"slug":127,"title":128,"summary":129,"image":81,"publication_date":45,"big5_category":130,"primary_hub":81,"cluster":81,"pillar":81,"hubs":131},"\u002Fde\u002Fwissen\u002Fopenai-api-migration","openai-api-migration","Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis","Der Umstieg von OpenAI oder Anthropic auf ein selbst betriebenes offenes Modell in der Schweiz sieht dank OpenAI-kompatibler Endpoints nach einer Ein-Zeilen-Änderung aus, ist aber doch mehr. Wo Prompts, Tool-Calling und Feature-Lücken zur Stolperfalle werden.","how-to",[],{"path":133,"slug":134,"title":135,"summary":136,"image":81,"publication_date":45,"big5_category":112,"primary_hub":81,"cluster":81,"pillar":81,"hubs":137},"\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf","quantisierung-int4-int8-awq-gptq-gguf","Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Wir zeigen dir ungeschönt, was Quantisierung wirklich kostet und wo GPTQ, AWQ, GGUF und bitsandbytes hingehören.",[],{"path":139,"slug":140,"title":141,"summary":142,"image":81,"publication_date":45,"big5_category":112,"primary_hub":81,"cluster":81,"pillar":81,"hubs":143},"\u002Fde\u002Fwissen\u002Frag-schlechte-antworten","rag-schlechte-antworten","RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt","Die meisten RAG-Systeme scheitern nicht am Sprachmodell, sondern am Retrieval davor. Wir zeigen die häufigsten Fehlerquellen bei Chunking, Embeddings und Retrieval-Strategie sowie, wie du Retrieval- und Generationsfehler sauber auseinanderhältst.",[],{"path":145,"slug":146,"title":147,"summary":148,"image":81,"publication_date":45,"big5_category":130,"primary_hub":81,"cluster":81,"pillar":81,"hubs":149},"\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen","vram-modell-gpu-berechnen","Welches Modell passt auf welche GPU? VRAM richtig berechnen","Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.",[],{"path":151,"slug":152,"title":153,"summary":154,"image":81,"publication_date":155,"big5_category":112,"primary_hub":81,"cluster":81,"pillar":81,"hubs":156},"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint","agent-oder-endpoint","Braucht ihr wirklich einen Agent oder reicht ein Endpoint?","Agenten sind im Trend, aber oft die teurere und fragilere Lösung für ein Problem, das ein einfacher Endpoint löst. Wann sich der Aufwand lohnt und wann nicht.","2026-06-30T00:00:00Z",[],{"path":158,"slug":159,"title":160,"summary":161,"image":81,"publication_date":155,"big5_category":112,"primary_hub":81,"cluster":81,"pillar":81,"hubs":162},"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das","datenhoheit-was-bedeutet-das","Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen","Datenhoheit ist mehr als ein Hosting-Standort. Was rechtlich, technisch und vertraglich dahintersteckt, und welche Fragen du jedem AI-Anbieter stellen solltest.",[],{"path":164,"slug":165,"title":166,"summary":167,"image":81,"publication_date":155,"big5_category":102,"primary_hub":81,"cluster":81,"pillar":81,"hubs":168},"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann","Kein Datenblatt, sondern ein Erfahrungsbericht. Wo die DGX Spark im täglichen Betrieb glänzt, wo ihre Grenzen liegen und für wen sich die Maschine lohnt.",[],{"path":170,"slug":171,"title":172,"summary":173,"image":81,"publication_date":155,"big5_category":130,"primary_hub":81,"cluster":81,"pillar":81,"hubs":174},"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","Eigenen LLM Endpoint aufsetzen: von der GPU zum ersten Token","Ein realistischer Weg vom blanken Server zum produktiven Inferenz-Endpoint. Die Schritte, die Reihenfolge und die Stolpersteine, die zwischen „läuft lokal“ und „läuft produktiv“ liegen.",[],{"path":176,"slug":177,"title":178,"summary":179,"image":81,"publication_date":155,"big5_category":90,"primary_hub":81,"cluster":81,"pillar":81,"hubs":180},"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","Welches offene Modell für welche Aufgabe? Llama, Qwen, Mistral & Co.","Nicht das grösste Modell gewinnt, sondern das passende. Wie du offene Modelle nach Aufgabe, Speicherbedarf und Lizenz auswählst, statt Benchmarks hinterherzulaufen.",[],{"path":182,"slug":183,"title":184,"summary":185,"image":81,"publication_date":155,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":186},"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","vLLM, Ollama oder TGI: welche Inference Engine für welchen Fall","Die Engine entscheidet über Durchsatz, Latenz und Betriebsaufwand. Ein nüchterner Vergleich der drei verbreitetsten Optionen, inklusive der Fälle, in denen die einfache Lösung gewinnt.",[],{"path":188,"slug":189,"title":190,"summary":191,"image":81,"publication_date":192,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":193},"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu","dgx-spark-vs-cloud-gpu","DGX Spark gegen Cloud-GPU: wann sich eigene Hardware lohnt","Unified Memory gegen rohen Durchsatz, Schweizer Hardware gegen Hyperscaler. Ein nüchterner Vergleich, inklusive der Fälle, in denen die Cloud gewinnt.","2026-06-18T00:00:00Z",[],{"path":195,"slug":196,"title":197,"summary":198,"image":81,"publication_date":192,"big5_category":120,"primary_hub":81,"cluster":81,"pillar":81,"hubs":199},"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten","llm-selbst-betreiben-kosten","Was kostet es, ein LLM selbst zu betreiben?","Die nüchterne Rechnung hinter eigenen LLM-Endpoints: Hardware, Betrieb und der Punkt, ab dem sich Selbermachen wirklich lohnt.",[]]