Model Selection | Parasail

For the complete documentation index, see llms.txt. This page is also available as Markdown.

Model availability and capabilities change frequently. Instead of relying on a static recommendation table, use this guide to choose a short list of candidates, check availability with the live models endpoint, and evaluate the models against your own prompts before committing to production.

To list currently available serverless models, use the /v1/models endpoint.

Start with the workload

Workload

What to optimize for

Start here

Choose the right product tier

Tier Best fit Notes
Serverless Fast experiments and production traffic on models already hosted by Parasail Use the models endpoint to check availability before wiring a model into an application.
Dedicated Instances Private models, custom Hugging Face models, predictable capacity, or model settings that need full endpoint control Start in the UI when possible so the compatibility checker can validate model and hardware choices.
Batch Large offline jobs, evaluation sets, embeddings, and workloads that do not need immediate responses Use custom_id values so outputs can be matched back to inputs and failed requests can be retried selectively.

Check live availability

Use the models endpoint before committing to a model name:

curl https://api.parasail.io/v1/models \
  -H "Authorization: Bearer $PARASAIL_API_KEY"

The response lists the serverless models available to your account. For Dedicated Instances, use the deployment flow or the Dedicated compatibility checks to validate public or private Hugging Face model IDs.

Evaluate candidates

Use the same representative prompts, documents, tool schemas, or images for every candidate. Track these dimensions:

Run a repeatable evaluation

Use one evaluation set for every candidate model.

  1. Collect representative prompts, documents, images, tool schemas, or expected JSON schemas from your product.
  2. Run the same inputs through each candidate model.
  3. Save the raw request, raw response, latency, token usage, and pass/fail result for each input.
  4. Review failures by category: wrong answer, bad format, missing tool call, hallucination, timeout, or cost outlier.
  5. Promote only models that meet your quality, latency, cost, and feature-support thresholds.

For small evaluations, call Serverless or Dedicated endpoints directly. For large offline evaluations, use Batch so you can process many requests at lower cost and retry failed rows by custom_id.

For private or fine-tuned models, start with Dedicated Instances and validate the model ID in the deployment flow before running a full evaluation.

Validate feature-specific requirements

Some workloads need more than general text quality:

Next steps