貪吃蛇AI省內存：兩行代碼的1600倍陷阱

400個元素存2比特信息？這種浪費在神經網絡訓練里能忍嗎？

一位開發(fā)者在優(yōu)化貪吃蛇AI時，發(fā)現(xiàn)方向編碼這個看似 trivial 的細節(jié)，竟成了內存優(yōu)化的最大瓶頸。從1600字節(jié)到250字節(jié)，差距藏在兩行代碼里。

1600倍的內存黑洞

先回顧背景。這位開發(fā)者之前用二元平面編碼（Binary Plane Encoding）表示貪吃蛇狀態(tài)：三個通道分別標記蛇頭、蛇身、蘋果位置。這個方案把游戲分數翻倍，但留了尾巴。

第四個通道是方向。蛇的當前朝向用uint8編碼：0=上，1=右，2=下，3=左。為了匹配矩陣形狀，這個單值被鋪滿了整個20×20的平面。

算筆賬：400個格子，每個存一個0-3的整數，實際信息只有2比特。通道級別的開銷是1600倍。

更糟的是連鎖反應。另外三個通道都是二值的，本可以按位打包（1比特/元素）。但方向通道的2比特打破了這一切——整個狀態(tài)被迫保持uint8格式，無法壓縮。

最終代價：每個狀態(tài)1600字節(jié)（20×20×4通道×1字節(jié)）。理論下限是250字節(jié)（20×20×5通道×1比特÷8）。一個通道的2比特，卡住了整個優(yōu)化鏈條。

直覺方案的翻車現(xiàn)場

四個方向，兩個比特，夠用了吧？開發(fā)者的第一直覺很幾何：用兩個二值通道，一個表示南北分量，一個表示東西分量。

北：南=0，東=0
南：南=1，東=0
東：南=0，東=1
西：南=0，東=0

發(fā)現(xiàn)問題沒？北和西都映射到(0,0)。碰撞了。

這個失敗很隱蔽。四個方向對應四種比特組合，數學上沒毛病。但"有沒有南北分量"和"有沒有東西分量"這兩個問題，對正交移動來說是錯的。

正交移動嚴格一維。垂直移動時，水平分量恒為零。但"不是東"和"不是西"在單比特里是同一個值。0無法區(qū)分"靜止的水平狀態(tài)"和"兩種相反方向"。

兩個比特確實能編碼四個狀態(tài)。只是這兩個比特選錯了。

換個問法：軸+符號

正確的編碼同樣用兩個比特，但問題變了：

軸比特：走哪個軸？（0=垂直，1=水平）
符號比特：朝哪個方向？（0=負，1=正）

北：軸=0，符號=0 → 00
南：軸=0，符號=1 → 01
西：軸=1，符號=0 → 10
東：軸=1，符號=1 → 11

四個方向，唯一編碼，無歧義。"哪個軸"和"哪一端"這兩個問題，對正交移動永遠有且只有一個答案。

符號約定（北是正還是負）無所謂，CNN會學會你的映射。關鍵是問題本身要匹配數據的結構。

開發(fā)者順便提了一嘴：如果是8方向游戲，軸+符號方案能擴展到3比特（2軸比特+1符號比特），或者直接用3比特做one-hot。但正交移動的貪吃蛇，2比特夠了——只要問對問題。

為什么這件事值得動手試試

這個案例的有趣之處不在技術深度，而在優(yōu)化層級的錯位。開發(fā)者最初在算法層發(fā)力（二元平面編碼），卻漏掉了表示層的低效。1600倍的浪費藏在最不起眼的地方：一個常數的存儲方式。

更典型的是調試過程。直覺方案"看起來對"，數學驗證也過關，卻在邊界情況（正交移動的零分量）上翻車。這種錯誤在神經網絡輸入工程里極其常見——特征工程的bug往往不崩潰，只是讓模型學得慢一點、差一點。

最后，這個優(yōu)化有明確的行動門檻：檢查你的狀態(tài)表示，有沒有"鋪滿平面"的標量？有沒有本可二值化卻被迫用整數的通道？內存瓶頸有時不在模型大小，而在數據管道的細節(jié)。

如果你也在做強化學習的游戲AI，現(xiàn)在可以打開代碼看看了。