深挖汽車科技 解碼智能安全
作者 | 溫崢峰，某大型主機廠智駕基礎架構負責人，專注于算力平臺可靠性、數據治理與安全生產體系的實踐研究
首發于談思汽車，轉載需授權
過去兩年，車企在智駕基礎設施上砸的錢，比前面五年加起來都多。GPU 萬卡集群從新聞變成了標配，智算中心的審批從能不能建變成了能建多快。從業務視角看，一切都在加速。
但如果你從安全治理的視角看同一件事，會發現一個斷層——基礎設施跑得很快，風險管控還在起點。
做網絡安全的朋友們盯的是車端：T-Box 有沒有漏洞、CAN 總線有沒有被注入、OTA 通道有沒有被劫持。但很少有人注意到，在智駕訓練的云端——那些跑著幾十億參數大模型的 GPU 集群里——同樣存在著結構性的脆弱層。它們不是傳統意義上的安全漏洞，但它們的后果，可能比一個漏洞嚴重得多。
問題
三個結構性的脆弱層
第一個脆弱層：算力使用的審計盲區。
多數團隊對 GPU 集群的管理停留在兩個指標上：分配率和使用率。前者說明多少卡被占用了，后者說明這些卡有沒有在跑。如果兩者都接近 100%，PM 就覺得錢沒白花。
但這兩個指標不回答治理真正關心的問題：誰在跑什么任務、任務訪問了什么數據、有沒有異常的算力調用模式、有沒有人在訓練非授權的模型。
我見過幾個真實場景。一個算法工程師周末提交了一個個人實驗任務，占了幾十張卡，跑了三天，沒人發現——分配率上升了，但沒人知道跑的是什么。
一次存儲告警失效，數據盤寫滿兩周才被注意到，期間多少任務讀到了損壞的數據、模型有沒有被污染，沒有審計記錄，無從追溯。GPU 節點維修后重新上線，線纜接錯導致通信帶寬大幅下降，任務沒報錯只是慢了，而訓練出來的模型質量沒人敢保證。
這些問題本質上是同一個：基礎設施能告訴你出沒出事，但無法告訴你出什么事了。做基礎設施的人只關心好不好用，做安全的人只關心有沒有被攻破，兩者之間的灰色地帶，沒人管。
第二個脆弱層：數據流轉的合規斷層。
智駕訓練依賴的路采數據，天然攜帶大量敏感信息——地理信息、道路設施、行人、車牌。這些數據的存儲和使用，涉及測繪資質、數據安全法、汽車數據安全管理規定等多重合規要求。合規云、數據脫敏、數據不出境，這些概念在車企安全團隊里已經耳熟能詳。
但在實際運行中有幾個接地氣的問題往往被忽略。
存儲分層的合規差異：
熱數據在本地并行文件系統，溫冷數據下沉到對象存儲，歸檔數據是否還受同一套合規策略保護，如果某個 bucket 被誤配成公開讀，系統多久能發現。
數據流轉的可見性：
一個訓練任務從準備數據到產出 checkpoint，數據在多個介質間流轉，出問題時能否全鏈路定位到環節。
外部團隊的接入路徑：
數據標注要接觸原始數據，合規云的原則是數據不出去，現實中的 VPN 打通或內部 VDI，本質都是在合規邊界上開了一道門，鑰匙誰來管、權限誰來審計、日志有沒有人定期查。
這些問題單獨看都不大，累加起來就是系統性風險。
第三個脆弱層：共享架構的隔離缺失。
感知、規劃、泊車、標注、仿真，多個算法團隊共享同一個 GPU 集群。共享帶來效率，也意味著一個團隊的異常可以輕易傳染給其他團隊。
資源擠占：
一個泊車任務因為算力不可用，在隊列里排了六個小時，沒人被告知，也沒有告警。如果這是關鍵版本發布的最后一輪訓練，延遲會直接傳導到整個發版流程。
配置漂移：
為了最大化利用率，運維團隊不斷微調調度策略、資源配額、親和性配置，這些變更很少經過安全評審。
單點依賴：
一個團隊集中提交大批任務后，集群控制面突發過載，所有團隊都無法提交新任務——沒有人被攻擊，是自己人把自己人搞掛了，這種內源性故障在傳統安全模型里幾乎沒有被討論過，因為傳統模型預設了攻擊來自外部。
共享不是錯，共享的前提應該是隔離：任務之間的隔離、團隊之間的隔離、故障影響范圍的隔離。這些隔離機制的缺失，本質上是基礎設施設計的治理缺陷。
解法
把治理框架拉通，而不是等系統自己變安全
這三個脆弱層有一個共同特征：它們平時不會爆發，因為觸發它們的是配置錯誤、任務堆積、存儲爆滿這類運維事件，走的也是運維團隊的響應流程，而不是安全團隊的應急流程。但一旦觸發，后果是系統性的：模型被污染而無法溯源、敏感數據在不可控的記錄中被存取、一次資源異常擊垮整個訓練排期。
所以解法不能停留在修系統、加告警的層面。車企的智駕基礎設施，已經到了需要把基礎架構治理和安全合規治理拉通來做的階段。這不是讓架構師去學安全，或者讓安全工程師去管 GPU，而是兩者必須在一個統一的治理框架下對話。
這個框架，我用三個原則來定義。
第一個原則：把算力當核心資產來治理。
車企過去對算力的認知，是把 GPU 當作資源——買多少、用多少、成本多少。但從治理視角看，算力集群正在變成承載公司最核心知識產權的地方：訓練數據、模型參數、訓練過程，全部在這里。對待核心資產的治理標準，跟對待資源的治理標準是不同的。資源可以粗放，核心資產必須回答幾個問題：誰能接觸、誰在接觸、接觸過程留不留下記錄、異常接觸能不能被發現。
這意味著治理的起點不是監控工具，而是資產盤點：搞清楚集群里到底有什么、誰在使用、價值幾何。這個認知轉變，是所有治理動作的前提。
第二個原則：治理要前置，不要等事故來教育。
安全行業有一句話，事后追責是成本最高的一種治理方式。智駕基礎設施更是如此——一次訓練事故，損失的不只是算力，還有時間窗口。訓練一輪大模型要幾個月，中途數據污染了，重來一遍的代價是數千萬的算力和幾個月的研發周期。
所以治理動作必須在事故之前：可觀測體系先于故障建立，隔離邊界先于共享確定，合規策略先于數據流轉定義。前置治理看起來像增加成本，實際上是在為未來最貴的那次事故買保險。買保險的最佳時機，永遠是你還沒有出險的時候。
第三個原則：治理是跨團隊共識，不是單部門職責。
智駕基礎設施的治理，天然跨越三個團隊：基礎設施團隊管資源，算法團隊用資源，安全團隊護資源。任何一方單獨行動，都無法形成閉環。基礎設施團隊部署了監控，算法團隊不配合打點，數據鏈路就是斷的；安全團隊制定了審計規范，沒有基礎設施團隊落實采集，規范就是空文。
管理層的角色，是讓這三個團隊在同一個治理框架下對齊目標，而不是各自為戰。具體到操作層面，是明確三個東西：數據歸誰、責任到誰、異常誰處理。這三個問題說不清楚，任何技術方案都落不了地。
在這三個原則之上，落地分三個階段。
第一階段
建立可觀測與審計基礎。把算力使用的全鏈路數據收上來，讓誰在跑、跑什么、跑得對不對從黑盒變成白盒。這是所有治理動作的數據底座，沒有這個，后面都談不上。這一階段的標志性產出，是集群從看不見變成看得見。
第二階段
明確數據與合規邊界。梳理數據流轉的每個環節，讓合規策略跟著數據走，而不是跟著系統走。數據到哪一層、誰能接觸、怎么審計，在流轉開始之前就定義清楚。這一階段的標志性產出，是數據邊界從模糊變成清晰。
第三階段
設計共享與隔離架構。在多團隊共享的集群里，把任務隔離、團隊隔離、故障影響范圍隔離當作架構原則來設計，而不是出了問題再補救。這一階段的標志性產出，是集群從單點風險變成結構化韌性。
三個階段走完，這套治理框架才算真正閉環：看得見、管得住、隔離得開。
說幾句心里話。
這三個脆弱層——審計盲區、合規斷層、隔離缺失——都不是新問題，也都不是無解的問題。但它們有一個共同特征：在不出事的時候，看起來都不重要。
而這種隱性，恰恰是智駕基礎設施最大的敵人。等你看得到影響的時候，損失已經發生了。
我寫這個專欄，就是想把那些踩過的坑、趟出來的路，一條條拆開講清楚。不聊概念，只講判斷。
下一篇聊可觀測性：安全團隊最沒底的事，是不知道算力集群里跑著什么。
- THE END -
本公眾號所發布內容僅供行業學習與交流參考，不構成任何投資或采購建議。文中觀點僅為作者個人見解，不代表平臺立場。因文章部分文字及圖片涉及到引用，如有侵權，請及時聯系17316577586，我們將刪除內容以保證您的權益。
點贊
收藏
分享
