週報 #210/12–10/18募資前紀錄
這週把小麥哪些地方接起來了，哪些失敗還是要繼續查
這週從單區塊數值、小模型的 True 接線與 CPU 更新保存，繼續做到故障回滾、同機 runtime 搬移和限定 CUDA 流程，最後在 A100 的 9B 等級模型完成兩次選定參數更新及第一次保存點的新程序恢復。我把公開、保管和退役也一起補進來，不過原多層 FP32 0/14、負控制 104/112 仍然失敗，第二保存點尚未第三程序重載，自主研究、一般輸入與能力提升還要另外驗。
W42 / NUMERICAL INSPECTION
把更新接起來，讓失敗繼續可見。
六組圖解看懂：單區塊數值、小模型接續、寫入後故障，以及 A100 兩次選定參數更新。每一段都保留自己的測試範圍。
真權重的單一 MLP，哪些數值對上了？
10/13 把前向與手動反向放進同一個固定門檻，先釘住一個區塊。
左右滑動看完整圖，或展開下方數據表。
查看圖表數據
| 項目 | 條件 |
|---|---|
| 權重與輸入 | 真權重轉 FP32；人工輸入與上游梯度 |
| 裝置 | CUDA |
| 比較元素 | 151,027,712 |
| 最大絕對差 | 3.72529e-9 |
證據邊界只是一個 MLP，並未驗收完整 decoder、一般輸入或原生 BF16 每步運算。小型 CPU BF16 取整診斷另有範圍，不能併入此結果。
多層 FP32 仍全敗，位元相同驗的是另一件事
4／8 層、hidden 64、intermediate 128、vocab 97。14 個新種子 CPU 人工案例，完整協定仍是 FAIL。
左右滑動看完整圖，或展開下方數據表。
分段重算保住原結果
GDN 的輸出與梯度原始 uint8 位元相同，支持這段重算沒有改值；它沒有證明原值符合另一個 FP32 參考。
控制本身也必須能抓到錯誤
原凍結控制漏掉部分錯誤。非連續資料可能改到副本的修補另存，人工反例不能回頭改寫原協定結果。
查看圖表數據
| 檢查 | 結果 | 能說明什麼 |
|---|---|---|
| FP32 | 0/14 PASS · 14 FAIL | 固定數學與框架參考門檻未通過 |
| GDN 重算位元 | 14/14 | 重算與原結果逐位元相同 |
| 負控制 | 104/112 | 未全數偵測，完整協定 FAIL |
補償候選在同一批已曝光案例仍是 0/14，而且更慢，因此沒有採用。這不是新一輪盲測。
證據邊界合成小模型的數值協定。這些分母來自不同性質的檢查，不能相加變成能力通過率，更不能推成完整 9B 通過。
CPU 接線開始能更新、保存，也保留寫入後的失敗
10/15–18 的進展是縮小配置的工程接續。各分支有自己的設定與驗收，不能拼成一次完整 9B 接管。
先改到狀態，再驗回滾
縮小 FP32 active Group 案例核對宣告狀態回復，並換新程序接續。外部 I/O 與任意 Python 記憶體仍不在保證範圍。
保存出錯時，預設載入拒絕
指標先往前、帳本未完整時，要明確指定上一個有效保存點。多檔案保存尚非原子操作，損壞 journal 仍可能需要復原。
查看圖表數據
| 分支 | 已核對與限制 |
|---|---|
| FP32 寫入後回滾 | 第 3 次實寫後故障，宣告狀態回復及新程序接續 |
| BF16 儲存 | 研究與 master 使用 FP32；active BF16 Group 未驗 |
| 較寬設定 | 僅局部 state-value 數值，未整套 cold-next |
| 另一根目錄及 runtime | 同一台 Windows 主機；未驗跨機或乾淨重裝 |
證據邊界沒有因此完成原生 BF16、全模型更新或全程串流。完整模型、optimizer、gradient 與 graph 的物化成本仍在；不同配置的最大規模不能拼在一起。
A100 的 9B 選定參數，接到第二次更新
10/18 選定 47 組參數。固定前綴 "a"、目標 " b" 由主機提供，沒有模型自主出題。
左右滑動看完整圖，或展開下方數據表。
查看圖表數據
| 階段 | 參數張量改變 | master 張量改變 | 保存後的新程序 |
|---|---|---|---|
| 更新 1 | 6/47 | 10 | 第一保存點已新程序恢復，列明狀態及 RNG 投影相等 |
| 更新 2 | 9/47 | 12 | 第二保存點尚未第三程序重載 |
第一次更新、恢復與 RNG 原件有編輯盤點讀回。第二次更新與新保存點沿用既有獨立審查，這次沒有重新讀遍全部遠端原件。原 JOB_TIMEOUT 與 recovery-pointer FAIL 都保留。
證據邊界兩次選定參數更新與第一次保存點接續。未證明全參數訓練、第二保存點冷重載、任意或長輸入、32 層一般數值、完整 True 接管、自主研究或持久能力提升。
一週接起工程，也把每條界線留在原處
週期 10/12–18，證據截止 10/18。10/26 只增補圖解，沒有把後一週結果倒填進來。
每日工程時間線
- 單區塊與研究梯度先核對2026-10-13
單 MLP 的 FP32 CUDA 比較與 17 組研究梯度有界核對；文字格式及方法拒絕仍保留，未進入新任務評估。
- 接成多層，原門檻失敗2026-10-14
14 個新種子案例的 FP32 全敗。重算位元一致性有通過；負控制未全數偵測，完整協定仍 FAIL。
- CPU 小模型接回 True 更新入口2026-10-15
接上原 caller、參數 owner、更新旗標、保存與新程序下一步。各配置分開驗證；補償候選仍敗，未採用。
- 寫入後故障與混合精度範圍2026-10-16
縮小 FP32 案例第三次寫入後注入故障，核對宣告狀態回滾及新程序接續。BF16 儲存搭配 FP32 計算，較寬配置僅局部數值。
- 保存故障、同機搬移與原件保管2026-10-17
缺件、保存中斷和指標先行時預設載入拒絕。另一根目錄與 runtime 仍在同一 Windows 主機；封存校驗不等跨機重啟。
- 限定 CUDA 接續到 A100 選定參數2026-10-18
先驗 h8 三層暫存開關及回退，再做 9B 等級選定參數雙更新。第一保存點有新程序恢復；第二保存點仍缺第三程序重載。
十關的版本來源
左右滑動看完整圖，或展開下方數據表。
當前來源實跑、歷史沿用與混合關卡，都保留自己的來源。十項不是同一新版全部重跑。
原件封存、雜湊讀回及四個歷史版本內容重建，是資料保管證據。部分舊 traces 已退役，完整封存重新解開及新環境啟動仍未全部走過。
證據邊界更新、控制、封存與目錄盤點各自回答不同問題。呼叫減少不等量到加速，檔案保存不等模型可重啟，人工接線不等模型自主發明方法。
當週用了哪些開源工具？網址直接放上來
只列公開紀錄明確出現的工具，版本跟著原案例。完整 GitHub 倉庫網址與授權可直接讀取。
PyTorch
CPU 案例 2.14.0+cpu；CUDA 版本未公開10/14 小型 CPU 多層對照明列 Torch 版本；10/13 單 MLP 保留 Torch CUDA GEMM 與基本逐元素 kernel。手動反向仍要接受獨立數值門檻。
BSD-3-Clause · 上游授權 ↗CPython / Python
CPU 案例 3.12.14；其他執行未列版本10/14 人工多層 CPU 案例的公開執行環境明列 Python 3.12.14。這個版本只綁該案例，不推定整週 CPU 與 CUDA 都相同。
Python Software Foundation License Version 2 · 上游授權 ↗當週公開使用證據：10/14 CPU
本期沒有據 RNG 或 HF 字樣推定 NumPy、Transformers 已實際執行。這份清單也不是完整依賴清冊。
證據邊界CPU 公開版本只綁 10/14 的小型案例；其他程序與 CUDA 版本未公開就不猜。10/26 查閱上游授權不代表當週安裝了新版，也沒有把後續外接研究助手補寫進 W42。
接著閱讀未改寫的完整週報正文，查原始進展、失敗與限制。圖解依公開摘要整理；雜湊承諾原件 bytes，不代表完整實驗重現。
這週做成了什麼
這篇週報原本在 10 月 15 日先整理了一次，後來這幾天又接著做了不少事情，所以這次把 10 月 12 日到 18 日這一週，能核對到的主要工作一起補進來。因為如果只看最後大模型更新成功的那一段，其實很難知道前面為什麼要做這麼多小模型、保存和失敗檢查，也容易把不同版本做成的事情，當成同一個版本一次就全部做成了。
這週前面還在處理 R20 那一輪留下來的問題。真模型的文字採樣有對回原來的結果，但文字內容仍有格式錯誤，研究方法的回覆也在原本允許的修正次數用完後被拒絕，還沒有走到方法執行和新題評估。另外，同一份實際特徵拿來核對的 17 組研究端梯度有對上，原更新資料的只讀逐位元核對也有一致，不過原執行器的拒絕紀錄仍然留著，這幾件事支持的範圍要分開看。
10 月 13 日比較明確往前走的一段，是原模型的一個 MLP 區塊，也就是模型裡的一部分運算。真權重轉成 FP32，搭配人工輸入和上游梯度，指定的前向與反向比較有通過原先門檻。BF16 我也另外用小型 CPU 案例去查每一步取整的差別，因為一路算 FP32、最後才轉回 BF16，和原本每一步的取整並不一樣，所以單一 FP32 區塊通過，還不能直接拿來說原生 BF16 也通過了。
接著，Claude 那一輪把注意力、GDN、正規化和輸出層的前向與手動反向，寫成可以逐項檢查的 Python，先用 CPU 人工案例去比較。這是在把原來比較難看清楚的運算拆開，讓後面能知道是哪一段開始有差別。不過各個區塊的人工案例能對上，和接成多層以後還能不能對上，是兩次不同的檢查，後面的多層失敗也還是保留。
到了 10 月 15 日，我開始把這些運算接回原來的呼叫端，先在縮小模型上，把前向、手動反向、更新、保存和新程序的下一步接起來，再去核對原本持有的參數物件、更新旗標和優化器狀態。原部署用的 GDN 和正規化也另外比過，文字學習、研究信用、Group 群組策略和 Decision 決策更新，以及原本整體 graph 的保存，都有各自的 CPU 紀錄。後來連原啟動和 constructor 也接進小模型流程，不過不同設定仍然分開記，沒有把幾個測試的最大規模加在一起，寫成一次完整 9B 執行。
10 月 16 日繼續往下做的，是縮小 CPU 模型的完整流程和 BF16 的情境延伸。研究情境從空的往非空的多驗了一段，也把 BF16 儲存、FP32 研究計算和 master 狀態的規則講清楚，因為這本來就是混合精度，不能再拿它當成每一步都照原生 BF16 算。較寬設定目前也只有局部 state-value 數值檢查，意思是核對狀態值參與計算的那一段，沒有把它寫成整套更新和冷啟動都驗過。
我也另外查更新已經寫進去一部分，後面才失敗時會怎樣。縮小 FP32 的 active Group 案例，確實讓第三次實際寫入之後出錯，再核對回滾和新程序接續，因為只測還沒碰到資料就拒絕，還不夠知道中途失敗能不能收回來。這幾天也把部分梯度、回滾備份和雜湊改成分塊或寫到磁碟，不過模型、優化器狀態和保存時的完整物化仍然有成本，記憶體上限還沒有因此全部解決。
保存本身也不是看到檔案出現就結束了。10 月 17 日另外驗了缺少資料、保存中斷，還有最新指標已經往前、帳本卻還沒寫完的情況。後面這種情況，預設載入會拒絕，需要明確指定上一個有效保存點才能恢復，所以現在多檔案保存還不能說已經具備原子性，也就是不能保證中途失敗時，所有檔案都一起停在同一個完整版本。
同一天也把指定的程式、依賴和保存資料搬到另一個根目錄，連 runtime 的位置都分開，再用新程序繼續跑，核對保存狀態和下一步。前面換目錄的保存點檢查，是這條線的前一段，這次把執行環境的位置也納進來。不過兩次都還是在同一台 Windows，沒有換一台電腦或重新安裝環境，所以我還是把同機搬移和跨機恢復分開看。
另外有一條比較容易被名字誤會的工作，是離線的研究證據記憶工具。它把原始收據、失敗和人工整理的筆記連在一起，讓之後找資料時能回到原件，也有做匯出、換目的地恢復和中文檢索。對我來說，這是在避免後面只剩一句整理過的結論，卻找不到原本怎麼做出來的；它沒有呼叫模型，也還沒有接成小麥模型層的長期記憶或自動學習。
正式入口這條線，在 10 月 17 日到 18 日也往前接了一段，在 hidden size 8、三層的小模型和單張 GPU 上，把更新、保存、新程序恢復和再更新做了限定驗收。不過十項關卡裡，只有四項是當前來源版本實跑，五項沿用各自原版本的歷史有限證據，另一項是兩者混合，不能寫成同一新版十項全部重跑。新版非空 state-value 比較雖然通過，原文 491 個 token 也只有 486 個編進去，末尾五個沒有進到這次範圍，前一版的失敗和逾時仍然保留。
10 月 18 日到新的運算環境以後，先把保存的研究資料復原，再另外建立執行環境，做小型檢查，接著才往模型流程走。逐段 CUDA 的路徑也是先用小模型去比梯度，另外補上更新前後的輸入核對。還有一個有記憶體上限的前綴暫存，有空間才用，空間不夠就回到原路徑；開啟、關閉和回退的指定案例有對上，但少做幾次呼叫，還不能直接當成實際速度已經提升。
後面 A100 上的 9B 等級模型，這次選定 47 組參數，實際完成了兩次更新。第一次有 6 組參數改變，換一個新的程序之後，參數、優化器等列入記錄的保存狀態投影，以及亂數狀態投影，都能對回第一次留下的記錄，接著第二次有 9 組參數改變，也存成另一個 checkpoint。這讓我知道這一段確實能接著往下做，不過第二個 checkpoint 還沒有再用第三個新程序載入，不能把下一段也先算成驗過了。
除了繼續接程式，這週也花了時間把做過的事情留好。10 月 13 日已結束的實驗，成功和失敗原件一起保存、讀回核對，再結束原來那台 GPU 實例，保留的是已知重要研究資料，沒有把整台主機最新檔案都保存下來。10 月 14 日的來源和原始結果也存進私有版本庫，資料交付完成和科學驗收失敗分開記，沒有因為上傳成功，就把原來失敗的研究改成成功。
公開的部分，10 月 15 日把分散的研究整理成 38 個家族的目錄，實際做結果複核的是其中三份歷史報告，其他收進目錄，還不代表研究都驗過。GitHub 首頁也整理成研究、證據、示範和文件入口，另外用身體拆解圖說明部件和範圍。10 月 18 日再把可以公開的數字、失敗與限制補出去並讀回核對，網站也沿用原本的研究週報入口，中英文一起整理，初版和增補日期分開，讓人回頭看時知道哪一段是後來才補進來的。
10 月 17 日整理舊版本時，也留下完整基準和真正不同的資料，核對四份歷史封裝重建出來的內容，再處理重複副本和已經結束的舊實驗。這裡有一個代價也要寫清楚，部分舊 trace 和狀態不再全部留下，所以那些歷史執行不能再逐值重驗或原樣接續。一張結果卡可以幫忙知道以前發生過什麼，但不能拿它當成還能執行的完整恢復包。
這次 A100 的程式、實驗紀錄和保存狀態，另外整理成私有備份，也做過封存內容校驗。不過當時只是校驗，沒有把完整包重新解開、在另一個環境從頭啟動，所以我把資料有保住，和整套軟體能重新執行分開記。公開這邊仍然是挑過的結果和限制，核心程式、權重、私人保存點和原始張量不放出去，公開雜湊只是讓日後能對回原件，也不能讓別人只靠摘要就重跑私有模型。
沒做成的
這週最主要還沒過的數值問題，仍然是 10 月 14 日那 14 個新種子、多層人工 CPU 案例，原 FP32 門檻是 0/14，共用負控制是 104/112，完整協定仍然失敗。後來補償候選雖然減少了一些超界座標，14 個案例還是全部失敗，也更慢，所以沒有換進主流程。另外也在部分座標查到兩種參考門檻彼此不相容，需要先把數學目標和原框架相容性分開說清楚；負控制的非連續資料問題則另外修補，沒有回填去改原凍結結果。
工程過程裡的失敗也沒有消失。中間有過外層程序正常結束，但模型實際入口沒有完成更新的情況；原始第一輪也有 JOB_TIMEOUT，第一次恢復指標也記為 FAIL，後來改正指標、接續成功，並沒有回頭改掉那些紀錄。新的小模型流程通過自己的條件，也不能拿來替前面多層的 FP32 失敗作結案，因為用的模型、來源和判準本來就不同。
還有這次大模型更新的輸入，仍然是主機指定的固定短文字，前綴是 a，目標是 b，不是小麥自己提出的研究內容。47 組選定參數的更新也不是全參數訓練，已有的 32 層執行觀測，還沒有補成完整 32 層的一般數值與一般輸入驗收。任意自由輸入、長輸入、原生 BF16 每步取整等價，以及完整 True 的一般接管，都還有各自缺的證據。
所以對我來說，這週比較具體往前走的，是逐漸知道哪些運算、更新和保存，可以在什麼條件下接起來，也比較知道失敗會落在哪裡。小麥能不能自己重新定義問題、提出原本沒寫好的方法，或是讓新的理解變成後續持久可用的能力，仍然要另外做方法轉移、消融和因果對照。張量操作紀錄也還不是完整逐值的因果解釋，研究循環接頭的工程測試沒有呼叫模型，這些不能只因為名字裡有研究、記憶或追蹤，就一起算成能力已經具備，整體加速也還沒有驗證。
接下來
接下來，A100 這條線會先從第二個 checkpoint 開始，用第三個新的程序載入，再核對不同輸入的更新和保存。因為第一次能恢復，和第二次保存完還能不能繼續用，是不同的檢查，這一段還是要實際走過才知道。這次公開整理沒有重跑模型，這裡寫的是接下來的工作，還沒有新的執行結果。
CPU 可以先做的，我會繼續查原多層數值和雙參考門檻、補負控制、保存故障和一般入口，也把 active BF16 Group、完整保存的記憶體成本及跨環境恢復的缺口列清楚。需要 GPU 的真尺寸數值和更一般輸入，再依這些條件另外驗。對我來說，公開週報就是把這些前後關係留下來，讓人知道這週做成的是哪一段、還缺哪一段，而不是把同一條流程的前驅、修補和備份，加成很多個能力成果。
小麥走到哪了
首頁的四個研究步驟，這週各自的狀態。
從未知出發，也追問自己怎麼研究
尚未驗證
自主重定義問題的正式能力驗證尚未完成。
把說出的理由，對回實際運算
部分做到
指定區塊及縮小案例可核對，完整模型一般數值仍未驗收。
讓新的理解，改變實際做法
部分做到
CPU 小模型到 9B 選定參數已有更新恢復證據；舊數值失敗保留。
重啟、換題之後，還能自己用上
尚未驗證
持久能力提升與新題效益仍待驗證。
技術紀錄完整數字、範圍限制與每日紀錄，給研究者核對
每日紀錄
- r20-method-and-grad文字方法拒絕保留；17 組梯度限定核對部分通過
- r20-mlp原模型單 MLP 的限定 FP32 CUDA 比較部分通過
- r20-custody-retire成功失敗原件保管；原 GPU 實例退役紀錄
- cpu-components-blindCPU 元件候選；多層 FP32 仍 0/14未通過
- true-cpu-lifecycle原 GDN、呼叫端、更新及保存冷啟接線部分通過
- numeric-conflict補償候選未過；查到部分參考門檻衝突未通過
- public-navigation公開研究目錄、正負結果與入口導覽紀錄
- cpu-bf16-rollbackCPU 混合 BF16 延伸及寫入後回滾部分通過
- checkpoint-faults保存故障、前一保存點及同機 runtime 搬移部分通過
- evidence-memory離線證據記憶工具；未接模型長期記憶紀錄
- historical-retirement歷史封裝內容重建核對及舊實驗退役紀錄
- formal-mixed-gates17–18 正式入口十關，來源實跑與歷史混合部分通過
- cuda-stage-cache小模型逐段 CUDA、有限暫存及回退核對部分通過
- a100-9b-continuation9B 兩次選定更新；首保存點新程序恢復部分通過
- public-weekly-scope限定公開摘要、私有保管與雙語週報紀錄
本週完成
- 10/13：R20 實際特徵的 17 組研究梯度核對、原更新資料只讀稽核，以及單一原模型 MLP 的限定 FP32 CUDA 比較；原文字和方法拒絕保留。
- 10/13：方法稽核、worker 與原始紀錄會計、一次性程序控制、封存輸出基本運算與明確反向；方法檔換行的保存及新程序執行修補使用人工案例，不是模型新方法。
- 10/14–15：CPU 元件候選、多層盲測失敗、另存負控制修補，以及數值補償開發；原 GDN 與 stable norms 的相容性比較，使用封存真輸入搭配人工上游梯度，沒有冒稱原訓練重播。
- 10/15：縮小模型生命週期、原 caller ownership、文字學習／研究信用／Group／Decision 交易、原 graph 冷啟與原啟動；不同 profile 的數字不合成一次完整模型執行。
- 10/14–15：張量操作紀錄及研究循環接頭的工程反例；研究接頭 model_calls=0。歷史解碼耗時拆解和 profiling 工具核對，沒有新 GPU profile 或效能修補部署。
- 10/16：縮小 CPU 原啟動完整流程、state-value、空／非空 BF16 混合設定、FP32 active Group 寫入後回滾、指定保存點搬移，以及梯度／回滾／雜湊記憶體元件。
- 10/17：保存故障拒絕、明確指定前一有效保存點、同機外部 runtime 新程序接續、來源與方法呼叫盤點、離線證據記憶工具。入口可達、實際呼叫、數值核對與冷啟證據分開記。
- 10/17–18：正式 Python 入口的 h8 三層、單 GPU 十項限定關卡，含當前來源 CUDA 更新、保存、固定保存點新程序接續與 RNG／裝置反例。
- 10/18：新環境資料復原與小 probe、小模型逐段 CUDA／交易邊界輸入核對、有上限前綴暫存與回退，再接 9B 等級模型兩次選定參數更新。
- 保管及公開：R20／盲測原件保存、舊 GPU 退役、歷史封裝四份內容重建核對與舊實驗退役；重複傳輸、影片和共用依賴整理屬保管，沒有重裝環境。研究目錄、導覽、部件說明圖、公開摘要與雙語網站屬研究溝通，沒有增加模型實驗。
驗證與數字
- MLP：151,027,712 個輸出／梯度元素，最大絕對差約 3.72529e-9；固定 atol=8e-6、rtol=5e-4。真權重轉 FP32，人工輸入；只是一個 MLP。
- 多層：4／8 層、hidden64／intermediate128／vocab97，14 個新種子 CPU 人工案例；FP32 0/14，超界 1,776 元素，最差 error/bound 約 39.65448。G 原始 uint8 位元 14/14 相同，共用負控制 104/112，完整協定 FAIL。
- 補償開發仍 0/14，使用已揭露的原 14 案例，不是新盲測。雙參考區間衝突由獨立者在兩案例的七個座標重現；不能把作者較大盤點寫成全部獨立重跑。
- 正式十關為四項當前來源實跑、五項歷史有限沿用、一項混合；不是十項同版重跑。當前 state-value 為 177 比較／2,472 值；原文 491 token，只編入 486，省略尾五個。
- 離線證據記憶：獨立測試 16 項中 15 通過，一項一般檔案 symlink 因權限跳過；實際 junction 與 ZIP symlink 拒絕有執行。這是同機工具驗證，不是模型記憶。
- CUDA／暫存小模型：h8 三層，逐段梯度指定比較最大絕對差為 0；CPU 暫存 OFF／ON／FALLBACK 的供給梯度雜湊和 loss 相同。ON 的層前向呼叫由 9 到 6，回退恢復 9；沒有時間效能比較。
- A100：9B 等級模型選定 47 組參數；第一次 6 參數／10 masters 改變，新程序恢復第一次的列明狀態及 RNG 投影相等。第二次由既有獨立審查記載 9 參數／12 masters 改變，step/revision=2，新保存點原生狀態為 COMMITTED_DURABLE。
- 這次盤點直接比較第一次更新、恢復和 RNG 小 JSON；第二次更新與新保存點讀的是既有獨立審查，沒有重新連遠端讀其全部原件。私有完整包當時是 verify-only，未完整提取及重新啟動。
- 研究公開目錄有 38 家族，歷史結果複核三份報告，其餘 35 家族沒有因此取得結果驗收。公開示範核對證據和算術，不重建完整輸出張量或執行私有模型；公開 CI 也不等於私有 GPU 數值驗收。
失敗與未完成
- 原 R20 方法回覆仍拒絕，人工方法格式修補沒有安裝進該次封存執行；只讀數值稽核不改原 comparer 拒絕，17 組梯度也不證完整 9B backward。
- 原 FP32 0/14、負控制 104/112 和凍結版本保留，數值根因未唯一證明。原 CPU 資源監測 FAIL／UNKNOWN、混合流程 TIMEOUT、前一來源版 state-value FAIL 仍在，不因後續限定通過消除。
- 中途曾有程序 exit 0、實際模型入口 FAILED 且沒有更新／保存的情況；原第一輪 JOB_TIMEOUT 與恢復指標 FAIL 保留。第二 checkpoint 尚未第三新程序重載。
- 固定主機前綴
a、目標b，沒有模型自提研究；全參數訓練、任意自由／長輸入、完整 32 層一般數值、原生 BF16 逐步等價、完整 True 接管、方法發明、因果能力收益與整體加速未驗證。32 層 guarded execution 觀測不等於完整數值驗收。 - BF16 active Group 未驗，較寬 state-value 未整套 cold-next。保存仍非原子；壞回滾日誌可能需恢復。只有同機換根目錄，沒有跨機或獨立重裝驗收。
- CUDA 選定梯度須先容得下 staging budget，再離開守門區寫磁碟；分塊雜湊不消除完整張量／graph 保存物化。完整模型已知成本在本機顯示卡預算下被拒，未知成本也仍是拒絕條件，沒有執行完整模型峰值測量。
- 部分舊 trace／state 已退役，放棄那些歷史執行逐值重驗及原樣接續；必要來源節錄、結果卡和封裝位元內容核對不等於完整可執行環境。研究證據記憶是離線工具，未接入 True 或證明科學效益。
作者與 AI 分工
郭俊逸負責研究方向、專案整合、範圍與判準，以及執行授權。AI 工具協助實作、文件、來源盤點與交叉核對，本期週報也由 AI 協助整理。
下一步
- 用第三個新程序載入第二 checkpoint，另驗不同輸入、後續更新及保存；未執行前不計通過。
- 固定原契約和失敗，先釐清雙參考要求、數值偏差與負控制；一般入口、active BF16 Group、完整保存記憶體成本及跨環境恢復分開驗。
- 本次全週整理未重跑模型。新增支線的公開白名單摘要放在全週證據摘要，保留來源承諾和證據層級，完整核心、權重、私人保存點與原始張量維持私有。