What is vendor lock-in?
Vendor lock-in is a state of dependency on one supplier so deep that switching to a competitor, or bringing a capability in-house, carries a high enough cost in money, time, or risk that it doesn't happen even when a better or cheaper alternative exists. The lock-in isn't the dependency itself; it's the cost of getting out of it.
How lock-in forms
Lock-in usually builds up gradually rather than through one decision. A team adopts a vendor's API, then writes application code that assumes that API's specific request format and response behavior, then stores data in that vendor's proprietary format, then trains staff on that vendor's tooling. None of these individually feels like a binding commitment, but together they raise the switching cost to the point where evaluating a competitor honestly requires budgeting for a migration project, not just a price comparison.
Where it shows up in AI infrastructure
Three common sources of lock-in appear in AI stacks. Proprietary model APIs: an application tuned around one provider's specific model behavior may need substantial re-testing to switch, since a different model can respond differently to the same prompts even for similar tasks. Proprietary data formats: embeddings, fine-tuning data, or logs stored in a vendor-specific format require conversion work to move elsewhere. And pricing dependency: a provider that changes rates or usage limits after an application is deeply built around it leaves the customer with little leverage to negotiate or leave quickly.
Lock-in isn't inherently bad
Depending on a vendor isn't a mistake by itself, every infrastructure choice creates some dependency, and switching costs are sometimes worth paying for the convenience or capability a vendor provides. The relevant question is whether the dependency was chosen deliberately, with the switching cost understood, versus accumulated without anyone noticing how expensive leaving became. Standard formats, open interfaces, and clear data portability reduce the cost of leaving without necessarily requiring you to leave.
Where GPUwerk fits
Running an open-weight model on self-hosted infrastructure keeps the model itself, an artifact you can copy and run elsewhere, decoupled from the hardware provider running it. GPUwerk's Spark nodes run standard containers and don't require adopting a proprietary API or data format to use them, so moving a workload to different hardware later is a matter of redeploying the same containers, not rewriting an integration. That doesn't remove every form of dependency (you still depend on the hardware being available), but it avoids tying application logic to a provider-specific API surface.