Choosing a base checkpoint is a route decision, not a leaderboard decision

[u/Designer_Mouse_6109]

If you are choosing an upstream checkpoint for domain work, the first question is not “which row wins?” It is: what uncertainty must the first pilot resolve?

Start with a decision card:

Decision	Known before a run	Keep open for the pilot
Objective	Continued pre-training, mid-training, domain SFT, post-training research, distillation, long-context work, and MoE research are the use categories named by the model cards	Task-specific pass and stop conditions
Family	Ling tiny is labeled 7.9B total parameters and 1.3B activated parameters per token; Ling flash is labeled 124B total and 5.1B non-embedding activated parameters	Memory, runtime, and task quality in the actual environment
Starting stage	Each family has final pre-training, final mid-training, and WSM-merged base checkpoints	Which stage fits the domain objective
Product state	All six are upstream checkpoints with no post-training, not finished chat or instruct releases	The downstream recipe and validation gates

Before the pilot, remove any row whose stage or intended-use boundary conflicts with the objective. Do not rank the remaining rows until the pass and stop conditions are explicit.

That makes the Ling-3.0 base model useful here as a concrete checkpoint menu, not as a preselected answer. Parameter labels are planning inputs; they are not memory or runtime measurements. A shared training recipe also creates a path to explore a strategy on tiny and then ask whether it scales to flash, but the supplied release evidence does not demonstrate that transfer.

The next step is to choose one family and one domain objective, enter its three repository identities into the shortlist, and define the pilot’s pass and stop conditions before seeing results.

Which constraint would you use to remove a checkpoint row before the pilot begins?