The right model for the job — not the one the vendor pitched.
Claude, GPT, Gemini, Llama, Mistral — every one of them is the best model in the world according to somebody's benchmark. I've shipped production systems on all of them, and the honest answer is: it depends on your task, your data boundary, and your unit economics. I do the selection, integration, and tuning with no vendor allegiance and a scoreboard for every choice.
Model selection is where most enterprise LLM projects quietly overcommit. Someone picks the model from a leaderboard or an enterprise agreement that already existed, builds a year of integration on top of it, and discovers too late that the task needed longer context, tighter grounding, cheaper tokens, or a model that could run inside the data boundary. Switching costs then do the deciding.
I run selection the way you'd run any procurement: your actual tasks, run against candidate models, measured on accuracy, latency, and cost per task — before anything gets built on top. Claude for long-context reasoning and agentic work, GPT where its tooling fits your stack, Gemini inside Google estates, Llama or Mistral when the data can't leave your walls. Usually the answer is a mix, with routing sending each task to the cheapest model that clears the quality bar.
Where I plug in
- Selection and benchmarking — your tasks, your data, candidate models head-to-head, with a written recommendation you can defend to procurement.
- Integration and architecture — API design, structured outputs, tool use, streaming, fallbacks, and rate-limit strategy that survives production traffic.
- Tuning and economics — prompt engineering, caching, routing, and fine-tuning where it actually pays, tracked on cost per task.
Every model vendor will tell you theirs is the answer. I'm the person in the room who's shipped all of them and bills for none of them.
Model strategy across four decisions.
Questions, answered.
Which LLM is best for enterprise use?
The one that clears your quality bar at the lowest cost per task inside your data boundary — which differs by task. In practice, mature enterprise deployments route between two or three models rather than standardizing on one. The selection benchmark answers this in about two weeks.
Should we fine-tune a model or use RAG?
Start with RAG for anything knowledge-shaped — it is cheaper, auditable, and updates instantly. Fine-tune for form, style, and narrow classification at volume. Many production systems use both. I wrote a full decision guide on exactly this question.
Can you work within our existing cloud agreement?
Yes — Azure OpenAI, AWS Bedrock, and Google Vertex all offer frontier models inside your existing cloud commitments and compliance boundary, and that is often the pragmatic path. The benchmark tells you what, if anything, that convenience costs in quality.
Do you build the integration or just advise?
Both. Most engagements start with selection and architecture and continue into the build — agents, RAG, document processing, or workflow automation on whichever model won. Same person, same scoreboard, no handoff loss.
Pick the model with evidence, not faith.
Two weeks of benchmarking beats two years of switching costs. Tell me what you're building and I'll tell you what I'd test.
