What the output means
Treat the output as a ranked starting point, not a final verdict. The right model still depends on your own prompts, throughput targets, and downstream workflow.
Decision Wizard
AI Model Recommender
Use this workflow when you do not want to manually browse hundreds of models. The recommender narrows the field using your task, constraints, and practical deployment priorities so you can move faster from idea to shortlist.
Best for early-stage model selectionUse case + constraints + prioritiesWorks well before side-by-side comparison
AI Decision Assistant
Smart Recommender Wizard
Find the optimal model for your exact architectural constraints, hardware budget, and deployment scenario.
Step 1
What Are You Building?
Start with a task family, then add context so the recommender can narrow the field.
Step 1/4
Best follow-up workflow
Take the top recommendation into the comparison workspace, then confirm memory and GPU fit before adopting it for a real app or deployment pipeline.
Related guides
Read Selection Pitfalls and Open vs Closed Models if you want the reasoning framework behind the recommendation flow.
How to choose an AI model
Model selection goes wrong in a predictable way: teams start from a leaderboard, pick the highest-scoring open model they recognise, and discover weeks later that it does not fit their card, that its licence carries obligations they cannot meet, or that it is excellent at benchmarks and mediocre at the one task they actually need. The order of the questions matters more than the answer to any single one.
Start with the constraint that cannot be negotiated. For most teams that is memory: a model either fits your GPU at an acceptable precision or it does not, and no amount of prompt engineering changes that. Work out your real budget first — weights plus KV cache at the context length you actually serve, not the model maximum — and use it to eliminate candidates before you compare quality. This is why the wizard asks about hardware early rather than last.
Second comes the task. "Good at everything" is not a useful category, and general capability rankings hide large differences on specific work. Coding, multilingual output, long-document reasoning, structured extraction, and tool calling each have models that punch well above their size and models that disappoint relative to theirs. A 7B tuned for your task will frequently beat a 34B that was not.
Third is the licence, and it is the one most often discovered too late. Apache 2.0 and MIT models impose essentially nothing. Open-weight licences such as Llama and Gemma permit commercial use but add acceptable-use terms, attribution requirements, and in some cases thresholds that apply at scale — and those obligations travel with the weights into anything you fine-tune or redistribute. Read the terms before a model becomes load-bearing, not after.
What a shortlist is for
The output here is a starting point, not a verdict. Its job is to take an unmanageable field down to three or four candidates that are all plausible, so your evaluation effort goes into comparing real options rather than surveying the field. The decision that follows should be made on your own prompts.
A workable evaluation is smaller than most teams expect. Assemble ten to twenty tasks drawn from real usage, including several that your current approach handles badly, and score each candidate on correctness and on format-validity separately — a model that is right but returns unparseable output is a different problem from one that is well-formed and wrong. Run them at the quantization and context length you would actually deploy, because a model evaluated at FP16 and shipped at 4-bit has not really been evaluated. Then confirm the memory numbers with the VRAM Calculator and check the specific card with Can I Run It.
If two candidates land within noise of each other, stop optimizing for quality and decide on the operational questions instead: which has better runtime support, a more permissive licence, a more active maintenance history, and a clearer upgrade path. Those differences compound over a deployment's life in a way that a two-point benchmark gap does not.
Frequently asked questions
How does the recommender choose models?
It filters before it ranks. Your task, context length, and licence constraints remove models that cannot do the job at all, then the remaining candidates are scored on memory fit against your hardware, capability signals for that task, and deployment practicality. A model that scores brilliantly but needs three times your VRAM is not a recommendation, so fit acts as a gate rather than one factor among many.
Why does it sometimes suggest a smaller model than I expected?
Because the largest model that technically fits is rarely the right default. Once weights and KV cache leave under about ten percent headroom, the deployment becomes fragile the moment context or concurrency grows. The recommender prefers a model that leaves room to operate over one that only fits on a short prompt with a single user.
Should I trust the shortlist without testing?
No, and it is not meant to be used that way. The shortlist narrows thousands of candidates to a handful worth your evaluation time. Which of those handful is actually best for your prompts, your output format, and your latency budget is something only your own test set can answer.
What does it not account for?
Anything it cannot measure from model metadata: the quality of a specific fine-tune, how a model behaves inside your agent loop, provider reliability, and how your prompts interact with a particular instruction-tuning style. It also assumes a single-GPU deployment unless you tell it otherwise.