TrueFoundry: ML-Plattform mit eingebautem LLM-Gateway

Was ist TrueFoundry?

TrueFoundry (truefoundry.com) ist eine proprietäre ML-Platform mit Sitz in Bangalore und San Francisco, die seit 2022 am Markt ist. Das Produkt war ursprünglich auf Model-Serving und Inferenz fokussiert (vergleichbar mit Anyscale, Modal Labs oder Determined AI); seit 2024 wurde ein dediziertes LLM-Gateway-Modul integriert, das parallel zur Modell-Inferenz funktioniert. Stand Mai 2026 ist TrueFoundry damit in zwei Kategorien aktiv: ML-Platform für Self-Hosted-Modelle und LLM-Gateway für Cloud-Provider.

Das LLM-Gateway in TrueFoundry deckt nach Anbieterangaben rund 1.000 LLMs ab und sitzt vor OpenAI, Anthropic, Mistral, Google Gemini, Azure OpenAI, AWS Bedrock und beliebigen Self-Hosted-Modellen (Llama, Mistral 7B, Phi, Qwen). Der Witz: die gleiche Plattform, die ein selbst trainiertes Modell als Endpoint deployt (mit Docker-Image, GPU-Scheduling, Auto-Scaling), kann es auch hinter dem Gateway-Layer registrieren. Dadurch ist ein Self-Hosted-Modell von aussen nicht von einem Cloud-Modell unterscheidbar – beide sprechen die gleiche OpenAI-kompatible API.

Die Architektur ist Kubernetes-zentrisch. TrueFoundry installiert sich entweder als Managed-Cloud auf TrueFoundrys Infrastruktur (mit BYOC-Option in AWS/GCP/Azure-Account des Kunden) oder als Self-Host-Deployment im eigenen Cluster. Self-Host läuft auf jedem konformen Kubernetes-Cluster (EKS, GKE, AKS, Rancher, k3s); für Production wird min. 3 Nodes empfohlen. Die Lizenz-Kosten beginnen bei rund USD 25.000-50.000/Jahr je nach Volumen und Support-Tier; Pilot-Lizenzen für drei Monate werden auf Anfrage gewährt.

Für fairlane.systems-Mandate ist TrueFoundry interessant, wenn ein Team neben dem reinen LLM-Gateway auch eigene Modelle trainiert oder feinabstimmt – und beide Funktionen aus einer Plattform fahren will. Für reine Gateway-Anwendungen ist TrueFoundry überdimensioniert; LiteLLM oder Portkey decken den Bedarf preiswerter ab.

Warum es für ML-Teams relevant ist

Drei Faktoren erklären die Position. Erstens: eine Plattform für Modell-Lifecycle und LLM-Gateway. Ein Team, das ein eigenes RAG-Modell (z. B. ein feinabgestimmtes Llama 3.3 70B für Treuhand-Terminologie) deployen will, hat in TrueFoundry den vollen Stack: Training-Jobs, GPU-Scheduling, Model-Registry, Inference-Server, Endpoint mit Auto-Scaling. Das Modell wird anschliessend hinter dem internen Gateway registriert und ist von Anwendungs-Seite ein normaler OpenAI-kompatibler Endpoint.

Zweitens: BYOC-Modell. Statt einer separaten Managed-Cloud kann TrueFoundry im AWS/GCP/Azure-Account des Mandanten installiert werden. Das bringt zwei Vorteile: Daten bleiben im Kunden-Cloud-Account (wichtig für Compliance), und die Cloud-Ausgaben laufen über den existierenden Vertrag mit dem Cloud-Provider. Im DACH-Markt mit Microsoft-Azure-Dominanz ist BYOC auf Azure EU eine sinnvolle Konfiguration.

Drittens: GPU-Workload-Management. Für Teams, die GPU-Inferenz selbst hosten – etwa weil sensible Daten nicht an Cloud-Provider dürfen – bringt TrueFoundry Scheduling und Optimierung mit (vLLM-Integration, Modell-Quantisierung, Multi-Tenant-GPU-Sharing). Das ist Standard-Funktionalität im ML-Platform-Bereich, aber in vielen LLM-Gateway-Lösungen fehlt es. Wer also Llama 3.3 70B auf 2x H100 on-premises betreibt und gleichzeitig OpenAI- und Mistral-Cloud-Calls durch das gleiche Gateway leiten will, hat in TrueFoundry eine integrierte Lösung.

Unter CH-DSG ist TrueFoundry positionierbar. Die Self-Host-Variante läuft komplett im Kunden-Datacenter (Hetzner, Bare-Metal, OnPrem), Daten verlassen die eigene Hardware nur in Richtung der konfigurierten Cloud-Upstreams. Die BYOC-Variante in Azure EU oder AWS Frankfurt erfüllt die EU-Daten-Residenz. Die Managed-Cloud (auf TrueFoundrys eigener Infrastruktur in US/IN) ist für CH-Mandate nicht ohne weiteres geeignet – hier braucht es BYOC oder Self-Host.

Wie es funktioniert

Die Installation läuft über ein Helm-Chart auf Kubernetes. Voraussetzung: Cluster mit min. 3 Nodes (8 vCPU, 32 GB RAM pro Node für Production), Postgres oder eine managed-Datenbank, Object-Storage (S3-kompatibel), Container-Registry und idealerweise ein bestehender Ingress-Controller. Die Helm-Werte definieren Cluster-Endpoint, Lizenz-Schlüssel und Provider-Konfiguration. Für eine erste Installation rechnen wir 1-2 Tage Aufwand, Production-Hardening (HA, Backup, Monitoring) weitere 3-5 Tage.

Das Gateway-Modul wird über das TrueFoundry-Dashboard konfiguriert. Provider werden eingetragen (OpenAI, Anthropic, Mistral usw.) mit Master-API-Keys; Modelle werden registriert (gpt-4o, claude-opus-4.7, mistral-large-2411) und mit logischen Aliassen versehen (z. B. eu-secure -> mistral-large-2411 mit Region Frankfurt). Anwendungen sprechen den Gateway-Endpoint via OpenAI-Schema an:

import openai client = openai.OpenAI( api_key="tfy-virtual-key-...", base_url="https://tfy.intern.example/v1" ) resp = client.chat.completions.create(model="eu-secure", messages=[...])

Virtuelle Keys, Token-Budgets, Rate-Limits und Cost-Tracking funktionieren analog zu LiteLLM oder Portkey. Was TrueFoundry zusätzlich bringt: ein Modell, das self-hostet werden soll, wird als TrueFoundry-Deployment angelegt (mit GPU-Anforderung, Auto-Scaling-Policy, Health-Checks) und erscheint anschliessend automatisch im Gateway-Katalog. Die gleiche Anwendung kann also ohne Code-Änderung zwischen Cloud- und Self-Hosted-Modell wechseln.

Observability läuft über das eingebaute Dashboard plus Anbindung an Prometheus, Grafana und externe Tracing-Systeme. Logs gehen in Postgres und Object-Storage; Cost-Reports lassen sich nach Workspace, Anwendung und Modell aufbrechen. Eine Exports-Funktion liefert CSV/JSON für externe BI-Tools.

Für ML-Teams ist zusätzlich der ML-Platform-Teil relevant. Modelle werden in der Registry versioniert, Training-Jobs laufen als Kubernetes-Jobs, Hyperparameter-Sweeps als Workflows. Diese Funktionen sind nicht das Thema dieser Seite – wer keinen ML-Workflow betreibt, nutzt nur den Gateway-Teil und lässt die Plattform-Funktionen ungenutzt.

TrueFoundry-Pilot in 5 Schritten

1. 01Pilot-Lizenz und Kubernetes-Cluster (3 Nodes, Postgres, S3) vorbereiten; Helm-Chart deployen, Lizenz-Schlüssel hinterlegen.
2. 02Provider-Konfiguration: OpenAI/Anthropic/Mistral mit Master-API-Keys, logische Modell-Aliasse (eu-secure, fast-cheap, premium) anlegen.
3. 03Eigenes Modell (falls vorhanden) als Deployment registrieren: Container-Image, GPU-Request, Auto-Scaling-Policy, im Gateway-Katalog publizieren.
4. 04Virtuelle Keys und Token-Budgets pro Workspace/Mandant einrichten; Observability-Hooks für Prometheus und Grafana anbinden.
5. 05Anwendung umstellen: base_url auf Gateway-Endpoint, Modell-Alias verwenden; Tests, Lasttest, dann Production-Cutover.

Wann TrueFoundry passt

Erstens, wenn das Team eigene Modelle trainiert oder feinabstimmt und gleichzeitig Cloud-LLMs nutzt. Das ist der eigentliche Sweet-Spot: eine Plattform für Training, Deployment, Inferenz und Gateway. Beispiel: eine Treuhand-Gruppe will Llama 3.3 70B auf eigene Akten-Daten feinabstimmen (privat, on-prem) und gleichzeitig für generische Recherche-Anfragen Mistral und Claude via Gateway nutzen. TrueFoundry deckt beides ab.

Zweitens, wenn Kubernetes als Standard-Stack steht und ein Plattform-Team die Infrastruktur betreibt. TrueFoundry passt zu Teams, die mit Helm-Charts, Operatoren und kubectl-zentrierten Workflows arbeiten. Wer kein Kubernetes-Wissen hat, hat einen steilen Lern-Hang.

Drittens für BYOC-Setups in Azure EU oder AWS Frankfurt. Wenn der Mandant einen bestehenden Cloud-Account hat und alle Workloads dort bündeln will, ist BYOC die saubere Architektur. TrueFoundry installiert sich im Kunden-VPC, alle Daten bleiben im Kunden-Account.

Viertens bei grösseren ML-Engineering-Teams mit GPU-Workloads. Mehrere GPU-Server, Multi-Tenant-Inferenz, vLLM-basiertes Batching, Modell-Quantisierung – alles eingebaut und über Dashboard steuerbar. Wer mehrere GPUs effizient auslasten will, bekommt hier ein Werkzeug, das LiteLLM nicht ersetzt.

Fünftens, wenn Procurement-Anforderungen an Enterprise-Support stellen. TrueFoundry bietet 24x7-Support und dedizierte Account-Manager im Enterprise-Tier. Für Mandate, die SLA und Eskalations-Pfad wünschen, ist das ein Faktor.

Wann NICHT

Erstens bei reinen Gateway-Anwendungen ohne ML-Workload. Wer nur OpenAI/Anthropic/Mistral hinter einer einheitlichen API will, hat in LiteLLM, Portkey oder Helicone die preiswertere Lösung. TrueFoundry-Lizenz von USD 25k+/Jahr für ein einfaches Gateway lohnt nicht.

Zweitens bei kleinen Setups ohne Kubernetes. TrueFoundry braucht einen produktiven Kubernetes-Cluster mit mindestens 3 Nodes. Für KMU mit einer einzelnen VM und drei Anwendungen ist die Plattform überdimensioniert.

Drittens, wenn das Team kein Plattform-Engineering-Know-how hat. TrueFoundry bietet zwar Onboarding-Support, aber die operative Betreuung eines Kubernetes-Clusters mit Helm-Releases, Postgres-Backup, GPU-Driver-Updates und Multi-Tenant-Sicherheit braucht erfahrene Plattform-Engineers. Wer das nicht im Team hat, sollte auf eine Managed-Cloud-Lösung setzen.

Viertens bei strikten OSS-Anforderungen. TrueFoundry ist proprietär – eine OSS-Variante existiert nicht. Wer Apache-2.0- oder MIT-Komponenten verlangt (öffentliche Hand, einige Universitäten), kombiniert besser LiteLLM (Gateway) plus Langfuse (Observability) plus vLLM/Ollama (Inferenz).

Fünftens, wenn die Plattform-Roadmap unklar ist. TrueFoundry ist ein vergleichsweise junges Unternehmen mit USD 30 Mio. Series-B-Funding (Q4 2025). Wer für 5+ Jahre Investitions-Sicherheit verlangt, sollte etablierte Plattformen wie Databricks oder SageMaker prüfen – oder eine zerlegte OSS-Architektur wählen, die unabhängig vom Anbieter-Schicksal ist.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. TrueFoundry Documentation – LLM Gateway, ML Platform, Inference · 2026-05
2. TrueFoundry Pricing and Enterprise Tier · 2026-04
3. TrueFoundry Series B funding announcement – USD 30M · 2025-11
4. TrueFoundry LLM Gateway – Multi-Provider routing and governance · 2026-03