GPT-5.6 Sol 把 GPU 核心成本砍 20%

以前模型只会补代码，现在它能进生产 GPU 内核流程，把成本直接压下来。

我最近一直盯着一件让我又兴奋又烦的事：模型开始不只会写 demo 代码，而是碰生产环境里的硬骨头。以前让它补函数、写脚本、改测试，我还能忍；现在它开始往 GPU 内核这种地方挤，我反而更在意。因为这里不是“看起来能跑”就算数，每一行都要跟性能、正确性、回归风险狠狠干架。OpenAI 这次丟出来的东西，刚好踩在我最在意的那條線上。

我最不吃的就是那種“AI 幫你提效”的空話。你把它接進 workflow，它只會點頭、復述、吐一堆像樣但不能落地的東西。可這次不一樣。這篇知乎文章提到，GPT-5.6 Sol 透過 Codex 去重寫生產環境的 GPU 內核，還用到 Triton 和 Gluon，最後把推理成本降了 20%。這就不是“模型會寫碼”而已，這是模型開始直接碰錢。

我先講清楚：我下面拆的是這個方法論，不是替原文加戲。原文明確提到三個東西：Sol 用 Codex 自主重寫生產 GPU 內核、用 Triton 和 Gluon 這類開源 GPU 編程語言、再透過 FpSan 做正確性檢查。這個組合才是重點，單看任何一個都容易看歪。

別把「模型寫代碼」還停在補全器腦袋

GPT-5.6 Sol 透過 Codex 自主重寫了 OpenAI 生產環境裡的 GPU 內核代碼。

翻譯一下就是：它不是幫人補幾段輔助腳本，而是直接碰最敏感的性能路徑。GPU 內核這種東西，通常不是“能跑就行”。它要算吞吐、延遲、記憶體訪問、線程調度，還要盯著數值穩定性。很多團隊自己改這塊都要反覆 review，更別說交給模型去碰。

我真正關心的是“自主重寫”這四個字。它表示模型不是在人工逐行盯著改，而是在更高層級接收任務、生成候選實現，再被驗證工具和工程流程篩掉不靠譜的結果。也就是說，模型已經從“寫作助手”往“工程執行器”挪了一步。

我以前試過讓模型改性能熱點代碼，結果很典型：它會給我一個看起來很聰明的版本，但細看就知道是把複雜度挪到別處。要嘛引入分支，要嘛多一次拷貝，要嘛把問題藏進更難測的抽象層裡。人類 code review 最煩的就是這種表面優化。所以我看到這裡強調的是生產環境，我第一反應不是驚嘆，而是：他們到底怎麼把驗證鏈路搭起來的？

你如果要借這個思路，第一步不是“讓模型寫內核”，而是先定義什麼叫可接受輸出。性能目標、正確性約束、回滾條件、基線實作，全都要先擺出來。沒有這些，模型只會給你更多需要你擦屁股的代碼。

• 把任務定義成“替換某個熱點路徑”，不要寫成“優化一下性能”。
• 先有基線實作和可重複 benchmark，再讓模型動手。
• 把“正確”和“更快”分開驗證，別混成一個模糊結論。

Triton 和 Gluon 不是裝飾，是模型能下手的接口

用的是 Triton 和 Gluon，兩種 OpenAI 自己維護的開源 GPU 編程語言。

這句很關鍵。很多人一聽到“AI 改內核”，腦子裡想的是模型直接吐 CUDA C++。現實裡更可能是先讓模型在更可控的抽象層上工作。Triton 本身就是面向 GPU kernel 開發的高層語言，適合寫塊級並行邏輯；Gluon 也是同一類思路，給模型一個更結構化、更容易生成和驗證的表達空間。

我把這理解成：OpenAI 不是硬把模型塞進最底層機器碼地獄，而是給它一個“夠接近底層、但還沒低到失控”的操作面。這選擇很務實。因為模型最怕的不是不會寫，而是寫出來之後你根本不知道它在哪一步開始偏了。高層 GPU DSL 至少能把很多危險收斂住。

我以前在團隊裡做性能優化時，也見過類似的分層思路。人類工程師不會直接讓實習生改彙編；會先讓他改更高層的性能敏感模組，再透過 profiling 和測試逐層下壓。模型也是一樣。你給它的抽象越合理，越有機會讓它產出可審查、可替換、可驗證的候選實現。

所以如果你想復用這個模式，重點不是“選哪種語言最酷”，而是“哪種語言最適合讓模型少犯致命錯誤”。我會優先看這幾個條件：

• 語法和語義是否足夠規則，方便模型生成。
• 是否有成熟的編譯、測試、profiling 工具鏈。
• 是否能把性能熱點和正確性約束表達清楚。

說白了，語言不是給人炫技的，是給系統留安全邊界的。Triton 和 Gluon 在這裡的價值，就是把模型能碰的範圍圈住，讓它有機會真的產出工程結果，而不是胡亂發揮。

20% 成本下降，真正值錢的是這筆帳

改完之後，整體推理成本降低了 20%。

我不太喜歡“降本 20%”這種數字被單獨拎出來吹，因為脫離上下文很容易誤讀。但在推理成本這個場景裡，20% 就不是小數了。大模型服務的成本結構裡，GPU 時間就是硬錢。你省下來的不是“體驗更好一點”，而是可以直接映射成毛利、容量、定價空間，或者同樣預算下更多請求量。

這也是為什麼我總說，AI 真要落地，最後都會回到成本表。模型寫代碼能不能成，不取決於它會不會說漂亮話，而是取決於它能不能在不破壞正確性的前提下，把單位請求的成本壓下去。這裡的重點不是“模型幫人寫了代碼”，而是“模型寫出來的東西直接影響了線上帳單”。

我自己見過很多團隊在優化推理時卡住，原因很簡單：人類優化工程師太稀缺，熱點代碼太碎，改動太慢。你要一個人去盯 kernel、算訪存、調 block size、查回歸，最後還要過安全審核，週期長得離譜。這個時候模型如果能批量生成候選方案，再配合驗證工具自動篩，效率就會明顯不一樣。

但這裡也有一個常被忽略的坑：節省成本不等於節省複雜度。很多優化最後會把複雜性轉移到維護側。你今天省了 20%，明天多了 30% 的排障時間，那就虧了。所以真正有價值的不是一次性的“更快”，而是“更快且還能維護”。

如果你在自己的系統裡想做類似事情，我建議先從最容易量化的路徑開始：

• 選一個請求量最大、GPU 占比最高的 kernel 或算子。
• 建立優化前後的統一 benchmark。
• 把成本指標和正確性指標同時掛在 CI 裡。

我會特別強調最後一點。沒有 CI 的性能優化，基本等於在給未來埋雷。你今天贏了 20%，下個版本可能就悄悄虧回去。

FpSan 不是配角，它是這件事能不能成立的關鍵

OpenAI 還專門用了開源驗證工具 FpSan 來確保 Sol 寫的內核代碼是對的。

這句我很喜歡，因為它終於沒有把“AI 生成”當成魔法了。模型生成代碼，最怕的不是慢，而是錯得很隱蔽。尤其在 GPU 內核這種地方，錯不一定立刻炸，可能只是某些輸入下數值偏一點，或者性能回退得很隱蔽。你如果沒有驗證工具，最後就是靠人肉抽樣和運氣。

FpSan 的存在說明 OpenAI 不是在賭模型“應該是對的”，而是在把正確性檢查自動化。這個思路我非常認同。因為一旦你把驗證做成機器可執行的規則，模型的作用就從“拍腦袋寫代碼”變成“批量生成候選，由系統篩選”。這才是工程。

我以前在做自動化重構時也踩過類似坑。代碼生成器最容易犯的錯就是輸出一堆看著像樣的東西，結果邊界條件全漏。後來我們把單元測試、靜態檢查、差分測試、性能回歸都接上，生成器才真的開始有用。不是因為它突然變聰明了，而是因為我們終於能穩定地拒絕壞答案。

所以你要學的不是“讓 AI 寫得更像人”，而是“讓系統更會判錯”。這點特別重要。模型再強，也不該承擔最終裁判的角色。裁判應該是測試、驗證器、基準和回歸門禁。

如果你要把這個模式搬到自己的項目裡，我會這樣做：

• 先定義數學上或行為上的不變量。
• 把這些不變量變成可執行測試，而不是文檔裡的口號。
• 讓生成器只負責產出候選，不負責宣布勝利。

這就是為什麼 FpSan 這種工具值錢。它不是錦上添花，它是讓模型進入生產鏈路的門檻。

Codex 的角色不是寫代碼，是跑工程回路

GPT-5.6 Sol 透過 Codex 自主重寫了……

我把 Codex 放到最後講，是因為很多人會誤解它的角色。Codex 不是單純的代碼生成器，它更像一個能在倉庫、測試、工具鏈之間來回跑的執行層。也就是說，它不是只吐文本，而是能參與工程回路：讀代碼、提修改、跑驗證、再修正。

這個差別太大了。前者是“會寫”，後者是“會幹活”。我見過太多 AI 編程產品卡在前者：補全很漂亮，落地很痛苦。因為真正的工程不是一次性輸出，而是反覆試錯、修補、驗證、再試錯。沒有這個閉環，代碼永遠停留在半成品狀態。

原文裡說 Sol 是“透過 Codex”做這件事，我理解為模型被放進一個更完整的執行框架裡，而不是孤零零地生成一段 kernel。這個框架裡應該有任務分解、上下文讀取、候選生成、驗證反饋和迭代修復。沒有這些，所謂“自主重寫”很容易只是一次漂亮的演示。

我在實踐裡最怕的就是把“生成”當成終點。其實生成只是第一步，後面還有很多髒活：修命名、補邊界、對齊風格、跑測試、看 profiler、處理回歸。Codex 這類系統如果真要進入生產，就必須把這些髒活也吃進去。

你要借鑑這個思路，別先問“怎麼讓模型更強”，先問“怎麼讓它能在失敗後繼續工作”。這是工程系統和玩具演示的分界線。

我會怎麼把這套方法搬進自己的團隊

如果是我來設計一條類似流水線，我不會一上來就讓模型碰最核心的 kernel。我會先挑一個有明確瓶頸、但風險可控的熱點路徑。然後我會把它拆成三層：候選生成、自动驗證、人工抽查。模型負責多產出，工具負責多拦截，人類只盯最值得看的部分。

這套方法的核心不是“讓 AI 取代工程師”，而是把工程師從重複試錯裡解放出來。說白了，工程師不該把時間都花在寫第十個相似 kernel 版本上，而應該花在定義約束、看異常、處理邊界和做架構判斷上。

我也會把可觀測性提前做好。沒有 profiling、沒有回歸測試、沒有版本對比，模型寫得再多都沒意義。你得知道每次修改到底改了什麼，快了多少，壞了哪裡。否則你根本沒法判斷模型到底是在幫忙，還是在製造更多噪音。

最後我會給團隊留一個硬規則：任何模型生成的性能代碼，都必須能被獨立重現。不能重現的優化，一律不算優化。這條規則聽起來死板，但它能省很多爛帳。

如果你只記一個點，我希望是這個：這類系統的價值不在“AI 會寫內核”，而在“AI 寫出來的內核能被驗證、能被替換、能被算進帳本”。這才是能進生產的東西。

可抄的模板

# AI 生成性能代碼的生產模板

## 目標
- 優化對象：{kernel / 算子 / 熱點函數}
- 目標指標：{延遲 / 吞吐 / GPU 成本 / 顯存占用}
- 約束條件：{正確性、數值誤差、接口兼容、回滾要求}

## 輸入材料
- 基線實作：{path}
- benchmark 腳本：{path}
- 測試集：{path}
- 性能基線：{當前 p50 / p95 / 吞吐 / 成本}
- 允許使用的語言 / DSL：{Triton / Gluon / 其他}

## 生成任務
讓模型完成以下步驟：
1. 讀取基線實作和性能瓶頸說明
2. 生成 3 個候選實作
3. 對每個候選說明優化思路
4. 標記可能的正確性風險
5. 輸出最優候選及原因

## 驗證流程
- 靜態檢查：{lint / typecheck / compile}
- 正確性檢查：{單測 / 屬性測試 / 差分測試 / FpSan 類工具}
- 性能檢查：{benchmark / profiler / regression gate}
- 通過條件：
  - 所有正確性測試通過
  - 性能提升 >= {threshold}
  - 無顯著回歸

## 人工審查清單
- 是否引入隱藏分支或額外拷貝
- 是否破壞數值穩定性
- 是否增加維護複雜度
- 是否能在當前倉庫結構中長期維護

## 失敗處理
- 若驗證失敗：把錯誤日誌喂回模型，要求只修復失敗點
- 若性能不達標：保留正確版本，繼續生成替代候選
- 若維護成本過高：拒絕合併，即使性能更好

## 合併規則
- 只有當「正確性 + 性能 + 可維護性」同時滿足時才合併
- 所有模型生成的改動都必須可重現
- 所有優化都必須附帶基線對比數據

這份模板的重點不是形式，而是控制權。模型可以幫你批量試錯，但最後門檻必須握在人和驗證系統手裡。否則你只是把 bug 的生成速度提上去了。

原始來源是 這篇知乎文章，以及文中提到的 Codex、Triton、Gluon、FpSan。我這篇是基於這些材料做工程拆解，模板段落是我重新整理過的，可直接拿去改成你自己的流程。