新聞

【韓國東灘報導】一輛屬於韓國車用視覺AI軟體公司Stradvision的測試車，從研發中心駛上京畿道東灘的市區道路。車輛才開始移動，車內螢幕便以不同色框標示前方車輛、行人、車道與交通號誌。

駛入一段約百公尺、兩側停滿汽車的狹窄街道後，安裝在擋風玻璃上的單一前視攝影機，不只逐一辨識並標示路旁車輛，也持續追蹤前方及來向車輛的位置與移動狀態，將環境資訊提供給車輛控制系統，支援行駛過程中的轉向控制。

在停車場的另一輛測試車上，測試人員按下自動停車按鈕，車身四周攝影機拍攝的影像隨即顯示在螢幕上，系統辨識出停車格標線、三角錐、鄰近車輛及其他障礙物，再規畫倒車路徑。接著，整合視覺感知軟體的自動停車系統接手轉向、排檔、油門與煞車，將車輛倒入停車格。據現場車內觀察，整個過程一次完成，未見駕駛介入或反覆修正方向。

這類AI輔助駕駛與自動停車功能，在部分高價車款上已不罕見；但要進一步普及到中階甚至平價車款，卻仍受到感應器成本、晶片運算能力與軟體移植成本等因素限制。

另一方面，各國正逐步把部分先進駕駛輔助系統（ADAS）功能納入新車安全要求。歐盟一般安全規則（GSR II）已將智慧速限輔助等功能列為新車要求；美國國家公路交通安全管理局（NHTSA）在2024年公布的FMVSS 127最終規則，也要求輕型車配置可偵測前車與行人的自動緊急煞車系統，車廠必須在2029年9月符合規範。

在這樣的趨勢下，Stradvision看見一個機會，以成本相對較低的攝影機、輕量化AI模型，以及能支援多種系統單晶片（SoC）的軟體架構，協助車廠把原本多見於高階車款的ADAS功能導入更多價格帶的車型。
不過，法規帶來的需求能否轉化為量產訂單，還取決於一連串不容易被駕駛看見的工程挑戰：同一套AI軟體如何搭配不同平臺的晶片與攝影機？某個國家特有、卻很難蒐集的道路情境，要從哪裡取得訓練資料？模型每次修改後，又如何在交付期限前重新完成完整驗證？

Stradvision營運長權泰山（Taesan Kwon）指出，這些問題正是ADAS軟體走向量產時必須克服的挑戰，也使這個市場的競爭不再只是訓練出辨識率更高的神經網路。

先不做完整自駕系統，從感知軟體切入

成立於2014年的Stradvision，主力產品SVNet是一套以攝影機影像辨識車輛、行人、車道、號誌與標誌的AI感知軟體。這家公司一開始採取的策略不是提供從感知、決策到車輛控制的完整自駕系統，而是把軟體提供給一級供應商（Tier 1）或車廠，整合進ADAS與自駕系統。

權泰山表示，Stradvision目前聚焦L2、L2+至L3部分自動駕駛市場，而不是以L4高度自動駕駛為主要戰場。這也影響了公司的產品方向，相較於採取高成本感應器與運算硬體的方案，它選擇從攝影機、低功耗晶片與輕量化模型切入，希望把ADAS帶入更多價格帶的量產車。

這項策略的另一個重點是硬體彈性。車廠可能因車型、銷售地區、成本或供應鏈考量更換SoC晶片，如果感知軟體必須與特定攝影機及晶片高度綁定，每次更換平臺都可能增加軟體移植與驗證成本。

權泰山表示，Stradvision已將SVNet實作於超過30款SoC平臺，包括Texas Instruments、Renesas、AMD等業者的產品。如此一來，車廠可以在高階車使用運算能力較強的晶片，也能在印度、東南亞或南美等成本敏感市場，選擇功耗與成本較低的方案。

為了維持這樣的硬體彈性，Stradvision發展出共通平臺框架（Common Platform Framework），把不同SoC的底層硬體差異封裝起來，讓上層感知功能的應用程式層可以在不同平臺重複使用。權泰山表示，憑藉這套架構與工程團隊多年累積的硬體知識，面對新的SoC平臺，移植工作最快可以在一至兩週內完成。

Stradvision表示，SVNet目前已導入超過500萬輛量產車、50款以上車型。車用軟體從原型進入量產，還得經過Tier 1整合、車廠驗證與後續維護；因此，能否跨硬體平臺持續交付，和模型本身的辨識能力同樣重要。

利用生成式AI與模擬補足特殊道路情境

當ADAS進入不同國家，另一個問題隨之出現：以為已經訓練成熟的影像辨識模型，其實未必能應付當地特殊的情境。

當Stradvision進入印度市場後，首當其衝的挑戰就是韓國道路沒見過的牛隻隨地棲息的狀況，這不只是要能辨識突然闖入道路的牛，還包括躺在道路中央或兩側、姿態與一般影像不同的牛。除此，對於突然闖入車道的行人、大型拖車切換車道等高風險事件，也不能為了蒐集資料而在真實道路上演練。

為此，Stradvision把開發流程拆成五個相互銜接的環節：管理資料的SVDataFlow、生成合成資料的SVGenFlow、訓練模型的SVDeepFlow、建立動態情境的SVSimFlow，以及負責推論與評估的SVEvalFlow。整體開發過程中的資料從蒐集、補充、訓練到驗證，發現弱點後再回頭修補資料，形成一個資料飛輪（Data Flywheel）循環的資料處理管線。

為了要解決難以取得的少見或特殊情境的影像，Stradvision利用AI影像生成技術發展出SVGenFlow，不過它並非完全憑空生成特殊情境的道路影像，而是在已蒐集到的真實道路影像中，利用合成方式加入欠缺的物件與情境，生成所需的合成資料（Synthetic Data），並同時產生標註。根據AWS與Stradvision公布的成果，在加入合成資料後，動物情境的2D辨識指標由35.2提高至58.7，3D辨識指標由16.2升至24.9；近距離物件的檢測指標則由0.40升至0.98。

Stradvision指出，目前以模擬資料與實際道路資料訓練的模型之間，仍有約15%的性能差距，因此合成資料尚無法完全取代真實道路情境。不過，開發團隊可以在合成資料任意改變天候、光線或周遭物件數量，觀察模型在哪些條件下出現效能退化，再據此補充資料及調整模型，就能更快找出模型尚未處理好的情境。

模新更新要跑2萬小時資料驗證，算力尖峰以雲端承接

利用合成資料補充特殊道路情境後，模型仍須回到真實道路資料接受驗證。權泰山表示，不論訓練時加入多少合成資料，最終交付給客戶的新模型都必須重新接受測試。Stradvision會將過去從公共道路蒐集到的2萬小時影像，重新送入候選模型，檢查模型更新後是否出現效能退步或新的誤判。透過合成資料增加了模型可以學習的特殊或少見情境，而藉由真實道路資料來驗證，則守住交付前的最後安全關卡。

但這也帶來新的運算問題。模型更新越頻繁，需要重跑的資料越多，算力需求會在訓練與交付前突然升高。如果只為尖峰需求持續添購地端GPU，那麼這些算力在其他時間可能就閒置了。

Stradvision為此採取混合雲架構，同時運用位於浦項（Pohang）市的自有資料中心與AWS雲端服務。例行資料處理，以及規模較小的FrontVision、SurroundVision模型訓練，可以由浦項資料中心負責；遇到較大型的MultiVision感知模型訓練（整合前視、環景與遠景視覺），或必須在交付期限前完成1萬至2萬小時影像資料評估時，再使用可依需求彈性擴充的AWS GPU資源。

針對不同工作負載，Stradvision分別採用不同等級的GPU執行。例如，以配備Nvidia L40S的Amazon EC2 G6e執行合成資料生成與模擬，以配備Nvidia H200的EC2 P5en進行大型模型分散式訓練，再以配備Nvidia L4的EC2 G6執行大規模推論與評估。

AWS表示，Stradvision的架構設計可讓資料處理成本降低30%以上，訓練叢集準備時間縮短90%，訓練週期加快2倍；負責評估的SVEvalFlow實驗週期則縮短50%，並可同時執行數百項平行驗證。

安全規範讓測試情境持續增加

在因應歐盟GSR II智慧速限輔助要求的案例中，Stradvision必須在短時間內讓SVNet辨識歐洲32國、1,642種交通標誌。他們利用AWS的平行運算資源執行SVSimFlow，在兩個月內完成12,591項模擬情境；如果使用原有的單臺8 GPU地端伺服器，AWS估算相同作業約需6個月。

Stradvision接著再以SVSimFlow生成的資料訓練模型，結果原本表現最差的交通標誌辨識率由92.3%提高至98.1%，誤判數由31件降至22件。

除了提供可整合進ADAS的AI視覺感知軟體，Stradvision下一步還計畫把內部使用的資料管線SVDataFlow發展成雲端服務，預計2027年上半年透過AWS Marketplace推出。車廠與Tier 1供應商就可在自己的AWS環境中處理不便外流的車輛影像資料，並利用這些資料訓練或調整所需的AI模型。

Stradvision也希望把這套資料管線推向汽車以外的市場，包括機器人、國防與基礎設施等Physical AI應用。
這項跨產業計畫能否形成新的產品與客戶，仍待觀察。但從這次展示可以看出，至少在ADAS量產市場，AI模型的辨識能力只是挑戰的一部分。能否把模型快速移植到不同晶片平臺、補足現實中難以取得的資料，並在交付期限前完成大規模驗證，才是AI感知軟體真正上車前必須面對的考驗。