NVIDIA 論壇聊 SU(7) CUDA 晶格引擎

2026 年 3 月，NVIDIA Developer Forums 出現一篇很怪的討論。主角是 Anchor4 SU(7)。它把系統想成 7×7×7 的晶格，總共 343 個節點。

作者還提到一個二進位傳輸格式，叫 SU7P。說真的，名字很硬派，但真正有意思的地方，是它想怎麼塞進 CUDA。

這篇討論不是在比誰的數學名詞多。它是在比誰真的懂 GPU。shared memory、warp、bank conflict，這些才是會讓程式卡住的東西。

Anchor4 SU(7) 到底想做什麼

Anchor4 SU(7) 被描述成一種 runtime 架構。它拿相位值做狀態同步。白話一點，就是把整個系統當成一張晶格，然後依照鄰居和遠端連結更新狀態。

作者把它連到 SU(7) 的對稱概念。也提到 Kuramoto order parameter。這種寫法很像研究筆記。看起來很玄，但核心還是同步與耦合。

這裡的重點是資料結構，不是哲學。7×7×7 等於 343 個節點。這個規模不大，很多 NVIDIA GPU 的 shared memory 都有機會放得下。作者也提到 13、25、49 這些更大的格子。意思很清楚：小格子走快路，大格子就得切塊。

• Adaptive topology：依 R 值切換連結型態
• Vectorized update：用矩陣運算取代迴圈
• SU7P：用來傳 lattice state 和 file
• CUDA port：把更新邏輯搬進 kernel

這種設計很像研究原型。它有一點理論味，也有一點系統味。問題只剩一個：GPU 會不會買單。

我覺得這才是論壇討論有趣的地方。不是 SU(7) 聽起來多帥，而是它是不是一個能跑得動的工作負載。

論壇回覆把話題拉回硬體

真正有用的回覆來自使用者 Curefab。他直接把話題拉回 shared memory。講白了就是：先把一大塊資料載進來，再讓整個 block 重複用。

這句話很樸素，但很對。CUDA 的效能常常不是輸在演算法，而是輸在 memory access。你一直打 global memory，速度就會很難看。

Curefab 也提醒了 warp 的問題。32 個 thread 一起跑，資料對齊不好，就會碰到 bank conflict。這種問題很煩。看起來只差一點點，實際上效能可能差很多。

“A large data block would be loaded into shared memory and the whole Cuda block would work on it, so data is reused.”

這句話很像老司機在救火。不是在講故事，是在講怎麼活下來。CUDA 開發常常就是這樣，先讓資料流順，再談別的。

作者回應時也補了細節。他說 7×7×7 可以放進 shared memory。更大的格子則會用 tiled phase-lattice。還提到 bit packing、texture objects、register-heavy updates。這些方向都合理，但熟不熟就要看實作了。

更現實的是，作者自述人在烏克蘭，還常遇到停電和斷網。這不影響技術判斷，但會讓整個專案看起來更像邊做邊試的研究筆記，而不是完整產品。

CUDA 真正會卡在哪裡

一旦談到實作，問題就變得很具體。Curefab 建議每個 thread 處理一個鄰域，例如 2×2×2 或 3×3×3。這樣附近的資料可以在 shared memory 內重複使用，不必一直回 global memory。

作者則提到把 3D 座標壓成 1D 陣列，再用 bit shift 做索引。這很 CUDA。因為 GPU 喜歡簡單位址計算。你位址算得越快，整體就越容易跑順。

但這裡也有坑。若 tunnel links 太多，而且位置又很亂，block 內的資料流就會變得很難預測。這時候再漂亮的對稱模型，也會被 memory traffic 拖住。

• 7×7×7 = 343 nodes，對 shared memory 很友善
• 13×13×13 = 2,197 nodes，開始需要 tiling
• 49×49×49 = 117,649 nodes，global memory 壓力很大
• Warp = 32 threads，映射不必硬湊成 32 才合理

作者還提到 __shfl_sync()。這是很實在的 CUDA primitive。用在 warp 內廣播或交換小資料時，確實好用。但它不是萬靈丹。register 很快，卻也很私有。你要做動態索引時，常常沒那麼順手。

所以 Curefab 的提醒很重要。不要為了對齊 warp 而硬做 1:1 映射。很多時候，一個 thread 處理一個小鄰域，反而比較省事，也更省 memory bandwidth。

和一般 GPU 設計比起來

如果拿它跟一般 stencil code 比，Anchor4 SU(7) 明顯更複雜。標準 stencil 的鄰居關係通常很固定。這個案子多了 adaptive links，還有遠端 tunnel。彈性高，但排程也更麻煩。

這種差異會直接反映在效能上。規則越固定，越容易做 coalesced access。規則越亂，越容易讓 shared memory 和 warp 排程出現雜訊。

下面這個比較最直白：

• 標準 stencil：鄰居固定，容易做 cache 和 shared memory reuse
• Anchor4 SU(7)：連結型態會變，資料流更難預測
• Warp 對齊：有時有幫助，但不必硬把模型塞進 32
• Shared memory tiling：只有在資料重複使用夠多時才划算

這也是這篇討論最實際的地方。不是在比哪個理論比較帥，而是在比哪個資料流比較省。

作者還把 Python reference implementation 放到 Zenodo。這點我給過。因為有 reference code，CUDA 開發者才有東西可以 profile。沒有基準，大家只是在空談。

如果你想看更接近的 GPU 實作思路，也可以對照 OraCore 先前整理的 CUDA grid 系統 kernel 設計筆記。核心概念其實很一致：規則資料流，比花俏名詞更重要。

這篇論壇串真正透露的事

Anchor4 SU(7) 目前看起來還不是成熟產品。論壇內容也沒有證明它一定比傳統方法快。可是它證明了一件事：只要你能把模型接到 memory layout、occupancy、synchronization，CUDA 圈子就願意聊。

我自己的判斷是，這個專案最有價值的地方，不是 SU(7) 這個名字，而是它試著把狀態更新寫成可重用的晶格。這種結構如果做得好，確實能讓 GPU 比較好發揮。

但風險也很明顯。只要對稱語言和動態規則太多，工程上就容易失焦。CUDA 不吃空話。它只吃幾個東西：連續記憶體、重複使用、少分支、夠多工作量。

如果這個案子真的要往前走，我猜第一個效能提升不會來自 SU(7) 數學本身，而是來自 shared memory tiling。先把鄰域 reuse 做好，再談那些更抽象的東西，這比較像 GPU 工程的正常路線。

你可以把這篇論壇串當成一個很典型的案例。研究想法很大，硬體限制很小。最後能留下來的，通常不是最漂亮的理論，而是最省資料搬運的那一版 kernel。

接下來該看什麼

如果 Anchor4 SU(7) 之後真的有 CUDA prototype，我會先看三件事。第一，shared memory 的利用率。第二，bank conflict 有沒有被壓低。第三，tunnel links 到底有多亂。

只要這三件事處理得不差，它就有機會變成一個有趣的 GPU 實驗。反過來說，如果資料路徑一直碎掉，再漂亮的對稱模型都救不了。

所以我的預測很直接：下一輪討論重點，會從 SU(7) 的數學，轉到 block 配置、tile 大小和 warp 邊界。你如果也在寫 CUDA，不妨先問自己一句：我的資料，是不是比我的模型還重要？