日前，GitHub 上出現了一個名為 MRVPlatform（代號 OrbitTest）的開源命令列工具，專門用於檢驗 ONNX 模型在遭遇輻射誘發的位翻轉時，是否仍然能維持正確的預測。這類位翻轉在學術上稱為單粒子翻轉（SEU），是衛星在軌執行中真實存在的記憶體錯誤來源。該工具並非簡單驗證模型能否執行，而是模擬星載計算機實際可能發生的儲存損壞，再評估模型的預測能力。
工具的工作流程是：先載入 ONNX 模型和驗證資料集，建立無故障的乾淨精度基線；然後根據使用者指定的故障率（單位是每位元每天的錯誤數）和任務暴露天數，計算每個權重張量中期望出現的位翻轉數量，即 expected_flips = fault_rate × tensor_size_bits × mission_days。隨後，工具直接在 IEEE-754 float32 的位元表示上隨機注入翻轉——符號位、指數位和尾數位均可能被選中——再用被破壞的權重重新對驗證集進行推理。為了避免單次試驗的偶發性，它會以蒙特卡洛方式重複多次（預設 20 次），並報告準確率的均值、標準差和範圍。最終，工具給出一個 0 到 100 的韌性評分：100 × (平均故障準確率 / 乾淨準確率)，並截斷到 [0,100]。
除了整體評分，逐層敏感度分析是該工具最有價值的輸出之一。它會固定只破壞某一個權重張量，保持其他張量乾淨，重複試驗後按平均準確率下降幅度排名。這樣工程師可以知道：如果只能加固或複製一個層，哪個層收益最大。專案在 README 中也詳細說明了故障率預設的來源：leo-typical（2×10⁻⁷ 錯誤/位元·天）源自 SAC-C 衛星上 4-Mbit SRAM 的實測在軌 SEU 率；saa-transit（1×10⁻⁵）是對南大西洋異常區影響的量級估計；solar-storm-worst-case（1×10⁻³）則與 1989 年 10 月 CREME96 最壞日基準一致。後兩者被明確標註為估算值，不能替代任務特定的輻射分析。
使用上，該工具是一個 Python CLI。使用者必須提供 --model 和 --data，並以 --fault-rate 或 --preset 指定故障引數，此外可設定 --mission-days、--trials、--layer-trials、--seed 等選項。輸出包括控制台摘要、完整 JSON 報告（含每次試驗細節、分佈統計、模型和資料集雜湊）以及準確率對比圖。
專案開發者特意強調了當前侷限：只破壞模型權重，不涉及啟用值、梯度、控制流或飛行軟體；韌性評分僅基於 top-1 準確率；每次執行只覆蓋單一工作點；目前只對一個小型線性模型和一個預訓練 CNN 做過驗證，尚未覆蓋 Transformer 等架構；兩個預設是數量級估算；推理僅限 CPU、單影像。整體而言，這是一個為期三天的 CLI 驗證衝刺，目的是在投入完整 SaaS 產品前，確認故障注入方法論是否有效、結果是否足以說服持懷疑態度的航空航天工程師。