MMPF 1.0 RC1
兩種模式，同一個數，不同的路。
MMPF 必須在還不知道一條路要跑多久之前就選好它，事後再為那個選擇負責。效能模式取預測成本最低的；保證模式取可證明的上界最低的 —— 而那通常刻意比較慢。
案例
train_balanced_14
選擇
no_tree_ecm_light
效能模式取的是「機器校正後預測成本最低」的那條路徑。
實測成本
相對 oracle 的 regret
共形上界
事後最佳
取自 results_v1/mode_comparison.csv 的四筆真實資料。全部 30 個案例中，兩種模式有 24 次選出不同路徑，而保證模式的上界守住了 28 次 —— 那兩次沒守住的，都放在這裡而不是被拿掉。
狀態
- 版本
1.0.0rc1—— 發布候選，不是穩定 1.0- 授權
- Apache-2.0
- Python
3.11+- 模式
- performance、assurance、batch
- 帳本
- 4 個，於官方 MMLC Runtime 1.0.0 下重播
- 系列
- 3M 的第四個專案，接在 MMR-Bench、MMLC 與 MLF 之後
已驗證
四個 MMLF 帳本共 902 筆交易，在官方 MMLC Runtime 下全數 PASS，於 驗證，並在 CI 上跨 Python 3.11／3.12／3.13 再驗一次。
它量到了什麼
三十個案例、五條路徑、一份機器輪廓。以下每個數字都是實測，不是模型推估。
| 指標 | 效能模式 | 保證模式 |
|---|---|---|
| 基準總成本 | 99.995 ms | 188.089 ms |
| 中位 regret | 1.000 | 1.435 |
| p90 regret | 1.288 | 3.854 |
| CVaR90 regret | 2.092 | 5.300 |
| 最大 regret | 4.210 | 6.745 |
保證模式的總成本大約是 1.9 倍，而且在每一個分位數上的 regret 都更高。這不是勉強承認的缺點 —— 這就是買一個上界的價錢，而那個上界正是它的產品。
未覆蓋
保證模式的選中成本覆蓋率：93.333%。30 個案例中有 2 個，實測成本超出了該模式自己宣告的上界。
批次模式
當候選登錄表與批次都夠大時，逐一 GCD 會換成共用的餘數樹。引擎由校正選出，而在這台機器上校正與實測一致。
| 指標 | 數值 |
|---|---|
| 批次大小 | 128 |
| 候選上界 | 10,000 |
| 校正選出的引擎 | remainder_tree |
| 實測最佳引擎 | remainder_tree |
| 逐一 GCD | 1.666 ms |
| 餘數樹 | 0.663 ms |
| 加速比 | 2.513× |
| 校正與實測一致 | 是 |
怎麼跑
bash
python -m pip install -e .
mmpf calibrate --output machine/my_machine.json以兩種模式分別分解一個數，並驗證回傳的憑證。
bash
mmpf factor 1000036000099 \
--mode performance \
--machine-profile machine/current_machine.json \
--output performance-cert.json
mmpf factor 1000036000099 \
--mode assurance \
--machine-profile machine/current_machine.json \
--output assurance-cert.json
mmpf verify performance-cert.json在這個範例整數上兩種模式的選擇一致 —— 1000036000099 是 1000003 × 1000033，兩者都選 tree_1000_rho。但一致並不是常態：整個基準裡 30 次有 24 次兩者分歧。
它在 3M 裡的位置
MMPF 是這一組裡第一個必須做「決定」而不是做「紀錄」的。另外三個給了它事後為那個決定辯護所需要的詞彙。