AntLing has published a full matrix of six checkpoints for the Ling-3.0 base model: two sizes, tiny and flash, each available in three stages: pretrained, mid-trained, and WSM-merged. This is not one endpoint repeated under different names, but six separate official repositories, all public and ungated at the time of the check, each with an MIT license. None of the checkpoints has undergone post-training: this is not a chat or instruct release ready for use, but material for continued pretraining, fine-tuning, and research.

The distinctive part of this release is that the “base model” is not delivered as a single static artifact, but as a family of intermediate states along the training trajectory. The AntLing team attached a stage map, described as a first-party image from the release thread: context, not independent validation. For people working on base-model research, the value is not just the final checkpoint, but the ability to choose the entry point into the training pipeline.

This choice has concrete implications. A team planning continued pretraining on a specialized domain might start from the pretrained checkpoint, keeping control of the next phase. A team wanting to reduce the computational cost of fine-tuning could evaluate the mid-trained checkpoint, already further along the path, while the WSM-merged checkpoint represents a different stage of the trajectory. However, the release does not indicate which stage is best for every downstream task, nor does it provide guidance on behavior after quantization. Performance, latency, and memory consumption evaluations remain the responsibility of the adopter.

This granularity signals a structural shift in how base models circulate: no longer just final weights, but explorable training trajectories. For teams evaluating on-premise deployment, this opens interesting scenarios but also adds benchmarking burden. On one side, the MIT license and public availability of the repositories lower access barriers and support inspection and adaptation. On the other, the absence of independent validation and post-quantization numbers means a team must build its own test matrix before deciding which checkpoint to use. There is no declared “best”: there is a family to test.

In this sense, the release is more useful to those doing base-model research and development than to those looking for a production-ready model. The value is less in the single checkpoint and more in the ability to compare different stages of the same model, an approach that for on-premise teams means more control but also more validation work. For those evaluating on-premise deployment, there are trade-offs between adaptation flexibility and verification cost: analytical frameworks like those from AI-RADAR on /llm-onpremise can help structure these decisions, but the final choice depends on specific requirements.

Six checkpoints, two sizes, three stages: the story is not the finished product, but the freedom to choose where to start.