HF models: choose by task
Build a model shortlist around evidence, permissions, quality, and a serving plan your team can actually operate.
Choose the job, then the model
A model is a component in a workflow, not the workflow itself. Define the input, expected output, unacceptable errors, and handling of missing evidence. The candidate that writes the most polished paragraph may not be the candidate that extracts the right field or follows your schema most reliably.
This page is a selection framework rather than a changing model leaderboard. It does not imply that every model discovered on Hugging Face is available through a hosted API or appropriate for a commercial application.
Map the task families
| Task family | A useful evaluation question |
|---|---|
| Chat and instruction following | Does the model follow the task and distinguish missing information? |
| Structured extraction | Are the required fields correct, supported, and well formed? |
| Embeddings | Do relevant items remain retrievable on the actual dataset? |
| Reranking | Does the ordering improve relevance for the target queries? |
| Multimodal understanding | Does the output reflect the supplied image or other permitted input? |
| Coding assistance | Does the result pass meaningful tests in an isolated environment? |
A shared interface does not make these roles interchangeable. Evaluate retrieval and generation together when your application relies on both.
Read the model card critically
The Hugging Face model card guide describes how publishers document intended use, limitations, evaluation, and licensing metadata. A card is a starting point for review, not an independent verification of every claim.
Record the repository, revision, card, and license you reviewed. Mark missing information as missing. Check whether the published evaluation resembles your inputs and whether the deployment format suits your serving stack.
Selection checklist
Hard requirements
Identify allowed use, access requirements, data-handling constraints, input language, output format, and hardware limits. A candidate that fails a hard requirement should not become acceptable simply because it performs well on an unrelated metric.
Task quality
Prepare ordinary, difficult, ambiguous, and unsuitable examples. Define the acceptance rubric before inspecting answers. Preserve a held-out set for the final comparison rather than repeatedly tuning on every available example.
Operating fit
Measure startup behavior, complete-response latency, valid-output rate, and cost per accepted task. Include retries and additional repair steps. Compare deployment routes using equivalent quality requirements.
Reversibility
Keep the model identifier and prompt revision in explicit configuration. Maintain tests and a rollback condition. A model change should be a reviewable application change, not a silent replacement of an assumed equivalent dependency.
Keep an evaluation card
For each candidate, record the task, repository revision, hosting route, input fixtures, generation settings, quality observations, performance measurements, and unresolved questions. Store the actual outputs safely so reviewers can inspect the decision rather than relying on a single aggregate score.
Avoid promising that a small successful evaluation eliminates production risk. It can reveal obvious mismatches and justify a controlled next step, but additional monitoring and review remain necessary once real inputs arrive.
Continue with the complete model-selection article, Hugging Face API overview, and benchmark worksheet.
Read the selection playbook