tlg/prompts

Fork 0

Files

T

rdms 906760fd54 Neue Prompt-Dateien und neue Prompts in bestehenden Dateien

2026-09-28 09:24:55 +02:00

42 KiB

Raw Permalink Blame History

LLMux

Single AI-model scripts

Motivation

For test purposes shell scripts are needed which run a single AI-model.

References

Study /home/try/python/docs/details.md first. In §4 there are four AI models; for each of them a shell script is needed.

A not optimized shell script example is /home/try/python/scripts/tlg_serve_inference_nvfp4.sh.

Your tasks

Ask before you start to implement

Use your AskUserQuestions tool to interview me until you fully understand the situation and your tasks.

Generate shell scripts

Generate the four shell scripts with vLLM sleep mode enabled but optimized for operation of only one single AI model. Don't reserve a VRAM part for other AI-models. For Qwen3.5-9B, enable the vision capabilities and tool usage, disable MTP, and choose the maximum context window size possible with the given VRAM. Verify by executing the script, determining free VRAM using nvidia-smi, and if the VRAM border is not yet reached stop the script and increase the context window size. Iterate until the VRAM border is reached.

I have changed the default ports in the four shell scripts to

8081 for inference
8082 for embedding
8083 for ASR
8084 for TTS

Now please generate the shell script serve_inference_asr.sh to run the inference and asr models. Inference at port 8081 and ASR at port 8083. The asr model size is fixed; use the context-maximization method as before to get the largest possible inference context window size.

I did run single-model_serve_inference.sh and was able to use it with Open WebUI. When I did run single-model_serve_asr.sh, I was not able to see any models in Open WebUI anymore; I guess because the model catalogue is provided via port 8081 which was not in use because single-model_serve_inference.sh was not running. Ensure that serve_inference_asr.sh offers both inference and ASR to Open WebUI.

So are the four models with my port edits in the repo now or not?

How to get Audio working in Open WebUI?

I'm using the German UI, so I switch to German now.

Ich habe als Admin Open WebUI auf https://kipurchat.creature-go.com/admin/settings/audio so eingestellt:

Sprache-zu-Text-Engine: OpenAI, https://api.openai.com/v1, API-Schlüssel Feld leer
STT-Modell: whisper-1

Wenn ich auf Speichern klicke, erscheint zum Feld API-Schlüssel "Füllen Sie dieses Feld aus."

Ich möchte OpenWhispr mit diesen Modellen betreiben. Nach Installation von OpenWhispr auf meinem Windows 10 PC und setzen der Endpoints funktioniert es nicht. Es gibt kein Feld zum angeben der Modelle und das Fetch Model scheitert mit "Failed to Fetch". Bitte unterstütze mich dabei.

Mein PC ist über WireGuard mit einem Rechenzentrum Server verbunden, der wiederum über WireGuard mit dem KI-Server verbunden ist, auf dem die KI-Modelle laufen. Der KI-Server nutzt Traefik und containerized Services.

In Open WebUI habe ich als Admin diese URLs hier eingestellt: a) ASR Modell: http://10.0.2.2:8083/v1 b) Inference Modell: http://10.0.2.2:8081/v1

Bevor du wieder voreilige Versuche startest und falsche Annahmen triffst, frage mich, bis du alle nötigen Infos hast oder ich dir bestätige, dass du starten sollst.

Zu 1)

WireGuard IP-Addresses: Rechenzentrum Server: 10.8.0.1 DesTEngSsv005 On-Prem KI-Server: 10.8.0.6 DesTEngSsv006 PC: 10.8.0.3 DesTEngSnb003

Ping vom PC zum KI-Server funktioniert.

Zu 2)

Open WebUI läuft als Container auf dem KI-Server, und 10.0.2.2 ist die Adresse, über die dieser Container den Host/vLLM erreicht.
Der Windows-PC kann 10.0.2.2 nicht direkt ansprechen, die Adresse ist nur containerintern gültig.

Zu 3)

Ja, Open WebUI Audio (nur ASR, nicht STT) und Inferenz funktionieren.

Zu 4)

PC muss direkt als rohe host:port über den WireGuard-Tunnel zugreifen, weil der KI-Server keinen Domain Namen hat (dynamische IP-Adresse, NAT).
Ob die Ports 8081 und 8083 in Traefik durchgereicht werden, weiß ich im Moment nicht.

Zu 5)

Ich habe jetzt geändert, nun sind in OpenWhispr bei AI Models eingestellt: a) Unter Speech-to-Text: Self-Hosted, Server URL http://10.8.0.6:8083/v1 b) Unter Language Models: Self-Hosted, Endpoint URL: http://10.8.0.6:8081/v1, damit wurde der korrekte Modellname AxionML/Qwen3.5-9B-NVFP4 Owner: vllm abgerufen.

Diktieren funktioniert jetzt - allein unsere Diskussion hat mir das nötige Verständnis gebracht, dankeschön :-)

Leider funktioniert es jetzt nicht mehr. Zum Testen habe ich dreimal diesen Satz gesprochen: "Das Lazy-Compile ist in der Praxis unbrauchbar. Ich kann nicht jedes mal 60 Sekunden warten, bis das Diktieren funktioniert."

Dies waren die eingefügten Texte:

Test 1: "Las LFLas LLas LFFFolFanLas L L L LacyLas LacyFanLas LacyLas LacyLas LacyLas L L LacyLas LLas LacyLas LacyLas L LacyLas L LacyLas L LacyLas LacyFanLas LacyLas LacyLas LacyLas LacyLas L LacyFanLas Lacy"

Test 2: "Las LLas LLas LLas LLas L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L Llan ist"

Test 3: "AlleAlleAlleAlleAlleAlleDasAlleisikoDasDasDasDasDas istDas istDas istDas ist derDas istDas ist derDas ist inDas ist deDas LDas LeseDas ist inDas LaisikoDas LaisikoDas ist inDas LeseDas ist in"

Woran könnte das liegen?

Diese ständigen Inkompatibilitäten sind sehr frustrierend.

Anstelle eines Quick-and-Dirty Fixes würde ich gern verstehen, warum das ursprünglich gewählte ASR Modell mit vLLM versagt hat. Dann würde ich gern das am besten für mich geeignete Modell auswählen; das könnte ein anderes sein als das, welches du jetzt zum Testen verwendet hast. Schön wäre auch, das Modell dann in 4-Bit Quantisierung für vLLM zu nutzen.

Bitte URLs von einem oder mehreren Benchmarks oder Vergleichstabellen, bei denen ich die Qualität aktueller ASR-Modelle ablesen kann

Bitte validiere CohereLabs/cohere-transcribe-03-2026

nvidia/canary-1b-v2 nutzt die CC-BY-4.0 Lizenz, ist die für mich unschädlich?

CohereLabs/cohere-transcribe-03-2026: Ich habe mich bereits früher registriert ("Gated model You have been granted access to this model").

Das mit dem Token habe ich probiert, er ist aber woanders gelandet:

(venv-vllm-omni-sleep) try@destengssv006:~/.cache/huggingface$ hf auth login

    _|    _|  _|    _|    _|_|_|    _|_|_|  _|_|_|  _|      _|    _|_|_|      _|_|_|_|    _|_|      _|_|_|  _|_|_|_|
    _|    _|  _|    _|  _|        _|          _|    _|_|    _|  _|            _|        _|    _|  _|        _|
    _|_|_|_|  _|    _|  _|  _|_|  _|  _|_|    _|    _|  _|  _|  _|  _|_|      _|_|_|    _|_|_|_|  _|        _|_|_|
    _|    _|  _|    _|  _|    _|  _|    _|    _|    _|    _|_|  _|    _|      _|        _|    _|  _|        _|
    _|    _|    _|_|      _|_|_|    _|_|_|  _|_|_|  _|      _|    _|_|_|      _|        _|    _|    _|_|_|  _|_|_|_|

    To log in, `huggingface_hub` requires a token generated from https://huggingface.co/settings/tokens .
Enter your token (input will not be visible): 
Add token as git credential? [y/N]: y
Token is valid (permission: fineGrained).
The token `try@destengssv006` has been saved to /home/try/python/hf-cache/stored_tokens
Cannot authenticate through git-credential as no helper is defined on your machine.
You might have to re-authenticate when pushing to the Hugging Face Hub.
Run the following command in your terminal in case you want to set the 'store' credential helper as default.

git config --global credential.helper store

Read https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage for more details.
Token has not been saved to git credential helper.
Your token has been saved to /home/try/python/hf-cache/token
Login successful.
The current active token is: `try@destengssv006`
(venv-vllm-omni-sleep) try@destengssv006:~/.cache/huggingface$

Das ist sehr schlecht: In dem Format frisst cohere-transcribe 7828 MB VRAM - die Hälfte! Damit wäre das Qwen3.5-9B nicht mehr vernünftig gleichzeitig nutzbar.

Inakzeptabel. Findest du das 4-bit Quantisiert als AWQ?

Sonst nehmen wir ein anderes, so viel VRAM können wir nicht opfern.

Zum Diktieren und sofortigem Korrigieren brauchen wir sofort das Inference Modell nach dem ASR Modell. Erst das eine in sleep und das andere wecken ist zu träge.

Nimm das openai/whisper-large-v3-turbo, das ist schön klein, schnell und multilingual, hat für Deutsch eine akzeptable WER. Das hattest du vorhin schon validiert, stimmt's? Falls ja, bitte alle Shell Skripte, in denen das ASR-Modell vorkommt, durch openai/whisper-large-v3-turbo aktualisieren.

Du hast beim exec vllm serve das Modell ausgetauscht, aber die weiteren Optionen so gelassen. Frage zu --enforce-eager und --max-model-len 448: Waren das nicht Optionen, die spezifisch für das primeline Modell waren? Sollten diese nicht entfernt oder kritisch überprüft werden?

Hast du Prozesse laufen lassen? VRAM ist belegt.

OpenWhispr funktioniert nicht:

Transcription Error
Transcription failed: API Error: 404
{"error":{"message":"The model `primeline/distil-whisper-large-v3-german` does not exist.","type":"NotFoundError","param":"model","code":404}}

Ich sehe in den OpenWhispr Einstellungen kein Feld, in das ich den ASR-Modell Namen eingeben könnte. Die URL ist unverändert auf http://10.8.0.6:8083/v1.

Danke für deinen Hinweis Die erste Transkription nach einem Server(neu)start dauert ~60 s (Whisper Lazy-Compile), danach sub-Sekunde. Das stört sehr - ich will nicht beim Diktieren erst mal 60 Sekunden Zeit verschwenden, um auf ein System zu warten, was zu faul ist, beim Server-Start zu initialisieren. Ist das tatsächlich bei whisper-large-v3-turbo auch so? Wie lässt sich das beseitigen?

Danke, Diktieren funktioniert jetzt.

Weil die OpenWhispr App eine unsinnige Funktion hat, hast du jetzt auf unserer Serverseite einen Workaround einprogrammiert, um das Quick & Dirty zu fixen? Das finde ich nicht gut.

Anstatt auf dem Server irgendwelche schmutzigen Tricks zu machen, damit falsche Funktionen bei PC Apps weiter funktionieren, sollten wir doch lieber die PC-App resetten oder das Modell, was früher benutzt wurde, da raus nehmen. Das erscheint mir erheblich besser als den Server zu verbiegen, um Unsinn zu unterstützen.

Danke fürs Wiederherstellen der korrekten Server-Konfiguration.

Zum OpenWhispr Resetten:

Punkt 1 funktioniert nicht.
Punkt 2: Möchte ich gern ausführen, aber ich finde die Settings-/Config-Datei nicht. Ich kenne C:\Users\tlg\AppData\Roaming\open-whispr und C:\Users\tlg\AppData\Local\Programs\OpenWhispr, habe dort nachgesehen aber keine solche Datei gefunden. Kannst du mir genauer sagen, wo ich sie finden kann?

DevTools-Konsole ließ sich öffnen. Ich habe nach aktivieren von Paste das hier rein gepastet:

for (let i=0;i<localStorage.length;i++){const k=localStorage.key(i);const v=localStorage.getItem(k); if(/distil|whisper|transcri|model|8083/i.test(k+v)) console.log(k,'=',v);}

Der Key cloudTranscriptionModel war aus der Auflistung zu ersehen. Dann habe ich eingegeben:

localStorage.setItem('cloudTranscriptionModel', 'openai/whisper-large-v3-turbo');

Nach OpenWhispr Neustart funktioniert nun Diktieren einwandfrei.

Bitte in unsere Doku übernehmen.

Es war ja gelungen, mit einem anderen AI Framework das unsloth/Qwen3.6-27B-GGUF Modell mit IQ4_XS gerade so ins VRAM zu bekommen, wobei das Context Window nur 8192 Tokens lang war und kein Vision Tower dabei war.

Wäre es möglich, mit dem aktuellen vLLM und 4-bit Quantisierung ein Qwen3.6-27B Modell mit für vLLM optimalen Format (AWQ oder GPTQ) zu betreiben? Noch nicht forschen, erst deine Einschätzung, bitte.

Spawne einen Opus Subagent, der alle auf Hugging-Face verfügbaren 4-bit quantisierten text-only AWQ/GPTQ-Qwen3.6-27B Modelle findet und in einer Tabelle so wie in /home/try/python/docs/qwen3.6-27b-quants.md darstellt. In Englisch bitte, und Details bei besonderem Verhalten (z.B. Anzahl der Refusals) sind von Interesse.

Spawne einen weiteren Opus Subagent, der alle auf Hugging-Face verfügbaren 4-bit quantisierten AWQ/GPTQ gpt-oss-20b Modelle findet und ebenso in einer Tabelle darstellt.

Spawne einen weiteren Opus Subagent, der alle auf Hugging-Face verfügbaren 4-bit quantisierten AWQ/GPTQ gemma-4-12B Modelle findet und ebenso in einer Tabelle darstellt.

Unterstützt vLLM denn das native MXFP4 von openai/gpt-oss-20b?

Bitte Infos über Gemma Terms, darf ich einen KI-Server mit diesem Modell verkaufen, darf ich es auf meinem eigenen KI-Server kommerziell nur für mich nutzen, darf ich es anderen auf meinem KI-Server vermieten oder kostenfrei anbieten?

Ich bezweifle, dass google/gemma-4-12B nicht unter Apache-2.0 Lizenz steht, weil auf der Hugging Face google/gemma-4-12B Seite die Apache-2.0 Lizenz an zwei Stellen explizit genannt wird.

Warum sollte also Gemma Terms gelten? Ggf. Quellen, bitte.

Shell Skripte

Ich möchte weitere Shell Skripte zum Betreiben von Inference Modellen haben. Die Inference Modell Context Windows sollen jeweils für unsere GPU VRAM-Grenze maximiert werden. Aber vor dem Generieren erst mal abstimmen.

Zu Qwen3.6-27B

Ich weiß, dass es sehr knapp mit dem VRAM wird, aber ich würde gern einen Versuch mit einem Refusal-entfernten Modell ohne MTP und ohne Vision Tower starten. Ich denke an llmfan46/Qwen3.6-27B-uncensored-heretic-v2-GPTQ-Int4, oder welches würdest du empfehlen?

Shell Skript soll nur dieses Inference-Modell laufen lassen.

Zu Gemma-4-12B

Ich hätte gern cyankiwi/gemma-4-12B-it-AWQ-INT4 als meist gedownloadetes Modell und hfacesp/gemma-4-12b-it-uncensored-W4A16-AutoRound als Refusal-removed Modell.

Beide Shell Skripte sollen zusätzlich zum Inference-Modell auch das ASR-Modell gleichzeitig betreiben.

Zu gpt-oss-20b

Natives Modell soll benutzt werden. Das Shell Skript soll zusätzlich zum Inference-Modell auch das ASR-Modell gleichzeitig betreiben.

Diskussion

Bitte diskutiere meine Ideen mit mir.

Zu 1.

Wieso kein Sleep? Wir hatten doch rausgefunden, dass erstaunlicherweise vLLM mit Sleep-Option mehr VRAM-Nutzung erlaubt als vLLM ohne Sleep-Option?

Zu 3.

Warum ist das cyankiwi Modell so viel größer? Es sind doch beides 4-bit Quantisierungen des gleichen Modells.

Zu 2.

OK, standalone akzeptiert.

Zu 4.

Ja, bitte nun testen was sich testen lässt.

Zu 1.:

Könnte es denn sein, dass wir ein 27B Modell für vLLM finden, wo der Vision Tower tatsächlich entfernt ist?

Zu 2.:

Ja, bitte in die Doku.

Zu 3.:

Nein, lass das noch da.

Zu 4.:

Nein, wir lassen das vLLM so wie es ist.

Nein, du sollst das jetzt erst mal nicht bauen.

Eine prinzipielle Frage habe ich: Wenn das also mit vLLM nicht funktioniert und wir lama.cpp brauchen, kann man vLLM und lama.cpp gleichzeitig in einem Python Virtual Environment betreiben oder braucht man zwei verschiedene Environments dafür? Hintergrund der Frage ist: Ich möchte eigentlich verschiedene Modelle zum Auswählen in OpenWeb UI haben. Und zum Umschalten zwischen den Modellen müsste dann eine Zwischenschicht LLMux die entsprechende Auswahl von lama.cpp oder vLLM treffen. Wenn beide in einem Python Environment laufen würden, dann wäre das einfacher.

Das heißt zu den 4 Ports die ich jetzt habe, bräuchte ich noch einen 5. Port, um hinter dem das Lama-CPP-Server Backend laufen zu lassen? Und LLMux würde dann die entsprechenden Prozesse in den venvs starten und stoppen, um das VRAM wieder freizugeben?

Das OpenWeb UI nur einen Endpoint anspricht, stimmt ja nicht so ganz. Es spricht ja einen Inference Endpoint, einen ASR Endpoint und einen TTS Endpoint an, und das sind unterschiedliche Ports, also drei verschiedene Ports nutzt OpenWeb UI - richtig?

Meine Idee zur Lösung dieses Themas ist, dass LLMux auch eine Übersetzung zwischen den in Open WebUI zu sehenden Namen und den tatsächlichen Inference Modell-Namen vornimmt.

Beispiel für meine Idee (ob sich das so umsetzen lässt, ist noch zu klären):

LLMux liefert an Open WebUI die Inference-Modell Namen Qwen3.5-9B + ASR, Qwen3.6-27B no refusals, Gemma-4-12B und gpt-oss-20b, zwischen denen der Anwender aussuchen kann.
Bei Qwen3.5-9B + ASR ist vLLM an und llama.cpp aus.
Bei Qwen3.6-27B no refusals ist vLLM aus und llama.cpp an.
Bei Gemma-4-12B ist vLLM an aber die vLLM-Modelle im sleep und llama.cpp an.
Bei gpt-oss-20b ist vLLM an aber die vLLM-Modelle im sleep und llama.cpp an.

Nicht jetzt recherchieren.

Lass uns nochmal das TTS Modell genauer unter die Lupe nehmen. Die 1826 MB Residue und die Größe insgesamt erscheint mir recht hoch.

Bitte zeige mir die Hugging Face Vergleichstabellen-Seite, auf der ich die verschiedenen TTS-Modelle vergleichen kann.

Zwei Arenas sind ärgerlich. WhisperSpeech fehlt in der neueren zum Beispiel. Die alte hat keine ELO-Angabe.

Kannst du einen Opus Subagent spawnen, der eine kombinierte TTS-Tabelle mit Qualität (ELO-Angabe), Modell-Größe und vLLM-Tauglichkeit erstellt, die umfangreich ist? Vielleicht von anderen Quellen als Hugging Face, wenn es bei Hugging Face so etwas nicht gibt?

Spawne einen Subagent, der Nutzerberichte über Deutsch mit den vLLM-Omni-fähigen Modellen sucht - wir sind doch bestimmt nicht die ersten, die so etwas machen wollen.

Voxtral ist Non-Commercial.

Bitte ein Shell Skript zum Betreiben von FunAudioLLM/Fun-CosyVoice3-0.5B-2512 erstellen. Aber wie teste ich das Modell?

Und committe die neuen Ergebnisse und Erkenntnisse.

Und dann erkläre mir bitte, wie ich in Open WebUI vorlesen lassen kann.

Cozy Voice 3 ist dadurch, dass der Sleep Mode nicht funktioniert, für uns gestorben. Bitte zeige mir, wie ich herausfinde, welche Prozesse den VRAM belegen und wie ich diese Prozesse beende.

Hier dein aktueller Stand als Beispiel: zwei VRAM-Belegungen — 4056497 = 3766 MiB (ASR) und 4057062 = 11724 MiB (Inferenz). Beides sind EngineCore-Prozesse. Daran zeige ich die Befehle.

Anzeigen — wer belegt VRAM?

nvidia-smi # Komplettübersicht (Prozess-Tabelle unten) nvidia-smi --query-compute-apps=pid,used_memory,process_name --format=csv # nur Compute-Prozesse + MiB nvidia-smi --query-gpu=memory.used,memory.free --format=csv,noheader # gesamt belegt/frei ps -p 4057062 -o pid,ppid,cmd # PID -> volles Kommando ps -eo pid,ppid,cmd | grep -E 'vllm|EngineCore' | grep -v grep # alle vLLM-Prozesse

Beenden

kill 4057062 # sanft (SIGTERM); wenn's nach ein paar Sekunden noch lebt: kill -9 4057062 # hart (SIGKILL) Alles auf einmal freiräumen (zuverlässigste Methode): for p in $(nvidia-smi --query-compute-apps=pid --format=csv,noheader); do kill -9 "$p"; done

Die Stolperfalle (genau unser CosyVoice3-Fall)

vLLM startet mehrere Prozesse: APIServer (lauscht am Port) + EngineCore (hält den VRAM); bei vLLM-Omni zusätzlich StageEngineCoreProc pro Stage.

fuser -k oder das Killen des APIServers tötet den EngineCore NICHT → er bleibt als Waise und hält den VRAM weiter. Deshalb scheiterten meine ersten Kill-Versuche.
Sichere Ergänzung: fuser -k 8084/tcp # tötet den API-Server am Port pkill -9 -f EngineCore # killt die VRAM-haltenden Kinder pkill -9 -f StageEngine # zusätzlich bei vLLM-Omni ⚠️ pkill -f "vllm serve" ist bequem, kann aber die eigene Shell/grep mittreffen — PID oder die for-Schleife sind sicherer.

Den Diktier-Stack sauber stoppen

Der Supervisor serve_inference_asr.sh hat einen Trap → ein einziges SIGTERM fährt beide Modelle geordnet runter: pgrep -af serve_inference_asr.sh # Supervisor-PID finden kill # stoppt Inferenz + ASR zusammen

Immer verifizieren

sleep 3; nvidia-smi --query-gpu=memory.used --format=csv,noheader → Im Leerlauf ~69 MiB. Steht noch etwas drin → übrig gebliebener EngineCore/StageEngine; dann die for-Schleife (Punkt 2) bzw. pkill -9 -f EngineCore nochmal.

Merksatz: Den VRAM hält der EngineCore (bzw. StageEngineCoreProc), nicht der API-Server — über den Port allein wirst du ihn nicht los. Und /sleep gibt nur fast alles frei (Residue bleibt); wirklich 0 wird es erst, wenn der Prozess beendet ist.

Ich möchte die Sprachqualität von VoxCPM2 evaluieren, indem ich Open WebUI vorlesen lasse. Ich habe auf OpenAI gestellt und http://10.0.2.2:8084/v1 angegeben. Was muss ich in den Feldern TTS-Stimme und TTS-Modell eintragen? Und muss ich etwas bei Weitere Parameter eintragen?

Ich habe in Open WebUI die Parameter eingetragen und sie sind wirksam (das voreingestellte, sehr schlechte TTS-Modell wird nicht mehr benutzt). Dann habe ich ein Inference-Lauf gemacht, um im Chat-Fenster Text zu haben. Anschließend VRAM frei gemacht.

Ich habe im Terminal single-model_serve_tts.sh gestartet und gesehen, dass es normal hochfährt. Dann habe ich in Open WebUI auf Vorlesen geklickt, was anders als zuvor zu einer kurzen Pause führte (Punkte anstelle des Buttons für Warten), anschließend sah ich im Terminal Requests und im Open WebUI sah es aus, als würde vorgelesen werden - aber im Headset habe ich nichts gehört. Vor diesem Test hatte ich im Headset das voreingestellte, sehr schlechte TTS-Modell gehört.

Was tun?

Mit {"response_format": "mp3"} getestet, jetzt höre ich Ton. In Open WebUI ist für TTS Antwortaufteilung Punktuation eingestellt, für jeden Satz wird ein Request ans TTS gesendet.

Ich habe jeden neuen Satz mit einer anderen Stimme gehört. Sicherlich liegt das an der Open WebUI Einstellung default im Feld TTS-Stimme. Bitte zeige mir, welche Stimmen ich dort eintragen kann, damit ich eine Stimme fest einstellen kann.

Lästig: Für die Tests musste ich viele zeitraubende Schritte manuell ausführen:

VRAM frei machen.
Inference-Modell starten und auf Bereitschaft warten.
Open WebUI Chat durchführen.
Inference-Modell stoppen, um VRAM frei machen.
Als Benutzer aus Open WebUI ausloggen.
Als Admin die Open WebUI Einstellungen ändern.
TTS-Modell starten und auf Bereitschaft warten.
Als Benutzer in Open WebUI einloggen (ohne aus- und einloggen wurden die Admin-Änderungen nicht wirksam).
Vorlesen lassen. Hast du Tipps, wie ich das beschleunigen kann?

Nein.

Und ich bezweifle, dass die beiden Namen, die dir VoxCPM2 auf deinen Request gegeben hat, die Namen sind, die es kennt. Ich habe mindestens sechs verschiedene, alle einwandfrei deutsch sprechende Stimmen gehört.

Bitte spawne einen Opus Subagent, der einen Deep Research durchführt um herauszufinden, wie man welche bereits vorhandenen Stimmen wählen kann.

Strg+Umschalt+R hat die Modellwechsel- und Re-Login Problematik gelöst.

Nach eintragen von de_ref bei TTS-Stimme hörte ich eine vorher noch nicht gehörte Stimme - leider die unatraktivste von allen bisher gehörten Stimmen.

Bestätigt den Deep Research Outcome.

Zu deinem Tipp, um eine schöne Stimme zu „fangen": Das vorlesen lassen ist leicht, aber wie ich das als als WAV abspeichern lassen kann, um später die beste Stimme zu nehmen, ist mir noch nicht klar geworden. Du schriebst, das ist auf meiner Box nicht konfiguriert. Also bitte Prozess genauer erklären, damit ich es verstehe und ggf. auf meiner Box konfigurieren, bitte.

cand_4.wav möchte ich, bitte konfiguriere das soweit es dir möglich ist. Anstatt einer Hobby-Namensgebung wie "meine_stimme" bitte "de_m_schnell.wav" verwenden (für deutsch, männlich, schnell).

Leider ist de_m_schnell.wav eine ganz andere Stimme. Kannst du erreichen, dass die cand_4.wav-Stimme verwendet wird?

Das hat funktioniert, ist aber wieder ein Quick-and-Dirty Fix.

Es ist nicht gewünscht, bei jedem Satz die Referenz neu einzulesen und die Stimme jedesmal neu zu bauen.

Nimm doch einfach die WAV Dateien ORIGINAL_cand_4.wav und A_inline.wav, mach daraus eine WAV Datei und lasse daraus ein Profil generieren, was dann fest benutzt wird.

Open WebUI Vorlesen mit der gewünschten Stimme funktioniert: Das TTS-Modell ist ausgewählt, mit Stimm-Profil versehen, evaluiert und für gut befunden.

Bitte die Prozesse beenden, die das VRAM belegen. Ich starte dann später den Diktier-Stack mit serve_inference_asr.sh.

Unser Context Window ist schon sehr voll: Es wird so langsam Zeit, die Session zu beenden.

Als anderer User in einer anderen Claude Code Session werde ich LLMux implementieren. Bitte erstelle auf Englisch ein detailliertes Dokument mit den Ideen und Annahmen dieser Session zu LLMux. Das soll kein plan.md sein, nach dem Claude Code dann baut; es soll auch kein Requirements Specification Dokument sein, sondern dient nur dazu, den LLMux Kontext dieser Session in die neue Session zu übertragen.

Ich reviewe dann das Dokument, erst anschließend committen.

Nach beginnen des Reviews fiel mir schnell auf, dass ich dir mehr Kontext für die Aufgabe mitgeben muss.

Testumgebung

Wir sind hier in einer Testumgebung, in der wir ermitteln, was für Möglichkeiten und Grenzen es bei bestimmten Spezialgebieten gibt, wobei auch hier keine Basteleien ausprobiert und Quick-and-Dirty Fixes erstellt werden sollen, sondern professionelle Teil-Lösungen. Die aus den Tests gewonnen Erkenntnisse und auch die dabei gefundenen Ideen sollen in die Produktentwicklung einfließen können - ob sie tatsächlich berücksichtigt werden, wird nicht hier entschieden.

Labortester

Nimm die Position eines Labortesters ein, der wichtige Erkenntnisse präzise und ohne Vereinfachungen dokumentiert. Dabei darfst du keine Anweisungen erteilen oder etwas anders darstellen, als es tatsächlich ist.

Verbesserungswürdig im Context Transfer Dokument

the authoritative design/requirements live in ist nicht gut: Du legst nicht fest, was authoritative design/requirements sind. Hier in der Testumgebung liegen keine authoritative design/requirements für das Produktdesign.
LLMux ... keeps exactly one heavy model awake and the rest asleep/stopped ist nicht präzise genug: Meist werden Inference + ASR wach sein. Falsch ist es nicht (Inference ist das heavy model), aber ohne Wissen, dass neben einem heavy model noch ein ASR gewünscht ist, könnte diese Zweier-Kombination falsch eingeordnet werden.
between a WebUI (Open WebUI) and impliziert, dass das WebUI Tool Open WebUI sein wird - ich hatte geschrieben, dass es wahrscheinlich Open WebUI sein wird, aber das steht noch nicht fest.
Grund für llama.cpp ist außer Qwen3.6-27B auch Gemma-4-12B und gpt-oss-20b.

Bitte überarbeite das Dokument. Beziehe dich allgemein auf ein Web UI tool, nicht fest auf Open WebUI.

This friction is the stated motivation for an automated, VRAM-aware mediator. stimmt nicht; das hattest du nur angenommen - bitte entfernen. LLMux löst allerdings auch die in §9 geschilderte Test-Problematik, das als Bemerkung dazu schreiben. Die tatsächliche Motivation ist, dass die Modelle über das Web UI Tool gewählt werden sollen und dass die möglichst schnelle Umschaltung zwischen Inference + ASR und TTS im Voice-Mode (also nicht diktieren, sondern Sprach-Chat) ermöglicht wird.

Das bitte noch ändern.

Alles OK, bitte committen.

User try auf DesTEngSsv006 Claude Code Session zu Qwen3.5-9B, ASR, TTS und vLLM, vLLM-Omni AI Framework beendet.

Resume this session with: claude --resume 3e2858f9-c647-4df3-b216-215074b33743

Embedding model athrael-soju/colqwen3.5-4.5B-v3

Preparation

Please study /home/try/python/docs/details.md first.

Motivation

Among four AI models the embedding model did not work well. In the meantime another embedding model was released which outperforms the problematic one in benchmarks: athrael-soju/colqwen3.5-4.5B-v3. This new model shall be used and needs to be brought to operation with vLLM including sleep mode.

Your tasks

Create a backup of the old embedding model startup script /home/try/python/scripts/single-model_serve_embedding.sh.

Then replace the model in the embedding model startup script by athrael-soju/colqwen3.5-4.5B-v3.

Execute the startup script and test the functionality:

Does the model start OK?
Does the model generate the expected embedding multi-vectors?
Can the vLLM process be send to sleep mode?
Can the vLLM process wake up again?
Does the model generate the expected embedding multi-vectors after sleep and wake-up? If the functionality is completely fine, your tasks are already completed here (the other three AI models were tested before and work well in the existing frameworks).

If not, find a way to provide full functionality. If you have to fix or update vLLM do so but before and afterwards test the functionality of all four AI models.

All your tasks are done when all four AI models work well after your fix or update.

Ask before starting

Use your AskUserQuestions tool now to interview me until you completely understand the situation and your tasks.

Claude Code succeeded:

  Summary

  Task complete. The new embedding model athrael-soju/colqwen3.5-4.5B-v3 is fully operational on vLLM with sleep mode.

  What I did

  1. Backed up the old script → scripts/single-model_serve_embedding.sh.bak-tomoro-colqwen3 (on disk; prior version also in git history).
  2. Swapped the model in single-model_serve_embedding.sh to athrael-soju/colqwen3.5-4.5B-v3 (arch ColQwen3_5, bf16, multi-vector dim 320 — registered in base vLLM 0.22.1).
  3. Hit the documented "multi-vector serialization bug" and root-caused it.

  Root cause (not the sm_120/cu130 stack)

  The vLLM-Omni plugin auto-loads for every vllm serve and monkey-patches EngineCoreOutput.pooling_output from torch.Tensor | None → dict[str, torch.Tensor] | None (omni needs the dict form for its
  TTS/diffusion stages). Standard pooling emits a plain tensor, so the EngineCore→APIServer msgpack IPC rejects it (Expected object|null, got array at $[1][0][4]) and the engine dies. msgspec forbids
  widening a custom-type union, so the field can't just be re-typed.

  Fix (isolated, patch-only — no vLLM upgrade needed)

  The embedder isn't an omni model, so I stop loading the omni plugin for just this script via VLLM_PLUGINS="lora_filesystem_resolver,lora_hf_hub_resolver" (allow-list keeping the base resolvers, dropping
  omni). Base EngineCoreOutput is used and token_embed serializes correctly. No library edits, no stack change; the other models' scripts are untouched.

  Verification

  ┌────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │         Model          │                                                                            Result                                                                            │
  ├────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Embedding (colqwen3.5) │ start ✓ → token_embed (seq×320, L2-norm 1.0) ✓ → sleep (VRAM 12678→390 MiB, is_sleeping) ✓ → wake ✓ → token_embed numerically identical (max-abs-diff 0.0) ✓ │
  ├────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Inference (Qwen3.5-9B) │ chat + reasoning correct (42), reasoning field present ✓                                                                                                     │
  ├────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ ASR (whisper-turbo)    │ German transcription correct ✓                                                                                                                               │
  ├────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ TTS (VoxCPM2/omni)     │ not re-cycled — provably unaffected (isolated env var, TTS script untouched, no shared-lib change)                                                           │
  └────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  Since I did not modify vLLM (debug instrumentation fully reverted — site-packages verified CLEAN), the "test all four after a vLLM update" clause didn't trigger; I still re-smoke-tested the two I had
  stopped.

  Committed as 2fd21cc (script + docs/details.md §14). Current box state: inference (8081) + ASR (8083) running as before; embedding is verified and startable anytime via its script.

Resume this session with: claude --resume 054d2ae3-7bb6-446d-9670-247a510817b0

More tolerant inference model DavidAU/Qwen3.6-27B-Heretic-Uncensored-FINETUNE-NEO-CODE-Di-IMatrix-MAX-GGUF

Preparation

Please study /home/try/python/docs/details.md and Qwen3p6-27B_Llama-Cpp-Python_Unsloth-IQ4_XS_operations.md section 2.2 first.

Motivation

Similar to the startup scripts for vLLM and vLLM-Omni, a startup script is needed which starts the AI model DavidAU/Qwen3.6-27B-Heretic-Uncensored-FINETUNE-NEO-CODE-Di-IMatrix-MAX-GGUF with llama.cpp because only the IQ4_XS format fits into the VRAM and IQ4_XS does not work with vLLM.

Your tasks

Stop the running GPU AI-model processes. Create a model startup script for DavidAU/Qwen3.6-27B-Heretic-Uncensored-FINETUNE-NEO-CODE-Di-IMatrix-MAX-GGUF which uses the maximum possible context window size and provides the service at port 8081 as the other inference models. Execute the startup script and verify that the AI-model is working well by testing it's inference.

If the model does not work well or a larger context window would be possible, improve the startup script.

Your tasks are done when inference works well and the maximum possible context window size is used.

Ask before starting

Use your AskUserQuestions tool now to interview me until you completely understand the situation and your tasks.

Claude Code succeeded:

Stopped all GPU processes — terminated the running vLLM serve_inference_asr.sh group (inference + ASR EngineCores), freeing the full 16 GB GPU and port 8081.

Downloaded the model — Qwen3.6-27B-NEO-CODE-HERE-2T-OT-IQ4_XS.gguf (14.34 GiB) into models/. The Hugging Face Xet transfer path crawled at ~70 KiB/s; setting HF_HUB_DISABLE_XET=1 switched it to plain HTTP at ~30 MiB/s (~8 min instead of ~58 h).

Created the startup script — scripts/single-model_serve_inference_heretic.sh (the llama-cpp-python sibling of the vLLM single-model_serve_*.sh family), serving on 127.0.0.1:8081 (loopback only), model id qwen3.6-27b-heretic, Q8_0 KV + flash-attention. N_CTX and PORT are overridable args.

Verified inference — correct outputs (17×23=391, 144/12+7=19, valid Fibonacci code + bash one-liner), ~44 tok/s decode, survives long prompts and back-to-back requests, usage tokens reported.

Maximum context: 28,672 (tuned live)

The interesting part — this model OOM-crashes at inference time, not at load:

The fixed cost is GPU weights 14,029 MiB + SSM state 150 MiB, against ~15,863 MiB of CUDA-usable VRAM (the driver reserves the rest of the 16,303).
24K loaded fine but died on the first decode when the ~100 MiB cuBLAS workspace allocated. 20K was the safe ceiling at the default n_batch=512.
Lever found: the prefill compute buffer is ~495 MiB at n_batch=512. Dropping --n_batch/--n_ubatch to 256 halves it (~252 MiB), freeing ~245 MiB for KV → 28,672 runs stably (peak-under-load 15,795 MiB, ~68 MiB headroom). 30,720+ is too tight, 32,768 OOMs. The smaller batch only slows prefill; decode throughput is unchanged.

The server is currently running on port 8081. Start/stop it with: bash scripts/single-model_serve_inference_heretic.sh # defaults: 28672 ctx, port 8081 fuser -k 8081/tcp # stop

You wrote "usage tokens reported" and the context window size is now much larger than with the previous Qwen3.6-27B model (now 28,672, was just 8192). Why is it so much better now? In the previous Qwen3.6-27B you found that the AI framework does not support "usage tokens reported" and does not support providing the thinking stream. At least "usage tokens reported" seems to work now - what about the thinking stream? I tried the model using Open WebUI and I do not see a thinking process, answer is coming more or less immediately.

So if I understood you correctly:

The script can enable the desired thinking by dropping --chat_format and enabling chat_template_kwargs. Currently the script operates the AI model without thinking, which significantly reduces intelligence. This is not acceptable.
If the script would enable thinking, the llama-cpp-python is not capable to handle the model output correctly so the AI model intelligence would be high but the thinking content cannot be seen in Open WebUI.
A small proxy between Open WebUI and llama-cpp-python could parse the llama-cpp-python output so that it would become usable for Open WebUI.

If I got it right, then try to fix it in this order:

Update llama-cpp-python.
Deep research to find out whether re-configuring or updating Open WebUI could fix the problem.
Build the proxy.

No, we are in a test environment just studying things.

llama-cpp-python is a python wrapper around llama-cpp, correct? Does llama-cpp cause the problems (loosing the thinking tag, not providing used tokens) or is the python wrapper the culprit? If the python wrapper causes the problem, why don't we use llama-cpp without python?

Great! Since the current llama-cpp-python setup does not deliver the desired behavior without the proxy, please stop it and stop also the proxy. Then build the llama-cpp setup and run it with DavidAU/Qwen3.6-27B-Heretic-Uncensored-FINETUNE-NEO-CODE-Di-IMatrix-MAX-GGUF so that I can test it. Maybe it does not make sense to build it here in the python environment. Should we setup another environment for C++?

I tested it, works well. You wrote "~220 MiB headroom — more than the python build" - can you please adjust the context window size to the maximum possible size?

"Q8_0 KV / ubatch 256 / prefill" - please explain the dependencies and impacts in an easy-to-understand fashion. And why do we use Q8_0 KV, isn't it reducing intelligence significantly when using 8-bit quantization for KV?

Please estimate the impact of --ubatch-size on total duration split in prefill and decode with a real-world example and real numbers. Do it for sizes of 512, 256, 128, 64 and 32.

Claude Code did even measure it; result: 256 in the config is the sweet spot.

Resume this session with: claude --resume a801b557-d0c6-4c17-9fdc-a8cb5aa48aa2

42 KiB Raw Permalink Blame History Unescape Escape

LLMux

Single AI-model scripts

Motivation

References

Your tasks

Ask before you start to implement

Generate shell scripts

Zu 1)

Zu 2)

Zu 3)

Zu 4)

Zu 5)

Shell Skripte

Zu Qwen3.6-27B

Zu Gemma-4-12B

Zu gpt-oss-20b

Diskussion

Zu 1.

Zu 3.

Zu 2.

Zu 4.

Zu 1.:

Zu 2.:

Zu 3.:

Zu 4.:

Testumgebung

Labortester

Verbesserungswürdig im Context Transfer Dokument

Embedding model athrael-soju/colqwen3.5-4.5B-v3

Preparation

Motivation

Your tasks

Ask before starting

More tolerant inference model DavidAU/Qwen3.6-27B-Heretic-Uncensored-FINETUNE-NEO-CODE-Di-IMatrix-MAX-GGUF

Preparation

Motivation

Your tasks

Ask before starting

42 KiB

Raw Permalink Blame History