Base Model or AI Assistant: What Are You Actually Buying?

A model release can give you a starting point for training, a system already adapted to follow instructions, or access to a managed product. Those are different purchases, even when all three are described as “AI models.” Before comparing benchmark scores, establish what the supplier provides and what your team must still build.

ERNIE 5.5 Flash Base makes the distinction explicit. Baidu describes the released weights as the checkpoint at the end of pre-training, before mid-training or post-training, intended as a starting point for further adaptation. That can be valuable to a team developing model behaviour. It does not make the checkpoint a finished business assistant. Baidu's release description

For an agency or company buying a practical capability, the decision should connect the required outcome to the remaining work: adaptation, serving, application controls, evaluation and ongoing support. A more flexible starting point can create a larger delivery obligation.

Start with three independent questions. What behaviour has the model been trained to produce? How can your team access it? What user-facing and operational features come with that access?

A base checkpoint is an artifact from a particular training stage. An instruction-tuned or otherwise post-trained model has undergone additional work to shape behaviour. A hosted API is a way to call a model. An assistant product adds interaction and workflow features around one or more models. These categories can overlap without becoming equivalent.

For example, a provider can host a base checkpoint, or publish the weights of a post-trained model. A polished chat interface may use a hosted model whose weights are unavailable. The presence of a download link therefore answers a different question from whether the model follows your instructions reliably.

Write these attributes separately in a shortlist. Avoid one column called “open” that attempts to cover weight availability, licence permissions, training transparency and deployment control. Each needs its own evidence.

The table is a buying framework, not a ranking. A suitable hosted assistant can be the right choice for one task while a specialised model-development project needs a checkpoint it can adapt directly.

A base model can have substantial language, coding and reasoning capabilities. The question is how those capabilities appear under the intended interaction format and whether they meet the application's behavioural requirements.

Do not assume the checkpoint has been trained for the conversation style, tool protocol, refusal behaviour or output structure your product needs. Some tasks may work with carefully designed prompts; others may require adaptation. Establish that empirically rather than inferring readiness from a model's size.

Baidu's ERNIE release evaluates base checkpoints using a matched evaluation setup and describes further training as an intended use. That comparison is evidence about the released base models under those conditions. It should not be presented as a direct ranking of complete assistant products. ERNIE evaluation setup

For a potential buyer, translate the open work into deliverables. Who will define the target behaviour, prepare examples, run adaptation, evaluate failures and maintain the resulting checkpoint? Which requirements can be met through the application, and which depend on the model changing?

Post-training can shape how a model responds, follows instructions or handles particular kinds of tasks. It does not automatically provide customer accounts, permissions, retrieval, billing, logging or a support process. Those remain product and operating decisions.

Arete-27B provides a compact example. Its model card identifies supervised fine-tuning of Qwen3.8-27B to change selected response tendencies. The intervention concerns model behaviour; it is not a complete application package. The card's details were checked on November 10. Arete model card

For procurement, ask whether the resulting behaviour matches your task. A model adapted for one preference or benchmark may not improve a different workflow. Preserve the distinction between the developer's stated training objective, its reported evaluation and the outcomes your team requires.

Test the surrounding application separately. A model can produce a sensible answer while the product retrieves the wrong document, applies the wrong account permissions or fails to record the result. Conversely, an application with good controls may still need a better model for the task.

Specify acceptance criteria at both levels. Model checks might assess answer correctness, instruction following and suitable uncertainty. Application checks should cover data access, action authorization, failure handling and the user's ability to correct an outcome.

A hosted route can let a team evaluate a model without first assembling the infrastructure to operate it. That can shorten the path to learning whether the capability is useful. It does not establish that a later self-hosted deployment will have the same limits, features or economics.

Thinking Machines' November 5 Inkling 2 Small announcement illustrates the distinction. It offered hosted sampling and fine-tuning through Tinker while describing full weights as a planned release after external testing. Hosted use and downloadable deployment were separate states in the announcement. Inkling launch announcement

Avoid treating a planned artifact as an available dependency. If a project requires weights to run in a specified environment, its delivery plan should identify the actual files, applicable terms and supported serving path before relying on them.

For hosted evaluation, record the exact surface being tested. A playground, training service and production inference endpoint can expose different features or limits. The model card's maximum context is not automatically the context available on every service route.

Ask what can be exported: prompts, evaluation cases, application data, trained adapters, complete checkpoints or only outputs. These are different forms of portability. A platform may support export in general while a particular model or account tier does not.

Weight availability is a technical fact, while permission to use those weights is a contractual question. Record the actual licence for the selected version, including the obligations that follow modification, distribution or commercial use.

ERNIE 5.5 Flash Base uses a custom Model License Agreement v1.0. The text checked on November 10 specifies a territory excluding the European Union, United Kingdom and South Korea, alongside commercial notice, attribution and revenue-related conditions. It should not be described as an Apache 2.0 release. Published ERNIE licence

That is a qualification issue to resolve before procurement, not a footnote to discover after adaptation work begins. A publicly downloadable artifact does not by itself establish permission for a particular operator, region or business model.

Use a brief licence record that identifies the model version, document version, intended use, operating locations and distribution plan. Route unresolved conditions to the person responsible for the organisation's contractual review. Keep the resulting decision with the technical evaluation so a later model swap does not bypass it.

Our open-weight model licence audit provides a structured way to gather those facts. Check hosted terms separately: permission to run a downloaded checkpoint and permission to submit data to a service are different matters.

Compare options over the same scope and period. A model API quote may exclude application development; an internal hosting estimate may exclude engineering support; an assistant subscription may include features the team would otherwise build. The figures are not comparable until the included responsibilities are clear.

Separate one-time work from recurring cost. One-time work can include data preparation, evaluation design, integration and adaptation. Recurring work can include inference, reserved capacity, monitoring, updates, review and incident response. Include failed attempts when estimating the cost of an accepted result.

Consider an entirely hypothetical comparison between two routes that meet the same acceptance standard. Route A requires £4,000 of initial work and £1,200 per month thereafter. Route B requires £16,000 initially and £700 per month. These are illustrative inputs, not provider prices or a Digital Applied quotation.

The simple break-even calculation is (£16,000 − £4,000) ÷ (£1,200 − £700) = 24 months. It assumes constant recurring costs, comparable quality and no additional migration or financing costs. If volume, staffing or the model changes, the result changes too.

Our RAG and fine-tuning cost comparison explores a related implementation choice. For procurement, keep the broader question visible: how much work remains before each option delivers the required outcome, and who bears that work?

Before selecting a route, map the obligations your team would inherit. A base checkpoint typically leaves more behavioural development to the buyer, while a managed product can cover more of the operating stack. Actual supplier contracts determine the allocation; the following matrix is a set of questions rather than a promise about every offering.

For each cell that remains unresolved, name the owner and the evidence needed. “The development team will handle it” is insufficient when the work involves infrastructure, data preparation, evaluation and support with different skills and budgets.

Do not infer deployment requirements from active parameter count alone. Hardware planning also depends on the complete model, weight representation, runtime support, working memory, request length and concurrency. A claim that only some parameters activate per token is not a complete memory or capacity estimate.

Use a representative workload when assessing serving options. Include long requests, concurrent use and required response times, not just one successful prompt. Record whether the configuration is supported and repeatable rather than a demonstration assembled for a single run.

The matrix should make gaps discussable before money is committed. If several critical obligations have no owner, choosing a more complete service may be more valuable than obtaining a model with a marginally better benchmark score.

Choose a bounded task with a defined acceptance standard. For example, assess whether the system can produce a source-backed internal answer from approved documents and correctly identify when the evidence is insufficient. Specify the documents, access boundaries and output checks before comparing options.

Evaluate a practical baseline first. That might be an existing hosted assistant or an unchanged post-trained model. The baseline establishes whether the task already works well enough and identifies the specific gaps that justify a more involved route.

Then test the smallest intervention that addresses those gaps. Improving retrieval, the workflow or the instructions may be sufficient. If the evidence points toward adaptation, define what improvement would justify its data and operating costs.

Keep development examples separate from final evaluation cases. Record the exact checkpoint or hosted model, configuration and application version so the result can inform a real purchasing decision. A demonstration with unknown settings is difficult to reproduce and easy to overinterpret.

Finally, test the exit path at a proportionate level. Confirm that the required data and configurations can be recovered, identify what would need rebuilding and record any dependency on an unreleased artifact. Portability becomes useful when it can support an actual move, not merely when a proposal promises flexibility.