Das Team will ein offenes Modell fine-tunen statt eine gehostete API aufzurufen. Wie würdest du entscheiden?

Entscheide entlang von vier Achsen: Qualität auf deiner konkreten Aufgabe, Kosten bei deinem tatsächlichen Volumen, Anforderungen an Latenz und Kontrolle, und Daten- oder Compliance-Randbedingungen. Fang mit der gehosteten API plus Prompting und Retrieval an, um billig eine Qualitätslatte zu setzen. Fine-tune, wenn du eine stabile Aufgabe mit guten gelabelten Daten hast, das Volumen hoch genug ist, damit die Ökonomie kippt, oder Daten in der eigenen Umgebung bleiben müssen.

Ich würde darauf drängen, das mit Zahlen zu beantworten statt mit Präferenz. Zuerst die gehostete Baseline bauen: ein guter Prompt, Retrieval, falls die Aufgabe Kontext braucht, und ein Evaluationsset. Das dauert in der Regel Tage und sagt uns, welche Qualität erreichbar ist, und oft ist sie schon gut genug, dann ist Fine-Tuning eine Lösung auf der Suche nach einem Problem. Wenn die Qualität wirklich nicht reicht, frage ich, ob die Lücke Wissen ist, was Retrieval löst, oder Verhalten und Format, was Fine-Tuning löst. Dann die Ökonomie. Gehostete Kosten skalieren linear mit Tokens; Self-Hosting sind überwiegend fixe Kosten für Beschleuniger, es gibt also ein Break-even-Volumen, und ich rechne es mit echten Traffic-Prognosen statt mit Hoffnungen. Unterhalb davon verliert Self-Hosting, bevor du überhaupt die Zeit eines Engineers gezählt hast. Die Kosten, die Leute vergessen, sind der Betrieb: Serving, Autoscaling, Upgrades, neue Evaluation beim Wechsel des Basismodells, jemand in der Rufbereitschaft. Das ist ein dauerhaftes Commitment. Wo es sich von selbst entscheidet, ist Compliance. Wenn die Daten unsere Umgebung nicht verlassen dürfen, ist die Entscheidung gefallen und es geht nur noch darum, welches offene Modell, nicht ob.