2026.05.25 —— 今日 10 則
TODAY'S THREAD 今天三條 deep 都在量「成本」與「邊界」：把 integer-to-string 壓進 SIMD 的硬體極限、替 AI agent 在 container 到 microVM 之間挑沙箱、以及 InnoDB 的 next-key lock 到底替你擋掉什麼；場邊有 NGINX 把 Multipath TCP 帶進開源、Chrome 想用宣告式做局部 DOM 更新、Stapelberg 用 Go 重寫 rsync 換掉整類記憶體漏洞、C++26 再補兩個函式包裝，加上一篇量化 LLM agent「約束衰減」的論文、登頂 HF 趨勢榜的 DeepSeek-V4-Pro 與 Dropbox 的 low-bit inference——軸線是：把抽象、隔離與正確性的代價，逐一量到位元與微秒這一層。
Constraint Decay——量化 LLM agent 在多步後端產碼裡怎麼一路忘掉約束
一篇 arXiv 論文把一個工程師都有感、但少有人量化的現象做成數據：當 LLM coding agent 一步步推進後端任務，先前定好的約束（schema、權限、命名規則）會隨步數累積而被違反或遺忘。作者刻畫了這種「約束衰減」的失效模式與退化曲線，指出問題不在單步品質，而在長程一致性。對任何把 agent 放進多步 codegen pipeline 的人，這篇把「為什麼跑著跑著就歪掉」講成可衡量的東西。
DeepSeek-V4-Pro 登上 HF 趨勢榜首——單週 460 萬下載、4200+ likes
DeepSeek-V4-Pro 以遠超同期模型的數字登上 Hugging Face 趨勢榜首：約 460 萬下載、4200 多個 likes，把第二名拉開一個量級。這是本週開放權重圈最受關注的釋出，社群的下載與微調熱度本身就是一個訊號——不管你跑不跑它，它都在重畫「預設拿哪個開放模型起手」的地圖。值得留意採用曲線而非只看 leaderboard 名次。
Dropbox 談 low-bit inference——量化怎麼把線上模型服務的算力與記憶體壓下來
Dropbox 工程團隊拆解他們怎麼用量化與 low-bit inference 把生產環境的模型服務成本壓下來：在精度可接受的前提下，把權重與啟動值降到更低位元，換取顯著的算力與記憶體節省。文章偏實務，講的是哪些層該量、哪些不該量、以及怎麼量測退化。對任何在自架推論、被 GPU 帳單卡住的後端團隊，這是一份把「量化不是免費午餐」講清楚的筆記。
把 integer-to-string 壓到 2 奈秒以下——SIMD itoa 的查表、SWAR 與 AVX-512
Daniel Lemire 的部落格與一篇同主題 arXiv 論文幾乎同時把一個看似平凡的操作做到極致：把整數轉成十進位字串。透過查表、SWAR（在一個暫存器裡平行處理多個位元組）與 AVX-512，單次轉換被壓到兩奈秒以下，比標準庫快 1.4 到 4 倍。重點不只是快，而是它示範了「資料相依的分支」怎麼被改寫成無分支、可向量化的算術。對寫序列化、日誌、數值輸出 hot path 的人，這是把 itoa 從瓶頸名單劃掉的做法。
用 Go 重寫的 minimal rsync——memory safety 怎麼整類繞過 C 版的漏洞
Michael Stapelberg 解釋他那個極簡的 Go rsync 實作，怎麼靠 memory safety 直接繞過困擾 C 原版多年的整類記憶體安全漏洞：沒有手動指標算術、沒有 buffer overflow、沒有 use-after-free 的攻擊面。文章誠實地討論了取捨——不是「Go 比 C 好」這種口號，而是「重寫一個有限子集，換到的安全性是哪一類、代價在哪」。對任何維護老 C 工具、在考慮要不要用 memory-safe 語言重寫的人，這是個務實的參照樣本。
C++26 再添兩個函式包裝——std::copyable_function 與 std::function_ref
C++26 補上兩個一直被 std::function 的設計缺陷逼出來的型別：std::copyable_function 修掉 const-correctness 的老問題（呼叫一個 const std::function 卻可能呼到非 const operator()），std::function_ref 則提供一個不持有、不配置的輕量「函式參照」，給只想借用 callable 的介面用。兩者一起把「我到底該收哪種 callable 包裝」這個每天都遇到的選擇講清楚。對寫函式庫 API 的人，這直接影響參數該怎麼宣告。
替 AI agent 挑 sandbox——container、gVisor 到 Firecracker microVM 怎麼權衡
Docker 把「跑 AI agent 該用哪種沙箱」這個正在發燙的問題攤開比較：原生 container 啟動快但共用 kernel、隔離最弱；gVisor 用 user-space kernel 攔 syscall，隔離強一截但有相容性與效能代價；Firecracker 這類 microVM 隔離最硬、卻要付出啟動延遲與資源開銷。當 agent 會去執行不可信的、模型生成的程式碼，這個選擇直接關係到爆炸半徑。文章把隔離強度、啟動成本與相容性三軸講清楚，給出按情境的選法。
NGINX OSS 1.29.7 把 Multipath TCP 與 session persistence 開源、upstream keep-alive 變預設
NGINX OSS 1.29.6／1.29.7 把幾個過去 NGINX Plus 限定的能力下放到開源版：session persistence（把同一客戶端黏在同一後端）與 Multipath TCP（讓單一連線同時走多條路徑、提升行動網路下的韌性）。另一個容易被忽略但影響廣的改動是——對 upstream 的持久連線（keep-alive）現在是預設開啟，少掉每次請求重新握手的成本。對跑反向代理或 API gateway 的人，升級後可能不改設定就少一截尾延遲。
Chrome 的 Declarative Partial Updates——不寫 JS 也能做局部 DOM 更新
Chrome 團隊提出 declarative partial updates：用一套宣告式語法，讓瀏覽器直接把伺服器回來的片段插進頁面的指定位置，少掉一層手寫 JS 的 glue code。這延續了 web 平台「把過去要靠框架做的事收回原生」的方向——和 View Transitions、Speculation Rules 同一脈。對做 SSR、漸進增強或想減少前端 hydration 負擔的人，這是一個值得追蹤的原生能力。仍在早期、需留意支援度。
InnoDB 的 next-key lock——REPEATABLE READ 怎麼用 gap lock 擋 phantom read
一篇把 InnoDB 在 REPEATABLE READ 下的鎖行為拆開講的分析：next-key lock 其實是 record lock 加上前面那段「間隙」的 gap lock，正是這個 gap lock 讓 InnoDB 在 RR 下就能擋掉 phantom read，而不必等到 SERIALIZABLE。這也解釋了一個常見的困惑——為什麼明明只 SELECT ... FOR UPDATE 一個不存在的列，卻把別人的 INSERT 卡住了。對任何被 MySQL 死鎖或莫名鎖等待咬過的後端，理解 gap lock 是繞不過去的。
today's deep reads
替 AI agent 挑 sandbox——container、gVisor、microVM 之間怎麼選
當 agent 會去跑模型生成的、不可信的程式碼，沙箱就是你的爆炸半徑控制器。原生 container 為什麼隔離最弱、卻仍是多數人的預設？gVisor 用 user-space kernel 攔 syscall，買到多少隔離、付出多少相容性與 syscall 開銷？Firecracker microVM 的硬隔離，啟動延遲與記憶體足跡的帳怎麼算？三軸——隔離強度、啟動成本、相容性——擺在一起，什麼情境該選哪一種？
把 integer-to-string 壓到 2 奈秒以下——SIMD itoa 的查表、SWAR 與 AVX-512
把一個整數轉成十進位字串，慢在哪裡？為什麼「先算有幾位數」這步的資料相依分支會擋住向量化？查表法、SWAR（在 64-bit 暫存器裡一次處理多個 digit）、到 AVX-512 各自買到多少？為什麼 lemire 的部落格與那篇 arXiv 論文會在同一週對同一個問題給出收斂的答案？sub-2ns、比 std 快 1.4 到 4 倍的數字，到底是怎麼一步步擠出來的？
InnoDB 的 next-key lock，從零講起——REPEATABLE READ 怎麼用 gap lock 擋 phantom read
phantom read 到底是什麼、為什麼比 dirty read 跟 non-repeatable read 更難擋？record lock 跟 gap lock 差在哪，合起來的 next-key lock 又鎖住了什麼？為什麼 InnoDB 在 REPEATABLE READ 就擋掉 phantom，而 SQL 標準說要 SERIALIZABLE 才行？以及那個經典的坑——SELECT ... FOR UPDATE 一個不存在的列，怎麼會把別人的 INSERT 卡死？