Temperature: LLM-Ausgaben steuern und Modellgröße verstehen

Temperature: LLM-Ausgaben lassen sich damit beeinflussen, sofern die API diese Einstellung unterstützt. Ein großes Sprachmodell (Large Language Model, LLM) mit der Größenangabe 70B hat rund 70 Milliarden erlernte Parameter. Ein Temperaturwert von 0.2 verändert dagegen, wie eine unterstützte API die Antwort durch Sampling erzeugt, und nicht die Anzahl der Modellgewichte. Hinter LLM-Parametern stehen also zwei Entscheidungen: welches Modell zum Einsatz kommt und wie seine Ausgabe angefordert wird. Zuerst wird das passende Modell für die Aufgabe gewählt; anschließend werden nur die Einstellungen gesetzt, die dessen konkrete API und Version unterstützen.

Am 25. Oktober 2026 anhand der aktuellen Dokumentation der Anbieter geprüft. Die Unterscheidung ist heute wichtiger als früher: Manche aktuellen APIs weisen Sampling-Einstellungen zurück, andere nehmen sie an und ignorieren sie. Eine kopierte Konfiguration kann deshalb einen Fehler auslösen oder schlicht wirkungslos bleiben.

LLM-Parameter erfüllen zwei unterschiedliche Aufgaben

Modellparameter gehören zum trainierten Modell. Generierungsparameter gehören zur Anfrage, die an das Modell gesendet wird. Wer die Anfrageeinstellungen ändert, trainiert damit nicht die Modellparameter neu.

Ein Gebäude veranschaulicht den Unterschied. Seine tragende Konstruktion legt fest, welche Lasten es aufnehmen kann; verstellbare Lamellen beeinflussen, wie sich der Raum nutzen lässt. Eine gedrehte Lamelle fügt kein weiteres Stockwerk hinzu. Genauso wenig wird ein kleines Modell durch eine andere Temperatureinstellung zu einem größeren.

Was versteht man unter LLM-Parametern?

Geht es um die Modellgröße, sind Parameter erlernte Zahlenwerte, vor allem Gewichte, die die Berechnungen des Modells bestimmen. Beim Training werden diese Werte mithilfe von Daten angepasst. Im API-Kontext bezeichnet „Parameter“ auch Einstellungen, die die Erzeugung der Ausgabe beeinflussen. Die Erklärung von IBM unterscheidet zwischen erlernten Werten und externer Konfiguration.

Wenn ein Anbieter sagt, sein Modell habe mehr Parameter, meint er das Modell selbst. Wenn ein Entwickler für die Rechnungsextraktion „die Parameter ändern“ will, sind vermutlich die Anfrageeinstellungen gemeint. Bevor daraus eine Aussage über die Leistungsfähigkeit abgeleitet wird, muss klar sein, welche Bedeutung gemeint ist.

Was ist ein einzelner Parameter in einem LLM?

Ein erlernter Parameter ist eine Zahl, die innerhalb des Netzes verwendet wird. Ein Gewicht bestimmt beispielsweise, wie stark ein internes Signal zu einem anderen beiträgt. Es handelt sich weder um einen sauber beschrifteten Fakt noch um ein Dokument oder ein Wort in einer eigenen Schublade.

Daneben gibt es Trainingshyperparameter: Einstellungen wie die Lernrate, die den Ablauf des Trainings steuern. Eine Geschäftsanwendung, die ein bestehendes Modell aufruft, hat normalerweise weder Zugriff auf diese Trainingseinstellungen noch auf die erlernten Gewichte.

Tokens sind wiederum etwas anderes. In diese Einheiten werden Ein- und Ausgaben zerlegt; häufig sind es Wortteile. Mehr Tokens in einem Prompt bedeuten nicht mehr Modellparameter. Der Leitfaden zu Tokens in der KI erklärt diese Einheit. Der Leitfaden zum System-Prompt zeigt, wie Anweisungen das Verhalten steuern, ohne die trainierten Gewichte zu verändern.

Teil eins: Was Modellparameter über die Größe aussagen

Die Parameterzahl hilft, Speicherbedarf und Rechenaufwand abzuschätzen. Welches Modell eine konkrete Geschäftsaufgabe am besten löst, lässt sich daraus nicht ableiten. Für die Infrastrukturplanung ist sie ein Ausgangspunkt. Entscheidend bleibt die Prüfung an der jeweiligen Aufgabe.

Was bedeuten Milliarden Parameter bei einem LLM?

Das „B“ steht für das englische „billion“, also eine Milliarde erlernter Werte. Ein als 70B bezeichnetes Modell hat ungefähr 70 Milliarden Parameter; „T“ steht für „trillion“, also eine Billion. Modellnamen können gerundete Angaben enthalten. Für eine genaue Abschätzung des Ressourcenbedarfs sind daher der tatsächliche Checkpoint und sein Speicherformat maßgeblich.

Zwei Modelle mit gleicher Parameterzahl können sich in Architektur, Trainingsdaten, Trainingsverfahren und Spezialisierung unterscheiden. Selbst dasselbe Modell kann unterschiedlich viel Speicher belegen, je nachdem, mit welcher Genauigkeit die einzelnen Gewichte gespeichert werden.

Bei der Beschaffung zählt, ob das Modell die Abnahmekriterien erfüllt: Extrahiert es den richtigen Rechnungsbetrag, erhält es die Kundenkennung unverändert oder erzeugt es einen Patch, der die erforderlichen Prüfungen besteht? Eine größere Parameterzahl beantwortet keine dieser Fragen.

Speicherbedarf der Gewichte eines 70B-Modells: eine Beispielrechnung

Der reine Gewichtsspeicher ergibt sich aus der Parameterzahl mal Bytes pro Parameter. Für ein hypothetisches Modell mit genau 70 Milliarden Gewichten ergibt sich die folgende Rechnung. Sie ist kein gemessenes Ergebnis eines laufenden Systems.

Gemeint sind dezimale Gigabytes. Die 140 GB entsprechen etwa 130.4 GiB, der binären Einheit, die manche Speicherwerkzeuge anzeigen. Die Umrechnung ändert die Einheit, nicht das Modell.

Hugging Face dokumentiert, wie Quantisierung den Speicherbedarf reduziert, indem Gewichte mit geringerer Genauigkeit gespeichert werden und die Genauigkeit der Ergebnisse möglichst erhalten bleibt. Unser Leitfaden zur LLM-Quantisierung erläutert die Formate und ihre Vor- und Nachteile.

Auch längere Prompts und gleichzeitige Anfragen verändern die Last im Betrieb. Die Dokumentation zum Modellspeicherschätzer von Hugging Face unterscheidet ausdrücklich zwischen dem Laden eines Modells und der Inferenz, also dem Erzeugen von Antworten.

Was die Parameterzahl über Kosten und Qualität verrät

Unter sonst gleichen Bedingungen brauchen mehr Gewichte in der Regel mehr Ressourcen für Speicherung und Betrieb. „Unter sonst gleichen Bedingungen“ ist allerdings eine erhebliche Einschränkung. Genauigkeit, Architektur, Hardware, die Bündelung von Anfragen und die verarbeitete Textmenge beeinflussen das Ergebnis.

Beim Self-Hosting hilft die Parameterzahl, geeignete Hardware einzugrenzen. Bei einer gehosteten API lässt sich daraus keine Rechnung ableiten: Hier bestimmen die Abrechnungsregeln des Anbieters und die Arbeitslast die Kosten. Ein Modell, das häufige Wiederholungsversuche oder umfangreiche manuelle Korrekturen erfordert, kann trotz scheinbarer Effizienz für den Betrieb ungeeignet sein.

Für die Qualität ist die Größe ein Hinweis auf die Kapazität, keine Bewertung. Beschaffungsunterlagen sollten Ergebnisse für repräsentative Eingaben, typische Fehlerfälle und die Bedingungen der Auswertung verlangen. Eine unveröffentlichte Schätzung der Parameterzahl eines geschlossenen Modells ist kein belastbarer Nachweis.

MoE-Modelle: Gesamtparameter und aktive Parameter unterscheiden

Die Gesamtparameterzahl beschreibt das vollständige Modell; die Zahl aktiver Parameter beschreibt den angegebenen Berechnungspfad für ein Token. Bei einem Mixture-of-Experts-Modell, kurz MoE, sind beide Angaben relevant.

Ein MoE enthält Experten-Teilnetze und einen Router, der auswählt, welche davon das jeweilige Token verarbeiten. Diese „Experten“ sind mathematische Komponenten, keine benannten Fachkräfte, denen sich Buchhaltung oder Rechtsfragen zuweisen lassen. Eine kleinere aktive Teilmenge kann gegenüber der Aktivierung des gesamten Modells Rechenaufwand sparen. Die übrigen Gewichte müssen trotzdem irgendwo vorhanden sein. Die MoE-Erklärung von PyTorch behandelt das Routing und die damit verbundene Kommunikation.

Für „104B aktiv“ gibt es ein konkretes, vom Hersteller veröffentlichtes Beispiel: Moonshot AI nennt in der Ankündigung von Kimi K3.1 Pro insgesamt 2.8T und 104B aktive Parameter. In der Einheit B sind das insgesamt 2,800B. Die Rechnung 104 ÷ 2,800 ergibt einen aktiven Anteil von etwa 3.7%. Diesen Prozentsatz haben wir aus den angekündigten Parameterzahlen berechnet. Er ist weder eine Messung des Geschwindigkeitsgewinns noch eine Qualitätsrangfolge.

Ein zweites Beispiel ist die Modellkarte zu Qwen3-235B-A22B von Qwen. Sie nennt insgesamt 235B und 22B aktivierte Parameter. Die Abbildung zeigt auch die inaktiven Räume: Der Speicherbedarf verschwindet nicht, nur weil ein bestimmtes Token einen anderen Weg nimmt.

Für den Betrieb muss geklärt werden, wie das gesamte Modell gespeichert und verteilt wird, wie die Experten auf der Hardware liegen und welche Leistung bei der tatsächlich benötigten Zahl gleichzeitiger Anfragen erreicht wird. Die aktive Parameterzahl ist keine Angabe zum erforderlichen Speicher des Grafikprozessors (GPU). Der Mixture-of-Experts-Leitfaden vertieft diese Infrastrukturfrage.

Teil zwei: Temperature, LLM-Ausgaben und weitere Generierungsparameter

Generierungseinstellungen beeinflussen innerhalb der Fähigkeiten eines Modells, wie die Ausgabe ausgewählt und wann sie beendet wird. Die API ist die Schnittstelle, über die eine Anwendung eine Antwort anfordert. Ihre Einstellungen können weder fehlendes Quellenmaterial ersetzen noch unklare Anweisungen reparieren oder eine richtige Antwort garantieren.

Temperature: Wie stark konzentriert sich die Auswahl?

Temperature verändert die Wahrscheinlichkeitsverteilung, anhand derer das nächste Token ausgewählt wird. Niedrige Werte begünstigen die wahrscheinlichsten Optionen stärker; höhere Werte lassen mehr Variation zu. So lässt sich zwischen einheitlicher Formulierung und einer größeren Bandbreite an Entwürfen abwägen.

Bei der Rechnungsverarbeitung ist Variation selten das Ziel. Für alternative Kampagnenüberschriften kann sie hilfreich sein. Eine niedrige Temperatur macht jedoch eine erfundene Rechnungsnummer nicht wahr, und eine hohe Temperatur fügt kein Wissen hinzu.

Auch eine Anfrage mit Temperatur null garantiert nicht grundsätzlich reproduzierbare Ergebnisse. Das Glossar von Anthropic weist ausdrücklich darauf hin, dass identische Eingaben selbst bei Temperatur null unterschiedliche Ergebnisse liefern können. Reproduzierbarkeit muss über das gesamte System hinweg geprüft werden, das die Antworten bereitstellt.

Top-p: Welche Kandidaten bleiben in der Auswahl?

Top-p, auch Nucleus Sampling genannt, begrenzt die Kandidatenmenge anhand ihrer kumulierten Wahrscheinlichkeit. Es handelt sich um einen Wahrscheinlichkeitsschwellenwert, nicht um die Anzahl der Kandidaten oder einen Prozentsatz des Wortschatzes.

Angenommen, die Wahrscheinlichkeiten für das nächste Token betragen 0.60, 0.25, 0.10 und 0.05. Bei einem Top-p-Schwellenwert von 0.9 werden die ersten drei Kandidaten benötigt: Die ersten beiden ergeben zusammen 0.85, die ersten drei erreichen 0.95. Diese Zahlen dienen der Veranschaulichung; sie sind keine beobachtete Modellausgabe.

Temperature verändert die Wahrscheinlichkeiten; Top-p schränkt die zulässige Auswahl ein. Für eine erste Konfiguration im Unternehmenseinsatz sollte jeweils nur eine Sampling-Einstellung geändert werden. Das entspricht auch der Empfehlung von OpenAI in der Referenz zu Chat Completions.

Token-Limit beim LLM: Obergrenze statt gewünschter Länge

Das Token-Limit für die Generierung begrenzt die Antwort nach oben. Es fordert das Modell nicht auf, genau diese Anzahl an Tokens zu verwenden. Ebenso wenig vergrößert es das Kontextfenster, also den Umfang des Gesprächs, den das Modell verarbeiten kann.

Ein zu niedriges Limit kann ein JSON-Objekt, einen Satz oder einen Code-Patch mitten in der Ausgabe abschneiden. Eine großzügige Obergrenze macht die Antwort nicht automatisch nützlich. Die gewünschte Länge gehört als Anweisung in den Prompt; bis zur Obergrenze sollte genügend Spielraum für ein vollständiges Ergebnis bleiben.

Bei Reasoning ist eine weitere Unterscheidung nötig. Laut Responses-Referenz von OpenAI umfasst die Ausgabeobergrenze sowohl sichtbare Ausgabe als auch Reasoning-Tokens. Die Messages-Referenz von Anthropic rechnet Thinking-Tokens ebenfalls auf max_tokens an. Das Budget einer Reasoning-Anfrage darf daher nicht so kalkuliert werden, als würde jedes zulässige Token in der endgültigen Antwort erscheinen.

Stoppsequenzen: An einer festgelegten Grenze enden

Eine Stoppsequenz beendet die Generierung, sobald eine bestimmte Zeichenfolge auftritt. Sie ist nur sinnvoll, wenn die Anwendung eine verlässliche Grenze hat, etwa eine ausdrückliche Endmarkierung, die im eigentlichen Inhalt nicht vorkommen darf.

Ein Zeilenumbruch eignet sich nicht als allgemeine Stoppsequenz für einen mehrzeiligen Bericht. Eine schließende geschweifte Klammer eignet sich ebenso wenig für verschachteltes JSON: Schon die erste passende Klammer kann die Antwort vorzeitig beenden. Für strukturierte Extraktion ist der vom Anbieter unterstützte Schemamechanismus vorzuziehen; die zurückgegebenen Felder müssen anschließend validiert werden.

Benutzerdefinierte Stoppsequenzen zunächst wegzulassen, ist meist der sinnvolle Ausgangspunkt. Eine Obergrenze für Ausgabetokens und die Validierung bleiben dennoch notwendig.

Penalties: Wiederholungen mit Bedacht begrenzen

Eine Presence Penalty berücksichtigt, ob ein Token bereits vorkam. Eine Frequency Penalty berücksichtigt, wie oft es vorkam. Positive Werte erschweren die erneute Verwendung; negative Werte können sie fördern, sofern der Endpunkt solche Werte unterstützt.

Wiederholungen sind nicht immer ein Fehler. Produktcodes, Kundennamen, JSON-Schlüssel oder Bezeichner im Programmcode müssen unter Umständen exakt wiederholt werden. Eine Sanktionierung kann dem Zweck der Aufgabe entgegenwirken.

Für Extraktion und Code sollte die Ausgangskonfiguration keine Wiederholungsstrafen enthalten. Bei Textentwürfen ist zuerst eine Anweisung zu korrigieren, die repetitive Strukturen begünstigt. Erst danach kommt ein kleiner, unterstützter Strafwert infrage. Dabei ist zu prüfen, ob er den Entwurf verbessert, ohne vorgeschriebene Begriffe zu verändern. Auch die Generierungsreferenz von Google warnt davor, dass negative Frequency Penalties zu Schleifen wiederholter Tokens führen können.

API-Wertebereiche und Standardwerte bei OpenAI, Anthropic und Google

Welche Einstellungen zulässig sind, bestimmen Endpunkt, Modell und API-Version. Ein identischer Feldname in einem SDK belegt nicht, dass alle Anbieter dieselbe Funktion implementieren.

Die Tabelle bezieht sich bei OpenAI auf Chat Completions, bei Anthropic auf die Messages API in Version 2026-10-21 und bei Google auf generateContent der Gemini Developer API. Einstellungen aus Googles Vertex AI oder Interactions API werden nicht übertragen.

NS bedeutet, dass die aktuell zitierte Felddokumentation keinen numerischen Wertebereich beziehungsweise Standardwert angibt. Es bedeutet weder null noch unbegrenzt oder nicht unterstützt. „Weglassen“ ist im Folgenden eine Empfehlung für die Anwendung, kein erfundener Standardwert des Anbieters.

Quellen: OpenAI-Anfrageschema, Anthropic-Anfrageschema, Anthropic-Versionsmigration, Google-Generierungsschema, Google-Modellmetadaten und Googles Top-p-Wertebereich.

Googles allgemeine Tabelle zur Fehlerbehebung nennt für Temperature einen engeren Wertebereich als die Referenz des Generierungsfelds. Maßgeblich sind die Feldreferenz zusammen mit maxTemperature des gewählten Modells. Für modellspezifische Werte dienen Model.temperature, Model.topP und Model.outputTokenLimit. Eine Beispielanfrage ist kein dokumentierter Standardwert.

OpenAI: Zuerst die Reasoning-Kompatibilität prüfen

Der aktuelle GPT-6-Leitfaden von OpenAI verlangt, temperature und top_p wegzulassen, wenn der Reasoning-Aufwand nicht auf none steht. GPT-6 Astra und GPT-6.1 Sol unterstützen none nicht; GPT-6 Sol und GPT-6 Luna tun dies. Das ist eine Einschränkung der Unterstützung, keine dokumentierte Festlegung auf einen bestimmten Temperaturwert.

Auch der Endpunkt ist entscheidend. Responses verwendet max_output_tokens mit einem Mindestwert von 16 im aktuellen Schema. Ein numerischer Standardwert und eine allgemeingültige Obergrenze werden dort nicht genannt. Das Create-Schema bietet die Chat-Completions-Felder stop, presence_penalty und frequency_penalty nicht an. Für Chat Completions kennzeichnet die Referenz stop ausdrücklich als nicht unterstützt bei o3 und o4-mini; max_tokens gilt dort zugunsten von max_completion_tokens als veraltet.

In der Praxis wird die Anfrage also zuerst für den gewählten Endpunkt aufgebaut und anschließend an die Kompatibilitätsregeln des Modells angepasst. Die gesamte Tabelle gehört nicht ungeprüft in eine einzige Anfrage.

Anthropic: Eine API-Version kann Einstellungen abschaffen

Laut Migrationsleitfaden von Anthropic vom 21. Oktober führt das Senden von temperature, top_p oder top_k mit der API-Version 2026-10-21 zu einem 400-Fehler, selbst wenn ein Standardwert übergeben wird. Ohne diese Felder gilt unter anderem eine Temperatur von 1.0.

Ältere API-Versionen bringen die Einstellmöglichkeiten nicht automatisch für jedes Modell zurück. Nach der Thinking-Dokumentation von Anthropic weisen unter anderem Modelle wie Claude Sonnet 5.5 Sampling-Werte zurück, die vom Standard abweichen. Das gilt unabhängig davon, ob Thinking aktiviert ist. Für diese Modelle nennt die Dokumentation einen Top-p-Standardwert von 0.99 und weist ausdrücklich darauf hin, dass 1 zurückgewiesen wird. Ein älterer allgemeiner Wertebereich hebt diese Modellregel nicht auf.

Für die eigentliche Generierung ist ein positives max_tokens-Budget innerhalb der Modellgrenze nötig. Das dokumentierte Minimum null dient dazu, den Cache vorab zu füllen, ohne eine Antwort zu erzeugen. Als Ausgangseinstellung für die Extraktion ist es nicht sinnvoll.

Google: Akzeptierte Einstellungen können wirkungslos bleiben

Der Migrationsleitfaden von Google für Gemini 3.6 Flash und 3.5 Flash-Lite erklärt, dass diese Modelle die veralteten Einstellungen für Temperature, Top-p und Top-k ignorieren. Entwickler sollen die Felder entfernen. Künftige Modellgenerationen werden sie laut Leitfaden mit einem 400-Fehler zurückweisen.

Das führt zu einem anderen Fehlerbild als eine zurückgewiesene Anfrage: Die Anwendung scheint eine Temperaturänderung anzunehmen, während sich das Modell unverändert verhält. Bevor eine erfolgreiche Antwort als Beleg für eine wirksame Einstellung gilt, muss die Dokumentation des ausgewählten Modells geprüft werden.

Sinnvolle Ausgangseinstellungen für Geschäftsaufgaben

Am Anfang stehen das vom Anbieter unterstützte Verhalten und eine messbare Definition von Erfolg. Die folgenden Zahlen sind unsere Vorschläge für erste Versuche mit einstellbaren Endpunkten. Sie sind weder Anbieterstandardwerte noch gemessene Optima oder übertragbare Voreinstellungen. Die zuvor beschriebenen Kompatibilitätsregeln haben Vorrang.

Extraktion: Exakte Werte bewahren

Für Rechnungsfelder, die Klassifikation von Supporttickets oder Vertragsmetadaten bietet sich ein Versuch mit Temperatur 0 oder 0.2 an, sofern unterstützt. Top-p bleibt unverändert. Benutzerdefinierte Stoppsequenzen und Wiederholungsstrafen werden weggelassen. Bei einem unterstützenden Modell in OpenAI Chat Completions lassen sich alternativ beide Strafwerte ausdrücklich auf 0 setzen, um eine Ausgangskonfiguration ohne Wiederholungsstrafen festzulegen.

Bei aktuellen Anthropic-Anfragen und den genannten Gemini-Flash-Modellen werden Sampling-Einstellungen weggelassen. Stattdessen sind eindeutige Felddefinitionen, zulässige Kategorien, Beispiele für fehlende Angaben und die unterstützte Funktion für strukturierte Ausgaben des Anbieters zu verwenden. Das Ergebnis muss unabhängig von seiner Formatierung validiert werden.

Für einen kurzen extrahierten Datensatz kann eine anfängliche Obergrenze von 1,000 Ausgabetokens als erster Versuch dienen, sofern die Anfrage kompatibel ist und kein Reasoning nutzt. Das ist kein allgemeingültiges Limit: Abbrüche und tatsächlicher Verbrauch müssen geprüft werden; gegebenenfalls ist Reasoning gesondert zu budgetieren. Fehlende Werte sollten mit einer Kennzeichnung ausgegeben werden, nicht mit einer erfundenen Rechnungsnummer.

Abnahmekriterium: Alle erforderlichen Felder sind vorhanden, die Werte stimmen mit der Quelle überein, und fehlende Informationen bleiben als fehlend erkennbar. Eine bestandene JSON-Validierung allein reicht nicht aus.

Textentwürfe: Formulierungen variieren, Fakten erhalten

Für eine Akquise-E-Mail oder eine Produktbeschreibung bildet das unterstützte Standardverhalten des Modells den Ausgangspunkt. Bei einem einstellbaren Endpunkt lässt es sich mit Temperatur 0.7 vergleichen; Top-p bleibt unverändert. Zielgruppe, Länge, Ton, erforderliche Fakten und unzulässige Behauptungen gehören in den Prompt.

Wiederholungsstrafen werden zunächst weggelassen. Wenn ein unterstützendes Modell in OpenAI Chat Completions unerwünschte Formulierungen wiederholt verwendet, ist eine Frequency Penalty von 0.2 ein kleiner Versuch innerhalb des dokumentierten Wertebereichs. Sie sollte nur bleiben, wenn die Prüfung eine Verbesserung zeigt. Erforderliche Produktnamen müssen unverändert erhalten bleiben.

Bei Modellen ohne Sampling-Einstellungen lassen sich unterschiedliche Ansätze ausdrücklich anfordern, etwa ein knapper sachlicher und ein erzählerischer Entwurf. Bewertet werden die Unterschiede in den tatsächlich entstandenen Texten.

Abnahmekriterium: Nützliche Variation ohne neue Tatsachenbehauptungen. Ein überraschenderer Text ist nicht automatisch der bessere Geschäftstext.

Code: Vollständige Ausgabe ermöglichen und Verhalten prüfen

Für einen klar abgegrenzten Patch ist Temperatur 0 oder 0.2 bei einem einstellbaren Endpunkt ein sinnvoller Vergleichswert. Bei einem Reasoning-Modell gilt dessen unterstützte Konfiguration; nicht unterstützte Sampling-Felder werden weggelassen. Wiederholungsstrafen und benutzerdefinierte Stoppsequenzen bleiben außen vor, sofern sie nicht durch ein getestetes Protokoll erforderlich sind.

Die Anfrage sollte den relevanten Code, die Randbedingungen und das erwartete Verhalten enthalten. Das Ausgabebudget muss für einen vollständigen Patch reichen. Erreicht die Antwort ihre Obergrenze, ist das Ergebnis als unvollständig zu behandeln. Der sichtbare Teil darf nicht ohne Weiteres als sicher anwendbar gelten.

Abnahmekriterium: Der Patch erfüllt die Spezifikation und besteht geeignete Prüfungen. Wiederkehrende Bezeichner sind in Code normal. Eine plausibel aussehende Antwort belegt nicht, dass der Code funktioniert.

Was Parameterzahlen und Einstellungen nicht versprechen können

Überzogen ist die Vorstellung, eine einzelne Zahl könne eine Bewertung ersetzen. Das kann sie nicht, unabhängig davon, ob sie die Anzahl der Gewichte oder die Temperatur angibt.

Ein größeres Modell ist für einen eng umrissenen Arbeitsablauf nicht automatisch besser. Eine kleinere aktive MoE-Parameterzahl bedeutet nicht, dass das gesamte Modell in entsprechend wenig Speicher passt. Eine niedrige Temperatur garantiert keine Wahrheit. Eine hohe Ausgabeobergrenze garantiert keine vollständige Argumentation. Und ein erfolgreicher API-Aufruf beweist nicht, dass jede übergebene Einstellung angewendet wurde.

Aussagekräftig sind eine repräsentative Eingabe, ein festgelegtes Erfolgskriterium und ein geprüftes Ergebnis. Bei der Beschaffung sollte der Anbieter den Arbeitsablauf mit genau der Konfiguration vorführen, die später eingesetzt wird. Bei der Entwicklung müssen Modell, Endpunkt, API-Version, Prompt und Einstellungen dokumentiert werden. So lässt sich nachvollziehen, was sich geändert hat, wenn sich das Verhalten ändert.

Nächste Schritte für Einkauf, Betrieb und Entwicklung

Der Einkauf sollte Ergebnisse vergleichen, der Betrieb Fehlerkriterien festlegen und die Entwicklung nicht unterstützte Einstellungen entfernen. Diese Aufgaben lassen sich an demselben kleinen Testsatz zusammenführen.

Wer einen gehosteten Dienst auswählt, kann auch ohne Kenntnis der Parameterzahl entscheiden, sofern der Dienst die benötigten Ergebnisse nachweist. Ein Hardwarekauf für Self-Hosting sollte warten, bis der Ressourcenbedarf anhand des vollständigen Checkpoints, der Genauigkeit und der Arbeitslast bestimmt ist. Ein funktionierender Arbeitsablauf muss nicht ersetzt werden, nur weil ein anderes Modell mit einer größeren Zahl wirbt.

Bei einem Modell- oder API-Versionswechsel sollte die Entwicklung die Kompatibilität jetzt prüfen. Wer eine verwaltete Oberfläche ohne zugängliche Generierungseinstellungen verwendet, ist von der Syntax der Anfragefelder weitgehend nicht betroffen. Die Ausgaben müssen trotzdem validiert werden.

1. 1

   Die Aufgaben sammeln, die zuverlässig gelingen müssen

   Am kommenden Montag 20 repräsentative Beispiele aus einem Arbeitsablauf zusammenstellen, darunter unvollständige, mehrdeutige und ungewöhnlich lange Eingaben. Das erwartete Ergebnis oder die Prüfkriterien werden festgehalten, bevor Modelle verglichen werden.

2. 2

   Die Anfragekonfiguration ausdrücklich festhalten

   Endpunkt, Modell und API-Version dokumentieren. Prüfen, welche Einstellungen unterstützt werden, die übrigen entfernen und ein Ausgabebudget wählen, das ein vollständiges Ergebnis erlaubt. Erforderliche Begriffe und der Umgang mit fehlenden Daten gehören in den Prompt.

3. 3

   Eine Sache ändern und das Ergebnis bewerten

   Die Ausgangskonfiguration mit einer unterstützten Anpassung vergleichen. Bei Extraktion zählt die Übereinstimmung mit der Quelle, bei Entwürfen die sachliche Richtigkeit und der Nutzen, bei Code das Verhalten und die Prüfergebnisse. Die einfachere Konfiguration bleibt, solange die Änderung keinen nachweisbaren Nutzen bringt.

Häufig gestellte Fragen

Wie funktioniert der Temperature-Parameter bei einem LLM?

Er verändert, wie stark die Wahrscheinlichkeitsverteilung für das nächste Token konzentriert ist. Niedrige Werte begünstigen wahrscheinliche Optionen, höhere Werte erlauben mehr Vielfalt. Die Einstellung verändert das Sampling, nicht die erlernten Gewichte. Manche aktuellen APIs weisen sie zurück oder ignorieren sie.

Wie viel Speicher benötigt ein 70B-Modell ungefähr?

Bei genau 70 Milliarden Gewichten beträgt der reine Speicherbedarf etwa 140 GB mit 16-bit, 70 GB mit 8-bit oder im Idealfall 35 GB mit 4-bit. Diese dezimalen Angaben enthalten weder den Arbeitsspeicher für den Betrieb noch den Zusatzbedarf durch Quantisierung. Die tatsächlichen Anforderungen hängen vom Checkpoint und der Arbeitslast ab.

Welche vier Arten von Parametern gibt es?

Für LLMs gibt es keine allgemeingültige Einteilung in vier Arten. Hilfreich ist die Unterscheidung zwischen erlernten Modellparametern, Architektureinstellungen, Trainingseinstellungen und Generierungseinstellungen. Diese Kategorien erleichtern das Verständnis des Systems. Sie besagen nicht, dass jede API vier Einstellmöglichkeiten bietet.

Was ist der Unterschied zwischen GPT und LLM?

LLM steht für Large Language Model, also großes Sprachmodell, und bezeichnet die übergeordnete Kategorie. GPT steht für Generative Pretrained Transformer und bezeichnet eine bestimmte Modellfamilie sowie einen Ansatz innerhalb dieser Kategorie. Auch andere Sprachmodellfamilien gehören zu den LLMs.

Welche vier Arten von LLMs gibt es?

Eine einheitliche Standardliste mit vier Arten gibt es nicht. Dichte Modelle und Mixture-of-Experts unterscheiden sich in der Architektur; offene und geschlossene Gewichte unterscheiden sich in der Verfügbarkeit. Diese Einteilungen beantworten unterschiedliche Fragen und ergeben zusammen keine vermeintliche Qualitätsrangfolge.

Ist ChatGPT ein LLM oder eine KI?

ChatGPT ist eine KI-Anwendung, die Modelle nutzt. Zu unterscheiden sind die Anwendung, das darin ausgewählte Modell und die API-Einstellungen, die Entwicklern zur Verfügung stehen. Es handelt sich um verschiedene Ebenen.

Welche KI ist kein LLM?

KI umfasst mehr als Sprachmodelle. Ein Klassifikationssystem zur Betrugserkennung oder ein System für maschinelles Sehen kann Verfahren des maschinellen Lernens einsetzen, ohne ein LLM zu verwenden. Auch Parameterzahlen sind nicht auf Sprachmodelle beschränkt.

Welches LLM ist die intelligenteste KI?

Aus der Parameterzahl lässt sich keine aufgabenunabhängige Antwort ableiten. Modelle sollten anhand repräsentativer Beispiele der tatsächlichen Arbeit verglichen werden, mit denselben Abnahmekriterien und einer dokumentierten Konfiguration. Ein Ergebnis in einem einzelnen Benchmark entscheidet nicht über die Eignung für jede Geschäftsaufgabe.

Zu welchem Bereich der KI gehören LLMs?

LLMs sind Deep-Learning-Modelle für die Verarbeitung und Erzeugung von Sprache. Ihre erlernten Parameter gehören zum Modell. Temperature und ähnliche Anfrageeinstellungen bestimmen dagegen, wie die Anwendung das Modell nutzt.

Für verständliche Einblicke in KI-Systeme und die Entscheidungen dahinter: den Newsletter abonnieren.