LLMs types enterprise use cases: a decision guide

What types of LLMs do enterprises use and how do they differ?#

Eleven LLM types serve enterprises: general-purpose, open-source, small, domain-specific, multimodal, code-focused, reasoning, embedding, fine-tuned, RAG, and locally deployed. Each type differs in architecture, cost, control, and performance. LLM types range from proprietary API-based models to self-hosted open-source implementations, with tradeoffs in cost, control, and performance.

Enterprise leaders face a choice. Do you want simplicity or control? Do you want to pay per token or own the infrastructure? Do you want a model that handles everything or a specialized model for one task? The answers determine which LLM type works for you.

What are the eleven LLM types and which should I know about first?#

General-purpose models (OpenAI's GPT-4o, Anthropic's Sonnet and Opus) handle diverse tasks; open-source base models (Llama, Mistral) give full control; small models run on edge; domain-specific models target finance or healthcare; multimodal combines text and images. Code-focused models excel at programming, reasoning models solve multi-step problems, embedding models turn text into vectors, fine-tuned models specialize on your data, RAG models retrieve and augment, and locally deployed models run on your servers.

Each type differs in architecture, training data, intended use, and deployment. A general-purpose model works best when tasks are broad because it trained on diverse data and handles many use cases. A domain-specific model wins when you have a narrow, deep problem. An embedding model solves a different class of problem, because it turns text into numbers so your application can search, classify, or cluster.

Enterprise leaders choose one of three paths. Path 1 starts with general-purpose models and accepts lower accuracy. Path 2 fine-tunes a general model on your domain data. Path 3 deploys a purpose-built model and runs infrastructure yourself.

Which path you take depends on your accuracy bar, your budget for retraining, and whether you have the team to manage models in production. A 2023 survey of how LLMs are evaluated, arXiv:2307.03109, organizes the question into what to evaluate, where, and how. For an enterprise buyer, five answers decide the purchase: cost, privacy, latency, accuracy and integration effort. These tradeoffs make LLMs types enterprise use cases hard to navigate without a clear framework.

Which LLM type solves which enterprise problem?#

Customer support teams use general-purpose models for tickets; document processing uses domain-specific or RAG systems; development uses code-focused models; finance uses fine-tuned models. Each enterprise use case maps to one or more LLM types, and the match between type and problem determines whether you succeed or fail.

Support tickets come in many forms: billing questions, technical issues, account problems. General-purpose models handle all three because they trained on diverse data. Domain-specific models trained only on finance would miss technical questions. A mid-market SaaS firm with 500 support tickets daily across three categories needs a general-purpose model. A domain-specific model would fail when tickets arrive that fall outside its training data.

Document processing needs a different model because every contract and invoice looks different but follows patterns. A domain model trained on legal language can catch issues a general model misses, but do not assume it will. A September 2026 study, arXiv:2609.13556, compared Llama 3.1 with a medically fine-tuned variant on medical terminology, and the general-purpose model did better on both tasks. Its authors conclude that domain adaptation should not be assumed to improve performance on specialized terms. Test a domain model against a general one on your own documents before you commit.

Manufacturing operations use embedding models to classify defect reports and route them by severity. Production facilities get hundreds of reports daily in text, images, and sensor data. Embedding models convert that diversity into standardized vectors for routing.

HR departments use general-purpose models to screen resumes. They rank candidates by keyword match and experience fit across diverse backgrounds. E-commerce teams use multimodal models to generate product descriptions from images. A photo of a shoe becomes text that mentions color, material, and style. Business automation uses reasoning models for expense approval and contract review. The model must trace logic across multiple clauses and justify its decision.

Each use case picks a different model type because one type solves one problem well and fails at another. A customer support system using a finance model returns wrong answers. A contract review using a general model misses clauses. A customer service agent using only an embedding model cannot reason about refund policies or escalation rules.

How do I compare LLM types by cost, privacy, performance, and LLMs types enterprise use cases?#

Cost ranges from $2.50 per million tokens to zero for self-hosted open-source; privacy depends on local vs cloud deployment. Performance varies by model size and training data, and scalability depends on whether you own the servers.

A general-purpose API model costs $2.50 to $15 per million tokens depending on size. A self-hosted open-source model costs nothing per token after infrastructure. SitePoint puts a quantized self-hosted deployment at about $10,200 to $12,200 a month for 50 million tokens a day, infrastructure and staff included. Performance matters as much as cost, and latency depends on your deployment, so measure it on your own traffic before you choose. Real-time customer support needs fast replies; an overnight batch does not.

Economics change at volume. SitePoint's 2026 comparison finds that teams under 5 million tokens a day almost always pay less with an API, and that self-hosting starts to win somewhere between 10 and 30 million tokens a day. At 50 million tokens a day, GPT-4o through the API comes to about $18,750 a month, against $10,200 to $12,200 for a quantized self-hosted deployment. The self-hosted figure includes a cost that is easy to miss: roughly half to one full-time DevOps or MLOps engineer to run it.

Privacy depends on deployment. An API model sends your data to the vendor's servers. A self-hosted model keeps data on your servers. A private API keeps data off logging systems but sends it outside your network. Local models run entirely on your infrastructure. Healthcare organizations with patient records need HIPAA compliance, which rules out cloud APIs. Financial institutions in regulated markets need data residency in specific locations. Manufacturing firms with trade secrets cannot use cloud APIs without legal risk.

Cost is one of five answers that decide the purchase, alongside privacy, latency, accuracy and integration effort, so a cost-only comparison misses the real picture. A model that costs half as much but takes 10 seconds per response might slow your team more than it saves. Scalability matters when your enterprise use case grows. An API-based solution scales instantly to handle traffic spikes. A self-hosted solution requires capacity planning weeks in advance.

Should I choose open-source or proprietary LLM models for my enterprise?#

Open-source models give full control and cost less at scale; proprietary models start faster and handle updates for you. Open-source trades operational simplicity for control and cost savings, while proprietary models trade cost and control for ease of adoption.

An open-source model lets you train and fine-tune on your data without paying per token. You run it on your servers so data stays internal. You customize it for your domain or business.

A proprietary model lets you start building in hours, not weeks. You avoid managing servers and GPU infrastructure. You get security updates and improvements automatically from the vendor.

Three questions drive the decision. First, how sensitive is your data? Financial transactions and health records stay private with open-source. Second, how much volume do you handle? Over 500 million tokens monthly, self-hosted costs less. Third, do you have the team to manage ML infrastructure? If not, proprietary models are faster even if they cost more.

Neither side wins everywhere. SitePoint's conclusion is that the choice depends on token volume, compliance, team capacity and task complexity together, and that many production systems now split the work: commodity tasks such as summarization and classification go to a self-hosted model, and complex reasoning goes to a commercial API.

What business value does choosing the right LLM type deliver?#

The payoff from matching LLM type to use case is mostly labor, not model spend, as the example below shows. It reduces time to value, lowers total cost of ownership, and prevents vendor lock-in regret from choosing the wrong model today.

A customer support team using the right LLM type can resolve more tickets per agent, because one model handles all three ticket categories without retraining. Fewer tickets need human review when routing works fast. A financial services firm using domain-specific models catches errors that general models miss. So they avoid compliance issues. A manufacturing operation using embedding models catches defects earlier in production.

Here's a worked example with illustrative numbers: a mid-market SaaS company handles 10,000 support tickets a month, averaging 100 input tokens and 50 output tokens each. That is 1 million input tokens and 500,000 output tokens a month. At $2.50 per million input tokens and $10 per million output tokens, the model costs about $7.50 a month. The agents are the real cost: at 200 tickets a month each, 10,000 tickets need 50 agents, and at $5,000 each that is $250,000 a month. If the model resolves 35 percent of tickets without an agent, 6,500 tickets are left, which need 33 agents. That saves 17 agents, or $85,000 a month, for a model bill under $10.

The same arithmetic applies to document processing, with one caution from the study above: measure each candidate model's catch rate on a sample of your own contracts before you price the difference, because a fine-tuned model is not guaranteed to beat a general one.

These gains justify testing and training. An enterprise that spends two weeks testing three LLM types and two weeks fine-tuning the best one invests 240 hours. At $200 an hour, those 240 hours cost $48,000; if the result saves $30,000 a month in labor, it pays back in about seven weeks.

Where do I find the official documentation to implement my LLM choice?#

Start with OpenAI API docs (https://platform.openai.com/docs), Anthropic's API docs (https://platform.claude.com/docs), or Hugging Face for open-source. Your next step is opening the exact documentation page for the LLM type you chose so you never return to search.

For proprietary models:

1. OpenAI: https://platform.openai.com/docs (models, pricing, API reference)
2. Anthropic: https://platform.claude.com/docs (models, API reference, guides)
3. Google Gemini: https://ai.google.dev/docs (Gemini models and API)

For open-source base models:

1. Hugging Face: https://huggingface.co/docs/hub/models (model browser and deployment guides)
2. Meta Llama: https://github.com/meta-llama/llama (Llama weights and documentation)

The documentation page for your chosen model is the ground truth for setup, API calls, pricing, and limits.

What is the bare minimum code needed to call an LLM?#

Python: Step 1, install SDK (pip install anthropic); Step 2, set API key; Step 3, call text completion; Step 4, handle response. You can have your chosen LLM returning text in four steps using Python and the official SDK.

# Step 1: Install SDK
# pip install anthropic

# Step 2: Set API key (export ANTHROPIC_API_KEY=sk-...)
import os
from anthropic import Anthropic

# Step 3: Create client and call text completion
client = Anthropic()
message = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    messages=[
        {"role": "user", "content": "What are the advantages of fine-tuned LLMs for finance?"}
    ]
)

# Step 4: Handle response (the reply can open with a thinking block, so print the text blocks)
for block in message.content:
    if block.type == "text":
        print(block.text)

This four-step pattern applies to every LLM type: install the SDK from the vendor, set credentials in an environment variable, call the API method, and print the response. Start with no authentication wrapping, no async patterns, and no complexity beyond what you need immediately.

For OpenAI, swap Anthropic() for OpenAI() and client.messages.create() for client.chat.completions.create(). For open-source models hosted on Hugging Face, use the requests library to call the HTTP endpoint. The pattern stays consistent end-to-end across all LLM types.

When NOT to use the LLM type you chose or when this is the wrong fit?#

Do not use proprietary APIs if data residency is required; do not use open-source if you lack infrastructure expertise; small models fail on reasoning tasks. If your constraint contradicts the LLM type you chose, use something different instead.

If data residency is a requirement, do not use a proprietary cloud API. Instead, deploy an open-source model on your own servers. Or use a private API from a vendor that offers data residency guarantees.

If you lack infrastructure expertise, do not deploy open-source models yourself. Instead, use a managed service like Together AI or Anyscale that runs open-source models on your behalf.

If reasoning is a core requirement, do not use small models or embedding models. Instead, use general-purpose reasoning models designed for step-by-step problem solving.

If cost is the only constraint, do not choose the cheapest model first. Instead, measure cost per quality. A model that costs half as much but returns half-useful answers costs twice as much in review and rework.

An LLM type that works for one use case fails for another. A general-purpose model handles customer support. A small model handles it faster but misses nuance. The honest test: if your use case contradicts the model's design, it is the wrong choice, no matter how popular it is.

Frequently asked questions about enterprise LLMs#

Read next#

Explore agentic systems in software development or AI and developer teams for deeper implementation patterns. You now know which LLM type to use and where to read next depending on your direction.

• Agentic Systems in the Software Development Lifecycle explains how LLMs work together in multi-step workflows
• AI and Developer Teams shows how teams adopt LLMs and the skills they need
• Scale and Optimize Your AI Implementation covers enterprise deployment and cost optimization
• API integrations covers wiring an LLM API into the systems you already run
• Enterprise Solutions covers how to implement LLMs across your organization

Your next step is opening the exact documentation page for the model you chose so you never return to search.