Small versus large models and practical routing
Words made simple
A few useful meanings before you read the explanation.
- Deterministic
- Following steps or rules defined by code. The model does not decide which step should run next in a deterministic workflow.
- Evaluation
- Checking results against examples and clear criteria to find whether the system works well and where it fails.
- Latency
- How long a request takes to return a result. Lower latency usually means a shorter wait for the user.
Overview
- Smaller models often reduce cost/latency but may perform worse on complex tasks; stronger models may justify higher cost for difficult reasoning or synthesis.
- Routing sends different tasks to appropriate paths.
- The right split comes from evaluation, not model size labels alone.
Why this matters
Task complexity and risk differ across requests.
An everyday example
A junior clerk handles routine classification while a specialist handles complex explanations.
A technical example
Template for verified claim status; small model for bounded intent; larger model for comparing several applicable clauses.
How it works
- Benchmark tasks
- Define deterministic routing signals
- Choose allowed model
- Validate output
- Use bounded quality recovery or escalation.
Architecture and flow
Task/risk/context size → route → selected model/template → validation.
The insurance assistant example
A known “claim status” endpoint bypasses a reasoning model entirely.
When to use it
Diverse workload where evaluations show meaningful efficiency gains.
When to avoid it
Avoid relying solely on a small model's claimed confidence to decide whether its own answer is safe.
Interview answer
“I route based on measured task capability and deterministic risk signals, with explicit privacy-compatible fallbacks and quality checks.”
Benefits, trade-offs, and production considerations
A route is a policy, so version and evaluate it. Changes in traffic mix can invalidate earlier benchmarks.
// Provider-neutral routing example; actual adapters implement this interface.
type Task = "claim_status" | "intent" | "policy_explanation";
type Request = { task: Task; evidenceTokens: number; restrictedData: boolean };
type Route = "template" | "small-approved" | "strong-approved" | "private-path";
function route(req: Request): Route {
if (req.task === "claim_status") return "template";
if (req.restrictedData) return "private-path";
if (req.task === "intent" && req.evidenceTokens < 1000) return "small-approved";
return "strong-approved";
}
// Threshold is illustrative; calibrate against quality and latency datasets.
// Each route still needs documented model capabilities and access policy.Can you explain it without the notes?
Small versus large models and practical routing
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
Smaller models often reduce cost/latency but may perform worse on complex tasks; stronger models may justify higher cost for difficult reasoning or synthesis. Routing sends different tasks to appropriate paths. The right split comes from evaluation, not model…
Turn this concept into a clear answer.
Practice this conceptKeep connecting the ideas.
Next lesson: Exact caching, prompt caching, and semantic cachingAdapted from 13_AI.MD · “Small versus large models and practical routing”. Examples are study fragments; framework behavior can depend on your version.