Knowledge tree
Offensive Security
Shells
File Transfer
Web Applications
Deployment Models
The main question when comparing AI deployments is straightforward: where does the model run, and which parts do I manage?
| Option | Example | What you manage |
|---|---|---|
| SaaS | ChatGPT or Claude | You use the application; the provider manages the model, runtime, and infrastructure |
| Hosted API | Direct API from OpenAI, Anthropic, or another provider | You build the application; the provider serves the model |
| Cloud API | Azure AI Foundry or Amazon Bedrock | You build the application and configure cloud resources; the platform manages inference |
| Gateway | OpenRouter or an internal gateway | Your application talks to a layer that routes to models or providers |
| Self-hosted | vLLM on your infrastructure | You manage runtime, model, capacity, and infrastructure |
| Local | LM Studio on a PC | You manage the model and runtime directly on your hardware |
SaaS
With a SaaS product, the provider delivers the finished application. The user works through the features exposed by the product and does not need to build a client or operate an inference server.
This is the most direct way to use a model, but it gives less control over how each request is assembled, which exact version runs, or which tools belong to the product.
Hosted APIs
With a direct API, the application and its state are yours. The provider loads the model, maintains the runtime, and operates the hardware.
An API delivered through a cloud platform adds that platform’s resources, identity, quotas, and regional options. It may expose familiar models, but features and pricing should not be assumed to match the provider’s direct API.
In both cases, your code selects context, handles the response, and performs external actions. Model APIs covers that integration.
Gateways
A gateway sits between an application and one or more providers. It can centralize credentials, logging, limits, or routing. OpenRouter is one example of a service that presents one API in front of different models; an organization can also operate its own gateway.
A common interface reduces client changes, but it does not make models identical. Tools, reasoning controls, parameters, and usage can still differ.
Self-hosted and local
With self-hosted inference, you operate the runtime and infrastructure. This gives control over the model and its configuration, while making capacity, upgrades, memory, concurrency, and availability your responsibility.
Local inference applies the same idea to a nearby host, usually a workstation or laptop. LM Studio or llama.cpp can load the model and expose an API for another application. Local Inference has more depth because quantization, context, and offload materially change the result.
Choosing an option
No path is best for every use case. The choice depends on how much control is needed, how much operational work is acceptable, where data may travel, and what the real usage costs.
The options can also be combined. A team may use SaaS for general work, a hosted API for an application, and a local model for testing. There is no need to turn that combination into a larger architecture until a concrete requirement appears.