CLM-8B selbst hosten: vLLM, Action-Cache und Verifier

CLM-8B ist interessant, wenn ein Agent zwischen bekannten Aktionen wählen soll, statt eine weitere Antwort zu schreiben. Das entscheidende Implementierungsdetail ist die getrennte Kodierung von Zustand und Aktion: Ein veränderter Zustand lässt sich mit bereits kodierten Kandidaten vergleichen. Wiederverwendbare Aktionskataloge sind daher ein sinnvoller Ausgangspunkt, bevor ein generativer Schritt einfach durch einen anderen Prompt ersetzt wird.

Das veröffentlichte CLM-v0.1-8B enthält Projektionsköpfe für Zustände und Aktionen, die an einen eingefrorenen Qwen3-8B-Encoder gebunden sind. Jeder Kopf hat ungefähr 20 Millionen trainierbare Parameter. Der vollständige Encoder wird auch bei der Inferenz benötigt. Für die Referenzgewichte gilt Apache 2.0. Die CLM-Modellkarte beschreibt Architektur, Lizenz und Grenzen. Gemeint ist hier ein kontrastives Sprachmodell, keine Software für Contract Lifecycle Management und kein allgemeines Chatmodell.

Die technische Frage lautet nicht „Hat CLM Jev geschlagen?“, sondern „Kann unsere Anwendung Kandidaten wiederverwenden, die Entscheidungsqualität halten und die gemessene Gesamtlatenz senken?“ Unser technischer Jev-Review, die Benchmark-Analyse zu Laya und Jev und der Leitfaden für Geschäftsprozesse behandeln diese eigenständigen Themen. Hier geht es um den Betrieb von CLM, seine Eingaben und die Evaluierung als Verifier.

Quellen geprüft am 28. September 2026. Die Codeanalyse bezieht sich auf CLM-Commit bb42c6c5bf914fd449bed2f6ca65be80602cb1f7. Die Beispiele sind vorgeschlagene Integrationsmuster, kein Wavect-GPU-Benchmark und kein Nachweis eines produktiven CLM-Einsatzes.

Welchen Schritt ersetzt CLM-8B tatsächlich?

CLM ersetzt einen Bewertungs- oder Auswahlschritt, wenn die Kandidaten bereits vorliegen. Ein Planer, ein Retrieval-System, eine deterministische Regel oder ein anderes Modell muss sie weiterhin bereitstellen. CLM kann keine korrekte Aktion auswählen, die fehlt, keine beliebigen Tool-Argumente generieren, das gewählte Tool ausführen oder dafür eine Berechtigung erteilen.

Das Projekt bietet eine typisierte, TypeSafe-kompatible API und einen direkten Ranking-Endpunkt. Es beschreibt ein Training mit ungefähr 60 Millionen Frage-Antwort-Paaren, 30 Millionen synthetischen schwierigen Negativbeispielen und einer Million agentischer Abläufe. Zustand und Aktion werden durch ein kontrastives Trainingsziel aufeinander abgestimmt. Die abschließende Entscheidung wird nicht als generierter Absatz erzeugt. Das versionierte Projekt-README erläutert Training und Serving.

„Auswählen statt schreiben“ ist kein geeigneter Gegensatz zwischen CLM und Jev. Jev ist selbst ein typisiertes Entscheidungsmodell, kein gewöhnlicher Chatbot. Die Einführung von TypeSafe erklärt diese Abgrenzung. Dass zwei Dienste dieselbe Anfrageform akzeptieren, belegt weder austauschbare Vorhersagen noch kalibrierte Wahrscheinlichkeiten oder identisches Betriebsverhalten.

Eine eng begrenzte erste Integration wäre ein Diagnoseassistent mit rein lesendem Zugriff. Die Anwendung liefert erlaubte Diagnoseaktionen, CLM bewertet sie anhand einer Fehlermeldung, und vertrauenswürdiger Code prüft die Auswahl, bevor ein separater Executor überhaupt etwas ausführt. Das ist ein Architekturvorschlag, kein Genauigkeitsnachweis für Ihre Logs.

Was belegen die Geschwindigkeits- und Coding-Ergebnisse?

Die veröffentlichten Zahlen sind Ergebnisse der Autoren, kein allgemeines Ablösungsurteil. Das Projekt nennt bis zu 9-fach geringere Latenz bei ausgewählten Zero-shot-Aufgaben und ungefähr 13-fache Beschleunigung bei rund 1.000 Kandidaten. Das sind unterschiedliche Aufgaben und Cache-Bedingungen, keine zwei Garantien für jede Anfrage. Die geprüfte Modellkarte enthält diese Angaben der Autoren.

Die T-Rex-Reproduktion dokumentiert einen Physikplaner, der sichere Aktionen kennzeichnet, mehrere gleichzeitig laufende Anfragen und einen aktivierten Schutzmechanismus. CLM lief lokal auf einer RTX 4090; der verglichene Jev-Endpunkt meldete jev-1.13.0. Gemessen wurde die clientseitige Latenz je Anfrage. Das Überleben im Spiel bewertet daher das Gesamtsystem und nicht die Fähigkeit eines ungestützten Modells, Screenshots zu verstehen. Die T-Rex-Methodik beschreibt Planer, Schutzmechanismus und Ausführungsumgebung. Aus einem Spieltest entsteht kein belastbares Latenzziel für den Produktivbetrieb.

Bei Coding-Aufgaben bewertet CLM Lösungskandidaten anderer Modelle. Das README nennt nach aufgabenspezifischem Fine-Tuning 81,6 % auf 38 zurückgehaltenen DeepSWE-Aufgaben und 87,6 % auf 30 zurückgehaltenen Aufgaben aus Terminal-Bench 2.1. Das sind weder Zero-shot-Ergebnisse des herunterladbaren Referenzkopfs noch Ergebnisse auf den vollständigen Benchmark-Suiten. Die angegebene Zeitmessung für den Verifier nutzt eine H100 und damit einen anderen Aufbau als T-Rex. Der versionierte Ergebnisabschnitt nennt Aufgabenzahlen und Hardware.

Die veröffentlichte DeepSWE-Modellkarte erlaubt eine präzisere Einordnung: Auswahl aus vier Kandidaten, Mittelwert der letzten zwölf verfügbaren Schrittbewertungen und 31 erfolgreiche Auswahlen bei 38 Testaufgaben. Als pass@1-Basis nennt sie 28/38 und als Oracle-Obergrenze 34/38. Die DeepSWE-Kopf-Modellkarte veröffentlicht Datenteilung, Bewertungsregel und Checkpoint-Hash. Gegenüber der genannten pass@1-Basis sind das drei zusätzliche erfolgreiche Auswahlen auf diesem Datensatz. Es beweist nicht, dass ein 8B-Modell einen vollständigen Coding-Benchmark selbstständig gelöst hätte.

Halten Sie für eigene Vergleiche Kandidatengenerierung, Datenteilung, Hardware, Parallelität und Netzwerkgrenzen konstant. Veröffentlichen Sie neben der Latenz auch Genauigkeit und Zurückweisungsrate. Eine schnelle Fehlentscheidung erzeugt Nacharbeit. Wer diese aus der Zeitmessung entfernt, erzeugt einen künstlichen Vorteil.

CLM-8B mit vLLM selbst hosten

Betreiben Sie zwei Dienste: einen Qwen3-8B-Pooling-Encoder und die CLM-Bewertungs-API. Ein kleiner Download für die Projektionsköpfe ist keine kleine vollständige Laufzeitumgebung. Das CLM-Paket verlangt Python ab Version 3.10 und führt unter anderem PyTorch, vLLM, FastAPI und NumPy als Abhängigkeiten auf. Die versionierte Paketdefinition dokumentiert die tatsächlichen Abhängigkeiten.

Nutzen Sie eine isolierte, CUDA-fähige Linux-Umgebung, die zu Ihren vLLM- und PyTorch-Versionen passt. Der folgende CLM-Commit fixiert weder sämtliche Abhängigkeiten noch die Revision der Encodergewichte. Lösen Sie diese Versionen passend zur Hardware auf und speichern Sie anschließend einen Umgebungs-Lock sowie die Encoderrevision. Hier wird weder ein Mindest-VRAM noch ein bestimmter Hardwarepreis behauptet.

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install \
  "git+https://github.com/Contrastive-LM/CLM.git@bb42c6c5bf914fd449bed2f6ca65be80602cb1f7"
python -m pip freeze > clm-environment.txt

Starten Sie den Encoder in einem aktivierten Terminal. Verwenden Sie Qwen3-8B mit dem erwarteten Pooling-Verhalten, nicht irgendein Embedding-Modell mit derselben Ausgabedimension:

vllm serve Qwen/Qwen3-8B \
  --served-model-name qwen3-8b \
  --runner pooling \
  --max-model-len 2048 \
  --host 127.0.0.1 \
  --port 8090

Stellen Sie in einem zweiten aktivierten Terminal CLM_API_KEY über Ihre Secret-Verwaltung bereit. Die Client-Shell benötigt denselben Schlüssel. Er gehört niemals ins Repository. Starten Sie eine private API mit ausdrücklich begrenztem Vektorcache:

: "${CLM_API_KEY:?Set CLM_API_KEY in this shell first}"
export CLM_API_KEY
clm-serve \
  --host 127.0.0.1 \
  --port 8700 \
  --emb-url http://127.0.0.1:8090/v1/embeddings \
  --emb-model qwen3-8b \
  --max-tokens 2048 \
  --device cpu \
  --action-cache 64MiB \
  --no-ui

Dieses Beispiel legt die kleinen Köpfe und ihren Vektorcache bewusst auf die CPU, während der 8B-Encoder auf der GPU bleibt. Es veranschaulicht eine Bereitstellung und entspricht nicht der Konfiguration hinter den beworbenen Beschleunigungen. Vergleichen Sie CPU- und GPU-Köpfe mit Ihrer eigenen Last.

Der untersuchte Server verwendet standardmäßig 0.0.0.0, aktiviert Authentifizierung nur bei gesetztem CLM_API_KEY und liefert im Health-Ergebnis sowohl ok als auch embedder. Die Serverimplementierung definiert Flags, Authentifizierung und Health-Verhalten. Die explizite Loopback-Bindung ist deshalb wichtig. Der CLM-Schlüssel schützt nicht automatisch den separaten Encoder-Endpunkt, und --no-ui ist keine Authentifizierung. Halten Sie beide Dienste privat. Vor externem Zugriff brauchen sie authentifizierten Zugang, Anfragelimits und eine geeignete Trennung der Workloads.

Ein erfolgreicher HTTP-Status des Health-Endpunkts allein belegt keine Betriebsbereitschaft. Prüfen Sie auch den Encoderstatus und das angebotene Modell:

curl -fsS --connect-timeout 5 --max-time 15 http://127.0.0.1:8700/health \
  | python -c 'import json,sys; d=json.load(sys.stdin); sys.exit(0 if d.get("ok") and d.get("embedder") and "clm-latest" in d.get("models", []) else 1)'

Begrenzte Anfrage senden, ohne Tool-Rechte zu vergeben

Verwenden Sie stabile Options-IDs und eigenständig verständliche Beschreibungen. In CLMs Choice-Implementierung erhält der Zustandsencoder Kontext plus Anweisungen zur Frage. Der Aktionsencoder erhält die Beschreibung jeder Option, bei leerer Beschreibung deren Schlüssel. Zwei verschiedene IDs mit derselben Beschreibung sind für diesen Encoder deshalb keine inhaltlich unterschiedlichen Kandidaten. Die Schemaimplementierung zeigt, wie Zustände und Kandidaten zu Text werden.

Die folgende synthetische englische Anfrage bittet um einen rein lesenden Diagnoseschritt. Die Testeingabe bleibt in allen Sprachversionen identisch, damit Ergebnisse vergleichbar sind. Die Option review ist bewusst vorgesehen. Anwendungscode braucht trotzdem einen erzwungenen Rückfallpfad: Das Modell muss die Überprüfungsoption nicht auswählen, wenn es sie eigentlich wählen sollte.

{
  "model": "clm-latest",
  "state": "A CI job fails during dependency installation. The log reports a lockfile mismatch. No production change is authorized.",
  "questions": {
    "next_step": {
      "type": "choice",
      "instructions": "Select the most useful permitted read-only diagnostic step, or request review when the evidence is insufficient.",
      "criteria": {
        "inspect_lockfile": "Read the manifest and lockfile to identify inconsistent dependency versions; make no changes.",
        "read_network_log": "Read existing dependency-download network logs to investigate connection failures; make no changes.",
        "review": "Ask a human to review because the supplied evidence is insufficient or no listed diagnostic is appropriate."
      }
    }
  }
}

Speichern Sie die Anfrage als request.json und rufen Sie die API aus einer Shell mit demselben CLM_API_KEY auf:

: "${CLM_API_KEY:?Set the same CLM_API_KEY used by the API}"
curl -fsS --connect-timeout 5 --max-time 30 \
  -H "Authorization: Bearer ${CLM_API_KEY}" \
  -H "Content-Type: application/json" \
  --data-binary @request.json \
  http://127.0.0.1:8700/v1/systemone

Prüfen Sie Antworttyp, Options-ID und Wahrscheinlichkeitsverteilung, bevor Sie das Ergebnis verwenden. Die Anwendung sollte unerwartete IDs ablehnen, Ausführungsberechtigungen gesondert prüfen und bei Zeitüberschreitung, unzureichender Evidenz oder nicht erfüllten Qualitätskriterien auf menschliche Prüfung zurückfallen. Die choice-ID darf nicht zu einem ungeprüften Shell-Befehl werden.

TypeSafe-kompatibel bedeutet nicht, dass ein bloßer Austausch der Basis-URL produktionsreif ist. Schwellenwerte, Beschreibungen und Eingabeaufbereitung müssen erneut validiert werden. Allgemeine Geschäftsprozessbeispiele gehören in den oben verlinkten Workflow-Leitfaden; hier geht es um den CLM-spezifischen Anfragevertrag.

Wann hilft der Action-Cache tatsächlich?

Caching hilft, wenn derselbe Kandidatentext gegen neue Zustände bewertet wird. Ein fester Satz von Diagnoseaktionen, Produktdatensätzen oder erlaubten Aktionen kann seine Kodierungskosten über mehrere Anfragen verteilen. Eine jeweils neue Sammlung langer generierter Lösungen kann deren Aktions-Embeddings nicht über unabhängige Aufgaben hinweg wiederverwenden. Zustandsseitige oder andere Wiederverwendung kann dennoch helfen.

Der untersuchte Embedder speichert normalisierte Encodervektoren anhand des exakten Eingabetextes in einem prozessinternen LRU-Cache. Bei Cache-Misses fragt er den konfigurierten Pooling-Endpunkt ab. Die Tokenanzeige erfasst die dafür neu verarbeiteten Tokens. Der Embedder-Code definiert Textcache und Tokenzählung. „Keine neuen Encodertokens“ bedeutet weder „keine Rechenarbeit“ noch kostenlose Infrastruktur oder den Nachweis einer unabhängig verarbeiteten neuen Nutzereingabe.

Auf Engine-Ebene verwenden projizierte Zustands- und Aktionsvektoren getrennte Namensräume; die Identität des Kopfes ist Teil dieses Namensraums. Die Engine trennt rohe Embeddings, projizierte Vektoren und Modellauswahl. Der geräteseitige Speicherbereich wird beim Start reserviert und verdrängt die am längsten ungenutzten Einträge. Die Vektorcache-Implementierung definiert die begrenzten Pools. Ihr Speicherbudget begrenzt weder den separaten Encoder-Textcache noch den gesamten Prozess. Beide Caches sind Implementierungsdetails, keine Berechtigungsschicht und kein dauerhafter Wissensspeicher.

Drei unterschiedliche Objekte benötigen unterschiedliche Wiederverwendungsregeln:

Unsere Empfehlung für den Betrieb ist ein Manifest mit Encoderrevision, Pooling-Modus, Kopf-Hash, Version der Textaufbereitung und Tokenlimit. Nach Änderungen am Encoder oder an der Vorverarbeitung sollten Sie neu starten und den Cache erneut füllen, statt anzunehmen, dass ein Kopfwechsel alle Ebenen invalidiert. Versionieren Sie den Aktionskatalog separat. Nach Änderungen an Berechtigungen oder Datensätzen darf eine alte Entscheidung nicht wiederverwendet werden.

Ein geteilter Prozesscache garantiert keine Mandantentrennung. Prüfen Sie für sensible Workloads getrennte Prozesse oder stärkere Isolation und berücksichtigen Sie Logs, Speicher, Cache-Timing und Request-Routing. Wärmen Sie ausschließlich autorisierte Kandidatenkataloge vor. Eine globale Liste zu kodieren macht deren Einträge durch einen hohen Score nicht zugriffsberechtigt.

Warum kann CLM sicher wirken und trotzdem falsch wählen?

CLM-Wahrscheinlichkeiten sind relativ zur übergebenen Kandidatenmenge. Eine Softmax-Verteilung muss ihre Masse verteilen, auch wenn alle Optionen ungeeignet sind. Bei genau einem Kandidaten beträgt die Wahrscheinlichkeit zwangsläufig 1,0. Das belegt nicht dessen Korrektheit. Weitere plausible Alternativen können Wahrscheinlichkeiten verändern, obwohl die Aufgabe gleich bleibt.

Das veröffentlichte Feld confidence ist die höchste Wahrscheinlichkeit minus dem Mittelwert der übrigen Wahrscheinlichkeiten. Es ist weder eine allgemeine Wahrscheinlichkeit für sachliche Richtigkeit noch ein Ersatz für eine kalibrierte Annahmeregel. Die Formel steht im oben verlinkten Schema-Code. Behandeln Sie 0.9 als zu validierende Modellausgabe, nicht als übertragbare 90-Prozent-Garantie.

Testen Sie für diese CLM-Integration fehlende korrekte Optionen, identische Beschreibungen, sehr ähnliche Kandidaten, widersprüchlichen Kontext, unterschiedliche Reihenfolgen und wechselnde Mengengrößen. Messen Sie die Fehlerrate am vorgesehenen Annahmeschwellenwert separat je relevanter Sprache und Aktionsfamilie. Dieser Artikel ist übersetzt; das belegt keine mehrsprachige CLM-Leistung.

Berechtigungsprüfungen gehören außerhalb des Scorers und müssen unmittelbar vor der Ausführung erneut stattfinden. Bei folgenreichen Aktionen ist ein Rückfallpfad eine Entscheidung der Anwendung, nicht nur ein weiteres Label, das dasselbe Modell ignorieren kann. Beschränken Sie den ersten Einsatz auf Vorschläge, bis unabhängige Testdaten mehr Befugnisse rechtfertigen.

Das 2.048-Token-Limit und typische Startprobleme

Der Referenz-Quickstart kürzt Eingabetexte auf 2.048 Tokens. Nur das Maximum des Encoders zu erhöhen entfernt die CLM-seitige Kürzung nicht. Für Tests mit 8K-Eingaben erhöhen Sie sowohl vllm serve --max-model-len 8192 als auch clm-serve --max-tokens 8192 und prüfen anschließend GPU-Speicher und Qualität erneut. Längere akzeptierte Eingaben beweisen nicht, dass der Kopf dafür validiert wurde.

Der untersuchte Embedder sendet truncate_prompt_tokens. Sowohl die Darstellung von Zustand und Frage als auch die Aktionsbeschreibungen bestimmen den tatsächlich eingebetteten Text. Testen Sie Anweisungen und wichtige Evidenz nahe der Längengrenze. Zu große Eingaben sollten durch vertrauenswürdigen Anwendungscode abgelehnt oder bewusst zusammengefasst werden, statt eine gekürzte Entscheidung stillschweigend als vollständig zu behandeln.

Ersetzen Sie Qwen3-8B nicht allein deshalb durch einen anderen Encoder, weil dieser schneller erscheint. Der Kopf ist an die Repräsentation und das Pooling seines Trainings gebunden. Quantisierung, alternative Laufzeitumgebungen und längere Kontexte benötigen jeweils eigene Qualitäts- und Latenztests.

CLM als Verifier nutzen, nicht als Codegenerator

Ein Verifier wählt zwischen vorhandenen Lösungen; er ersetzt weder Generierung noch Tests. Eine Pipeline kann mehrere Lösungen erzeugen, deterministische Prüfungen ausführen, verbleibende Kandidaten bewerten und ein ausgewähltes Artefakt zur Prüfung übergeben. Erfassen Sie die Generierungskosten getrennt von der Verifier-Zeit. Die allgemeine Architektur beschreibt unser Leitfaden zu LLMs als Verifier. CLM-spezifisch sind die Wahl des passenden Kopfes und das Evaluierungsrezept.

Für das veröffentlichte DeepSWE-Experiment enthält die Modellkarte einen reproduzierbaren Befehl mit gespeicherten Embeddings. Führen Sie ihn aus dem versionierten CLM-Checkout mit den dokumentierten Evaluierungsabhängigkeiten und verfügbarer Hugging-Face-CLI aus:

git clone https://github.com/Contrastive-LM/CLM.git clm-source
git -C clm-source checkout bb42c6c5bf914fd449bed2f6ca65be80602cb1f7
cd clm-source
hf download Contrastive-LM/deepswe-clm-heads-8k --local-dir heads/deepswe
python evaluation/bon_eval.py \
  --hf-dataset Contrastive-LM/deepswe-clm-embeddings-8k \
  --checkpoint heads/deepswe/best_head.pt \
  --tasks-file heads/deepswe/heldout_tasks.json \
  --n 4 --window 12

Damit wird ein Verifier auf einem veröffentlichten Embedding-Datensatz evaluiert. Der Befehl startet keinen Coding-Agenten, erzeugt nicht sämtliche Abläufe neu und misst nicht die Gesamtdauer zum Lösen der Originalaufgaben. Prüfen Sie die veröffentlichten Hashes für Checkpoint und Testaufgabenliste, fixieren Sie das Kandidatenbudget und halten Sie Aufgaben zwischen Training und Test getrennt.

Die Fine-Tuning-Anleitung des Projekts lässt Daten, Folds, Evaluierungsmenge und Best-of-N-Einstellungen ausdrücklich unverändert, während das Training verändert wird. Der versionierte Fine-Tuning-Leitfaden legt diese Versuchsgrenzen fest. Kleine trainierbare Köpfe können den parameterbezogenen Trainingsaufwand senken. Datenkennzeichnung, Embedding-Erzeugung, Evaluierung und Serving bleiben trotzdem Arbeit. Auf zurückgehaltenen Aufgaben zu optimieren und das Ergebnis anschließend als unberührte Testleistung auszugeben wäre irreführend.

Prüfen Sie auch die Lizenzmetadaten jedes Artefakts: Die CLM-Referenzgewichte sind Apache 2.0, die geprüfte DeepSWE-Kopf-Modellkarte kennzeichnet ihr Artefakt dagegen als MIT. Nicht jeder abgeleitete Checkpoint muss dieselbe Lizenz haben. Offene Gewichte bedeuten keine kostenlose Infrastruktur und keine Eignungsgarantie.

Vor dem Wechsel die gesamte Verarbeitung messen

Eine zehnmal schnellere Entscheidungskomponente macht nicht den ganzen Agenten zehnmal schneller. Ein ausdrücklich hypothetisches Beispiel: Ein Ablauf benötigt 900 ms außerhalb der Auswahl und 100 ms für die Auswahl. Wird daraus ein 10-ms-Schritt, beträgt die Gesamtdauer 910 statt 1.000 ms. Das sind 9 % weniger Zeit beziehungsweise ungefähr 1,10-fache Gesamtgeschwindigkeit. Diese Rechnung ist keine CLM-Messung.

Vergleichen Sie für einen CLM-Piloten neue Zustände mit kalten Kandidaten, neue Zustände mit warmen Kandidaten, identische wiederholte Anfragen und sich ändernde Kataloge. Eine unveränderte Wiederholungsanfrage kann einen anderen Cache-Pfad messen als reale Arbeit. Halten Sie diese Ergebnisse getrennt. Berichten Sie Ende-zu-Ende-p50/p95, Fehler, Speicherbedarf, Genauigkeit akzeptierter Entscheidungen und Prüfquote bei gleicher Parallelität und gleichem Kandidatenbudget.

Vor einer Freigabe brauchen Sie ein versioniertes Encoder-Kopf-Paar, klare Verantwortung für Kandidaten, getestete Fehlerbehandlung, Cache-Monitoring, repräsentative zurückgehaltene Testdaten und einen Rückweg. Lassen Sie den bisherigen Selector für Vergleichsmessungen mitlaufen, bevor der neue Dienst Schreibrechte erhält. Für die Investitionsentscheidung verwenden Sie die übergeordnete Scorecard zum Stoppen oder Skalieren eines KI-Piloten, statt hier eine zweite Rollout-Methode einzuführen.

Zum Prüfdatum beschreibt die Referenz-Modellkarte ein multimodales CLM-35B als für Anfang Oktober 2026 geplant. Das ist eine Roadmap-Angabe, keine veröffentlichte Funktion und kein garantierter Liefertermin. Spätere Checkpoints müssen eigenständig evaluiert werden; die 8B-Ergebnisse lassen sich nicht einfach übertragen.

Wavects KI-Integrationsleistungen können Auswahl, Berechtigungen, Beobachtbarkeit und Evaluierung gemeinsam betrachten. Die Twinsoft-AI-Fallstudie ist verwandter Umsetzungskontext, kein Nachweis eines CLM-Einsatzes. Nutzen Sie die QA-Checkliste vor dem Launch und einen repräsentativen Kandidatensatz, um einen klar begrenzten CLM-Verifier-Piloten zu besprechen.