Fine-Tuning oder RAG: was das Wissen Ihres Unternehmens ins Modell bringt

Was RAG und Fine-Tuning jeweils verändern

Für Unternehmenswissen, das sich ändert oder belegt werden muss, nutzen Sie RAG, für Ausgabeformat, Ton, Aufgabenverhalten und Fachkönnen Fine-Tuning; beides lässt sich kombinieren. Fine-Tuning ändert die Parameter des Modells, RAG dagegen, was das Modell zur Abfragezeit erhält.

Retrieval-augmented Generation, definiert in der ursprünglichen RAG-Arbeit vom Mai 2020, verbindet das parametrische Gedächtnis des Modells mit einem durchsuchbaren nicht-parametrischen. In den Worten ihrer Autoren waren der Herkunftsnachweis für die Entscheidungen eines Modells und die Aktualisierung seines Weltwissens offene Forschungsfragen. Anthropics Glossar beschreibt den Mechanismus operativ: Zur Laufzeit abgerufene Dokumente werden ins Kontextfenster gelegt. Die Gewichte bleiben unverändert.

Fine-Tuning funktioniert umgekehrt. NVIDIAs Leitfaden zur Anpassung hält fest, dass Fine-Tuning die vortrainierten Gewichte aktualisiert, während promptbasierte Techniken sie eingefroren lassen. Anthropics Glossar beschreibt das Ergebnis als ein Modell, das die Muster des Tuning-Datensatzes abbildet und nachahmt; es lernt also Muster statt Fakten.

LoRA, aus einer Arbeit vom Juni 2021, friert das Basismodell ein und fügt in jede Transformer-Schicht trainierbare Matrizen niedrigen Rangs ein. Gegenüber einem mit Adam feinabgestimmten GPT-3 175B berichtet die Arbeit 10.000-mal weniger trainierbare Parameter und einen um den Faktor drei geringeren GPU-Speicherbedarf: Der Trainingsspeicher sank von 1,2 TB auf 350 GB und der Checkpoint auf 35 MB. Außerdem berichtet sie 25 Prozent schnelleres Training und keine zusätzliche Inferenzlatenz. Für jeden Vergleich sind zwei Bedingungen dieser Zahlen wichtig. Die Parameterreduktion wurde bei Rang 4 und allein an den Query- und Value-Projektionen gemessen, während die PEFT-Dokumentation von Hugging Face festhält, dass die Anpassung aller linearen Schichten, wie sie QLoRA vornimmt, „eine Leistung wie bei einem vollständig feinabgestimmten Modell liefern kann“. Auch die Vergleichsbasis stammt von den Autoren selbst.

QLoRA, aus einer Arbeit vom Mai 2023, wendet LoRA auf ein auf vier Bit quantisiertes Basismodell an. Die Arbeit hat ein 65B-Modell auf einer einzigen GPU mit 48 GB abgestimmt und dabei die Aufgabenleistung des 16-Bit-Tunings erhalten; ein Tuning desselben Modells in 16 Bit brauchte mehr als 780 GB. Sie nutzt drei Mechanismen: einen Vier-Bit-Datentyp namens NormalFloat, einen zweiten Quantisierungsdurchgang, der die Quantisierungskonstanten von 0,5 auf 0,127 Bit je Parameter senkt, und ausgelagerte Optimierer. Die Angabe von 99,3 Prozent der Leistung von ChatGPT gilt allein für den Vicuna-Benchmark.

Entscheidungstabelle: welche Technik welches Problem löst

Die Tabelle ordnet jedem Problem die Technik zu, die es löst; die letzte Spalte gibt an, wie fest die veröffentlichten Ergebnisse das belegen.

Die Zeile zur Zugriffskontrolle ist unsere Schlussfolgerung, kein Befund der Arbeiten weiter unten: Der Abruf lässt sich je Nutzer filtern, Gewichte nicht, und deshalb setzt unser RAG-Leitfaden den Filter beim Abruf an.

OpenAI rät ausdrücklich davon ab, Fakten per Fine-Tuning zu vermitteln. Einer seiner Cookbook-Artikel schreibt „Wir empfehlen es im Allgemeinen nicht als Weg, dem Modell Wissen beizubringen“, und sein Leitfaden zur Genauigkeit rät, den Kontext zu optimieren, wenn Wissen im Training fehlt, veraltet oder proprietär ist. Anthropics Glossar definiert beide Techniken, ohne eine Rangfolge anzugeben, und eine Regel von NVIDIA dafür, parametereffizientes Tuning dem vollen Tuning vorzuziehen, haben wir nicht gefunden. Die Forschung weiter unten stützt dieselbe Regel mit Messungen. Die einzige veröffentlichte Schwelle, die wir gefunden haben, stammt von Anthropic und wurde im September 2024 für Claude geschrieben: Bei einem Korpus unter 200.000 Token, also etwa 500 Seiten, legen Sie den gesamten Korpus in den Prompt und bauen kein RAG. Auf einem privat betriebenen Llama 3.3 70B passt so viel Kontext nicht: Das Kontextfenster des Modells umfasst 128K Token (131.072), und ein volles Fenster belegt nach unserer Rechnung 20 GiB FP8-KV-Cache je gleichzeitiger Anfrage, bei 160 KiB je Token. Für größere Korpora oder wenn dieser Cache nicht in den Speicher Ihrer GPUs passt, beschreibt unser Leitfaden zu RAG auf Unternehmensdaten, wie Sie Retrieval aufbauen.

Entscheiden Sie sich für RAG, gehören Assistenten, die aus Ihren Dokumenten antworten, die Quelle nennen und die Zugriffsrechte jedes Nutzers beachten, zu unserem Service Private AI/ML. Beschreiben Sie uns die Dokumente und wer welche davon sehen darf; das erste Gespräch ist kostenlos.

Was Fine-Tuning an GPU-Speicher kostet

Den Trainingsspeicher bestimmen die Modellzustände, und die veröffentlichten Multiplikatoren unterscheiden sich: 16 oder 18 Byte je Parameter, was jede Zahl um ein Achtel verschiebt.

Die ZeRO-Arbeit schlüsselt Adam in gemischter Präzision auf: zwei Byte je Parameter für fp16-Gewichte, zwei für fp16-Gradienten, dazu eine fp32-Hauptkopie sowie Momentum und Varianz mit je vier Byte, zusammen sechzehn. Die Seite zur Speicheranatomie von Hugging Face führt dieselben Bestandteile auf und kommt auf 18, weil sie fp32-Gradienten statt fp16 annimmt. Die QLoRA-Arbeit nennt nur eine Untergrenze: Das Tuning eines 65B-Modells in 16 Bit „erfordert mehr als 780 GB“; das sind 65 Milliarden mal 12 Byte, also die Zählung ohne jene Hauptkopie. Wir rechnen deshalb mit einem Bereich von 16 bis 18 Byte je Parameter.

Unsere Rechnung aus den Multiplikatoren oben, keine Angaben von Herstellern oder aus Arbeiten, für Llama 3.1 8B, Qwen3-32B und Llama 3.3 70B mit den Parameterzahlen, die Hugging Face angibt. GB = 10⁹ Byte; nur Modellzustände, die Aktivierungen kommen obendrauf. LoRA und QLoRA mit Adaptern vom Rang 16 auf allen linearen Schichten, gerechnet mit 16 Byte je trainiertem Parameter, auf einer eingefrorenen bf16-Basis oder, bei QLoRA, auf einer Basis, deren lineare Schichten 0,516 Byte je Parameter belegen (NF4 mit doppelter Quantisierung; beides muss in Hugging Face Transformers ausdrücklich aktiviert werden), mit Embeddings und Ausgabeschicht in bf16. Unser Leitfaden zum GPU-Speicher für Fine-Tuning zeigt den Rechenweg.

Mit 32-Bit-Adam passt daher kein volles Fine-Tuning eines 8B-, 32B- oder 70B-Modells auf eine Karte mit 96 GB, schon vor den Aktivierungen, die mit Batch-Größe und Sequenzlänge wachsen. Ein LoRA-Tuning von 70B passt ebenfalls nicht, ein QLoRA-Tuning von 70B dagegen schon. Die Annahme, ein 7B-Modell lasse sich auf einer Karte vollständig abstimmen, verwechselt Inferenz- mit Trainingsspeicher: Für die Inferenz in FP16 braucht das Modell 14 GB, für volles Tuning rund 112 GB, ein Verhältnis von acht zu eins. Ein Acht-Bit-Optimierer verkleinert die Lücke. Hugging Face setzt 8-Bit-AdamW mit 2 Byte Optimiererzustand je Parameter statt 8 an, womit die Modellzustände des 8B-Modells nach der Zählweise der ZeRO-Arbeit auf rund 80 GB kommen und vor den Aktivierungen auf eine Karte mit 96 GB passen.

QLoRA spart Speicher auf Kosten der Geschwindigkeit, und NVIDIA veröffentlicht beide Zahlen auf einer Seite. Dort heißt es, QLoRA sei „bis zu“ 60 Prozent speichereffizienter als LoRA, eine Herstelleraussage über das eigene Produkt, und die Ersparnis schrumpfe mit wachsender Batch-Größe. Direkt darunter steht, dass das Training mit QLoRA 50 bis 200 Prozent langsamer ist als mit LoRA.

NVIDIAs Planungsmatrix für NeMo Customizer zeigt, wie viele GPUs der Dienst jedem Tuning-Job zuweist und bis zu welcher Sequenzlänge.

NVIDIAs Konfigurationsmatrix für NeMo Microservices, Version 25.12.0: Die Konfigurationen sind mit „+40GB“ gekennzeichnet, und die Seite nennt L40, A100 und H100, ohne sie den Zeilen zuzuordnen.

NVIDIA plant für einen 8B-LoRA-Job zwei GPUs ein, für den die Gewichtsrechnung rund 17 GB ergibt. Die Differenz sind Aktivierungen, Framework-Overhead und Voreinstellungen des Dienstes, und danach richtet sich die Beschaffung. Die Matrix nennt für kein 70B-Modell eine Konfiguration mit allen Gewichten. Beim Serving ist es umgekehrt: vLLM bedient viele LoRA-Adapter mit einer einzigen Kopie der Basisgewichte, und jeder Adapter ist klein, 35 MB im GPT-3-Beispiel der LoRA-Arbeit und nach unserer Rechnung rund 84 MB für einen Adapter vom Rang 16 auf allen linearen Schichten von Llama 3.1 8B in 16 Bit. Ein zusätzlicher Mandant belegt daher wenig zusätzlichen Speicher.

Was der Betrieb von RAG kostet: Embedding, Reranking und KV-Cache

RAG braucht keinen Trainingslauf; seine Kosten entstehen im Betrieb, im Embedding-Dienst, im Reranker, im Vektorspeicher und im KV-Cache.

Das Embedding-Modell ist ein eigener GPU-Dienst. NVIDIAs NIM-Matrix für Retrieval verlangt für Llama Nemotron Embed 1B v2 im nicht optimierten FP16-Profil mindestens 3,6 GiB GPU-Speicher, und die Werte auf dieser Seite unterscheiden sich um den Faktor sechzehn, von 2 GiB bis 33 GiB für bge-m3. NVIDIAs RAG-Blueprint betreibt neben dem Sprachmodell weitere Dienste: Microservices für Embedding und Reranking, die Dokumentenextraktion und einen Vektorspeicher, seit Release 2.6.0 standardmäßig Elasticsearch, mit Milvus als Option. Seine Standardbereitstellung verlangt drei GPUs, zwei davon für das Sprachmodell, sein Kubernetes-Chart acht, und jeder optionale GPU-Dienst, etwa für Bildbeschreibungen oder Audio, braucht eine weitere.

Die Voreinstellungen für das Chunking unterscheiden sich sogar innerhalb einer Bibliothek: Die Bibliothekskonstante von LlamaIndex steht auf 1.024 Token mit 20 Token Überlappung, während der eigene Satz-Splitter 200 verwendet, und der Basis-Splitter von LangChain steht auf 4.000 Zeichen mit 200, während das eigene Tutorial 1.000 und 200 nimmt. NVIDIAs RAG-Einführung enthält einen oft wiederholten Fehler: Sie schreibt, die Embedding-Modelle von OpenAI kodierten bis zu 1.536 Token und schnitten darüber hinaus stillschweigend ab. Für die API von OpenAI trifft beides nicht zu: Sie weist längere Eingaben mit einem Fehler ab, statt sie abzuschneiden. OpenAI dokumentiert 8.192 Token Eingabe, und 1.536 ist die Dimension des Ausgabevektors seines kleinen Modells.

Reranking verbessert den Abruf messbar. Anthropic hat auf seinen Testdatensätzen aus Code, Belletristik und Forschungsarbeiten eine Fehlerrate von 5,7 Prozent in den ersten 20 Treffern gemessen. Sie fiel mit kontextuellen Embeddings auf 3,7 Prozent, mit zusätzlichem kontextuellem BM25 auf 2,9 und auf 1,9, wenn die besten 150 Ergebnisse per Reranking auf 20 reduziert wurden. Das sind die relativen Senkungen um 35, 49 und 67 Prozent, die meist ohne die Basis von 5,7 Prozent zitiert werden. Für den Vektorspeicher rechnet die Dokumentation von Milvus mit 4 Byte je Dimension bei 32-Bit-Vektoren, eine Million Vektoren mit 128 Dimensionen belegen also vor dem Index-Overhead 512 MB; der Rohspeicher lässt sich so abschätzen, der Index wird gemessen.

Über die Servingkosten entscheidet der KV-Cache. NVIDIAs Formel für den KV-Cache lautet: zwei, mal Zahl der Schichten, mal versteckte Dimension, mal Byte je Element, und das je Token. Für Llama 2 7B in 16 Bit sind das 2 × 32 Schichten × 4.096 × 2 Byte, also 512 KiB je Token. Abgerufene Passagen sind Token wie alle anderen, 4.000 Token Kontext je Anfrage kosten also rund 2 GiB KV-Cache je gleichzeitiger Anfrage und rund 62 GiB bei 32 gleichzeitigen Anfragen: zwei Drittel einer Karte mit 96 GB, belegt mit abgerufenem Text, bevor ein einziges Token erzeugt ist. Diese Multiplikation ist unsere, und sie nimmt Multi-Head-Attention an wie bei Llama 2 7B. Aktuelle Modelle dieser Größe nutzen Grouped-Query-Attention mit weit weniger Key-Value-Köpfen und entsprechend geringeren Kosten je Token. Llama 3.1 8B hat laut Metas Llama-3-Arbeit 8 Key-Value-Köpfe gegenüber 32 Query-Köpfen. Nach unserer Rechnung kosten dieselben 4.000 Token in 16 Bit dann rund 0,5 GiB, 128 KiB je Token, und rund 15,6 GiB bei 32 gleichzeitigen Anfragen. Rechnen Sie die Formel mit der Konfiguration Ihres eigenen Modells. Unser Beitrag dazu, wie viele Nutzer eine RTX PRO 6000 bedient, rechnet das von Anfang bis Ende durch.

Wir bauen GPU-Server für private LLMs und RAG, ausgelegt nach Modellgröße und Zahl gleichzeitiger Nutzer. Nennen Sie uns das Modell und den abgerufenen Kontext je Anfrage, und Sie erhalten innerhalb eines Werktages Konfiguration und Angebot.

Was veröffentlichte Studien ergaben: Retrieval gegen Fine-Tuning

Eine Studie auf der EMNLP 2024, „Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs“, hat Mistral 7B, Llama2 7B und Orca2 7B auf MMLU-Teilmengen und an einer Aufgabe zu aktuellen Ereignissen geprüft, also an Wissen, das die Modelle nicht gesehen haben konnten. Mit Mistral 7B erreichte bei aktuellen Ereignissen das Basismodell 0,481, das Basismodell mit Retrieval 0,875, das feinabgestimmte Modell 0,504 und das feinabgestimmte Modell mit Paraphrasen 0,588. Die Studie kommt zu dem Schluss, dass „LLMs sich schwertun, neue faktische Informationen durch unüberwachtes Fine-Tuning zu lernen“.

Der Fine-Tuning-Arm der Studie war unüberwachtes fortgesetztes Vortraining auf Rohtext, kein überwachtes Tuning auf Frage-Antwort-Paaren, und genau Letzteres machen die meisten Unternehmen; die Arbeit sagt das in ihrer Zusammenfassung. Das Ergebnis auf überwachtes Tuning zu übertragen ist ein verbreiteter Lesefehler. Die Studie zeigt etwas Engeres: Ein Lauf mit fortgesetztem Vortraining auf einem Dokumentenkorpus bringt diese Fakten nicht zuverlässig in die Gewichte.

Das Gegenergebnis ist eine Fallstudie zur Landwirtschaft vom Januar 2024, die überwachtes Tuning einsetzte und beide Verfahren als additiv fand: über 6 Prozentpunkte durch Fine-Tuning und weitere 5 durch Retrieval obendrauf, wobei Retrieval bei kontextuell passenden Daten wirkt und Tuning beim Vermitteln von Fachkönnen. Die beiden Ergebnisse stimmen nicht überein. Die Tabellen der EMNLP-Studie zeigen das Basismodell mit Retrieval vor dem feinabgestimmten Modell mit Retrieval, 0,681 gegen 0,659 bei Anatomie ohne Beispiele mit Mistral 7B; die Tabellen der Landwirtschaftsstudie zeigen, dass sich die Gewinne addieren. Die Studien verwendeten unterschiedliche Aufgaben, Domänen und Tuning-Verfahren.

Zwei weitere Studien sind relevant. Eine Studie auf der SIGIR-AP 2024 hat zwölf Modelle von 80M bis 11B Parametern getestet und Retrieval bei Fakten geringer Popularität mit deutlichem Abstand vorn gefunden; ein kleines feinabgestimmtes Modell mit Retrieval zog mit einem viel größeren gleich, 1,6B gegen 8B: die Logik hinter dem Betrieb eines eigenen Modells statt einer Cloud-API. Und eine TMLR-Arbeit vom August 2024, „LoRA Learns Less and Forgets Less“, hat LoRA mit vollem Fine-Tuning bei Programmierung und Mathematik verglichen: Bei den üblichen niedrigen Rängen bleibt LoRA deutlich dahinter, und als Mechanismus wird vorgeschlagen, dass volles Tuning Gewichtsänderungen vom 10- bis 100-Fachen des Rangs lernt. Die LoRA-Arbeit selbst beansprucht Gleichstand oder mehr. Die beiden begutachteten Arbeiten widersprechen sich; testen Sie also einen höheren Rang, bevor Sie LoRA verwerfen.

Fehlerbilder und Wartung von Fine-Tuning und RAG

Der charakteristische Fehler des Fine-Tunings ist katastrophales Vergessen, und der für die Planung wichtigste Befund betrifft die Modellgröße. Eine Studie von 2023 zum katastrophalen Vergessen beim kontinuierlichen Fine-Tuning hat es an Fachwissen, Schlussfolgern und Leseverstehen in Modellen von 1B bis 7B gemessen und fand es allgemein und, innerhalb dieses Bereichs, mit wachsender Modellgröße stärker. Bis 7B war ein größeres Basismodell keine Abhilfe; Instruction Tuning vor dem Fachtuning half dagegen. LoRA ist eine Teilantwort mit einem dokumentierten Zielkonflikt: Dieselbe TMLR-Arbeit, die LoRA in der Zieldomäne schwächer fand, sah es Fähigkeiten außerhalb dieser Domäne besser bewahren als Weight Decay oder Dropout.

Die Fehler von RAG sind benannt und gezählt. Ein Erfahrungsbericht auf der CAIN 2024 aus drei Fallstudien zählt sieben auf: fehlender Inhalt im Korpus, das richtige Dokument zu niedrig einsortiert, das richtige Dokument bei der Zusammenführung verloren, die Antwort im Kontext, aber nicht extrahiert, eine Ausgabe, die das verlangte Format ignoriert, die falsche Genauigkeitsstufe und eine richtige, aber unvollständige Antwort. Der fünfte Fehler, das falsche Format, ist ein Fine-Tuning-Problem innerhalb einer RAG-Fehlertaxonomie. Der Bericht kommt zu dem Schluss, dass sich ein RAG-System nur im Betrieb validieren lässt, und die laufende Arbeit besteht darin, seine Parameter abzustimmen: Chunk-Größe, Embedding, Chunking, Abruf- und Zusammenführungsstrategie, Kontextgröße und Prompts.

Ein längeres Kontextfenster gleicht einen schwachen Abruf nicht aus. Die TACL-Arbeit „Lost in the Middle“ fand die Leistung am höchsten, wenn die einschlägige Passage am Anfang oder am Ende des Kontexts steht, und in der Mitte abfallend, selbst bei Modellen mit langem Kontext: Fünfzig Chunks in den Kontext zu legen, statt das Ranking zu verbessern, kann die Ergebnisse verschlechtern. Beide Wege brauchen eine Evaluierung. OpenAI rät, die Evaluierungen vor dem Tuning aufzubauen; für den Abruf bewertet Ragas auf der EACL 2024 Relevanz, Treue zur Quelle und Generierungsqualität ohne Referenzantworten.

RAG und Fine-Tuning kombinieren, und wie viele Trainingsdaten nötig sind

NVIDIA empfiehlt eine Reihenfolge statt einer Wahl: mit RAG beginnen und dann anpassen, wenn mehr fachspezifische Genauigkeit nötig ist. NVIDIAs RAG-Einführung hält fest, dass die beiden keine Alternativen sind, und beschreibt eine oft übersehene Kombination: parametereffizientes Tuning innerhalb eines RAG-Systems, das das Sprachmodell oder das Embedding-Modell verfeinert. Den Retriever statt des Generators abzustimmen wird seltener besprochen.

Zusammengenommen stützen die Quellen diese Reihenfolge: zuerst die Evaluierungen; dann Prompt- und Kontext-Engineering; den Korpus messen und nur dann auf Retrieval verzichten, wenn er in das Kontextfenster des Modells und in Ihr KV-Cache-Budget je Anfrage passt; bei größeren Korpora Retrieval aufbauen; erst dann zu LoRA greifen, um Format, Ton, Aufgabentreue und Fachkönnen zu richten; das Embedding-Modell zuletzt abstimmen. OpenAI ergänzt eine Anweisung: Nehmen Sie den Prompt, der vor dem Tuning am besten funktioniert hat, in jedes Trainingsbeispiel mit.

Um Verhalten zu vermitteln, braucht es relativ wenige Daten. OpenAI nennt ein hartes Minimum von 10 Beispielen, berichtet Verbesserungen bei 50 bis 100 Beispielen und empfiehlt, mit 50 sorgfältig gebauten Demonstrationen zu beginnen; die Qualitätslatte lautet, dass eine kleinere Menge guter Daten eine größere Menge schlechter Daten schlägt und dass die Beispiele in sich geschlossen, konsistent und in dem Format sein müssen, das zur Inferenzzeit erwartet wird. LIMA hat ein 65B-Modell auf 1.000 kuratierten Prompts feinabgestimmt und wurde in 43 Prozent der Vergleiche gegenüber GPT-4 bevorzugt oder als gleichwertig bewertet; seine Autoren folgern, die Ergebnisse „legen nachdrücklich nahe“, dass nahezu das gesamte Wissen im Vortraining gelernt wird und für gute Ausgaben nur begrenzte Instruktionsdaten nötig sind. Die QLoRA-Autoren stimmen zu, dass Qualität die Datenmenge schlägt. Die Zahlen von OpenAI stammen von seiner Self-Service-Plattform für Fine-Tuning, die OpenAI auslaufen lässt. Laut der Deprecations-Seite von OpenAI können Organisationen, die dort zuvor kein Fine-Tuning betrieben haben, seit dem 7. Mai 2026 keine Fine-Tuning-Jobs mehr anlegen, und bestehende Kunden ab dem 6. Januar 2027 keine neuen mehr.

Fakten brauchen weit mehr Daten als Verhalten. Die EMNLP-2024-Studie fand die Genauigkeit monoton mit der Zahl der verwendeten Paraphrasen steigen: Jeder Fakt muss vielfach umformuliert werden, und das Ergebnis bleibt trotzdem hinter Retrieval zurück. Zur Einordnung umfassten die beiden Datenregime der TMLR-Arbeit rund 100.000 Prompt-Antwort-Paare für Instruction Tuning und rund 20 Milliarden unstrukturierte Token für fortgesetztes Vortraining; das sind die getesteten Größen, keine Mindestwerte. Für zwei Angaben haben wir keine veröffentlichte Zahl gefunden, und wir schätzen sie nicht. In NVIDIAs NeMo-Dokumentation haben wir keine Mindestzahl an Beispielen gefunden, und Anthropics Ankündigung vom Juli 2024 zum Fine-Tuning von Claude 3 Haiku in Amazon Bedrock verlangte nur hochwertige Prompt-Completion-Paare, ohne eine Menge zu nennen (die eigene API von Anthropic bietet Stand Oktober 2026 kein Fine-Tuning an); die Genauigkeitsangabe dieser Ankündigung, von 81,5 auf 99,6 Prozent bei der Moderation von Online-Kommentaren, stammt aus Anthropics eigenem Test an einer einzigen Aufgabe und sagt nichts darüber, wie viele Beispiele eine Aufgabe braucht.

Was wir tun

Wir liefern die GPUs und Server für beide Wege EU-weit und dimensionieren sie nach Ihrem Korpus, Ihrem Modell und Ihrer Spitzenzahl gleichzeitiger Anfragen statt nach dem Namen einer Technik. Unser Engineering-Partner Vixen.UNO baut und betreut die Plattform darauf im Rahmen unseres Services Private AI/ML, von RAG-Assistenten, die die Zugriffsrechte jedes Nutzers beachten, bis zu MLOps auf Kubernetes, unter einem Vertrag mit Eurokommerz.

FAQ