過去三天的素材從模型本身延伸到支撐模型服務的基礎設施、舊 GPU 的實際吞吐，以及數學內容如何被社群閱讀與修訂。OpenAI 公開的是自家大規模儲存平台的工程經驗；開源專案則分別修改消費級 GPU 的硬體設定、把 Java 程式交給加速器執行，與替 AI 產生的數學 write-ups 補上引用及可讀性。這些內容都提供了具體做法，但沒有把單一案例直接變成普遍保證。

🔥 OpenAI 公開 Habitat 支援 10 億 ChatGPT 使用者的儲存架構

OpenAI 在第二篇 Habitat 工程文章中表示，這套線上儲存平台服務 ChatGPT、API、Codex 與內部服務，資料量超過 500 PB，分布在 40 個地理區域；文章所述最大 Azure Cosmos DB 帳戶儲存數十 PB，服務超過每秒 2,000 萬次查詢。Habitat 的主要儲存後端是 Azure Cosmos DB，也搭配 Nanobase、Valkey 與 Blob storage。

文章記錄了多租戶設計的調整過程。早期共用容器會讓不同工作負載受到相同 physical partition 的限制，熱門 partition key 或儲存量增加造成的 partition split，可能降低個別 partition 的有效吞吐。團隊曾改用獨立容器隔離關鍵服務，但每個產品都必須自行預估與預先配置容量，發布時流量從測試規模升高也會造成容量不足。

目前的做法是預設採用多租戶容器，搭配對熱門 key 優先節流、依工作負載分級的 QoS，以及 Azure Cosmos DB 改良後的 serverless mode。OpenAI 表示，這些調整讓它在不為每個產品預先建立獨立容器的情況下處理工作負載隔離；文章也說明，這需要 OpenAI 與 Azure 團隊共同測試控制平面、gateway、SDK 與故障轉移，而不是單靠資料庫預設設定。

在讀取效能方面，OpenAI 描述了鄰近使用者配置資料、只複製少量低延遲資料、以 Valkey 快取其他讀取，以及用 Azure Cosmos DB change feed 在數秒內傳播快取失效。Habitat 的全球 read p50 從約 120 毫秒降至約 10 毫秒；這是 OpenAI 自行公布的內部平台數字，文章沒有提供外部可重現的測試資料或完整分位數分布。OpenAI 也表示正在開發採用 RocksDB Cloud 核心與 Raft 複製的 exabyte-scale 儲存系統，該系統仍在開發中。

NVIDIA RTX 30 系列的 FP/BF16 發射速率可由 gpu-unlock 修改

gpu-unlock 是一個 Linux kernel module，目標是把 NVIDIA RTX 3000 系列部分 GA102、GA103、GA104 與 GA106 卡的 FP/BF16 instruction issue rate 調整到專業卡相近的設定。專案作者表示，這套方法結合 CMP unlocker 的 V67/PLM 技術與 UEFI 方法中的 pre-driver timing，並以 kernel module 形式在 NVIDIA driver 更新後避免每次手動修改。

README 的 RTX 3090 Ti 測試是在 450 W、8192³ dense GEMM、FP32 accumulation 下進行，FP16 從 87.46 TFLOPS 到 118.39 TFLOPS，BF16 從 87.50 TFLOPS 到 157.41 TFLOPS，TF32 從 42.58 TFLOPS 到 82.61 TFLOPS。其他使用者回報的 BF16 GEMM 增益依型號與功率限制而異：RTX 3090 列為約 25–67%，RTX 3080 10 GB 為約 70–73%，RTX 3070 為約 73–81%，RTX 3060 12 GB 約 80%。

專案明確註明這些增益來自各自回報的 dense GEMM benchmark，不能直接互相比較；功率上限也會影響數字，最低的 RTX 3090 回報是在 225 W 限制下取得。矩陣運算、LLM prefill、diffusion 與 FlashAttention 可能受益，但 README 表示受 memory bandwidth 限制的 LLM decode 與 INT8 工作大致不變。RTX 3080 Ti 20 GB OEM 版本則列為解鎖完成但 BF16 仍維持半速，GA103 也尚無回報。

這個專案需要修改啟動流程並在 kernel command line 明確設定 gpu_unlock.targets；它不是 NVIDIA 官方支援功能。README 也保留 firmware、卡片穩定性、功率與不同工作負載的差異，使用者回報的結果不能替代個別硬體測試。

TornadoVM 7.3 把 Java 程式連接到 CUDA、Metal 與多 GPU

TornadoVM 7.3 是開源的 Java 異質運算框架，讓 Java 程式把可平行化的工作卸載到多核心 CPU 或 GPU。InfoQ 報導指出，新版本以 Foreign Function & Memory（FFM）API 取代 JNI，移除對實驗性 JVM Compiler Interface（JVMCI）的依賴，並以 reflection、ASM 與 Unsafe 組成在支援 JDK 21、25、26、27 上共用的 compiler metadata 路徑。

新版加入較深的 NVIDIA 整合，包括 CUDA backend、cuTile programming model 的 TileContext、CUDA library calls 與 multi-GPU execution。Apple 端也提供相近的 hybrid API，可搭配 Metal 與 MXL library。TornadoVM 的設計仍要求工作負載適合加速器；沒有迭代相依性的 data-parallel loop 比一般 Java 計算更適合卸載，並非所有程式都會因轉到 GPU 而受益。

框架可與 Apache Flink、Quarkus、Lang4j、Spring AI 等工具整合。InfoQ 所述的 Flink 範例讓開發者以 Table API 撰寫查詢，再由 task manager 檢查節點是否有 GPU，並分析中間表示以判斷是否適合加速。TornadoVM 同期也推出以 TornadoVM 為基礎的 jitLLM 2.0，文章指出團隊將它定位為 llama.cpp 與 Ollama 的競爭方案，並以單一 JAR 發布；這項定位是團隊說法，來源沒有提供相同硬體與模型下的獨立效能比較。

數學社群建立平台，校訂 OpenAI 的數學 write-ups

Terence Tao 的部落格刊登一篇由 Abhinav Nellore、Johannes Schmitt、Soledad Villar 與 Rachel Ward 撰寫的公告，介紹 oai-math-revised。該 GitHub 專案針對 OpenAI 公開的數學 write-ups，提供社群修訂、補充引用與改善說明的協作空間；公告指出，原始 write-ups 可能難以理解，也可能缺少完整引用。

專案在 mathcommunity/oai-math-revised 維護，並提供 GitHub Pages 瀏覽介面。數學社群的學生、博士後、教授與其他參與者都可加入；公告也邀請有意擔任管理員或 reviewer 的人，以 email 說明適合審查的分類。這個平台是社群另行建立的 repository，公告沒有表示它由 OpenAI 維護或代表 OpenAI 發表修訂版本。

原始公告只說明了參與方式與平台目的，沒有列出已完成修訂的 write-ups 數量、審查標準、作者歸屬規則或 OpenAI 是否會採用社群修改。相關 GitHub repository 的內容與審查流程仍需由參與者自行查看；目前可確認的是一個供外部讀者與數學工作者協作的校訂入口，而不是對原始結果完成獨立驗證的聲明。