Title: Discussion 15 — Vendor Longevity Risk in Build-vs-Buy
Course: AIINFRA 302: AI Security, Guardrails & Governance > Section: Week 15 — Autoscaling Economics, Spot Instances, and Build-vs-Buy

💬 Discussion 15 — Vendor Longevity Risk in Build-vs-Buy (20 pts)

Hugging Face's Text Generation Inference (TGI) entered maintenance mode in December 2025, with Hugging Face itself recommending affected teams migrate to vLLM or SGLang. Any team that had already built its self-hosted inference stack around TGI was handed a migration project it didn't plan for and didn't budget. Prompt: Given that a tool's maintenance status can change out from under a team with little warning, how should a team weigh vendor/tool longevity risk into a build-vs-buy inference decision? Consider in your response:

- What signals (project governance, funding model, community activity, corporate backing) might have hinted at TGI's risk before December 2025?
- Does this kind of risk push teams toward managed APIs, toward more "boring"/widely-adopted self-hosted tools, or toward some other mitigation (e.g., abstraction layers that make swapping inference engines cheaper)?
- Is vendor longevity risk different for open-source infrastructure tools (like TGI, vLLM, SGLang) than it is for closed managed APIs? Why or why not?

Post your initial response (150+ words), then respond to at least two classmates — ideally engaging with a viewpoint or mitigation strategy different from your own.