作者：Aaron Ang
汽車產業正邁入AI 定義汽車的全新時代：Arm展望將AI嵌入車用運算的核心，讓車輛能夠即時感知、推理，並依據駕駛需求與周遭環境做出調整。透過Zena CSS等平台，強大且安全的AI處理如今可以直接在車內執行。本地智慧不僅能提升隱私保護與反應速度，也能開創更高層次的安全性、便利性與個人化體驗。
我們的專案正是朝這個願景邁出的一步。我們打造了一款裝置端代理式AI多模態助理，展現模組化、協作式AI如何提升車內體驗，並在本地硬體上高效率運作。
在這樣的新典範下，AI代理將成為駕駛不可或缺且主動的夥伴，協助處理從診斷到環境控制等各種任務。
用語對照
- 代理（Agent）：負責特定能力的模組化軟體元件。每個代理會處理各自的輸入與輸出，並透過定義明確的介面與其他代理溝通。
- 監督者（Supervisor）：負責協調的代理，能解讀使用者意圖，並將任務分派給合適的代理或工具，確保每項請求都由正確的元件處理。
- 檢索增強生成（Retrieval-Augmented Generation，RAG）：一項透過從本地知識庫（向量儲存）擷取相關段落來提升準確度的技術。這些段落會作為脈絡提供給語言模型，讓助理即使沒有網路連線，也能回答車輛相關的特定問題。
- 向量儲存（Vector store）：用來儲存嵌入的資料庫；嵌入是文字或影像的數值表示，因此可快速擷取語意相近的項目。
- 量化（Quantization:）：一種壓縮技術，能以較少位元表示模型權重（例如從 32 位元降至 4 位元），藉此降低記憶體使用量並加快推論速度，讓大型模型也能在資源受限的裝置端硬體上運作。
- 裝置端/邊緣推論：直接在車輛運算系統上執行AI模型，進而提升隱私保護與可靠性。
系統架構：邊緣端的模組化智慧
此助理的架構是以模組化代理為核心而設計。每個代理負責一項特定能力，例如防護機制、車輛控制、檢索與視覺。監督者代理會協調這些元件，根據使用者意圖與系統脈絡分派任務。
圖1：代理式車用助理的高階架構。
元件
輸入模組：透過 whisper.cpp 將語音查詢轉換為文字，並轉送至防護代理。此模組也會依據可設定的頻率，從攝影機擷取影像資料，供視覺代理使用。
防護代理：驗證使用者輸入，並拒絕不安全或惡意的指令，例如存取系統提示，或覆寫安全關鍵控制。
監督者代理：接收經過驗證的輸入，並決定要呼叫哪一個代理或工具。此介面透過維護可用工具與代理的登錄檔來擴充，每個工具與代理都以一致格式描述。這樣的設計讓新功能可以輕鬆接入，不需修改監督者的核心邏輯。
視覺代理：使用視覺語言模型（Vision-Language Model，VLM）分析攝影機畫面，例如判斷駕駛是否遵守交通規則。
輸出佇列：作為核心代理系統與輸出模組之間的中介，確保回應會依正確順序傳遞，無論是用於語音合成或使用者介面皆然。這可維持面向駕駛輸出的穩定一致與可靠性。
公用工具：代理會與一組本地工具互動，這些工具透過 Model Context Protocol（MCP）伺服器公開，或以直接函式呼叫的方式提供。這些工具是助理連接車輛及其支援系統的介面。在目前的原型中，這些工具使用模擬資料，但此設計已預期未來可整合實際車用子系統。
- 駕駛與安全
o 發生碰撞或偵測到危險時，聯絡緊急救援服務。
o 設定車內環境，例如空調控制、天窗與座艙照明。
o 向駕駛傳送通知與警示。
- 個人助理
o 從本地向量資料庫擷取車輛資訊（透過RAG）。
o 控制資訊娛樂功能，例如藍牙連線與媒體播放。
透過將這些能力以模組化工具的形式公開，系統能在推理（代理）與執行（工具）之間維持清楚分工。這樣可確保系統具備擴充性，未來也更容易整合新的車用功能。
輸入輸出流程範例
假設駕駛說：「將我的手機與車輛的藍牙配對。」
- 輸入模組：將駕駛的語音轉錄為文字。
- 核心系統：
- 防護代理：驗證該請求，確保其安全且符合範圍。
- 監督者代理：將意圖解讀為環境控制任務，並將其導引至車輛控制代理。
- 車輛控制代理：呼叫 Automobile MCP 工具，處理駕駛裝置的藍牙配對，並輸出結果。
- 輸出佇列：暫存結果，確保回應依序傳遞，且不會受到併行任務中斷。
- 輸出模組：將回應傳送至 TTS 用戶端與 UI。
接著，助理會確認：「您的裝置已成功配對。」
以下日誌顯示系統如何即時執行該請求。每筆紀錄都對應到流程中的一個步驟。若不包含連接藍牙裝置所需的時間，代理工作流程可在5秒內完成。
圖2：代理日誌，顯示語音轉錄、代理交接與工具呼叫。
模型與硬體配置
系統會在記憶體中同時運作兩個模型：
- 大型 VLM（InternVL3-Instruct 14B），供視覺代理進行影像與文字推論。
- 較小型 LLM（Jan-nano 4B），用於所有其他文字任務，包括檢索與工具協調。
兩個模型皆經過4位元量化，並透過 llama.cpp 提供服務。我們選用 Unsloth 的 Dynamic 2.0 GGUF 格式，因為在主流量化方法中，這個格式能在模型大小與執行效能之間取得最佳平衡。這項選擇讓兩個模型都能置於14 GB的VRAM內。
我們在 Amazon EC2 g5g.4xlarge 執行個體上開發此助理原型。此執行個體配備 16 個 Arm 架構 Graviton2 vCPU、32 GB RAM，以及具備 16 GB VRAM 的 T4G Tensor Core GPU。整體運算與記憶體資源大多專用於執行 ML 工作負載，這與真實車輛的限制相符。
2025 年的汽車平均配備 16 GB DRAM，預計到 2026 年將成長為三倍。這樣的資源相近性可確保我們的開發環境能對應到可投入量產的 AI 代理所具備的資源配置。採用 Graviton2 也支援 Arm 的 SOAFEE 框架，讓我們能先在雲端開發與測試容器化車用工作負載，再部署至車內系統。
設計意涵
此架構支援多模態互動，且不需仰賴外部連線也能可靠運作。透過新增代理、工具或能力，也能在對既有元件做最少變更的情況下進行擴充。
漸進式能力
此助理採分階段方式開發，每個階段都會導入新的感知與行動能力。這種漸進式方法展現系統如何從基本資訊檢索，逐步發展為具備情境感知的自主能力。
第1級：透過語音指令檢查車輛狀態
在基礎階段，助理能回應語音查詢，從車載感測器擷取即時車輛狀態。例如：「目前車內溫度是多少？」這可讓駕駛立即以免手持方式取得車輛資訊。
第2級：透過語音指令修改車輛狀態
在檢索能力的基礎上，助理能執行駕駛指令，調整車輛設定。例如：「將溫度設定為 (華氏) 70 度。」這讓助理的角色從資訊來源，進一步轉變為車輛操作中的主動參與者。
第3級：視覺解讀與駕駛警示
整合視覺能力後，助理便可透過即時視覺輸入處理駕駛環境。例如，它可以偵測車輛是否位於高乘載車道（High Occupancy Vehicle，HOV），並在未符合乘載人數要求時發出警示。
在此階段，助理能針對複雜、動態且真實世界的情境進行推論。它解讀的是情境，而不只是指令。
圖3：合成生成影像，顯示視覺代理從車內與車外觀察到的高速公路場景。
圖4：助理解讀視覺輸入，辨識高乘載車道違規情況，並提供安全/合規警示。
第4級：視覺輔助的自主行動
助理結合深度視覺理解與自主決策能力，使其能提供關鍵的安全介入。例如，若偵測到碰撞，助理可以自主聯絡緊急救援服務，確保即使駕駛無法回應，也能派遣援助。
這項能力代表助理從被動監測，轉向主動的情境回應。助理不僅能感知並解讀周遭環境，也能果斷採取行動，確保駕駛安全。
圖5：車輛發生事故時的車內與車外合成影像。
圖6：助理辨識緊急情況並聯絡緊急救援服務。
整體而言，這些漸進式級別展現出清楚的發展軌跡：從簡單的感測器查詢，逐步邁向自主且具備情境感知的行為。每一步都讓我們更接近能在車輛環境中真正感知、理解並採取行動的車內助理，為全面AI定義的行動體驗鋪路。
主要心得
針對擴充性進行設計
我們比較了兩種常見的代理式系統設計方法：
- 單體式架構：由單一大型代理管理所有任務。
- 模組化架構：由監督者代理擔任路由器與守門，負責協調特定的子代理。
內部評估顯示，模組化方法能更有效地擴充，並提供更穩定一致的結果。此方法讓個別元件可以更新或擴充，而不會影響整體系統，就像更換汽車零件時，不需要重建整具引擎。
我們的觀察與LangChain的研究結果一致。其研究顯示，隨著工具數量增加，採用監督者的多代理架構仍能維持效能；相較之下，當單一代理系統負責過多文字脈絡或能力時，效能會快速下降。
圖7：代理式架構擴充性。（資料來源：LangChain）
在資源受限的硬體上實現即時推論
在邊緣硬體上執行 AI 模型具有挑戰性，因為運算與記憶體資源有限。為了克服這些限制，我們在VLM與精簡型LLM之間分派請求，並對兩者都套用4位元量化。
較大型的VLM能提供強大的多模態推理能力，但會帶來較高延遲。因此，非視覺任務會分派至LLM，以維持回應速度。這樣的分工在功能性與反應速度之間取得平衡，讓資源受限的裝置也能針對車用工作負載執行即時多模態推論。
圖8：KV快取暖機對端到端延遲的影響。
我們進一步透過預先運算系統提示的KV快取來降低延遲。此快取會做為所有對話開頭的固定內容重複使用。在消融測試中，針對「這輛車的油箱容量是多少？」這項輸入查詢，此暖機程序讓端到端延遲提升至2倍速度。
透過裝置端RAG提升準確度
導入RAG提升了助理的回應能力與可靠性。透過將車主手冊等知識庫嵌入系統中，助理能在無需網路連線的情況下，快速且私密地回答具備情境脈絡的技術問題。這大幅提升即時實用性，也有助於建立駕駛信任。
多模態理解開啟全新可能性
整合視覺元件是關鍵一步，讓助理從單純的聆聽者，轉變為具備情境感知的觀察者，能理解車內外的視覺線索，例如乘客安全或車道狀況，進而落實更直覺且主動的行為。
可觀測性加速迭代
我們透過 MLflow 追蹤與 OpenAI Agents SDK 對系統進行檢測，藉此掌握每個代理的執行時間、工具使用情況與交接流程。這項可視性有助於在系統逐步成熟時，加速偵錯、效能調校與設計改善。
圖9：MLflow追蹤可針對每項請求提供細緻的可視性。
限制代理能力
我們的架構對代理行為施加嚴格限制，以確保安全性與可靠性。每個代理只能存取其所需的最少工具集，並透過最小權限原則限制其作用範圍。
我們透過防護代理設計出封閉式控管機制。防護代理會使用以規則為基礎的檢查來篩選所有輸入，在不安全或超出範圍的指令觸及敏感工具之前就加以阻擋。我們也透過對抗式測試，驗證系統面對惡意或對抗性輸入時的穩健性，並使用 DeepEval 等框架，降低因複雜輸入操控而導致非預期代理行為的風險。
採取行動
為了將這款代理式裝置端車用助理從原型推進至實際部署，我們必須在四項優先要務之間取得平衡：模型智慧、延遲、記憶體使用量與安全性。
要在邊緣硬體上提升模型智慧，需要持續推進訓練後技術，例如剪枝、量化與知識萃取。這些方法能讓精簡模型即使在參數容量有限的情況下，仍維持強大效能。
要進一步降低延遲，則有賴硬體架構改善，以解決受記憶體限制的推論問題。例如，將運算更靠近記憶體，以盡可能降低資料移動造成的瓶頸。最佳化記憶體使用量也需要採用硬體感知策略，包括量化感知訓練、高效率注意力機制，以及穩健的輕量化模型架構。這類策略可確保模型在嚴格的 VRAM 預算內運作，同時仍保有實用功能。
最關鍵的是，安全性必須內建於每一層。由於 Arm 的 IP 支援 ISO/SAE 21434 合規要求，此系統具備良好基礎，可與車用網路安全標準接軌。
然而，若要大規模部署這類系統，仍需符合業界通行的驗證實務，並進行完整的對抗式測試，以滿足技術與法規要求。
因應這些相互交織的挑戰，需要持續最佳化、安全風險工程，以及跨產業協作。這些努力對於將安全、具備強大能力且可即時回應的 AI 助理帶入未來的車輛中是相當重要的。
展望未來：車內智慧的未來
這個原型只是起點。裝置端助理的下一波尖端發展包括：
主動且具備情境感知的推論
透過運用世界模型，也就是能學習並模擬真實世界動態的 AI 系統，未來的助理將不僅能回應人類輸入與預先定義的觸發條件，也能預判情境、規劃行動，並適應長期影響。在豐富的虛擬環境中訓練這些模型，將使其在真正上路之前，就能安全且可靠地處理複雜的駕駛條件。
個人化的持續學習
未來的助理將能持續適應每位駕駛。透過 QLoRA 等高效率微調技術，模型可隨著時間逐步適應使用者的獨特偏好、駕駛風格，以及特定車輛用語。久而久之，這將讓互動感受更自然，也更符合每個人的需求。
結語
當強大且以隱私為優先的 AI 直接進駐車內，我們才剛開始探索其中的可能性。本文介紹的代理式助理說明了：智慧化、協作式且可擴充的車內 AI 已近在眼前。軟體與硬體的每一項進展，都讓我們更接近這樣的汽車：不只是交通工具，更是每段旅程中真正智慧且直覺的夥伴。
若想進一步了解 Arm 如何推動這項願景，請造訪 Arm 車用開發者平台 Arm Automotive Developer Platform 與 Automotive Learning Path，取得在 Arm 生態系中打造次世代車用軟體的相關資源。
致謝
特別感謝 Arm Developer Advocacy 團隊，以及我的團隊成員 Barbara Corriero、Han Yin 與 Tim Ko 在實習期間提供指導。By Aaron Ang
(參考原文：Building an on-device multimodal assistant for automobiles；本文作者為於Arm實習之數據工程師，中文版校閱者為 Arm 首席應用工程師林宜均)
- 【Arm的AI世界】打造車用裝置端多模態助理 - 2026/06/16
- 【Arm的AI世界】運算平台開發者必看：無須硬體也能進行OpenBMC+UEFI模擬與驗證！ - 2026/04/09
- 【Arm的AI世界】運用ExecuTorch與Arm SME2加速裝置端機器學習推論 - 2026/03/18
訂閱MakerPRO知識充電報
與40000位開發者一同掌握科技創新的技術資訊！
