Choosing a Model

By Syncfusion®, Inc. · Last updated November 2, 2026

Pick a model per task from eval results, p95 latency and cost: find the Pareto front, apply quality, latency and licence rules, and build a model plan with its monthly bill, in TypeScript or C#.

What you will learn

• Read an eval table with quality, p95 and cost per model
• Find the Pareto front of models for a task
• Pick the cheapest model that meets quality, latency and licence rules
• Build a model plan per task with its monthly cost

One Model for Everything

Brightgrid runs three model tasks:

• classify: what kind of question is this? A short answer.
• extract: pull the order id and dates into JSON.
• reply: write the answer the customer reads.

All three run on Qwen2.5 7B, the biggest model in the catalogue. It was picked once, for the hardest task, and nobody changed it since.

A one-word classification does not need the biggest model. But a smaller model might fail the reply task. You need numbers for each task, not a guess.

Press Play, or use Next to go one step at a time.

• Frame 1: eight models on the reply task: quality, p95 latency and cost.
• Frame 2: models that are worse than another on every axis drop out.
• Frame 3: the product's requirements pick one model.

Simple lesson: pick a model per task, from eval results, cost and latency.

A Real-World Example

A team switched everything to a cheaper model to save money. Classification stayed fine. Replies got worse, and refund answers got worse most.

The fix was not "go back to the big model". It was a different model per task.

Simple lesson: the cheapest model that passes the eval is chosen per task, not per company.

What You Will Build

In this lesson, you will learn:

1. how to read an eval table with quality, p95 and cost per model
2. how to find the Pareto front: the models worth considering
3. how to pick the cheapest model that meets a quality bar, a latency limit and a licence rule
4. how to turn the picks into a model plan with a monthly cost

You will finish three files in the models folder:

• Pareto (src/models/pareto.ts, or Models/Pareto.cs): drop dominated models.
• Pick (src/models/pick.ts, or Models/Pick.cs): the cheapest model that qualifies.
• Plan (src/models/plan.ts, or Models/Plan.cs): one model per task, and the monthly bill.

Open the Code tab. The harness has eval results for 8 models × 3 tasks, the licences your legal team cleared, and each task's requirements.

Simple lesson: model choice is data plus requirements, so it can be code.

Read the Eval Table

Each row has three numbers:

• quality: the share of cases passed in your eval suite, from the Evals & Observability course
• p95: 95% of calls finish faster than this
• cost per 1,000 calls: from the task's typical tokens and the price table

Run the cell. Then change the task to "classify" and "extract".

• reply: quality climbs steeply with model size.
• classify: small models are almost as good as the 7B.
• licence: one model is marked, because its licence is not cleared for your use.

Simple lesson: different tasks need very different model sizes.

The Pareto Front

A model is dominated when another model is at least as good on quality, cost and p95, and strictly better on one of them. You would never choose a dominated model.

The models that are left form the Pareto front. Your choice is always one of them.

Simple lesson: remove dominated models first, then choose.

Pick by Requirements

Each task has requirements from the product:

• a minimum quality, from the eval
• a maximum p95, from the latency budget
• an allowed licence, from legal

Among the models that meet all three, take the cheapest. On a tie, prefer the lower p95, then the higher quality.

Simple lesson: the requirements decide, and the cheapest qualifying model wins.

A Model Plan per Task

Run the cell. Move the reply quality bar.

• 75% and 80%: the same model, the same bill.
• 85%: only the 7B qualifies, and the bill jumps.
• 90%: no model qualifies. The plan says so instead of hiding it.

The quality bar is a product decision with a price. This cell shows the price.

Run npm run models (or dotnet run -- models). The plan uses three different models and costs 56% less than the 7B everywhere, with every task above its bar.

Simple lesson: a model plan per task, with its bill, is the result to review with the team.

Small Open Models and Hosted Tiers

Real decisions often include a hosted closed model. The lab only runs open models, but the price table has two reference tiers for comparison: a mid-tier and a frontier hosted API, with illustrative prices. The Prices tab also lists what some hosts charged for these open models when the course was checked.

Run the cell. On the same ticket, the frontier tier costs about 80 times the 1.5B model. That gap pays for a lot of routing, caching and eval work.

Simple lesson: compare tiers on cost per task, measured on your own eval.

Try it on a real model. Ask a 0.5B and a 1.5B model the same question. Code checks each reply, and the table shows speed and cost side by side. Switch Model to Real in the lab's top bar. It runs an open model in your browser with WebLLM, and needs WebGPU. It is not graded.

Put It in Your App

• Model per task in config. Read the model id for each task from configuration, not from code. Then a model change is a config change with an eval run.
• Re-run the plan when things change. New models, new prices and new eval cases all change the picks.
• Keep the residency rule too. If data must stay in a region, filter models and hosts by region, the same way as licences.

Simple lesson: models are configuration, chosen by code and checked by the eval.

Common mistakes

Check Your Understanding

Exercises

Build It in the Project

The other files of this lesson's project are optional practice. Finish them to run the lesson's script on your own code.

What to Remember

• Pick a model per task, not one for everything.
• Use your own eval for quality, recorded runs for p95, and the price table for cost.
• Drop dominated models, then take the cheapest that meets the bar.
• Licence and residency rules come before price.
• Keep the model per task in config, and re-run the plan when anything changes.

Next: Routing and Escalation. You will send each request to a small model first, and escalate only when a check says it needs the big one.