LLMs for enterprise use cases: the eleven types, what they cost and where they run

LLMs for enterprise use cases: which of the eleven types do you need?#

Enterprises choose among eleven LLM types: nine kinds of model, from general-purpose to embedding, and two ways to adapt one, fine-tuning and RAG. The nine kinds are general-purpose, open-source, proprietary, small, domain-specific, multimodal, reasoning, code-focused and embedding. The two techniques are fine-tuning and retrieval-augmented generation (RAG). So those two change what a model knows, not which model you run.

The labels overlap, and that is the point. For example, Mistral's model overview, read in September 2026, calls Mistral Large 3 "A state-of-the-art, open-weight, general-purpose multimodal model". So one model can carry three labels at once. In practice, the labels that matter are the ones that change the bill, where the data goes, or whether the answer is good enough.

Three variables settle most choices. First comes the daily token volume, because every API charges per token. Second come the data rules, because some records may not leave your own servers. Then comes the task, since a coding job, a scanned invoice and a clinical question need different strengths. When you know those three, the list of eleven shrinks to two or three.

What does the LLM type you pick do to the monthly bill?#

The same 50M tokens a day costs 450 dollars a month on GPT-6 Luna and 45,000 on GPT-6 Astra, a hundredfold spread set by the tier. The workload is SitePoint's mid-size example of 25M input and 25M output tokens a day. Over a 30-day month, that is 750M tokens each way. Each monthly figure below is that volume times the vendor's own rate, from the OpenAI, Anthropic, Google and Mistral AI price pages of September 2026.

So the tier moves the bill more than the vendor does. Two flagship tiers from two vendors land on the same 45,000 dollars in September 2026. Yet two tiers from one vendor sit a hundred times apart. As a result, the first design question for LLMs for enterprise use cases is which tier the task needs. The vendor question comes after it.

You can check the arithmetic yourself. On GPT-6 Luna, OpenAI charges 0.10 dollars per million input tokens and 0.50 per million output tokens in September 2026. Multiply each rate by the monthly volume each way and add them, and the month comes to 450 dollars. And because Haiku 4.5 costs 1 and 5 dollars per million, the same volume there comes to 4,500.

What do proprietary general-purpose models cost per million tokens?#

OpenAI's September 2026 rate card runs from 0.10 dollars per million input tokens on GPT-6 Luna to 10 dollars on GPT-6 Astra, with output five times input. So within one proprietary general-purpose family, the tiers differ a hundredfold in price per token. The middle tier, GPT-6 Sol, charges 2 dollars in and 10 dollars out.

Output tokens usually decide the bill. A support reply or a drafted report writes far more than it reads. So the output rate matters most for generative work. But a classifier is the reverse case, because it reads a long ticket and writes one label.

The same page lists a code-focused model, gpt-5.3-codex, at 1.75 dollars in and 14 dollars out per million. It also shows the privacy lever on a proprietary API. According to OpenAI's pricing page in September 2026, regional processing endpoints carry a 10% uplift on eligible models released on or after 5 March 2026. In short, you pay a little more to keep processing in a named region. The model itself stays the same.

How do Anthropic's model tiers trade price for speed?#

Anthropic's tiers run from 1 dollar per million input tokens on Haiku 4.5 to 10 dollars on Fable 5.1, and Anthropic ranks them fastest to slower. In short, on Anthropic's September 2026 overview, a proprietary family's cheapest tier is also its fastest. The dearest tier is for demanding reasoning and long agent work.

Anthropic's models overview, read in September 2026, describes each tier in its own words. It calls Haiku 4.5 "The fastest model with near-frontier intelligence". It calls Sonnet 5 "The best combination of speed and intelligence". Then Opus 5.5 is "For long-running agentic coding and knowledge work". Finally, Fable 5.1 is "For demanding reasoning and long-horizon agentic work".

The same page states that "All current models support text and image input". So image reading comes with every tier rather than as an extra. The page also gives a default. It says to start with Opus 5.5 for most workloads, and to move to Fable 5.1 when your own tests at higher effort still fall short.

That is the reasoning type in practice. A reasoning model spends more time and more tokens thinking before it answers. And you pay for that thinking in price and in speed. So the choice inside one family is price against speed and depth. If a chat assistant must answer in a second, it wants the fast tier. But a long agent task that runs for an hour can afford the slow one.

What does a multimodal model add, and what does it cost?#

A multimodal model takes images, audio or video as input, and Google prices Gemini 3.5 Flash-Lite at 0.30 dollars per million input tokens across all four. In short, on Google's September 2026 price page, multimodal input is a standard feature of general models, priced per token like text.

Google's Gemini API pricing page, read in September 2026, lists that 0.30 dollar rate for "text / image / video / audio". It lists 2.50 dollars per million for output. Also, Google's image understanding guide says "Gemini models are built to be multimodal from the ground up". It names image captioning, classification and visual question answering as tasks the models handle.

This matters for two enterprise jobs above all. First, document processing often starts from a scan or a photo, not clean text. Second, an e-commerce catalogue needs product photos read and described at volume. Neither needs a separate vision product now. Instead, the general model reads the image and bills it by the token.

The same Google pricing page also lists an embedding model, Gemini Embedding 2, which it calls "Our first multimodal embedding model". Its text input is charged at 0.20 dollars per million tokens in September 2026. So images and text can share one search index, which the RAG section returns to.

What do open-source LLMs give an enterprise that an API does not?#

Open-weight models such as Llama run on hardware you control, and Meta's context lengths grew from 4K tokens in Llama 2 to 10M in Llama 4 Scout. So open weights move the model inside your own perimeter. And since Llama 4 shipped in April 2025, the open families match proprietary context lengths.

Meta's llama-models README on GitHub, read in September 2026, lists each release with its context length. Llama 3 had 8K tokens in April 2024. Then Llama 3.1 reached 128K in July 2024. Finally, Llama 4 shipped in April 2025 at 1M tokens for Maverick and 10M for Scout.

The privacy case is the simple one. With open weights on your own servers, no prompt and no document leaves your network. Because the vendor never sees the data, its retention policy never applies. That is often the deciding factor for health records, legal files and some financial data.

Capability has closed much of the gap too. A 2025 enterprise benchmark study on arXiv found that "open-source contenders like DeepSeek R1 rival proprietary models in reasoning tasks". The same study adds that they "lag in judgment-based scenarios". However, open weights do not remove the work. You run the servers, the updates and the monitoring, and the self-hosting section prices that work.

Can a small or domain-specific model do the job of a large one?#

Microsoft's phi-3-mini scores 69% on MMLU with 3.8B parameters, small enough to run on a phone, and phi-3-medium reaches 78% at 14B. Small, domain-specific and code-focused models trade breadth for cost and placement, as papers from 2022 to 2024 show.

The Phi-3 technical report on arXiv, from April 2024, puts phi-3-small at 75% on MMLU with 7B parameters. It describes phi-3-mini as "small enough to be deployed on a phone". So a model that size can run inside a device or a private server, and the data never travels.

Domain-specific models trade breadth for depth. For example, BloombergGPT, described on arXiv in 2023, is a 50 billion parameter model. Its authors trained it on a 363 billion token dataset built from Bloomberg's own financial sources. But medicine shows the limit of a score alone. Flan-PaLM reached 67.6% accuracy on MedQA in a 2022 paper on arXiv. Yet the same authors wrote that "human evaluation reveals key gaps in Flan-PaLM responses".

Code-focused models follow the same pattern. Code Llama, released on arXiv in 2023, scored up to 67% on HumanEval among open models. Also, the paper notes that Code Llama Python 7B beats the general Llama 2 70B on that test. In practice, a smaller specialist often beats a larger generalist on its own ground.

Which LLM type fits each enterprise use case?#

Customer support and HR suit small models, document processing needs long context or RAG, software development suits code-focused models, finance and healthcare need domain checks. Each enterprise use case has one deciding constraint, and that constraint names the type.

For document work, the constraint is context length. Anthropic's models overview, read in September 2026, lists 1M tokens of context for Fable 5.1, Opus 5.5 and Sonnet 5, against 200K for Haiku 4.5. So a long contract or a year of reports fits whole in the larger window. Otherwise, a small window needs RAG to feed it the right pages.

Here is how the constraint maps to the type for each common job:

• Customer support: volume decides, so a small or cheap general tier with RAG over your help articles.
• Document processing: context and input format decide, so a multimodal model with a long window, or RAG.
• Software development: task fit decides, so a code-focused model, with a reasoning tier for hard changes.
• Finance: domain accuracy and data rules decide, so a domain model or RAG over approved sources, with review.
• Healthcare: privacy and accuracy decide, so open weights on your own servers or a regional endpoint, with clinical review.
• Manufacturing: placement decides, so a small model near the line for manuals and fault logs.
• HR: privacy and volume decide, so a small model over the policy library, kept inside your network.
• E-commerce: images and volume decide, so a multimodal model for catalogue work and an embedding model for search.
• Business automation: volume decides, so the cheapest tier that passes your test set, with a reasoning tier for the rare hard case.

A 2024 survey on arXiv of LLMs in finance, healthcare and law describes these as "high-stakes" fields. That is why those rows carry a review step. The model drafts the answer, and a qualified person signs it.

When is self-hosting an open-source model the wrong tool?#

SitePoint estimates self-hosting a quantized Llama 4 model at 10,200 to 12,200 dollars a month, so below about 5M tokens a day an API is cheaper. When NOT to use this, on SitePoint's 2026 figures: below the crossover volume, or without MLOps time, self-hosting costs more than a small API tier and the better tool is the API.

SitePoint's 2026 guide builds that estimate from two reserved H100 instances at about 4,200 dollars a month. Then it adds half of one DevOps person's time on top. For the same 50M tokens a day, it puts a commercial API on GPT-4o at about 18,750 dollars a month.

Now set that against the September 2026 list prices from the bill section. GPT-6 Luna runs the same volume for 450 dollars, and Haiku 4.5 for 4,500. So self-hosting wins only against a large tier, at high volume, with staff to run it. SitePoint places the crossover between 10M and 30M tokens a day in 2026.

Three cases call for a different tool. First, a workload under 5M tokens a day belongs on a small API tier, where SitePoint's 2026 guide calls the cost difference marginal. Second, a team with no DevOps or MLOps time should use a managed API. After all, the guide counts 0.5 to 1.0 of a full-time role for upkeep. Finally, a strict data rule at low volume is better served by a regional endpoint than by your own GPUs.

Should you use RAG or fine-tuning, and which pages do you build from?#

Start with RAG from an embedding model's guide, because OpenAI is winding down its fine-tuning platform and LoRA cuts trainable parameters 10,000 times for teams that tune. So RAG with an embedding model is the default way to ground a model in company data. Fine-tuning is the exception, on a narrowing set of platforms, and the LoRA figure comes from its 2021 paper on arXiv.

RAG goes back to a 2020 paper on arXiv by Lewis and colleagues. It set out to "combine pre-trained parametric and non-parametric memory for language generation". In plain words, the model keeps its general skill, and a search step hands it your documents at question time. So when a policy changes, you update the documents, not the model.

Fine-tuning changes the model itself. OpenAI's pricing page, read in September 2026, states that "OpenAI is winding down the fine-tuning platform". For open weights, the LoRA paper on arXiv reports that it "can reduce the number of trainable parameters by 10,000 times". So tune when you need a fixed style or format that prompts cannot hold. Never tune just to teach the model facts.

Build from these official OpenAI pages, in this order:

1. Vector embeddings guide: the client.embeddings.create call, the text-embedding-3-small model and ranking by cosine similarity.
2. Reasoning guide: the client.responses.create call and the reasoning.effort setting for harder questions.
3. Pricing page: the per-token rates for each tier and the notice on fine-tuning.
4. Model optimization guide: what to try when retrieval alone is not enough.

What is the smallest working RAG example?#

A working RAG loop in Python is three steps: embed the documents, pick the closest by cosine similarity, and answer from them with a small tier. It fits in about twenty lines, using an embedding model and the cheapest general tier.

The embedding model sets the price of the search half. OpenAI's embeddings guide, read in September 2026, lists text-embedding-3-small at about 62,500 pages per dollar and a 62.3% MTEB score. By contrast, the larger model scores 64.6% at about 9,615 pages per dollar. So the small one is the sensible start.

from openai import OpenAI

client = OpenAI()

def embed(texts):
    response = client.embeddings.create(input=texts, model="text-embedding-3-small")
    return [item.embedding for item in response.data]

def dot(a, b):
    return sum(x * y for x, y in zip(a, b))

def cosine(a, b):
    return dot(a, b) / (dot(a, a) * dot(b, b)) ** 0.5

# Step 1: embed your documents once and keep the vectors.
docs = ["Refunds go to the original card when the item arrives back.", "Support replies to tickets by email on weekdays."]
doc_vectors = embed(docs)

# Step 2: rank the documents by cosine similarity to the question.
question = "How do refunds work?"
q = embed([question])[0]
best = max(range(len(docs)), key=lambda i: cosine(q, doc_vectors[i]))

# Step 3: answer from the best match on the cheapest general tier.
prompt = f"Answer only from this text: {docs[best]} Question: {question}"
response = client.responses.create(model="gpt-6-luna", input=prompt)
print(response.output_text)

The same three steps scale up without changing shape. First, swap the list for a vector database. Then return the top five passages instead of one. Finally, move the answer step up a tier only when your own test set shows Luna falls short.

Where to go next#

Price your own daily token volume against the tiers above, then read how a typed small model or a routed classifier handles the cheapest jobs. Your next step is your own arithmetic, and the posts and pages below cover what comes after it.

For the small-model branch, a typed small model compared with LLMs on cost per workload shows where a narrow model beats a general one. Before launch, the four numbers to settle before an enterprise AI model goes live covers the checks that come first. And for a worked support case, a small hosted model that classifies and routes form submissions shows the cheapest tier doing real work.

If you want a model built into your product or delivery, our AI-augmented development team does that work. If the chosen model has to work inside your existing systems, our enterprise software team wires it in. If the model has to call your systems and act on its own, see AI agent development. But the official pages listed above are enough to build the first version on your own.