Using Pre-trained Models

Suman SharmaSuman Sharma

I do not train foundation models. I use models someone else already trained, then I spend my time on the product around them.

That is the default for almost every AI feature I have shipped.

Code on a laptop — most AI products call a model, they do not train one

Why I start here

Benefits of pre-trained models:

  • You can demo a feature this week, not after a research project
  • Quality on language, code, and images is already high
  • You pay for inference, not for a GPU cluster and a data team
  • You can swap providers if price, latency, or policy changes

Where they disappoint

Limitations and considerations I check before I commit:

  • The model does not know your private data
  • It will sound sure when it is wrong
  • Context length is finite. More tokens cost more and often answer worse
  • Cut-off dates / knowledge mean anything after training is invisible unless you retrieve it
  • Pricing, rate limits, and data-retention rules differ by vendor
  • A model that is great at chat can be bad at strict JSON

I keep a short list and re-test when a feature is expensive or flaky:

  • OpenAI models — strong default for chat, tools, vision, and image generation. The API surface is what a lot of tutorials assume.
  • Anthropic's Claude — I reach for it when I want careful long-form writing or a large context that still follows instructions.
  • Google's Gemini — worth a bake-off when the product already lives in Google Cloud, or when multimodal is the whole feature.
  • Mistral and Cohere — useful when I want a smaller, cheaper, or more specialized model, including embeddings from Cohere.
  • Hugging Face models — where I look when I might self-host instead of calling a closed API.
  • Replicate — a way to run open models without standing up GPUs myself.
  • Azure AI and AWS SageMaker — what I use when the company already mandates that cloud, or when procurement will not approve a direct OpenAI key.

There is no permanent winner. I pick on a golden set for this feature: quality, latency, and dollars per successful task.

Capabilities I write down before I choose

For each candidate I note:

  • Capabilities — chat, tools, vision, JSON mode, embeddings
  • Context length — input plus output, not the marketing number alone
  • Knowledge cutoff — and whether the product needs live facts anyway

If two models tie on quality, I take the one with clearer pricing and a fallback I can switch to in an afternoon.

Next

The API most tutorials start with, and the token math behind it:

Frequently asked questions

What is a pre-trained model?

A model that was already trained by someone else. You call it. You do not train it from scratch for a normal product feature.

Does a longer context window always mean better answers?

No. A long context lets you pass more text. Stuffing it with irrelevant text usually makes the answer worse and the bill higher.

What is a knowledge cutoff?

The date after which the model was not trained on the world. Anything newer has to come from retrieval, tools, or the user.

Contact

Get in Touch

Want to call me? book a call and I'll respond in the available time slot. I will ignore all soliciting.