Model selection
The deepinfra models catalog is a starting point when you know what you want to do but not which model fits. Use it to narrow the field, then check a candidate’s current details before sending a request.
The general Deepinfra entry point introduces the service. A model-first route starts with your workload and the details you need to evaluate before testing.
You need vectors for semantic search rather than a conversational answer. A general overview will not tell you which output shape to inspect.
Start with the embedding workload, then check vector dimensions and input limits on the candidate listing.
You need help with code changes and want to distinguish a coding workflow from a general chat test.
Identify the coding task first, then evaluate candidate output against a representative repository question.
You have a multi-step question and need to inspect a specific candidate instead of browsing the whole catalog.
Compare the candidate’s documented input format and limits with the task you intend to run.
You want to test a named candidate on a draft, but its availability and capabilities need checking.
Confirm the listing exists, then compare its documented constraints with your draft length and expected output.
Separate output types, inspect a task-specific workflow, and examine a named candidate. Those are more useful next moves than choosing from a name alone.
A short test tells you more than a model name. Keep the task and evaluation criteria fixed while you compare candidates.
Write down whether you need text, code, or vectors. Include a representative input and what a usable answer would contain; this keeps unrelated model types out of your shortlist.
For each Deepinfra candidate, check the supported task, request format, context or input constraints, and any availability notes shown on its listing. Do not assume two similarly named variants accept identical requests.
Try the same input with each suitable candidate and compare accuracy, output shape, and handling of your edge case. Recheck the listing before building around a result, because catalog details can change.
Use a different acceptance check for each output type. Deepinfra model names alone cannot establish whether an answer works for your application.
Text
Give the candidate a question with a verifiable answer and clear instructions about format. A polished response can still omit a required fact or ignore a constraint.
Code
Supply a small function, expected behavior, and one edge case. Evaluate the resulting code with your own tests instead of treating plausible syntax as proof that it works.
Vectors
Embed a small set of documents and queries, then inspect whether relevant items rank where you expect. Confirm the documented vector shape before connecting an index.
The Deepinfra catalog helps you discover candidates; it cannot validate your particular data, guarantee a listing remains unchanged, or replace application testing.
Supported task labels do not show how well a candidate handles your domain vocabulary, formatting rules, or failure cases.
What to do instead
Test a small, representative set of inputs and review the outputs yourself.
A model family name does not establish the accepted payload, context limit, or output format of every variant.
What to do instead
Read the current documentation for the exact candidate you intend to use.
One good response cannot establish consistent behavior, suitability for sensitive inputs, or performance under your workload.
What to do instead
Repeat tests with edge cases and review applicable data-handling information before deployment.
Start with one task and one representative input. Shortlist suitable Deepinfra candidates, check their current requirements, and compare the outputs against criteria you chose in advance.
Start with the output you need: generated text, code, or vectors. Shortlist candidates in that category, read their current listings, and run the same representative test against each suitable option.
No. Candidates may differ in supported tasks, request formats, input constraints, and the kind of output they return. Check the exact listing rather than assuming that models with similar names behave alike.
Use the documentation or listing for the exact candidate you plan to test. Catalog availability and technical details can change, so verify them again before relying on a model in an application.
A name is useful for finding a candidate, not for establishing that it meets your requirements. Compare the documented capabilities and run a task-specific test with an expected result.