Skip to content

feat: decouple FPM workflows from analytical model classes - #238

Draft
Arsene12358 wants to merge 6 commits into
feat/guided-fpm-clifrom
feat/fpm-model-decoupling
Draft

Arsene12358 wants to merge 6 commits into
feat/guided-fpm-clifrom
feat/fpm-model-decoupling

Conversation

@Arsene12358

@Arsene12358 Arsene12358 commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

Why and what changed

Whole-forward FPM measurements can now drive onboarding, prediction, recommendation, and replay without an analytical model class. A complete fpm_profile supplies the exact model/runtime/topology/precision identity and per-rank resource bounds; Rust constructs the selected estimator through main’s canonical ForwardPassPerfModel::best_available(ForwardPassPerfModelConfig) interface. The Python binding and all application callers use that same contract.

Interpolation controls live at estimator_config.fpm_interpolation.method: auto|sol|direct. Nested auto selects SOL for a registered architecture and direct for an unknown architecture with a valid profile. Explicit direct requires a profile; explicit SOL requires a registered model. Main’s separate top-level estimation_mode: auto retains op_level -> fpm_interpolation -> fpm_regression priority. Invalid configuration does not trigger fallback. Construction pins the method and preserves the full profile, precision, roots, and policy in provenance and exported configs; query coverage errors never change estimators.

Profile-based onboarding explicitly generates:

estimation_mode: fpm_interpolation
fallback_policy: deny
estimator_config:
  fpm_interpolation:
    method: direct

Native direct interpolation uses genuine measured timings, within-curve interpolation and two-sided KV brackets, including the validated wider KV bracket when the narrower one is unavailable. It excludes synthetic fake_fallback rows and unsupported extrapolation. Fake-only cells cannot report ready or shadow usable later data roots. Direct timing and profile-based memory admission need no operation graph or per-operation silicon data. The existing registered/SOL and regression algorithms remain unchanged.

Profile and quantization schemas live in lightweight aisimulate_core modules, with application re-exports sharing the same types. Native core exports load on use, so parsing and strict configuration validation remain inside the resource-supervision boundary while the core SDK retains main’s separation from application orchestration. Supported aisimulate.sdk and aisimulate_core.sdk paths share canonical objects; main’s removal of the old aiconfigurator import namespaces is preserved.

Recommendation resolves profile defaults through the same native configuration normalization and serialization used by estimator construction. Cache identity and exact candidate checks use that normalized request while explicit conflicting overrides still fail.

The same profile supports collector planning and memory admission before timing data exists. Collection checks exact topology/precision and the observed runtime version. The supported profile scope is vLLM decoder-only TP/DEP/TEP, PP1/CP1, and linear KV storage. Unsupported provider combinations fail explicitly.

Review map

  • Risk level: high; native interpolation, construction readiness, serialized identity, and compiler/sweeper/collector boundaries.
  • Start with native fpm/config.rs, fpm/model.rs, engine/readiness.rs, operators/fpm_forward.rs, then the lightweight aisimulate_core/fpm_profile.py/quantization.py, SDK runtime bridges, and application profile transport.
  • Public or serialized contract changed: complete canonical fpm_profile, nested interpolation method, resolved provenance, and native EngineSpec interpolation field. Legacy flat fields migrate only at input boundaries.
  • Compatibility: the combined EngineSpec format is version 20 because main and this branch previously used version 19 for different positional layouts. Regenerate old binary EngineSpecs; both older layouts are rejected before payload decoding. Profiles require an explicit literal runtime matching the declared deployment. No-profile version defaults retain main’s policy.

Evidence

Merge integration head: 8d798b1d3a1e80fa14df112eb830bb922b148314, on #196 head 05bf61484a9ebe7358c66e29fdbdce9f0c453b2a. Independent review closed all four integration findings with no deferred items. Final source suites passed 546 root consumers and 322 package tests, including real profile recommendation/export and optional nonfinite regression-input serialization. The 386 registered-path parity checks passed without golden updates; native FPM, schema and public API checks also passed.

The combined stack at #248 head 45574cd95c27d4c652a15cd1995ba0fb95303990 was built and tested as an installed wheel. MiniMax/H200 TP4 and GLM/B200 DEP8/TEP8 each completed config-derived onboarding, prediction and recommendation; each exported recommendation replay matched all 80 compared serving metrics. Class construction and precollection timing guards remained clear. These checks use the existing timing cells with declared resource bounds, not newly measured memory or serving-runtime qualification.

Exact-head Fast CI passed on 8d798b1d3a1e80fa14df112eb830bb922b148314; DCO and generated CODEOWNERS checks passed as well. This remains a draft requiring the applicable human reviews and Full CI.

The prior direct-interpolation implementation reproduced all 32,409 genuine exact points and rejected 306 synthetic-only coordinates. Its frozen MiniMax and GLM holdout outcomes are retained; the prior worst GLM holdout error is 141.54%. These checks establish implementation parity and bounded coverage, not general predictive accuracy.

Modeling or data provenance

No measured timing data or per-operation silicon data changes relative to main. Existing checked-in Parquet/metadata pairs provide timings; AIC_ALLOW_UNLISTED_VERSIONS=1 explicitly permits the retained 0.25.1 fixtures. Validation memory bounds and checkpoint declarations are illustrative inputs, not hardware memory qualification or proof of historical checkpoint provenance. No new GPU collection was performed.

The historical MiniMax BF16 FMHA/FP8 KV cell remains a prediction identity. New collection uses checkpoint-native precision and rejects a mismatched profile instead of relabeling that data; a new native-FP8 campaign requires a separate clean dataset because existing publication IDs omit FMHA. GLM’s FP8 FMHA/KV identity is preserved.

Tracking

Signed-off-by: Yiming Liu <yimingl@nvidia.com>
Signed-off-by: Yiming Liu <yimingl@nvidia.com>
Signed-off-by: Yiming Liu <yimingl@nvidia.com>
@copy-pr-bot

copy-pr-bot Bot commented Sep 16, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@coderabbitai

coderabbitai Bot commented Sep 16, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

Comment @coderabbitai help to get the list of available commands.

Signed-off-by: Yiming Liu <yimingl@nvidia.com>
…ndary

Signed-off-by: Yiming Liu <yimingl@nvidia.com>
Signed-off-by: Yiming Liu <yimingl@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant