Senior AI/ML Engineer — KI/ML-Ingenieur Interviewfragen

Erkläre KV-Caching und Quantisierung bei LLM-Inferenz — warum sind sie wichtig?

KV-Caching speichert die für vorherige Tokens berechneten Key- und Value-Vektoren, sodass die Generierung jedes neuen Tokens nur Attention für dieses eine neue Token benötigt, statt die gesamte Sequenz neu zu berechnen — ohne das wäre autoregressive Generierung quadratisch langsamer. Quantisierung reduziert die Präzision der Gewichte (etwa von FP16 zu INT8 oder INT4), um den Speicherbedarf zu senken und den Durchsatz zu steigern, wobei ein kleiner, meist akzeptabler Genauigkeitsverlust gegen eine deutliche Senkung der Serving-Kosten getauscht wird. Beides zusammen macht das Servieren eines 70-Milliarden-Parameter-Modells überhaupt erst wirtschaftlich sinnvoll.

Was ist RLHF, und welches Problem löst es eigentlich?

RLHF (Reinforcement Learning from Human Feedback) nimmt ein Modell, das bereits darauf trainiert ist, das nächste Token vorherzusagen, und tunt es weiter, damit es Ausgaben liefert, die Menschen tatsächlich bevorzugen — typischerweise indem ein Reward-Modell auf menschlichen Vergleichen von Ausgaben trainiert und dieses Reward-Modell dann genutzt wird, um die Policy mit einem Algorithmus wie PPO zu fine-tunen. Es schließt die Lücke zwischen „sagt plausiblen Text voraus" und „ist hilfreich, ehrlich und folgt Anweisungen" — worauf reine Next-Token-Vorhersage überhaupt nicht optimiert. Neuere Ansätze wie DPO erzielen ähnliche Ergebnisse ohne separates Reward-Modell und RL-Loop, weshalb Teams die klassische RLHF-Pipeline zunehmend überspringen.

Worin unterscheiden sich Data-, Model- und Pipeline-Parallelism, und wie entscheidet man sich zwischen ihnen?

Data Parallelism repliziert das gesamte Modell über mehrere Geräte und teilt den Batch auf, was einfach ist, aber verlangt, dass das gesamte Modell auf ein Gerät passt. Model Parallelism teilt das Modell selbst über Geräte auf, wenn es zu groß für eines ist — Tensor Parallelism teilt einzelne Schichten, Pipeline Parallelism teilt das Modell in nacheinander verarbeitete Stufen. In der Praxis nutzt das Training eines großen Modells alle drei gleichzeitig, und das eigentliche technische Problem ist, den Kommunikationsoverhead zwischen den Geräten zu minimieren — der ist es, der den Durchsatz tatsächlich begrenzt.

Wie entscheidest du, ob du auf eine Foundation-Model-API aufbaust, ein offenes Modell fine-tunst oder von Grund auf trainierst?

Training von Grund auf ist außerhalb einer Handvoll gut finanzierter Labore fast nie gerechtfertigt — Daten- und Rechenkosten sind enorm, und die erreichbare Basisfähigkeit ist schlechter als das, was bereits existiert. Die eigentliche Entscheidung ist API versus selbst gehostetes offenes Modell: Eine API lässt sich schneller ausliefern und erfordert keine eigene Infrastruktur, aber die Kosten skalieren linear mit der Nutzung, und man hängt von der Verfügbarkeit und den Rate-Limits eines anderen ab; ein selbst gehostetes, fine-getuntes Modell verursacht anfängliche Engineering-Kosten, gibt einem dafür aber Datenkontrolle, planbare Unit-Economics bei Skalierung und Unabhängigkeit von Richtlinienänderungen eines externen Anbieters. Datensensibilität und -volumen entscheiden diese Frage meist schneller als reine Kostenmodellierung.

Wie entscheidest du zwischen Fine-Tuning, Retrieval-Augmented Generation (RAG) und reinem Prompt Engineering?

Fang mit Prompting an — es lässt sich am günstigsten iterieren und bringt dich bei Aufgaben, die nur bessere Anweisungen oder Beispiele brauchen, oft schon 80% ans Ziel. Greif zu RAG, wenn das Modell Fakten braucht, auf die es nicht trainiert wurde oder die sich häufig ändern, denn Retrieval hält das Wissen aktuell, ohne neu zu trainieren, und erlaubt Quellenangaben. Fine-Tuning ist dafür da, einen konsistenten Stil, ein Format oder eine spezialisierte Fähigkeit beizubringen, bei der das Basismodell auch mit gutem Prompt und Kontext danebenliegt — und es ist am teuersten in der Iteration, weil jede Änderung einen neuen Trainingslauf und Eval-Durchgang bedeutet. Die meisten Produktionssysteme kombinieren am Ende RAG für Fakten mit einem leicht feingetunten Modell für Ton und Format, statt sich auf eines zu beschränken.