VLLM and VPLLM: standardizing a layered architecture.

The model is one part of the architecture.

A language model provides generation capabilities. Turning them into a consistent experience also requires decisions about behavior, knowledge, identity and boundaries. Putting all these decisions into one prompt makes it hard to distinguish system-wide rules from application-specific choices.

The laboratory’s proposal organizes these responsibilities into layers: the LLM as the inference foundation, the VLLM as a system profile, and the VPLLM as a private identity. An access channel presents the experience without becoming a new cognitive identity.

Illustrative video about layered language models.

From model to experience

LLM
Language capabilities
The base model generates responses. It may be accessed through a provider or through self-managed infrastructure, according to the application’s requirements.
VLLM
Shared behavior
Virtual Large Language Model: a logical layer bringing model selection, parameters, capabilities and common instructions together under a system contract.
VPLLM
Private identity and knowledge
Virtual Private Large Language Model: a configuration bound to a scope, with a purpose, identity, response framework and authorized knowledge.
04
Access channel
A website, app or integration presents the agent. Changing the channel should not, by itself, create another agent or expand its permissions.

What needs to be standardized

A common engine contract

The VLLM describes how language capabilities are offered: a reference model, permitted parameters and available capabilities. Changing providers requires validating this contract rather than assuming that different models are equivalent.

Private configuration with clear boundaries

The VPLLM specializes shared behavior through its purpose, tone, languages and knowledge sources. Its response framework specifies the expected reference; the desired adherence to that content needs to be defined and evaluated.

Explicit rule precedence

Private instructions may supplement system policy, but should not remove central restrictions. Retrieved content, documents and user messages are not given authority to change those rules.

Permissions outside the prompt

The application must check access to documents, tools and conversations on each operation. The word “private” does not guarantee isolation: identity, authorization and data separation must be implemented.

Version the effective configuration.

Standardization should make it possible to identify the combination of model, VLLM profile, VPLLM configuration and context sources involved in an execution. A later change should not erase the reference used to evaluate an earlier result.

Before promoting a new engine or response-framework version, evaluate responses using representative cases, record differences and plan a rollback. Layering supports evolution but does not replace compatibility testing.

One shared engine, two identities.

At a hypothetical research center, the same VLLM profile can support different agents. Common capabilities are shared, while each agent’s authorized context and purpose remain distinct.

Visitor guide

One VPLLM consults public guidance, opening hours and visitor information. Its purpose is to help people arriving at the facility.

Research assistant

Another VPLLM works with a team’s authorized documents. Sharing an engine does not give the first agent access to that collection.

Standardize responsibilities, preserve differences.

In this proposal, creating a VLLM or VPLLM does not mean training a new model or reserving a dedicated machine. They are configuration and operational abstractions. Their value depends on clear contracts, bounded context, verifiable controls and continuous response evaluation.