Apertus 1.5 Release Notes: What Enterprise Teams Should Verify

Apertus 1.5 has a 262,144-token context window and accepts image and audio input, but generates only text. For enterprise teams, that changes what to test; it does not establish whether the model meets a workload's accuracy, capacity, or governance requirements. ¹

The release notes describe Apertus 1.5 as continued pretraining of Apertus 1.0, with additional training disclosures and reported improvements across several evaluations. Those results are not deployment evidence. Treat the update as a reason to revise your evaluation plan, not to skip it. ¹

Apertus 1.5 training and model scope

Apertus 1.5 is continued pretraining, and its architecture remains unchanged; the vocabulary was extended. The 8B model received 4 trillion additional training tokens, bringing its stated total to 19 trillion. The 70B model received 2 trillion additional tokens, bringing its total to 17 trillion. ¹

Pretraining used four stages: unpaired text and media, paired image-caption and audio-transcript data, a cooldown phase with higher-quality data and more math and code, and a long-context phase that expanded the window step by step from 8,000 to 262,144 tokens. More than half of the training tokens are text-only. Refreshed text sources include FineWeb2-HQ+, FinePDFs, and Nemotron-CC. ¹

Post-training includes supervised fine-tuning, long-context supervised fine-tuning, reinforcement learning, direct preference optimization, and charter alignment. The release notes report 3.7 million text SFT samples, plus image and speech data, and about 350,000 prompts for reinforcement learning with verifiable rewards. Tool-use data is restricted to execution-verified trajectories. The text SFT mix, preference pool, and training pairs are released. ¹

The release describes Apertus as having open weights, open data, open values, and published training details. It says new data is publicly available, permissively licensed, and retroactively respects robots.txt opt-outs. ¹

Analysis: These disclosures give evaluators more material to inspect, including data sources and training methods. They do not, by themselves, settle the legal status of every model or training artifact. Review the relevant terms and artifacts separately before treating openness as grounds for a deployment decision.

Multimodal capability: what's documented and what isn't

Apertus 1.5 accepts images and audio, but generates only text. Spoken-language processing is described as experimental. ¹ The release documents multimodal input, not image or audio generation; it does not establish that every speech task is production-ready.

The models use early fusion: image and audio tokens enter the same sequence as text tokens rather than using a separate vision encoder. The architecture remains unchanged, and the release notes say training runs at text-only speed. ¹ That is a training-time description, not a serving benchmark, so it does not establish inference latency or capacity.

Tokenization figures can inform prompt design: the release notes say a 512×512 image becomes 1,024 tokens with the Emu3.5 tokenizer, while audio uses 40 tokens per second with WavTokenizer. ¹

Enterprise AI model evaluation: a deployment checklist

Analysis: The release notes leave several questions for your own testing. They describe training and reported evaluation gains, not serving behavior on your hardware or accuracy on your data. A practical checklist follows from that gap:

• Workload accuracy. Inspect the published evaluation records, then reproduce the relevant tests on internal tasks. Run both the 8B and 70B models rather than assuming one predicts the other.
• Long-context and multimodal serving. A 262,144-token window and early-fusion inputs say nothing about latency, throughput, or memory. Measure these under realistic prompt lengths and image or audio volumes.
• Speech tasks. Because spoken-language processing is described as experimental, test it separately and do not fold it into a general sign-off. ¹
• Licenses and artifacts. Review the terms for every model and data artifact you depend on.
• Governance and security. Settle access controls, data handling, and audit requirements before production traffic reaches the model.

Keep the same test set across every candidate so results are comparable. A governed model catalog makes it easier to line candidates up against one set of constraints. One reading is that routing rules for region, data policy, and allowed models are easier to enforce in an enterprise AI gateway than scattered through application code. For a similar exercise on another vendor's headline limit, see Gemini 4 Argon's 1M-Token Output Cap: What API Teams Should Verify Before Building Around It.