1. 從一場展會聊起對話式 AI 為什么突然“卷”進了所有硬件今年逛完 AWE 的展館我最大的感受不是某款電視有多薄、某臺冰箱有多智能而是一個幾乎被所有廠商掛在嘴邊的詞——對話式 AI。從掃地機器人到智能眼鏡從車載中控到廚房電器甚至一把電動牙刷的展臺都在講“你可以直接跟它說話”。這個信號非常明確對話式 AI 正在從手機和音箱這兩個“老陣地”快速滲透到每一個你能想到的終端硬件里。這件事的本質(zhì)是什么說白了過去十年我們和硬件的交互方式基本沒變過——按鈕、觸屏、遙控器。而對話式 AI 要做的事情是把“人適應機器”變成“機器適應人”。你不需要學任何操作邏輯張嘴說就行。這個變化聽起來簡單但背后牽扯的技術(shù)鏈條非常長語音喚醒、降噪拾音、語音識別、語義理解、對話管理、技能調(diào)度、語音合成每一個環(huán)節(jié)都要在資源受限的硬件上跑通。我寫這篇東西不是要復述展會上那些漂亮的宣傳語而是想從一個實際做過多款語音交互產(chǎn)品的人的角度把“對話式 AI 進硬件”這件事拆開講清楚。如果你正在做智能硬件的產(chǎn)品定義、技術(shù)選型或者只是好奇為什么今年所有廠商都在押注這個方向那這篇內(nèi)容應該能給你一些實在的參考。我會聊技術(shù)架構(gòu)怎么搭、端側(cè)和云側(cè)怎么分工、不同品類的硬件各自面臨什么坑以及我在實際項目中踩過的那些教訓。2. 對話式 AI 進硬件的整體架構(gòu)設計思路2.1 為什么不能直接把手機上的方案搬到硬件上很多人第一反應是手機上語音助手已經(jīng)跑得很成熟了直接移植到其他硬件不就行了我一開始也這么想過實際做下來發(fā)現(xiàn)完全不是一回事。手機有強大的 SoC、充足的內(nèi)存、穩(wěn)定的網(wǎng)絡連接還有用戶已經(jīng)養(yǎng)成的“對著手機說話”的習慣。但換成一個智能門鎖、一個車載后視鏡、甚至一個咖啡機情況就完全不同了。最核心的矛盾在于資源約束。一顆用于智能家居設備的 MCU可能只有幾百 KB 的 RAM 和幾 MB 的 Flash你不可能把一個大模型或者完整的語音識別引擎塞進去。另一個矛盾是場景差異。手機語音助手的典型場景是用戶主動喚醒、安靜環(huán)境、近距離說話但一個廚房電器的場景可能是油煙機轟鳴、用戶手上沾著面粉、站在兩米外喊話。這兩個場景對拾音和識別的技術(shù)要求天差地別。所以對話式 AI 進硬件的架構(gòu)設計第一步不是選模型而是明確場景約束。我通常會從四個維度來評估算力預算、功耗預算、網(wǎng)絡條件、交互距離。這四個維度決定了你的技術(shù)方案能走多遠。2.2 端云協(xié)同哪些活必須在本地干哪些可以丟到云上目前行業(yè)里比較務實的做法是端云協(xié)同但具體怎么切分不同團隊的做法差異很大。我的經(jīng)驗是遵循一個原則跟實時性和隱私相關(guān)的放端側(cè)跟復雜語義和內(nèi)容生成相關(guān)的放云側(cè)。具體來說端側(cè)必須搞定的是這幾件事喚醒詞檢測這個必須本地跑因為需要 7×24 小時監(jiān)聽如果一直往云端傳音頻流帶寬和功耗都受不了。常用的方案是輕量級的關(guān)鍵詞識別模型參數(shù)量控制在幾十 KB 到幾百 KB 之間。前端信號處理包括降噪、回聲消除、波束成形、自動增益控制。這些算法必須在本地實時完成否則上傳的音頻質(zhì)量太差云端識別率會慘不忍睹。語音活動檢測VAD判斷用戶什么時候開始說話、什么時候說完這個也必須在本地做不然會傳大量無效音頻上去。云側(cè)負責的是大詞匯量連續(xù)語音識別把音頻轉(zhuǎn)成文字這個需要大模型端側(cè)跑不動。自然語言理解與對話管理理解用戶意圖、維護多輪對話狀態(tài)、決定下一步動作。內(nèi)容生成與技能調(diào)度調(diào)用各種服務接口生成回復內(nèi)容。語音合成把回復文字轉(zhuǎn)成自然語音雖然現(xiàn)在端側(cè) TTS 也有輕量方案但音質(zhì)和自然度還是云端更好。注意端云切分不是一成不變的。如果你的硬件有 4G/5G 常連能力且用戶不介意延遲可以多往云側(cè)放如果是離線場景或者對隱私極度敏感端側(cè)就要承擔更多。我見過一個做智能門鎖的團隊因為擔心音頻上云的隱私問題硬是把小詞匯量的命令詞識別全部放在了端側(cè)云端只做兜底的復雜語義解析。2.3 不同品類的架構(gòu)選型差異不是所有硬件都適合同一套架構(gòu)。我按算力和場景把常見終端分成三檔每檔的選型邏輯完全不同檔位典型硬件算力水平推薦架構(gòu)關(guān)鍵約束輕量級智能燈控、傳感器、小家電MCU無 OS 或 RTOS端側(cè)喚醒命令詞云端兜底功耗和成本極度敏感中量級智能音箱、掃地機、車載中控應用處理器Linux/Android端側(cè)前端處理云端 ASR/NLU網(wǎng)絡穩(wěn)定性、拾音距離重量級智能座艙、機器人、AR 眼鏡高算力 SoC可跑小模型端側(cè)跑小模型云端大模型協(xié)同散熱、功耗、多模態(tài)融合這個表格是我自己在做產(chǎn)品定義時常用的一個快速判斷工具。你先把自己的硬件往里面套基本就能確定技術(shù)路線的大方向。輕量級硬件不要想著跑大模型重量級硬件也不要什么都往云端丟找到平衡點才是關(guān)鍵。3. 核心技術(shù)點拆解從拾音到出聲每一步都有坑3.1 前端拾音與降噪對話式 AI 的第一道生死關(guān)我經(jīng)常跟團隊里新來的工程師說一句話語音交互的效果七分靠拾音三分靠識別。如果前端拾音沒做好后面用再大的模型也救不回來。展會上那些演示效果很好的產(chǎn)品背后在麥克風陣列和降噪算法上下的功夫遠比宣傳材料里寫的多。麥克風陣列的選型是第一個決策點。常見的有 2 麥、4 麥、6 麥甚至 8 麥方案。麥克風越多波束成形和聲源定位的能力越強但成本和結(jié)構(gòu)設計難度也越高。我的經(jīng)驗是近距離交互0.5 米以內(nèi)如手機、遙控器單麥或雙麥足夠重點做回聲消除。中距離交互1-3 米如音箱、廚電4 麥環(huán)形陣列是甜點方案能實現(xiàn) 360 度拾音。遠距離交互3-8 米如車載、會議室6 麥以上線性或環(huán)形陣列配合波束成形鎖定說話人方向。降噪這塊傳統(tǒng)方案用譜減法、維納濾波現(xiàn)在越來越多團隊用深度學習降噪。但我要提醒一點深度學習降噪在穩(wěn)態(tài)噪聲如空調(diào)聲、發(fā)動機聲下效果很好但在非穩(wěn)態(tài)噪聲如突然的敲擊聲、多人說話下可能引入失真。實際項目中我通常采用傳統(tǒng)算法和深度學習混合的方案穩(wěn)態(tài)噪聲交給深度學習瞬態(tài)干擾交給傳統(tǒng) VAD 和波束成形來抑制。還有一個容易被忽視的點是回聲消除AEC。如果硬件本身會播放聲音比如音箱、電視那麥克風一定會拾到自己的聲音。AEC 沒做好的話會出現(xiàn)“自己喚醒自己”或者“說著說著被打斷”的情況。AEC 的關(guān)鍵在于參考信號的同步精度這個在硬件設計階段就要考慮好軟件層面很難完全彌補。3.2 喚醒詞檢測低功耗與高召回率的平衡術(shù)喚醒詞是用戶和硬件對話的“敲門磚”。這個環(huán)節(jié)的核心指標有兩個喚醒率和誤喚醒率。喚醒率低了用戶喊半天沒反應體驗極差誤喚醒率高了設備動不動自己激活用戶會覺得這產(chǎn)品“有病”。在資源受限的硬件上做喚醒詞檢測通常用輕量級的神經(jīng)網(wǎng)絡比如 DSCNN深度可分離卷積網(wǎng)絡或者 TC-ResNet。模型大小控制在 100KB 以內(nèi)推理一次的計算量在幾 MFLOPs 級別這樣可以在低功耗 MCU 上以 10-20ms 的幀移持續(xù)運行。實際調(diào)參時我一般會把喚醒閾值設得稍微保守一點寧可讓用戶喊兩次也不要頻繁誤喚醒。因為誤喚醒帶來的困擾遠大于多喊一次的不便。另外喚醒詞的選擇也有講究音節(jié)要豐富、聲學上要容易區(qū)分、最好 3-4 個音節(jié)。兩個音節(jié)的詞太容易和日常對話混淆五個音節(jié)以上用戶又記不住。實操心得喚醒詞檢測模型一定要用目標硬件采集的數(shù)據(jù)做微調(diào)。我見過一個團隊用公開數(shù)據(jù)集訓練模型在實驗室里效果很好但裝到實際產(chǎn)品上喚醒率直接掉了一半原因就是實際產(chǎn)品的麥克風頻響特性和數(shù)據(jù)集不匹配。后來他們補采了 2000 條真實場景數(shù)據(jù)做微調(diào)喚醒率才回到可用水平。3.3 語音識別與語義理解端側(cè)小模型和云側(cè)大模型的配合語音識別ASR這塊端側(cè)和云側(cè)的方案差異很大。端側(cè)通常用流式小模型詞匯量有限但延遲低、隱私好云側(cè)用大模型準確率高、支持熱詞和上下文但有網(wǎng)絡延遲。我的建議是做分級策略簡單命令詞如“打開”“關(guān)閉”“調(diào)高溫度”走端側(cè)復雜語句如“幫我找一下上周買的那本書的物流信息”走云端。端側(cè)識別置信度低的時候自動轉(zhuǎn)云端重試。這樣既保證了常用操作的響應速度又覆蓋了長尾需求。語義理解NLU是對話式 AI 的“大腦”。傳統(tǒng)方案用規(guī)則模板和意圖分類模型現(xiàn)在越來越多團隊用大語言模型來做。大模型的好處是泛化能力強用戶換個說法也能理解壞處是推理成本高、響應慢、有時候會“胡說八道”。我在實際項目中采用的是一個混合 NLU 架構(gòu)高頻意圖用輕量級分類模型處理保證速度和穩(wěn)定性低頻、復雜意圖路由到大模型利用其泛化能力。同時在輸出層加一個約束校驗模塊確保大模型生成的回復不會超出設備的能力范圍。比如用戶說“幫我把空調(diào)調(diào)到 30 度”如果設備最高只能到 28 度校驗模塊要能攔截并給出合理回復。3.4 語音合成讓硬件“說話”自然的關(guān)鍵語音合成TTS經(jīng)常被忽視但它直接影響用戶對產(chǎn)品的感知。一個機械、生硬的合成音會讓用戶覺得產(chǎn)品“低端”一個自然、有情感的合成音會讓用戶覺得產(chǎn)品“聰明”。端側(cè) TTS 方案主要有兩類拼接合成和參數(shù)合成。拼接合成音質(zhì)好但占用存儲大參數(shù)合成靈活但音質(zhì)稍差?，F(xiàn)在也有一些輕量級的神經(jīng)網(wǎng)絡 TTS 方案可以在端側(cè)跑比如基于 FastSpeech 的蒸餾版本音質(zhì)接近云端水平模型大小控制在幾 MB 以內(nèi)。云端 TTS 的優(yōu)勢在于音色豐富、情感表達強、支持 SSML 標記。如果硬件網(wǎng)絡條件好我通常建議 TTS 走云端端側(cè)只做緩存和降級方案。但要注意首字延遲——用戶說完話到聽到回復的第一個字如果超過 1.5 秒體驗就會明顯變差。優(yōu)化方法包括流式 TTS、預取常用回復的音頻、端側(cè)緩存高頻語句。4. 實操落地一個中量級硬件的對話式 AI 接入全流程4.1 硬件選型與系統(tǒng)框架搭建假設我們要給一款智能廚電比如帶屏幕的烤箱接入對話式 AI。這個場景的特點是廚房環(huán)境噪聲大油煙機、攪拌機、用戶可能離設備 1-3 米、手上有油污不方便觸屏、網(wǎng)絡通常穩(wěn)定。硬件選型上我推薦這樣的配置主控四核 ARM Cortex-A53 或以上主頻 1.5GHzRAM 2GBFlash 8GB。這個配置可以跑 Linux 系統(tǒng)支持端側(cè)前端處理和輕量級喚醒詞檢測。麥克風4 麥環(huán)形陣列間距 40-60mm信噪比 65dB 以上。環(huán)形陣列適合廚房這種用戶可能從任意方向說話的場景。音頻編解碼支持 16kHz 采樣、16bit 精度最好帶硬件 AEC 加速。網(wǎng)絡Wi-Fi 2.4G/5G 雙頻保證音頻上傳的帶寬和穩(wěn)定性。揚聲器5W 以上支持回聲消除參考信號輸出。系統(tǒng)框架上我通常分成四層硬件抽象層麥克風陣列驅(qū)動、音頻編解碼驅(qū)動、網(wǎng)絡驅(qū)動。音頻前端層AEC、降噪、波束成形、VAD、喚醒詞檢測。對話引擎層端側(cè) ASR命令詞、云端 ASR 客戶端、NLU 路由、對話管理。應用層技能實現(xiàn)、設備控制、UI 反饋。這個分層的好處是每一層可以獨立迭代。比如前端降噪算法升級了不需要動對話引擎新增一個技能只需要在應用層加代碼。4.2 關(guān)鍵參數(shù)計算與配置示例在實際配置中有幾個參數(shù)需要根據(jù)場景仔細計算。我拿拾音距離和麥克風間距的關(guān)系舉個例子。假設用戶最遠在 3 米外說話聲速 343m/s4 麥環(huán)形陣列的直徑為 60mm。要保證波束成形的有效增益麥克風之間的最大延遲差不能超過半個采樣周期。在 16kHz 采樣下半個采樣周期是 31.25μs對應聲程差約 10.7mm。60mm 直徑的陣列相鄰麥克風間距約 42mm聲程差最大約 42mm遠大于 10.7mm。這意味著在 16kHz 采樣下高頻部分的波束成形會有空間混疊。解決方案有兩個一是提高采樣率到 48kHz這樣半采樣周期對應聲程差約 3.6mm空間混疊問題大大緩解二是接受一定的高頻混疊因為語音的主要能量集中在 300-3400Hz這個頻段的波長較長混疊影響相對可控。我通常建議中量級硬件用 48kHz 采樣做前端處理然后在送入 ASR 之前降采樣到 16kHz。喚醒詞檢測的配置示例wake_word: engine: dscnn model_path: /opt/models/wakeword_v3.tflite threshold: 0.72 frame_length_ms: 25 frame_shift_ms: 10 min_activation_duration_ms: 200 refractory_period_ms: 1500這里的threshold是喚醒置信度閾值refractory_period_ms是喚醒后的不應期防止連續(xù)觸發(fā)。這些參數(shù)需要根據(jù)實際測試調(diào)整沒有萬能值。4.3 聯(lián)調(diào)過程中的典型問題與解決聯(lián)調(diào)階段是最容易出問題的。我記錄了幾個高頻問題問題一喚醒后識別不到說話內(nèi)容。排查下來發(fā)現(xiàn)是喚醒詞檢測和 ASR 之間的音頻緩沖區(qū)沒有對齊喚醒后前 200ms 的音頻被丟棄了。解決方法是在喚醒檢測模塊和 ASR 模塊之間加一個環(huán)形緩沖區(qū)喚醒觸發(fā)時把緩沖區(qū)里的音頻一起送過去。問題二廚房噪聲下誤喚醒率飆升。油煙機的聲音頻譜和某些喚醒詞有重疊。解決方法是采集廚房噪聲數(shù)據(jù)加入訓練集的負樣本中重新訓練喚醒模型同時在喚醒前加一個噪聲分類器判斷當前環(huán)境是否適合喚醒。問題三云端 ASR 返回結(jié)果延遲波動大。有時候 300ms 就返回了有時候要 2 秒。排查發(fā)現(xiàn)是網(wǎng)絡抖動加上云端排隊。解決方法是在端側(cè)做流式上傳不要等用戶說完再傳而是邊說邊傳同時在端側(cè)緩存最近幾條識別結(jié)果網(wǎng)絡不好時用端側(cè)小模型兜底。問題四TTS 播放時被自己的聲音喚醒。這是 AEC 沒做好的典型表現(xiàn)。檢查發(fā)現(xiàn)揚聲器參考信號和麥克風采集信號之間存在非線性失真線性 AEC 無法完全消除。解決方法是加入非線性回聲抑制模塊或者在 TTS 播放期間暫時降低喚醒靈敏度。避坑技巧聯(lián)調(diào)時一定要在真實場景下測試不要只在實驗室里測。我見過太多團隊在安靜的會議室里調(diào)好了一到用戶家里就各種問題。廚房、客廳、車內(nèi)這些場景的噪聲特性完全不同必須分別采集數(shù)據(jù)、分別調(diào)參。5. 不同終端品類的落地差異與選型建議5.1 智能家居成本敏感下的取舍智能家居品類最大的特點是成本極度敏感。一個智能燈泡的 BOM 成本可能只有十幾塊錢你不可能給它配 4 麥陣列和四核處理器。所以這個品類的對話式 AI 方案必須做極致裁剪。我的建議是只做命令詞識別不做自由對話。用戶說“開燈”“關(guān)燈”“調(diào)亮一點”這些固定命令詞用幾十 KB 的模型就能搞定。云端只做兜底而且可以做成可選的——用戶不聯(lián)網(wǎng)也能用基本功能。拾音方案上單麥加軟件降噪就夠了。但要注意遠場拾音的問題如果設備裝在墻上用戶站在 3 米外說話單麥的信噪比會很低。這時候可以考慮在房間里放一個帶麥克風的網(wǎng)關(guān)設備通過藍牙或 Zigbee 把語音指令轉(zhuǎn)發(fā)給各個設備。這樣成本分攤下來每個設備只增加幾塊錢。5.2 車載場景噪聲、多說話人和安全約束車載是對話式 AI 落地最復雜的場景之一。噪聲大發(fā)動機、風噪、胎噪、可能有多人同時說話、還要考慮駕駛安全不能分散駕駛員注意力。麥克風陣列通常用 4-6 麥分布在車頂或 A 柱。波束成形要能區(qū)分主駕和副駕的聲源方向。降噪方面發(fā)動機噪聲是穩(wěn)態(tài)的可以用自適應濾波風噪和胎噪是非穩(wěn)態(tài)的需要深度學習降噪。車載場景還有一個特殊要求響應必須快。駕駛員說“導航到某某地方”如果等 3 秒才有反應駕駛員可能已經(jīng)錯過了路口。所以車載方案通常把更多處理放在端側(cè)云端只做 POI 搜索和路徑規(guī)劃。端側(cè) ASR 用限定領(lǐng)域的模型覆蓋導航、音樂、電話、空調(diào)這些高頻場景。安全約束也很重要。行駛中要限制某些語音操作比如“打開視頻”這種會分散注意力的指令應該被攔截。這需要在對話管理層面加一個駕駛狀態(tài)感知模塊根據(jù)車速、檔位等信息動態(tài)調(diào)整可用技能。5.3 可穿戴與 AR 眼鏡功耗和形態(tài)的極限挑戰(zhàn)可穿戴設備耳機、手表、AR 眼鏡對對話式 AI 的要求最苛刻功耗要低、體積要小、還要保證可用性。以 TWS 耳機為例電池只有幾十 mAh你不可能讓它一直跑喚醒詞檢測。常見的做法是手機協(xié)同耳機只做最基本的 VAD 和音頻采集喚醒和識別都交給手機。但這樣又依賴手機連接脫離手機就廢了。AR 眼鏡的情況更復雜。它需要多模態(tài)融合——語音、手勢、眼動、頭部姿態(tài)一起用。用戶說“把這個窗口移到左邊”同時眼睛看向某個窗口系統(tǒng)要能理解“這個”指的是哪個。這需要語音和視覺的聯(lián)合理解目前還處于比較早期的階段。我的判斷是可穿戴設備的對話式 AI 在未來兩年內(nèi)還是會以手機協(xié)同為主、端側(cè)為輔。真正獨立的端側(cè)對話能力要等低功耗 NPU 和輕量級大模型進一步成熟。6. 常見問題與排查技巧實錄6.1 喚醒率低、誤喚醒高的排查思路這是最高頻的問題。我整理了一個排查清單現(xiàn)象可能原因排查方法解決方向喚醒率低麥克風靈敏度不足用標準聲源測頻響曲線更換麥克風或調(diào)整增益喚醒率低喚醒詞與用戶口音不匹配采集目標用戶口音數(shù)據(jù)測試補充口音數(shù)據(jù)微調(diào)模型喚醒率低環(huán)境噪聲掩蓋了喚醒詞在不同噪聲級別下測試加強降噪或提高喚醒閾值誤喚醒高訓練負樣本不足分析誤喚醒時的音頻內(nèi)容補充負樣本重新訓練誤喚醒高閾值設置過低統(tǒng)計不同閾值下的 ROC 曲線提高閾值犧牲部分喚醒率誤喚醒高電視/音樂中的相似詞觸發(fā)采集電視音頻做負樣本加入相似詞對抗訓練這個表格是我在實際項目中反復使用的基本上 80% 的喚醒問題都能通過這個清單定位到原因。6.2 識別延遲大、響應慢的優(yōu)化手段延遲是對話式 AI 體驗的殺手。用戶能接受的端到端延遲從說完到聽到回復通常在 1.5 秒以內(nèi)。超過這個值用戶就會覺得“卡”。優(yōu)化延遲要從全鏈路入手拾音階段減少音頻緩沖區(qū)大小從 200ms 降到 100ms代價是抗抖動能力下降。VAD 階段用更激進的端點檢測策略用戶停頓 500ms 就認為說完了而不是等 1 秒。上傳階段流式上傳邊說邊傳不要等 VAD 觸發(fā)再開始傳。云端處理選擇離用戶近的服務節(jié)點減少網(wǎng)絡 RTT。TTS 階段流式合成生成第一個字就返回不要等整句合成完。我實測下來這套組合拳可以把端到端延遲從 2.5 秒壓到 1.2 秒左右。但要注意每個優(yōu)化都有代價比如激進的 VAD 會導致用戶說話中途停頓被誤判為說完。需要根據(jù)具體場景調(diào)平衡。6.3 多輪對話中的上下文丟失問題多輪對話是對話式 AI 的高級能力但也是最容易出問題的。用戶說“幫我找一下附近的餐廳”系統(tǒng)推薦了幾家用戶接著說“第二家”系統(tǒng)要能理解“第二家”指的是上一輪推薦列表中的第二個。上下文丟失通常有幾個原因?qū)υ挔顟B(tài)沒有正確保存每輪對話結(jié)束后狀態(tài)被清空了。超時設置太短用戶思考了 10 秒才回復系統(tǒng)已經(jīng)認為對話結(jié)束了。多設備干擾用戶在家里多個設備之間切換上下文沒有同步。解決方法是在對話管理層面維護一個會話狀態(tài)機記錄最近 N 輪的意圖、槽位和實體。超時時間根據(jù)場景設置簡單命令 5 秒復雜查詢 30 秒。多設備場景下會話狀態(tài)可以存在云端用用戶 ID 關(guān)聯(lián)。實操心得多輪對話的上下文不要存太多輪3-5 輪就夠了。存太多不僅占用資源還會引入噪聲。我見過一個團隊存了 20 輪上下文結(jié)果用戶說“好的”的時候系統(tǒng)把 20 輪前的意圖又翻出來了鬧了笑話。7. 我對這個方向的一些個人判斷做語音交互產(chǎn)品這些年我最大的體會是技術(shù)不是瓶頸場景理解才是。展會上那些演示效果驚艷的產(chǎn)品背后往往不是用了多先進的模型而是把場景吃透了——知道用戶會在什么環(huán)境下說話、會說什么、不會說什么、說錯了怎么辦。對話式 AI 進硬件這個趨勢短期內(nèi)還會繼續(xù)“卷”。但我建議做產(chǎn)品的同行不要被“卷”帶偏了節(jié)奏。先想清楚你的硬件到底解決了用戶的什么問題對話式 AI 在這個問題里扮演什么角色然后再去選技術(shù)方案。不要為了加語音而加語音用戶不傻不好用的功能只會讓產(chǎn)品顯得更蠢。另外端側(cè)小模型的能力在快速提升。我預計未來一兩年內(nèi)中量級硬件上跑一個 1-3B 參數(shù)的對話模型會成為常態(tài)。到那時候端云協(xié)同的切分點會進一步向端側(cè)偏移隱私和延遲問題都會得到改善。但現(xiàn)在這個時間點務實的分級策略還是最穩(wěn)妥的選擇。