vatt'ghern jaskier's ballads

2026.09.11 —— 今日 10 則

TODAY'S THREAD 今天有好幾則是在重算一筆舊帳——RSA 的金鑰長度、React Native 的跨平台紅利、DNS 回應塞得進 UDP 的假設,過去成立的理由都被人重新量了一次,而量出來的數字跟當初不一樣。

10 items ai · 2 systems · 2 infra · 3 web · 2 backend · 1
0 / 10 read
#01

同樣的分數,帳單少了六成四

Cognition 把 SWE-2 從 Kimi K3 這顆 2.8 兆參數的底模 post-train 出來,官方說法是第一次把 RL 做在多兆參數的規模上,reward 寫成帶成本懲罰的 R = S - λ_e C,懲罰係數對齊 Pareto frontier 在各 effort 等級的局部斜率。FrontierCode 1.1 Main 拿到 50.0%,跟 Fable 5.1 的 50.9% 差不到一分,成本則宣稱便宜 64%。Terminal-Bench 2.1 是 92.8%,換到 Terminal-Bench 4 只剩 27.3%——同一顆模型跨兩代 benchmark 的落差,比它跟對手的差距大得多。

read source → agentic-coding

#10

fp64 拆成餘數,丟給 FP8 tensor core

Satoshi Matsuoka 這篇處理的是用 CRT 餘數系統在 FP8 tensor core 上模擬 fp64 矩陣乘法,重點不在乘法,而在把運算元轉成餘數平面的那段——那是在 tensor 運算開始前就先把資源吃掉的階段。工程手法是 convert-once 的餘數工作區、走整數管線且常數約化剛好兩個 limb 的 GEMM,再把轉換 pipeline 到 MMA 後面藏起來。論文給的是模型推估、不是實測:作者註明每一個數字都還等著被量出來,在這個前提下,NVIDIA Rubin 上 thread-block cluster 之內能貼到約 473 TFLOPS 的算術上限,輸出放大之後則卡在約 235 TFLOPS 的地板;文中提的 Option C 硬體改動是在非同步複製路徑上加一塊固定功能的餘數轉換單元,宣稱能把地板拉回 473。

read source → fp8

#02

沒有兩個 runtime 給出同一個答案

Gavin Gray 把 async/await 的設計空間拆成九個維度,分成 start of life(eagerness、suspension)、end of life(extent、reference strength、destruction、propagation)與 cancellation(awareness、direction、persistence)三組,再把 Python、Rust、C#、JavaScript、Swift、Tokio、Smol、Asyncio、Trio 標到上面。他的結論是同一支小程式的三個變形,測到的七個 runtime 裡沒有任何兩個給出相同輸出——差的不是效能,是可觀察語意。作者自己把話說得很鬆:每個維度在效能、記憶體、人因與語意上各有取捨,沒有對錯之分。

read source → async-await-semantics

#09

一百多個 repo 之後,Rust 成了 tier-1

Victor Ciura 在 Rust Foundation 的客座文章裡定義了 Microsoft 內部所謂 tier-1 語言是什麼:一條從本機開發到 production 的鋪好的路——安全的工具鏈建置、堪用的開發者工具、品質流程、深度平台整合,以及符合 SDL 要求。文中給的數字是超過 100 個 Microsoft 專案 repo 今天已經用它建置,而且每週還在增加,適用範圍寫的是從韌體與驅動、kernel 與 hypervisor,到微服務與應用程式。production-ready 的時間點標在 2026 年初,self-hosted 則從 Rust 1.90 開始。

read source → rust

#03

四十萬美元,把 260 位數拆開

Cognition 的 Eric Lu 用 GNFS 分解掉 RSA-260,格點篩選那一段跑在 GPU 上,用的是自己寫的 siever「glas」,文中宣稱成本比先前公開的最佳結果低十倍。整趟從 2026 年 8 月 18 日跑到 9 月 3 日,約 4,900 GPU-day、也就是 13.5 GPU-year,以當時市價估算約 40 萬美元,而量測、叢集操作與最佳化多半是交給 Devin 的 agent session 端到端跑完的。外推的數字是 RSA-1024 一個約 3,000 萬美元,而 RSA-2048 仍難上約十億倍、看來不受這次結果影響。

read source → deep read cryptography

#04

一個簽章 2,420 位元組,UDP 裝不下

1.1.1.1 開始驗證 ML-DSA-44 的 DNSSEC 簽章,而一個 ML-DSA-44 簽章就是 2,420 位元組、公鑰另外 1,312 位元組,在還沒算進被簽的 RRset、網域名稱、DNS header 與其他 DNSSEC 記錄之前,光簽章本身就超出常見的 1,232 位元組 UDP payload 預算。Cloudflare 的處理不是把回應拆成片段——文中直說分片 UDP 不可靠、應該避免——而是讓權威伺服器回截斷標記,把 resolver 推去 TCP 或其他 transport。這個轉移的代價量得出來:約 85% 的 1.1.1.1 查詢從 UDP 進來,把 Big Pineapple 上所有 DNS 產品一起算則約 60%,其餘走 TCP、DoT 與 DoH。

read source → dnssec

#05

驗證走的也是被劫走的那條路

2026 年 8 月 28 日到 30 日之間,AS62390 透過 transit 商 AS6204 宣告了 162.55.80.0/24 這條更明確的路由,把原本落在 Hetzner 162.55.0.0/16 裡的 Softaculous 基礎設施流量拉走,受影響的包含軟體更新端點與客戶計費入口。真正麻煩的是憑證——Let's Encrypt 的自動網域擁有權驗證同樣被路由進那條劫持路徑,攻擊者因此拿到一張合法憑證,連線端看不到任何警告。在被導走的區間內檢查更新的 Virtualizor 安裝會拿到惡意更新包,內含一個 /etc/systemd/system/java-jre-update.service 的 systemd unit,官方說受影響的伺服器只有少數幾台。

read source → bgp-security

#06

同一個功能寫兩次,成本不再是問題

Shopify 宣布行動端走回 Swift 與 Kotlin,理由寫得很直白——coding model 進步之後,對他們的 app 與團隊來說,同一個功能用 Swift 與 Kotlin 各寫一次已經不再是以前那個成本。要走到這步得先解掉兩件事:agent 操作模擬器又慢又脆,靠 accessibility tree 與截圖驅動,改一行程式是幾秒鐘、驗證卻要幾分鐘;一次性把 React Native 翻成原生的產出則是難以維護的 slop,於是他們做了 Helix,強制每個檢查點都要通過測試、視覺審查與對抗式 code review。Shop app 從概念驗證到完整原生版上架花了 12 週,而 Shopify app 本身有 300 多個畫面、桌面與鎖定畫面 widget、Apple Watch app、complication 與 Siri Shortcuts,預定 2026 年稍晚出貨。

read source → deep read react

#07

module specifier 當成真的 URL 來解

Cloudflare 重寫了 workerd 的 module registry,把 module specifier 當成真正的 URL 解析,包含 query string 與 fragment:相對 import 的結果跟 new URL(specifier, base) 一致,import attribute 會被驗證,query string 不同的同一個 URL 會產生不同的 module instance,import.meta 也補上了。舊實作把 specifier 當成檔案系統路徑,而且整包 Worker 事先編譯、每個 V8 isolate 各留一份;新設計一開始就把 laziness 與快取共享放進來,模組改成第一次被 import 時才編譯,isolate 副本之間共用編譯後的程式碼。跟著一起變的是 Node.js 相容 API 預設開啟、應用程式大小上限提到 64 MiB,並以 new_module_registry 這個 compatibility flag 選用。

read source → nodejs

#08

每個 shard 都還是真的 Postgres

PlanetScale 的 Neki 進入 platform preview,立場寫得很明確——「stick to Postgres, don't work around it, fake it, or turn away from it」,每個 shard 上跑的是真的 Postgres,擴充套件、SQL 支援與行為都保持標準,而不是一個相容實作。應用程式連的是 Neki router,走標準 Postgres wire protocol,由 router 負責解析查詢、規劃分散式執行、緩衝並合併結果;每個 shard 是一個 primary 加上兩個以上 replica、跨三個可用區,shard group 則讓不同的表與工作負載落在不同的 shard 集合上。連線池以 sidecar 同時掌握 router 側與 Postgres 側,量的是實際容量而不是估算值;預覽階段官方明說不建議放上 production 工作負載。

read source → deep read sharding

today's deep reads

deep · 01 RSA-260 倒下,帳單是四十萬美元 deep · 02 Shopify 把 React Native 換回原生 deep · 03 每個 shard 都還是真的 Postgres