ANDREW YUAN / PUBLIC PROJECTS

Engineering Lab

把工程問題，做成能檢查的實驗。

我用公開專案探索效能、容量、部署、資源分配、快取重用、遠端變更復原與上行備援：先說清楚要解決的限制，再用實作與量測檢查判斷。你可以從問題開始，接著看證據、完整文章或程式碼。

各個實驗的模型與量測方法各有範圍，數字不宜跨專案直接排名。

效能與驗證

tiny-infer-lab

程式變快了，怎麼確認它仍然算對？

我做了什麼: 以 C 實作小型推論引擎，加入系統 BLAS 路徑，並建立六個後端的同模型比較與獨立數值檢查。
實驗證據: 450 筆保留測試資料、五種批次大小，六個後端的逐筆分類結果全部一致，準確率 97.33%（438/450）；機率輸出也通過獨立 float64 參考值的誤差檢查。
量測範圍: Apple M5 Pro、64→32→10 Digits 模型。效能比較的是暖機後、透過 Python 呼叫並輸出機率的介面。
如何解讀: 每筆攤提時間不等於單筆請求延遲；程序 RSS 不等於模型 RAM。不同批次有不同的最快後端，不能推論自製 C 一定更快。

記憶體與容量

tiny-arena-lab

我做了什麼: 以 C11 實作記憶體規劃器與圖執行器，依 Tensor 生命週期重用空間；同時檢查中間數值、實際位址與故障注入結果。
實驗證據: batch size 16 時，Tensor Arena 從 8,832 降至 6,144 bytes，減少約 30.4%，可在設定的 7 KiB Arena 預算內完成推論。兩種配置的分類結果一致，準確率均為 97.33%（438/450）。
量測範圍: Apple M5 Pro 主機實驗；同一組 Digits 權重、運算順序與核心，比較獨立配置和生命週期重用。
如何解讀: Arena 不是整個程式的 RAM，7 KiB 是實驗設定，未在 MCU 上實測。推論時間的觀測範圍重疊，這次結果證明容量可行，沒有證明可靠的加速。

部署與量測

inference-doctor

我做了什麼: 建立 ONNX 部署診斷工具，檢查輸出、同步推論呼叫時間與 Worker RSS，並將 Execution Provider 的執行證據及其缺口寫入報告。
實驗證據: 在四種最大批次設定下，CPU EP 的暖機推論時間都較短；兩個 EP 的逐筆分類結果一致，準確率均為 96.89%（436/450）。輸出的 logits 與機率也通過參考值檢查。
量測範圍: Apple M5 Pro；同一個小型 Digits ONNX 模型與 450 筆保留測試資料。最大批次為 1、16、64、128，最後不足一批的資料仍完整執行與檢查。
如何解讀: 這是部署路徑比較，不是 CPU 與 GPU／NPU 的晶片能力排名。Provider 被啟用不代表已證明使用 Neural Engine；Worker RSS 不含 CoreML 輔助程序與裝置記憶體。

資源分配與公平

tiny-fair-proxy

我做了什麼: 以 Rust 實作實驗性 TCP Relay，加入有界 payload 緩衝、背壓與 Tenant 加權位元組排程，比較按連線與按 Tenant 分配的差別。
實驗證據: 三個隨機配對區塊，共 24 次試驗。等權重、A 一條連線與 B 四條連線時，A 在共同接收時窗的占比中位數，按連線約 20%、按 Tenant 約 50%；包含尾段的整體吞吐量大致相近。
量測範圍: 原生 macOS ARM64 loopback；每條連線傳送 512 KiB，各方向共同限速 512 KiB/s。份額觀察開始後 0.4–1.4 秒；以受信任的 listener 分類 Tenant。
如何解讀: 共同時窗占比不是整輪總 payload 占比、瞬間比例或請求延遲保證。Listener 分類不是身分驗證；payload 有界不等於全系統記憶體有界，取樣 Proxy RSS 不含 peer 與 kernel socket buffers。

快取、路由與失效

tiny-dns-router

我做了什麼: 以 Python 實作本地 DNS 轉送服務，加入依網域後綴路由、正向與否定快取、容量限制及逾時後切換上游。
實驗證據: 重複查詢的 UDP 情境中，停用／啟用快取各有三次試驗；每次 p50 延遲的中位數由 7.33 降至 0.69 ms，上游查詢次數的中位數由 120 降至 4。
量測範圍: 原生 macOS loopback，受控上游延遲 6 ms；每次試驗從空快取開始，預定每 3 ms 一筆、共 120 筆查詢，重用四種查詢鍵。延遲從實際發起查詢算到回覆驗證完成，不含發送前等待。
如何解讀: 每次不同的查詢收益有限；TTL 限制重用期限，不保證答案最新或正確。Colima Linux 結果分開報告，未驗證真實 Internet 或最大吞吐量；未提供 DNSSEC validation，快取容量限制不等於程序 RAM 硬上限。

遠端變更與復原

rulemoor

我做了什麼: 實作遠端 Linux 防火牆變更服務，串接管理埠預檢、新 TLS 確認與必要復原；可選 Boot Guard 在核對日誌及雙協定政策後，才啟用指定介面。
實驗證據: 同一份來源在 macOS 與 Linux 各通過 132 項測試，另有 12 個實際 systemd／Linux VM 階段，包含安裝設定與清理。實際 EISDIR 收據寫入失敗時，受測清理與停止仍嘗試關閉介面並讀回 DOWN。
量測範圍: 明確啟用的隔離命名空間、靜態 veth 與獨占介面啟用權。兩次正常 VM 停機／啟動分別驗證待確認基準與已提交政策復原；舊 Executor 先退場，再接受後繼政策。讀回與探測為有限取樣。
如何解讀: 介面操作可能失敗，舊 OPEN 收據不代表實際就緒；UP 前檢查不涵蓋所有故障。未驗證真實磁碟耗盡、突然斷電、實體網卡、WAN、一般網路管理器或全主機開機零空窗。需保留獨立復原入口。

上行備援與健康證據

uplinkstead

我做了什麼: 實作明確啟用的雙 DHCP Linux IPv4 備援服務，分別取得租約、綁定路徑做 TLS 探測，再由具權限的 Writer 驗證切換；保留遲滯與跨重啟切換額度。
實驗證據: 保留的同來源紀錄：macOS 與 Linux 各 295 項測試、六次實際安裝服務的上游黑洞／恢復循環；約九分鐘 268 個資源樣本中，Writer、Worker 與兩個 DHCP Client 身分維持不變。
量測範圍: 隔離 Linux VM、受控 DHCP／TLS 伺服器及共享 Kernel 的命名空間。新 LAN TLS 經預期替代路徑成功；Stop／Start 在取樣後另測。最後同 Client 觀察採較慢續租節奏，避開每 Session 64 筆歷史上限。
如何解讀: 指定 TLS 目標可達不等於整個 Internet 或業務正常。既有連線可能中斷，額度耗盡可能阻止再切換；長期 Session 重建、實體 ISP、一般 DHCP 相容性、突然斷電與開機零空窗未驗證。短期資源觀察不證明無洩漏。

INTERACTIVE EXPERIMENTS