IX2-0538

① SA Source

Context Before

One of the main changes we have made since v1 is the cadence with which we perform sweeps. Previously, we were jestermaxing and performed a full sweep over each configuration nightly. However, as we added more chips, disaggregated prefill, wide EP, and other features, we realized that running every single night was way too time consuming and wasteful. Moreover, it’s just not necessary – benchmarks only really need to be re-run when recipes change or a new software version is released.

We now trigger sweeps based on additions to a changelog at the root of the repo. When a developer makes a performance-impacting change to a given config, they add an entry to the changelog listing the affected config along with a brief description of the change. All configs are defined in a master configuration YAML file , which serves as the stateful representation of every data point to be swept, including core settings like ISL/OSL, EP, TP, DP, MTP, and so on. When a PR containing a changelog addition is merged, a workflow parses the referenced config keys, pulls the corresponding sweep definitions from the master config, and fans them out as individual GitHub Actions jobs. The jobs collect all data points for the full sweep and upload the results as artifacts.

Evidence

Below is a high-level diagram of how InferenceX launches jobs

Context After

image

Klaud Cold AI Usage

② Atomic Claim

文章提供一張 InferenceX 啟動 jobs 流程的高階架構圖。

  • Epistemic Mode: ASSERTED
  • Mapping Status: COMPLETE

③ Semantic Frame

{
  "attribute": "DESIGN_PROPERTY",
  "context_nodes": [],
  "entity": {
    "id": "04_knowledge_base/InferenceX",
    "label": "InferenceX"
  },
  "frame_type": "ATTRIBUTE",
  "qualifiers": {
    "condition_text": null,
    "numeric_mentions": [],
    "temporal_mentions": []
  },
  "value": {
    "numeric_mentions": [],
    "value_text": "文章提供一張 InferenceX 啟動 jobs 流程的高階架構圖。"
  }
}

④ Canonical Entity Mapping

RoleSurface LabelCanonical Target
entityInferenceXInferenceX

⑤ Human Review

請在 Properties 逐項確認:

  • 原文 → Atomic Claim 是否忠實
  • Atomic Claim → Semantic Frame 是否忠實
  • Canonical Entity mapping 是否正確
  • Epistemic mode 是否保留原文語氣
  • 最後選擇 review_action

Review state

Markdown 內文不是正式 approval。只有 Apply bridge 寫入的 Decision Ledger event 才是正式決策。