Skip to content

CONCEPT Cited by 1 source

Cross-model portability

Definition

Cross-model portability is the property that switching the underlying model (or model provider) in a production system requires no caller-side code change — ideally only a configuration or model-name-string edit — while preserving the caller's existing prompt, parameter choice, and evaluation rubric.

It is the direct consequence of a unified parameter protocol applied across a model class (image generators, LLMs, embedding models, etc.).

Why it matters

Model portability changes the economics of model evaluation. Without portability:

  • Each candidate model requires caller-side integration work.
  • Teams settle on the first model that works, not the best one.
  • Model-landscape churn forces repeated migrations.

With portability:

  • Evaluating a new model is a config flip + re-run of the eval harness.
  • Teams can A/B test model choices per-workload, per-project, per-A/B cohort.
  • When a better model lands (new provider release, internal fine-tune), adoption is rollout-speed, not rewrite-speed.

The "best model varies by project" argument

From Instacart PIXEL (Source: sources/2025-07-17-instacart-introducing-pixel-instacarts-unified-image-generation-platform):

"An interesting outcome we realized from launching various applications was that the best performing model varied project by project. PIXEL enabled project leads to initiate projects using pre-configured, optimal model and parameter recommendations. Subsequently, they could rapidly test other models with a sample dataset and decide which one works best before moving to production image generation at scale."

The observation is canonical enough to anchor the architectural argument: there is no single best model for a portfolio of workloads, so portability is not a premature-optimisation luxury — it is how the portfolio gets good results at all.

Required mechanisms

Cross-model portability is load-bearing on three platform investments:

  1. Unified parameter protocol — canonical parameter vocabulary with platform- side translation.
  2. Single endpoint — one API surface that fronts all models.
  3. Evaluation harness / VLM-as-judge — model-agnostic quality evaluation that makes "is model A better than model B for this project?" quantitatively answerable.

The three compose: single endpoint routes the call, unified protocol translates parameters, evaluation harness scores the result. Any of the three missing and portability becomes nominal-only — technically possible but operationally expensive.

Seen in

Last updated · 319 distilled / 1,201 read