芯耀
1352
主講 | 蔣沁宏? ?編輯 | Amy
編者注：本文是HiEV出品的系列直播「硬核拆解BEV」第三期問答環(huán)節(jié)內(nèi)容整理。商湯絕影量產(chǎn)行車智能駕駛研發(fā)負責人蔣沁宏，與連線嘉賓寒武紀行歌自動駕駛總監(jiān)李想、宏景智駕高級工程經(jīng)理柴可寧、主持嘉賓周琳展開深度交流，并進行了答疑。
BEV對芯片的核心訴求
Q：近兩年自動駕駛落地并上車，與此同時，涌現(xiàn)多個芯片玩家，例如地平線、寒武紀和黑芝麻，大家共同為自動駕駛行業(yè)努力。那么像商湯絕影這樣的智駕解決方案供應(yīng)商，對國產(chǎn)芯片有何核心訴求？
蔣：過去一年多，我們在芯片使用上存在一些痛點，主要是兩方面。首先，是整個芯片對硬件設(shè)計，包括對算子的支持，我們希望能考慮到目前一些算法的發(fā)展趨勢。大家有目共睹，整個模型趨勢是向 All-in-One 方向發(fā)展的，新模型必然帶來新需求。
例如早先的 AI 芯片，更多會考慮對 CNN、Pooling 等的優(yōu)化。而現(xiàn)階段可能要更往前一步，例如考慮到引入Transformer 算法后，可能對芯片的帶寬要求更高，并需要能夠支持 BEV 算法的相關(guān)算子。這也是算法供應(yīng)商對國產(chǎn)芯片的強需求。其次，是生態(tài)支持。新芯片需要建立新生態(tài)，而打磨是長周期的過程。而且新芯片必然會碰到多個新問題，這些問題不止與模型推理相關(guān)，還有量化的對齊、傳感器的接入和預(yù)處理等。我認為在工具鏈和文檔不完備的情況下，很需要一些完善的售后服務(wù)和快速響應(yīng)。
Q：深有體會，所以我們在芯片設(shè)計階段，會盡可能前瞻性地考慮這些。那像商湯絕影這樣綜合的解決方案公司已經(jīng)做過很多項目，使用了國內(nèi)外不同的芯片方案，能點評一下使用體驗或優(yōu)缺點嗎？
蔣：從芯片本身來講，大家風格不同。有的芯片不管是在算力、CPU還是帶寬上，都比較均衡，但沒那么突出；而有的芯片某一方面可能會很優(yōu)秀，例如AI算力，但其他方面少許偏科。這都是芯片公司根據(jù)趨勢做的設(shè)計。所以我認為，第一，沒有完美的芯片，不管什么芯片都有一些對應(yīng)的算法、方案能夠完成部署，其部署難度也取決于芯片本身。第二，芯片差異可能在于文檔的可完善性，以及從生態(tài)角度來看，國內(nèi)外芯片還是存在差距的，畢竟人家深耕已久。而國內(nèi)芯片團隊則能給予較大支持力度，能夠共同做優(yōu)化、團隊響應(yīng)快，這也是國產(chǎn)芯片的優(yōu)勢。
算法供應(yīng)商如何支持主機廠的自研需求？
Q：自動駕駛技術(shù)趨勢發(fā)生了變化，前兩年都在堆算力，要上1000Tops，要配置5個激光雷達。但今年大家逐漸趨于理性，不再講堆料，而是降本，同時繼續(xù)做技術(shù)方案的探索、迭代甚至升級，比如城市NOA開始探索無地圖的方案。自動駕駛趨勢變化快，您作為自動駕駛老兵，認為自動駕駛技術(shù)方案終局如何？對于芯片公司以及算法供應(yīng)商，可能需要提前做哪些準備和規(guī)劃？
李：我先講個人感受，再講宏觀方法論。比如硬件算力和傳感器。這好比當年一起做L4的Robotaxi，最開始不管是從安全性，還是項目風險的角度出發(fā)，先把算力和傳感器埋進去。雖然當時講硬件預(yù)埋，是給大家留下更多功能想象，但更多是為了保證項目穩(wěn)定和車輛安全。而這本質(zhì)上是先摸清算力的底線。因為乘用車最終講究性價比和客戶買單，那么就要：
- 理清性價比的臨界點
- 保證方案和功能實現(xiàn)時最具性價比的算力
- 確定最終預(yù)算
這是市場所關(guān)注且過去兩年落地時堆料多的原因之一。另一原因是，OEM有同輩壓力。如果硬件預(yù)埋能保證功能交付時間節(jié)點，那肯定要做。但長期看，OEM也要摸清性價比的界線。這也是芯片公司和解決方案公司要努力的方向。
第二個問題，技術(shù)創(chuàng)新的角度，整個行業(yè)在前進，今年很多玩家在講mapfree，例如元戎啟行、華為。全國的高速高精地圖花個小幾千萬就可以買到，但是城市的高精地圖有以下特點：
- 本身成本高昂
- 更新成本高，為保鮮度要定期更新
如果城市NOA通過驗證發(fā)現(xiàn)不需要高精地圖，那有將有助于產(chǎn)品落地。方法論角度，通過與OEM的合作，我發(fā)現(xiàn)（整個產(chǎn)業(yè)）是一個To B、To C的產(chǎn)業(yè)，不單純是To B的。所有人要思考OEM怎樣讓用戶買單，這才符合大家共同的商業(yè)模式。
第一，長期來看，研發(fā)費會逐步降低，營收要靠訂閱收取，但訂閱率如何提高，是我們和OEM共同要面對的。
第二，科創(chuàng)和技術(shù)創(chuàng)新講究「人無我有」。但從近幾年自動駕駛的發(fā)展看，各家功能級的差異還未能跨出一代。而創(chuàng)新能否真正解決用戶需求或痛點，則和訂閱率掛鉤。
第三，性價比。中國產(chǎn)業(yè)的發(fā)展路線都是從創(chuàng)新到卷性價比，去年大家開卷行泊一體，未來可能會有艙駕一體。而我比較好奇，未來艙駕一體能否在中國實現(xiàn)，哪家車廠會第一個有魄力做出來并量產(chǎn)？
而大方向上，算力也有下降趨勢，技術(shù)側(cè)終要為產(chǎn)品側(cè)服務(wù)。因此，產(chǎn)品側(cè)的預(yù)判和方向，技術(shù)側(cè)仍要拆解，芯片和解決方案方皆要提前做預(yù)埋和準備。
Q：BEV落地過程中，BEV跟傳統(tǒng)的單目2D算法，是共存還是徹底替換的關(guān)系？
蔣：問題很好，這也是我們目前在做技術(shù)迭代或算法迭代時遇到的問題。我認為，這要分任務(wù)類型抉擇。首先，對于同一類感知任務(wù)且下游依賴相對統(tǒng)一，比如PVB目標感知它的下游只有融合，肯定是替代關(guān)系。沒必要出了BEV的PVB，還要出2D的PVB，最后可能只有一個下游在用。其次，還有一些任務(wù)，受到下游的算法影響。眾所周知模型、方案的迭代很快，而下游算法例如標定，它的更替相對要慢。比如車道線，現(xiàn)在BEV直接檢測出車道線，給到規(guī)劃控制用。但車道線還有另一種用法，比如在線標定時它其實用的是一些2D車道線，對于這些任務(wù)來說，因為下游還未完成算法的更替，我出這套BEV方案時，還要額外做一些2D任務(wù)。還有一些任務(wù)，出于技術(shù)或是真值的局限性，在任務(wù)沒重要到用BEV 3D做時，還是用2D做。例如交通燈標志牌，我們獲得其 3D 的真值還是較為困難，而2D方案也可以通過多幀聯(lián)合優(yōu)化來解算3D位置。
另外一點，要考慮如何迭代高效。因為做多任務(wù)學(xué)習，必然會有一些任務(wù)更新迭代很快，而另一些則相對較慢，例如PVB和TSR的迭代節(jié)奏就不同，此時就需要解決不同研發(fā)人員之間版本更新的沖突。要保證更新不影響部署，研發(fā)資源就需要協(xié)調(diào)和妥協(xié)。所以，從總體上來看，（BEV算法與傳統(tǒng)算法）在部分任務(wù)上是共存關(guān)系，部分任務(wù)上可能是替換關(guān)系。
Q：很多OEM有自研BEV的需求，作為算法供應(yīng)商，或者像我們這樣的系統(tǒng)供應(yīng)商/域控供應(yīng)商，應(yīng)該扮演怎樣的角色去滿足車廠BEV自研需求？蔣：這并不沖突，從當前的商業(yè)模式下，很多人認為，我們跟主機廠自研的需求之間的關(guān)系看起來是可替代的。從技術(shù)演進的角度來看，這兩者之間并不是零和博弈的。從商業(yè)模式角度來說，我們在項目研發(fā)過程中，會衍生出一些新的商業(yè)模式。另外，作為解決方案供應(yīng)商的角度，我們在算法上的領(lǐng)先和探索是核心優(yōu)勢。我剛剛有提到，我們在端到端和大模型上做的一些布局和思考，不局限于智駕這一個領(lǐng)域。而在這些方面的領(lǐng)先性，讓我們可以跟主機廠探索進一步合作，從而可以帶給C端用戶一些用戶價值。商業(yè)的成功是利他，利他最后可能才是利我。
未來域控向單SOC集中式發(fā)展
Q：域控形態(tài)非常多樣，有的域控是單SOC的，有的是多個SOC的，可能需要外掛一顆MCU解決功能安全等問題，有的直接是一體化的，那無論是從行泊一體，還是駕艙一體角度出發(fā)，您認為，域控最終的理想形態(tài)是怎樣的？
柴：首先從算法升級和技術(shù)角度來考慮，我們認為，未來域控肯定是更傾向于單SOC這種芯片式集中域控方式發(fā)展的。因為無論是像這種感知端的BEV，包括前融合技術(shù)，還是接下來決策規(guī)劃一體式的后端架構(gòu)，往往需要在獨立的中高算力芯片上高效運行。如果是比較小的、多個的ASOC或多個芯片，那么效率就沒那么高。還有就是，之前泊車和駕艙一體的芯片去年又開始火起來了，未來我們非?？春?strong>駕艙一體。駕艙一體其實相當于把駕艙泊車和行泊一體進一步整合，隨著以后座艙或者駕艙一體芯片的升級，和整個功能安全架構(gòu)設(shè)計的升級，艙駕一體化肯定能進一步降低成本，提升客戶體驗。我認為，從市場和消費者的角度來說，其實這個東西做了以后，消費者能否感知到實際的提升比較重要。蔚來汽車發(fā)布了Banyan車機系統(tǒng)2.0.0版本，它整合了Orin X和8155的算力，它把很多的8155上的一些AI語言模型都遷到了Orin X上，整個算力通過異構(gòu)的方式集合起來，在往駕艙一體方向發(fā)力。升級以后，從消費者體驗來說，我感覺車機更絲滑，語音交互更智能，其實消費者是會在這個地方買單的。
Q：駕艙一體使用了8155芯片和傳統(tǒng)的自動駕駛芯片，如果打通的話，難點在哪里？
柴：一個難點是，從芯片公司角度考慮，駕艙和智駕是兩撥公司，可以看到很多芯片公司在AI芯片上下一代的布局，例如英偉達、高通，國內(nèi)的地平線、芯馳、寒武紀和安霸等。應(yīng)用方面，從自身經(jīng)驗來看，這對軟件能力、工程要求較高，比如在一個單J3芯片上做行車和泊車一體，其實行車和泊車的感知算法沒辦法同時跑的，肯定存在切換的過程，而如何通過高效的軟件設(shè)計，讓切換在用戶端是無感的，這就比較考驗各家實際落地能力。我覺得，主要在芯片端和使用端的這兩點上。
Q：我想問下宏景智駕，BEV帶來大量感知數(shù)據(jù)，從供應(yīng)商的角度來講，解決方案供應(yīng)商如何與主機廠一同把這些數(shù)據(jù)處理好？包括數(shù)據(jù)隱私問題，應(yīng)該怎樣去做數(shù)據(jù)處理，作為供應(yīng)商應(yīng)該怎樣去配合車廠？
柴：BEV需要大量真值數(shù)據(jù)，獲取原始數(shù)據(jù)很容易，但如何用好很困難，無論是算法供應(yīng)商，還是主機廠都要有很強的數(shù)據(jù)利用和閉環(huán)能力。比如，如何用原始數(shù)據(jù)去做大規(guī)模的無監(jiān)督的預(yù)訓(xùn)練，自動化的云端標注系統(tǒng)，需要做好數(shù)據(jù)的埋點和回灌。舉個例子，我認為在開發(fā)階段可以用LiDAR提供真值，裝一個真值系統(tǒng)去生成大量數(shù)據(jù)。但在量產(chǎn)之后，我們還需要給車廠提供OTA，他發(fā)現(xiàn)反饋的圖像在目標檢測和車道線3D地圖檢測方面做得并不好，那我們也需要對相關(guān)數(shù)據(jù)進行優(yōu)化。純視覺的3D場景重建加標注的難題是量產(chǎn)BEV的公司必須修煉的內(nèi)功，還有就是數(shù)據(jù)合規(guī)和數(shù)據(jù)使用權(quán)肯定屬于車廠的財產(chǎn)。作為供應(yīng)商或者合作伙伴，如何基于車廠的大量數(shù)據(jù)幫他們通過OTA提升性能，然后在客戶端體現(xiàn)，這是我們要思考的問題。
BEV落地后，有哪些預(yù)判？
以下是商湯絕影量產(chǎn)行車智能駕駛研發(fā)負責人蔣沁宏回答觀眾問題的內(nèi)容整理。
Q1: 繼BEV之后，我們預(yù)判感知會有一些新趨勢，不知道蔣老師怎么看？
A：我剛剛也有提及在BEV方面上，大家還是以往DL方案上發(fā)展。趨勢來看，還是要向端到端的方向發(fā)展。越來越多的算法會加到模型里，包括預(yù)測和算法，我們現(xiàn)在就在做這部分工作。而作為算法供應(yīng)商，跟（學(xué)術(shù)界）做研究不同的點在于，我們需要額外考慮，不能單純追求效果。比如在所謂的端到端的框架下，我們還是要追求控制和規(guī)劃的確定性，這也是作為真正的行業(yè)從業(yè)者需要考慮的。
Q2: 主機廠從研發(fā)BEV到量產(chǎn)上車，部分系統(tǒng)開放功能周期通常要多久？
A：因為我們不是主機廠而是供應(yīng)商，我們給主機廠做BEV，從整個算法來講，我們的算法預(yù)研肯定不是這個時期開始的。從開始做，到算法在項目上的開發(fā)，再到最后上車，按照之前的節(jié)奏來看大概需要半年。這里面涉及到的不僅是方案上線和部署，歷史的case、數(shù)據(jù)、性能等都需要重新做，而且整個行業(yè)都很在意的主動安全、AEB等很嚴肅的東西都需要做大量的驗證，我認為，整個周期至少要半年。
Q3：蔣總，您提到會把激光雷達作為真值，而BEV很大程度上強化了視覺算法，視覺在整個感知里重要性增強，那么你怎么看后續(xù)系統(tǒng)對激光雷達和高精地圖的依賴程度？
A：這其實是兩個東西。首先，像商湯最早做智駕開發(fā)系統(tǒng)設(shè)計的時候，就把在線建圖的輸出跟高精地圖的輸出格式做了統(tǒng)一。從我們的角度來說，高精地圖其實是不保鮮的，需要逐漸把高精地圖拿掉。和激光雷達不太一樣，視覺算法對障礙物（如 PVB 等）的檢測和還原過程，本質(zhì)是對數(shù)據(jù)的擬合，見過的可以擬合，沒見到的就沒辦法。從安全性的角度來考慮，激光雷達從原理上就保障了對障礙物的識別精度。另外，城區(qū)NOA場景其實很復(fù)雜，例如廣州的城中村，有的地方到處都是石墩子、人車混行的復(fù)雜場景，現(xiàn)階段的視覺算法對于障礙物的感知精度，與激光雷達對比還是比較有限的。
個人認為，從精度上來講，視覺算法肯定還是達不到激光雷達的水平的，激光雷達還是有天然的碾壓性優(yōu)勢。
Q4：以大模型、大數(shù)據(jù)為驅(qū)動的算法團隊，對于原來智駕團隊的研發(fā)架構(gòu)有怎樣的影響？
A：研發(fā)架構(gòu)是為算法架構(gòu)服務(wù)的，這一直是我的觀點。我們需要思考怎么高效地把算法落地，然后去搭對應(yīng)的架構(gòu)。我覺得，對研發(fā)架構(gòu)可能會有幾個影響，一個是因為深度學(xué)習的引入，在不同的模塊，可能都需要引入一些具備相關(guān)背景的人員。另外，可以類比一下以前手機的領(lǐng)域，大家所謂的算法模型研究員和工程分工就比較清晰。因為整個算法就是一個黑盒，工程人員需要做的就是把對應(yīng)模型部署，然后做對應(yīng)的嵌入式芯片優(yōu)化、性能優(yōu)化。我覺得，整個智駕演變的方案可能也是這樣。從研發(fā)架構(gòu)上來講，研發(fā)和工程的切分可能會越來越明顯。研發(fā)團隊會去做算法的研發(fā)、模型的產(chǎn)出，工程團隊可能會做模型的部署、嵌入式的優(yōu)化等，以團隊分工的架構(gòu)模式，可能會逐漸替代按模塊劃分感知、地圖、規(guī)控的架構(gòu)模式。
Q5：剛剛您有提到貴公司在低、中、高配算力芯片上不同的部署，那能聊聊8Tops和100Tops芯片部署B(yǎng)EV的差異嗎？8Tops的芯片可以做BEV嗎？
A：8Tops的芯片上可以實現(xiàn)BEV感知，而且已經(jīng)做了。首先，8Tops算力的芯片，它的感知精度必然是比不上100Tops的芯片。然后，我們在算法方案上的選擇也會有一些差別。高算力平臺基本都是基于Transformer這種carrier-based方案來做；在低算力平臺，我們還是選類似BEVDepth、BEVDet這種2D轉(zhuǎn)3D的方式去實現(xiàn)。當然，哪怕是BEVDet也塞不進8Tops芯片，所以我們做了優(yōu)化。通過模型結(jié)構(gòu)的精簡、提高BEV檢測距離等算法層面的優(yōu)化，去提升性能。
Q6：BEV對數(shù)據(jù)和算力要求較高，而主流車型價位區(qū)間基本在10萬-20萬，您判斷，BEV適合上車這個價位的車型嗎？
A：這樣說吧，比8Tops高一點的16或者32Tops（的芯片）上都能夠?qū)崿F(xiàn)BEV算法，而這個算力的芯片配置（16Tops、32Tops）大概對應(yīng)10萬-20萬價位的車型。只是難點在于，城區(qū)NOA以及我們做的map-less的方案，確實需耗費更多算力資源，這可能有難度。但目前該價位車型上是能夠部署BEV方案的，并且也能夠?qū)崿F(xiàn)車道線、目標感知的能力。
Q7：如果有激光雷達，還有必要做Occupancy（占用網(wǎng)絡(luò)）嗎？Occupancy是不是為脫離激光雷達做的準備？
A：不完全算。首先，3D的Occupancy做不到激光雷達的精度的。因為Occupancy本質(zhì)上是對FreeSpace 往高度層面的擴展。從技術(shù)上來說，它確實可以幫規(guī)控更好地處理問題。但這帶來的，不只是對感知的挑戰(zhàn)，對規(guī)控也是一種挑戰(zhàn)。因為規(guī)控需要接入地圖、Free Space、目標障礙物等，同時還需要去算占位圖（Occupancy）。大家之前都沒這樣用過。要在結(jié)合3D視覺感知算法下做好確定性的規(guī)劃，也涉及到各個模塊的聯(lián)調(diào)，同時也需要把感知結(jié)果做得更準，最終不再需要通過規(guī)控做后處理，直接去構(gòu)建所謂的「可通行區(qū)域」。
Q8：如果采用BEV，雷達和相機的布局會發(fā)生怎樣的變化和影響？比方傳感器的數(shù)量、位置會不會為BEV提供更好的配置？
A：在視覺BEV的布置上，我們會盡可能讓不同的攝像頭之間能有一個更大的重疊區(qū)域，這樣整個的BEV空間或者特征空間是全的，不太存在漏洞。因為相機去畸變后并不能達到它實際的視場角（FOV），比如：FOV120度的攝像頭，去完畸變，其FOV可能只剩100度或者100多度。
激光雷達的話，量產(chǎn)車如果要做成本下探、同時要提升視覺感知精度，激光雷達更多的作用就是補盲，能夠在城區(qū)場景、關(guān)鍵障礙物的感知上實現(xiàn)更好的感知效果。因此激光雷達要裝得稍微低一點，例如裝在車前保險杠等。如果激光雷達裝上面，側(cè)邊的激光雷達就需要盡量下探一些。
下載ECAD模型
