Apertus 1.5 report opens its multimodal training recipe

Swiss AI's Apertus 1.5 technical notes make the model's multimodal training and evaluation easier to inspect. The October publication describes 8B and 70B models with 262,144-token context. It also establishes a timing distinction: the Apache 2.0 weights shipped in July, rather than arriving with this month's report.

Key facts

• The release notes say the 8B and 70B weights were released on July 24, 2026 under Apache 2.0.
• Swiss AI documents a 262,144-token context window, described as four times the first generation's window.
• The training description says continued pretraining added four trillion tokens for the 8B model and two trillion for the 70B model.
• The multimodal design accepts text, images, and audio but generates text only; spoken-language processing remains experimental.

The October development is research disclosure

DeAI's October 20 RSS collection found the release notes, dated October 15 in the feed. The notes cite an October technical report and describe training stages, datasets, intermediate checkpoints, and evaluation tooling. Treating this as a new October model-weight release would misstate the chronology given by the project itself.

The notes present Apertus 1.5 as continued pretraining of the preceding models. They describe separate stages for unpaired multimodal material, paired examples, higher-quality cooldown data, and context extension. Post-training then adds instruction tuning, longer-context instruction data, verifiable-reward learning, preferences, and charter alignment for the smaller final model.

That disclosure is relevant to researchers trying to explain behavior rather than only use an endpoint. Intermediate checkpoints provide a way to investigate what changed at a particular training stage. Published data mixtures and recipes can make a reported improvement more tractable to examine, even when reproducing the entire training run remains expensive.

How multimodal input enters the model

Swiss AI describes an early-fusion design in which images and audio become discrete tokens in the same sequence as text. Its explanation contrasts that with attaching a separate vision encoder. The vocabulary expands while the language-model architecture remains unchanged.

This makes the difference between input support and generated output especially important. The models can answer text questions about non-text material; the notes do not claim that the released checkpoints synthesize speech or render images. A product planning a spoken assistant still needs a separate output component if it wants audible responses.

The experimental label on spoken-language processing also deserves to remain visible. A demo or an architecture description cannot establish reliable recognition across every accent, recording condition, or language. An application should evaluate the actual inputs it expects rather than treating the word multimodal as a single uniform capability.

Reproducibility includes evaluation settings

The project describes broader evaluations for vision, audio, reasoning, translation, instruction following, and tool use. It links public evaluation repositories and says results are published in the Every Eval Ever format. The notes explain that these records can include who ran an evaluation, how the model was accessed, generation settings, and metric interpretation.

That information helps distinguish two scores that appear to use the same benchmark label but were produced differently. Thinking mode, prompt formatting, runtime, and task subset can all change a result. Machine-readable records are useful because they can carry those conditions alongside the score rather than leave them in scattered prose.

This is still the project's description of its reporting infrastructure. DeAI has not independently reproduced the evaluations or audited every data source. Swiss AI's statements that new data follows its licensing and opt-out criteria should remain attributed to the project. Publishing a transparency repository makes examination possible; it is not itself a completed independent audit.

The notes also acknowledge that Apertus trails frontier open-weight models on some capabilities. That is a useful qualification for procurement. Transparency can be a reason to shortlist a model without establishing that it is the strongest choice for a particular coding or reasoning task.

Background and practical next steps

DeAI's open-weight versus open-source explainer separates checkpoint access from the broader materials needed to inspect development. Apertus's public recipes and data documentation are relevant to that distinction. The open-weight model guide and model hub cover the deployment and release context.

For a team choosing between the released sizes, the useful comparison starts with its actual documents and tool schemas. Evaluate ordinary responses and thinking mode separately, include representative image inputs if needed, and record the serving configuration. Maximum context is a supported capacity claim, not proof that every long document will be used accurately.

For researchers, the next step can be narrower: compare adjacent intermediate checkpoints using the public task definitions. That can test whether a claimed training-stage improvement appears on a particular held-out set without requiring a complete pretraining reproduction.

The immediate value of the October material is an expanded evidence trail. It gives builders and evaluators more artifacts with which to question the model's behavior and reported results. Its availability should be reported on those terms, with the July weight-release date intact and with project claims distinguished from checks that outside researchers have actually completed.