Skip to content

Model Lab

Use the Right Model, Own the Right Intelligence.

Model choice is an architecture decision with cost, latency, sovereignty and lock-in consequences. The lab recommends a strategy, a routed portfolio, and names the trade-offs you are accepting.

Task
Data sensitivity
Latency requirement
Cost target
Reasoning requirement
Deployment

Recommended model strategy

Self-hosted open-weight portfolio, routed by task

The lab recommends a strategy, never a “best model”. That claim cannot be supported without your data, your tasks and your held-out set — and any vendor who makes it is describing a leaderboard, not your workload.

Mid-size open-weight model

PRIMARY WORKHORSE

Self-hosted open weights keep the capability, the data and the cost base under your control — the deciding factor when residency or continuity is a requirement.

TIER 1

Hosting

In-perimeter inference on Kubernetes with GPU scheduling, sized for sustained utilisation rather than peak. Weights, index and control plane all inside the boundary.

Fine-tuning

Consider after retrieval quality plateaus. If the failure mode is format, terminology or refusal behaviour rather than missing facts, LoRA-based adaptation is the efficient answer.

Routing

Route by task class with a confidence-based escalation path, and cache aggressively at the semantic level. Most enterprise traffic is more repetitive than teams expect.

Trade-offs

  • Private hosting trades per-token cost for capacity cost. Below roughly half utilisation it is usually more expensive; above it, it is usually cheaper. Model your actual curve before assuming either.
  • Regulated classes need provable processing boundaries. Enforce the boundary at the gateway and evidence it in telemetry rather than asserting it in policy.
  • Every model choice is reversible only if the interface is abstracted. Keep the gateway between your applications and any provider from the first release.

How to prove it

  1. 1Build the held-out set before choosing a model. Without it, model selection is a preference exercise.
  2. 2Score on your tasks and your data — public leaderboards do not predict performance on your terminology or formats.
  3. 3Measure quality, P95 latency and cost per thousand requests together. Optimising any one alone moves the others in ways you will discover late.
  4. 4Re-run the suite whenever a provider updates a model. Hosted model behaviour changes without a version bump.

Prove Your Data Strategy

Model selection without a held-out set is a preference exercise. Bring us the task and we'll help you build the evaluation that makes the decision defensible and keeps it defensible when a provider silently updates a model.

30 MINUTES WITH AN ARCHITECT · BRING YOUR HARDEST CONSTRAINT