A base model is not an assistant: recalibrating the comparison

Yandex has published AliceAI-Foundation-80B-A3B-Base on Hugging Face. The name says a lot: 80 billion total parameters, reduced active component, mixture-of-experts setup. But the element that should guide analysis is not scale. It is a base model, not a post-trained version. This is not a minor detail: a base model without fine-tuning and alignment has a different profile from instructed Qwen or DeepSeek. It is not ready for chat, tool calling, or agents. Comparing it with already refined models is an asymmetric exercise.

For those evaluating on-premise deployment, the difference is practical. Weights alone are not enough. The next step matters: fine-tuning, alignment, integration with inference runtimes. These elements determine real production usability far more than raw pretraining benchmarks. A team that needs to build an internal assistant or an agent on company documents cannot consider AliceAI as a direct alternative to instruct models. It must design an adaptation path with resource and time costs.

There is also a signaling issue. Positioning a base model next to Qwen and DeepSeek may indicate ambition in pretraining. But the comparison shifts to the quality of initial training, not the maturity of the whole pipeline. For AI-RADAR this is a recurring point: those building local infrastructure do not buy only weights, they buy the maturity of the chain from training to serving. The distinction is structural, not stylistic.

Missing Llama.cpp support: runtime as adoption prerequisite

The second concrete element is the absence of Llama.cpp support. In self-hosted and local contexts, Llama.cpp is one of the most widely used runtimes for executing LLMs on CPU, consumer GPU, and hardware with limited VRAM. It is not a hobbyist detail: it is an infrastructure piece. A model with custom architecture that has no backend in that project remains outside the toolbox of many operators. It cannot enter lightweight inference pipelines, cannot be tested under realistic conditions by those using machines without expensive accelerators.

The bottleneck is not permanent. Ports arrive when there is demand. But today the model cannot run in stacks that many on-premise teams have already adopted. This creates a waiting window: those who want to experiment with AliceAI must first invest in an alternative runtime or wait for the community to write support. It is not a question of willingness, but of development priorities. The community tends to focus on models that show concrete adoption or promise of post-trained releases.

The paradox is evident: to properly evaluate a custom architecture, local tests are needed, but local tests require a compatible runtime. This circular dependency is common for new-generation models. Architectures that depart from standard transformer designs or already supported designs pay an entry cost. For on-premise deployment, runtime support is a non-negotiable selection criterion, as much as model quality.

From fine-tuning to foundation model design

Yandex's choice not to rely on Qwen3 and to develop its own architecture signals a shift. International competition on foundation models is no longer confined to fine-tuning existing models. It is moving toward model design. This has deep implications for those building on-premise infrastructure. If differentiation no longer lies only in post-training but in architectural design, organizations must manage a growing variety of model families, each with specific execution requirements.

The proliferation of custom architectures increases runtime maintenance costs. Each new family may require dedicated support work: kernels, conversions, inference optimizations. Those who have bet on a single serving framework must deal with the need to update stacks, test compatibility, and train staff. This is not a one-time cost: it is a recurring cost that adds to the TCO of self-hosted infrastructure.

Model portability across different stacks decreases. A model with a standard architecture can be moved relatively easily among different inference engines. A custom design introduces friction. This is not a judgment on AliceAI's technical quality; it is a consequence of the landscape. Those evaluating data sovereignty and local control must also consider architecture sovereignty: how much do we depend on a single vendor or a single community to run a model.

The invisible TCO of non-standard architectures

When talking about on-premise deployment, the cost is not just hardware. There is an integration TCO that often does not appear in comparisons based on parameters or benchmarks. A model with custom architecture forces a review of fine-tuning, alignment, quantization, and serving pipelines. If the runtime is not ready, the team must dedicate resources to development and maintenance. If the runtime arrives late, the project remains on hold. This opportunity cost is rarely quantified but affects decisions.

Adopting a base model like AliceAI in an enterprise context requires skills that are not evenly distributed. Downloading weights is not enough. You need to know how to set up fine-tuning, possibly quantization to reduce VRAM requirements, and connect the model to business tools. Without support from the most widespread frameworks, these steps become more onerous. The risk is that the project remains confined to the lab, as an interesting artifact for researchers, instead of entering production.

There is also a reliability issue. A mature runtime brings years of fixes, optimizations, and verified use cases. A newly written backend for a new architecture is less tested. Those managing critical services cannot afford surprises. The maturity of the inference ecosystem is a value multiplier: it can make a mediocre model more usable, or an excellent model inaccessible. AliceAI currently pays this gap.

Who benefits and who loses in this scenario

The immediate beneficiaries are research labs and teams working on pretraining. For them, a custom architecture is an object of study, not necessarily a component to put into production. Organizations with internal development resources and proprietary serving stacks can also see an advantage: if they can write their own backends, architectural novelty can offer differentiation.

Those who lose, or rather experience friction, are self-hosted operators using Llama.cpp or similar frameworks as a standard base. For them, AliceAI is not currently a plug-and-play choice. Inference platform vendors must also invest to add support, and they will do so only if demand justifies it. Companies that want data sovereignty and local control but lack an internal research team remain in a waiting position.

There is an intermediate category: integrators and consultants. For them, the proliferation of architectures is a business opportunity, but also an increase in complexity. Each new model requires updated skills, compatibility testing, documentation. The market rewards those who can reduce this complexity, but the margin for error grows.

What to watch in the coming months

The first signal is obvious: the possible arrival of an AliceAI backend in Llama.cpp or other widespread runtimes. This would rapidly change the model's accessibility for the self-hosted community. It is not a binary question; even partial or experimental support can indicate direction. The second signal is the publication of a post-trained version. If Yandex releases an instruct or aligned model, the comparison with Qwen and DeepSeek will become more balanced and the value of the architectural investment can be better assessed.

A third element to monitor is documentation. The presence of fine-tuning examples, conversion scripts, indications on VRAM requirements and quantization pipelines says a lot about the seriousness of the project. Without these materials, the model remains an artifact for researchers. Finally, one should observe the community reaction. If independent developers start working on porting, it will be a demand signal. If the project stalls, it will be an indicator that architectural novelty alone is not enough to justify investment.

In summary, AliceAI 80B is not currently a plug-and-play model for self-hosted environments. It is a research signal and a technical direction. The open question is not whether the architecture is valid, but whether the inference ecosystem will invest before a post-trained version arrives. For those evaluating on-premise deployment, the story confirms that choosing an LLM is never just a choice of weights: it is a choice of value chain.