Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Wenn man günstige Modelle wie DeepSeek Chat, GPT-4o-mini oder Gemini 2.5 Flash nutzt, lassen sich die API-Kosten definitiv senken. Das Problem ist jedoch, dass selbst bei geringem Traffic die Antwortzeiten von 10 auf bis zu 60 Sekunden ansteigen können. Tritt eine solche Verzögerung in einer herkömmlichen synchronen HTTP-Anfragestruktur auf, werden die Server-Worker-Prozesse durch die Wartezeit blockiert und reagieren nicht mehr, während das Frontend mit einem Timeout-Fehler abstürzt.
Für Alleinentwickler, die Side-Projects umsetzen, oder bei einem knappen Budget ist ein gelähmter Server fatal. Dennoch kann man nicht einfach zu teuren Modellen zurückkehren. Stattdessen muss man eine asynkrene Entkopplungsarchitektur aufbauen, die die direkte synchrone Verbindung zwischen Client und LLM trennt und die fehleranfällige Ausgabe des Modells sicher an das Frontend überträgt.
Der Webserver darf nicht direkt darauf warten, dass das LLM die Inferenz abschließt. FastAPI sollte als API-Gateway fungieren, während ein Redis-Message-Broker und Celery-Distributed-Worker kombiniert werden, um die Annahme von Anfragen und die eigentlichen Inferenzberechnungen vollständig voneinander zu trennen. Sendet ein Nutzer eine Anfrage, gibt der Server sofort nur die Job-ID zurück und trennt die Verbindung.
Läuft Celery mit den Standardeinstellungen, gehen Aufgaben verloren oder werden doppelt ausgeführt, falls ein Worker abstürzt. Um die durch die Besonderheiten der LLM-Inferenz verlängerten Bearbeitungszeiten abzufangen, muss visibility_timeout auf 3600 Sekunden erhöht und task_acks_late = True gesetzt werden, damit eine Empfangsbestätigung erst nach ordnungsgemäßem Abschluss des Jobs gesendet wird. Zudem ist es unerlässlich, worker_prefetch_multiplier = 1 zu konfigurieren, damit ein einzelner Worker nicht mehrere schwere Aufgaben gleichzeitig an sich zieht und Engpässe verursacht.
