Key points
- Model weights need roughly 2 bytes per parameter at 16-bit, 1 at 8-bit and 0.5 at 4-bit, plus room for the context cache.
- A rented GPU bills for every hour it is on, while an API bills only for tokens you send and receive.
- At $0.15 per 1M input and $0.50 per 1M output tokens, 20,000 chats a day of 1,500 in and 500 out cost $285 a month.
- Self-hosting wins when you need fine-tuning, a different model, offline use or a steady, very high volume.
The short answer: it depends on your volume
If you are asking how to host llm weights yourself, the honest summary is that it is easy to get a model answering on your own machine and hard to run one cheaply for other people. A laptop or a desktop GPU is enough for personal use. A service that must answer many users at once, at any hour, needs more memory, more tuning and someone to keep it alive.
The alternative is to call a hosted OpenAI-compatible endpoint and pay per token. For small and medium workloads this is nearly always cheaper, because you never pay for idle GPU time. For very large and steady workloads, or for jobs that need your own fine-tuned model, owning the hardware starts to make sense. The sections below put numbers on both sides so you can find your own break-even point.
There is no free tier here. You can claim a one-time $0.50 trial credit on the API key page after signing up, and after that you add prepaid credit from $20. The trial is enough to run a real test of your own prompts before you decide anything.
What hosting a model actually requires
A language model is a large file of numbers, the weights, that must sit in fast memory while the model runs. The size of that file is the first constraint, and you can compute it yourself: parameters multiplied by bytes per parameter.
| Model size | 16-bit weights | 8-bit weights | 4-bit weights |
|---|---|---|---|
| 8B parameters | 16 GB | 8 GB | 4 GB |
| 32B parameters | 64 GB | 32 GB | 16 GB |
| 70B parameters | 140 GB | 70 GB | 35 GB |
These are weights only. On top of that you need memory for the key-value cache, which grows with the length of every active conversation, and some headroom for the runtime. A model that nominally fits in 24 GB can run out of memory the moment you ask for a long context or several parallel users. Quantising to 4-bit shrinks the file, but it also changes output quality a little, and the effect varies by model.
Then there is the software side. You need an inference server such as llama.cpp, Ollama or vLLM, an HTTP layer so your apps can call it, a way to restart it when it crashes, and monitoring so you notice when it does. None of this is difficult in isolation. All of it takes time, and the time is part of the cost.
Option one: run it on your own computer
The cheapest way to start is the machine you already own. Tools like Ollama and llama.cpp download a model and expose a local server, and many of them also offer an OpenAI-style endpoint, so the code you write against them can later point at a hosted API by changing two settings.
Local hosting is a good fit when:
- you are one person experimenting, and a few seconds per answer is fine;
- the data must never leave the machine;
- you want to try many different open models quickly;
- you have a GPU with enough memory and it is idle most of the day anyway.
It is a weak fit when you need to serve other people, when the model you want is larger than your memory, or when you want long contexts. Our own comparison of local uncensored models and hosted APIs goes through the trade-offs in more detail, including what changes in answer quality between small local models and larger hosted ones.
Electricity is a real but small line item for a single user. The larger cost is the hardware you had to buy, which you pay for whether or not you use it. If you already own it, the marginal cost is low and local hosting is hard to beat for private experiments.
Option two: rent a GPU server
When your own machine is not enough, the next step is a rented GPU. Providers charge by the hour for a machine with a given amount of GPU memory. Prices vary a lot between providers and change often, so check their current pricing instead of trusting any number you read in an article, including this one.
What matters is the shape of the bill. A rented server charges for every hour it is switched on, whether it is answering one request or none. If you leave it on all month, the arithmetic is simple: a month has about 730 hours (8,760 hours in a year divided by 12). Suppose, purely as an assumed example and not a quote, that a suitable server costs $1 per hour. Running it around the clock then costs 730 × $1 = $730 a month before you add storage, bandwidth and your own time.
You can turn the server off when you are not using it, but then you pay with delays: loading a large model into memory takes time, and the first user after a pause waits for it. Autoscaling setups reduce this, and they add their own complexity.
The break-even against an API follows from the price. One million input tokens plus one million output tokens cost $0.15 + $0.50 = $0.65 on this API. Your assumed $730 server equals 730 ÷ 0.65 ≈ 1,123 such pairs, or roughly 1.1 billion input and 1.1 billion output tokens in a month. Below that volume, the API costs less. Above it, a well-utilised server can win, provided it can actually keep up with that traffic, which depends on the model, the GPU and how well you tune the server.
Option three: use a hosted API
The API route removes the hardware, the server and the idle time. You send a request, you get an answer, and you pay for the tokens that were used. Pricing here is $0.15 per 1M input tokens and $0.50 per 1M output tokens, pay as you go from prepaid credit, with no subscription. Credit never expires, and failed or refused requests are not charged.
Here is how that looks at three realistic volumes. A typical chat turn is assumed to use 1,500 input tokens (system prompt plus history) and 500 output tokens.
- One request: 1,500 input tokens cost 0.0015 × $0.15 = $0.000225, and 500 output tokens cost 0.0005 × $0.50 = $0.00025. Together that is $0.000475.
- 1,000 chats a day, 30 days: 1,000 × $0.000475 = $0.475 a day, or $14.25 a month.
- 20,000 chats a day, 30 days: 20,000 × $0.000475 = $9.50 a day, or $285 a month.
- A batch job of 100,000 requests with 2,000 input and 400 output tokens each: input is 200M tokens, so 200 × $0.15 = $30; output is 40M tokens, so 40 × $0.50 = $20. The total is $50.
At the middle figure, the API costs $285 a month, which is well below the assumed $730 for an always-on server. At the largest figure you would need far more traffic before a rented server catches up. Your own prompts decide the real numbers, so measure a sample rather than guessing. The usage block that comes back with every response tells you the exact token counts.
The $0.50 trial credit covers about 1,052 requests of the 1,500 in, 500 out size (0.50 ÷ 0.000475 ≈ 1,052), which is plenty for a test. After that you top up with any whole amount from $20 to $500. Larger top-ups carry a bonus: +5% from $50, +10% from $100 and +15% from $200, so a $100 top-up gives $110 of credit. Details are on the pricing page. Payment is by card (Visa, Mastercard, Apple Pay, Google Pay) or crypto (USDT on TRC20, USDC on Base).
What you give up by not hosting
An API is not free of trade-offs, and it is better to know them before you build on it.
- One model. You get a single open-weight model, addressed as
uncensored. You cannot swap in a different one or load your own weights. - No fine-tuning and text only. There is no training endpoint, no embeddings and no image, audio or video generation.
- Limits. A full key allows 8 concurrent requests and 300 requests per minute. A trial key allows 2 and 60. That fits most apps, but a very large batch needs queuing on your side.
- Context. The window is 100,000 tokens for prompt plus completion.
- Your data leaves your network. Prompts are not used for training, but they do travel to a third party. If that is not acceptable for a given dataset, host locally.
Self-hosting is the better choice when any of these is a hard requirement: fine-tuning on your own data, a specific model the API does not offer, fully offline operation, or a steady volume large enough that owned hardware stays busy around the clock.
Try the API before you buy hardware
A one-hour test costs less than a single hour of most rented servers and tells you whether the model answers your prompts well. The endpoint is OpenAI-compatible, so if you already have code that talks to a local server, you only change the base URL, the key and the model ID. This script also reports what each call cost, using the usage numbers in the response:
from openai import OpenAI
client = OpenAI(
base_url="https://api.uncensoredllmhub.com/v1",
api_key="YOUR_API_KEY",
)
resp = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": "Summarise the pros and cons of self-hosting an LLM."}],
)
u = resp.usage
cost = u.prompt_tokens / 1_000_000 * 0.15 + u.completion_tokens / 1_000_000 * 0.50
print(resp.choices[0].message.content)
print(f"in={u.prompt_tokens} out={u.completion_tokens} cost=${cost:.6f}")
Run it on a few dozen of your real prompts, add up the cost lines, and multiply by your expected daily volume. That gives you a figure you can set beside the hardware quote. If you want the setup details, the documentation lists the supported parameters, including streaming, tool calling and JSON mode.
