Outcome and baseline
Extend qualified model coverage through existing FFN semantics or an explicitly
accepted extension. CrossPool has engine-neutral FFN Model Adapters, automatic
discovery, serving-specific adapters, and concrete numerical/graph suites.
Existing coverage is the comparison baseline, not proof for an untested family
or for every topology of an existing family.
This issue selects and scopes one next increment. Its completion does not
require implementing the selected model, and it does not promise every
model/serving-engine/accelerator combination.
Suggested implementation route
- Compare an explicitly bounded shortlist of concrete model families with
the supported-model baseline. Record FFN formula, activation, Dense/MoE
layer policy, shared experts, geometry, routing, checkpoint mapping, dtype,
operators, TP constraints, and serving integration requirements.
- Separate families compatible with current gated Dense/MoE semantics from
those needing Unary FFN, expert parallelism, quantization, a Router change,
or another operator. Use a minimal source/checkpoint probe when static
evidence cannot resolve compatibility. Record resource prerequisites.
- Recommend one concrete family/model increment and its accepted-boundary
delta, independent reference, topology, dtype, and graph evidence. Propose
a focused task or a target plan for any new semantic capability.
- Once that scope is accepted, implement checkpoint mapping, model adapters,
and any separately accepted operator or semantic extension at their owners.
- Run the selected model's independent FFN numerical and installed-serving
graph qualification. Update supported-model claims only for the actual
model, topology, and execution scope proved by that evidence.
Discovery completion evidence
- A concrete compatibility matrix distinguishing source evidence, existing
qualification, missing capability, and unresolved assumptions.
- A recommendation for one bounded increment with model identity, required
weights/resources, reference strategy, and qualification scope.
- A reviewed implementation recommendation or an evidence-backed conclusion
that the reviewed candidates need a deferred prerequisite capability.
Missing weights or hardware are recorded prerequisites, not model
incompatibility. Compatible families can become focused implementation tasks;
new FFN semantics require their own accepted design. Timeline observability
may aid diagnosis, while existing numerical qualification is directly reusable.
References
Outcome and baseline
Extend qualified model coverage through existing FFN semantics or an explicitly
accepted extension. CrossPool has engine-neutral FFN Model Adapters, automatic
discovery, serving-specific adapters, and concrete numerical/graph suites.
Existing coverage is the comparison baseline, not proof for an untested family
or for every topology of an existing family.
This issue selects and scopes one next increment. Its completion does not
require implementing the selected model, and it does not promise every
model/serving-engine/accelerator combination.
Suggested implementation route
the supported-model baseline. Record FFN formula, activation, Dense/MoE
layer policy, shared experts, geometry, routing, checkpoint mapping, dtype,
operators, TP constraints, and serving integration requirements.
those needing Unary FFN, expert parallelism, quantization, a Router change,
or another operator. Use a minimal source/checkpoint probe when static
evidence cannot resolve compatibility. Record resource prerequisites.
delta, independent reference, topology, dtype, and graph evidence. Propose
a focused task or a target plan for any new semantic capability.
and any separately accepted operator or semantic extension at their owners.
graph qualification. Update supported-model claims only for the actual
model, topology, and execution scope proved by that evidence.
Discovery completion evidence
qualification, missing capability, and unresolved assumptions.
weights/resources, reference strategy, and qualification scope.
that the reviewed candidates need a deferred prerequisite capability.
Missing weights or hardware are recorded prerequisites, not model
incompatibility. Compatible families can become focused implementation tasks;
new FFN semantics require their own accepted design. Timeline observability
may aid diagnosis, while existing numerical qualification is directly reusable.
References