In this analysis
Document operator, caller and exposed capability before interpreting a service-related condition attached to the model artifact.
For Mistral Large4, an internal application and a model-serving offering are different deployment descriptions, so an inventory should identify the actual relationship before interpreting release terms.
Describe the arrangement first
A deployment diagram should show who operates the model, who calls it and what the caller receives. These facts are more informative than a machine’s location. A system running on private infrastructure can still expose a model capability to others, while a remote service can be consumed by an internal workflow.
The published condition
The weight announcement identifies a modified license with a model-as-a-service condition. The earlier Mistral3 release and Large4 preview establish preceding stages, not a universal permission statement for every later arrangement. This article records the distinction without deciding whether an individual deployment satisfies the full terms.
The practical documentation task is to preserve the facts needed for review. Calling a system internal because one component belongs to the operator can be incomplete if another component exposes the model to a different set of users.
A deployment map
| Relationship to record | Why the distinction matters |
|---|---|
| Model operator and application operator | They may be different parties with different responsibilities. |
| Direct model interface and finished application output | They describe different ways the capability reaches a user. |
| Intended users and actual exposed users | A configuration can differ from the diagram originally approved. |
These are descriptive questions rather than a substitute license test. The authoritative terms remain the relevant source, and a short table should not invent exemptions or obligations that the release does not state.
Changes can occur without moving weights
Imagine an organization first using a model for its own document processing, then exposing a general-purpose endpoint. The checkpoint and host can remain unchanged while the relationship between operator and caller changes. A model-only inventory would miss that operational transition.
Review the diagram when the exposed capability or user relationship changes. Preserve the prior arrangement rather than rewriting history as if the new use had always been present. This helps separate an artifact upgrade from a deployment change that needs its own examination.
The retrospective implication
The release makes artifact access and distribution boundaries part of the same historical event. Understanding it requires both the exact license identity and an accurate description of the system being considered.
The conclusion is to document the relationship before applying shorthand labels. This avoids treating hardware location, organization branding or a wrapper’s license as sufficient evidence about the conditions attached to the model artifact itself.
Further analysis: Reproducible inference stacks: preserving a GPU pilot’s result; GPU hosting for multimodal models: count more than text.