1. 從三個(gè)爆款硬件看實(shí)時(shí)音視頻與多模態(tài)AI的架構(gòu)共性寵物翻譯機(jī)、嬰兒護(hù)理助手、AI故事機(jī)這三個(gè)品類看起來八竿子打不著一個(gè)面向養(yǎng)寵人群一個(gè)面向新手父母一個(gè)面向兒童教育。但如果你把它們的硬件拆開、把軟件鏈路攤開會(huì)發(fā)現(xiàn)底層跑的是同一套東西實(shí)時(shí)音視頻采集與傳輸 多模態(tài)AI推理 LLM驅(qū)動(dòng)的Agent決策。我過去兩年陸續(xù)參與過這三類產(chǎn)品的架構(gòu)設(shè)計(jì)踩過的坑基本重合所以這篇文章不打算分開講三個(gè)產(chǎn)品而是把它們當(dāng)作同一套技術(shù)架構(gòu)的三個(gè)應(yīng)用切面來拆。先說清楚這套架構(gòu)到底解決什么問題。傳統(tǒng)做法是把音視頻數(shù)據(jù)傳到云端云端跑一個(gè)模型出結(jié)果再傳回來。這條路在寵物翻譯機(jī)和嬰兒護(hù)理助手上都走不通原因很直接延遲。嬰兒哭聲檢測如果端到端延遲超過800毫秒家長已經(jīng)自己跑過去看了助手的價(jià)值歸零。寵物叫聲翻譯如果延遲兩秒以上狗早就不叫了翻譯出來給誰聽AI故事機(jī)的交互更苛刻孩子說完一句話如果三秒內(nèi)沒有回應(yīng)注意力就轉(zhuǎn)移了。這三個(gè)場景共同指向一個(gè)工程約束端到端響應(yīng)必須壓到500毫秒以內(nèi)理想狀態(tài)是300毫秒。那怎么做到核心思路是端側(cè)預(yù)處理 邊緣推理 云端LLM兜底的三級架構(gòu)。端側(cè)負(fù)責(zé)VAD語音活動(dòng)檢測、降噪、特征提取和輕量級分類邊緣節(jié)點(diǎn)負(fù)責(zé)多模態(tài)融合和中等復(fù)雜度推理云端只處理需要大模型語義理解的部分。WebRTC在這套架構(gòu)里承擔(dān)的是端到邊緣的實(shí)時(shí)傳輸通道而不是端到端的全鏈路方案。這個(gè)區(qū)分很關(guān)鍵很多團(tuán)隊(duì)一開始就把WebRTC當(dāng)成萬能傳輸層結(jié)果發(fā)現(xiàn)云端LLM推理的延遲根本壓不住問題不在傳輸在推理調(diào)度。提示如果你的產(chǎn)品定義里端到端延遲要求低于500毫秒不要試圖用純云端方案硬扛端側(cè)必須承擔(dān)至少30%的推理負(fù)載。適合讀這篇文章的人正在做或準(zhǔn)備做實(shí)時(shí)音視頻AI硬件產(chǎn)品的工程師、架構(gòu)師、技術(shù)產(chǎn)品經(jīng)理。不需要你精通WebRTC或LLM但至少要知道什么是音頻幀、什么是推理延遲。我會(huì)盡量用生活化的類比把關(guān)鍵概念講清楚同時(shí)給出可以直接參考的參數(shù)和代碼片段。2. 整體架構(gòu)設(shè)計(jì)與技術(shù)選型背后的取舍邏輯2.1 為什么是三級架構(gòu)而不是端到端云端方案先算一筆賬。假設(shè)你做一個(gè)嬰兒護(hù)理助手麥克風(fēng)采樣率16kHz16bit量化單通道。每秒鐘產(chǎn)生的原始音頻數(shù)據(jù)是16000 × 16 × 1 256000 bit也就是32KB/s。這還只是音頻如果加上攝像頭視頻流720p30fps的原始數(shù)據(jù)量是每幀約2.7MB每秒81MB。當(dāng)然實(shí)際會(huì)編碼壓縮但即便用Opus編碼壓到24kbps視頻用H.264壓到1Mbps端到端傳輸加云端推理的延遲構(gòu)成是這樣的環(huán)節(jié)典型延遲可優(yōu)化空間端側(cè)采集與編碼20-50ms硬件編碼可壓到10ms網(wǎng)絡(luò)傳輸端到邊緣30-80ms邊緣節(jié)點(diǎn)就近部署邊緣解碼與預(yù)處理10-30ms硬件加速云端LLM推理200-800ms模型量化、投機(jī)解碼結(jié)果回傳與端側(cè)播放30-60ms預(yù)加載音頻緩存合計(jì)290-1020ms端側(cè)分擔(dān)推理可壓到300ms內(nèi)關(guān)鍵洞察在于LLM推理是延遲大頭而且它不可預(yù)測。同樣一句話LLM生成10個(gè)token和100個(gè)token的耗時(shí)差10倍。如果你把VAD、降噪、特征提取這些確定性任務(wù)也放到云端等于讓所有環(huán)節(jié)排隊(duì)等LLM延遲波動(dòng)會(huì)非常大。三級架構(gòu)的本質(zhì)是把確定性任務(wù)下沉到端側(cè)和邊緣把不確定性任務(wù)留給云端這樣端到端延遲的方差可控。2.2 WebRTC在架構(gòu)中的真實(shí)角色與常見誤用WebRTC經(jīng)常被誤解為“端到端實(shí)時(shí)通信的銀彈”。實(shí)際上在這套架構(gòu)里WebRTC主要解決三個(gè)問題NAT穿透、抖動(dòng)緩沖、自適應(yīng)碼率。它不解決推理調(diào)度也不解決模型部署。我見過不少團(tuán)隊(duì)把WebRTC的DataChannel拿來傳推理結(jié)果結(jié)果發(fā)現(xiàn)DataChannel的可靠性機(jī)制和推理結(jié)果的時(shí)效性要求沖突——推理結(jié)果過期了就不該重傳但DataChannel默認(rèn)會(huì)重傳。正確的用法是音頻流走WebRTC的媒體通道控制信令和推理結(jié)果走單獨(dú)的WebSocket或MQTT通道。媒體通道用UDP承載容忍丟包因?yàn)橐纛l丟幾幀人耳幾乎無感控制通道用TCP保證指令可靠到達(dá)。這個(gè)分離設(shè)計(jì)在寵物翻譯機(jī)上尤其重要因?yàn)閷櫸锝新暤姆g結(jié)果如果延遲超過1.5秒用戶會(huì)認(rèn)為設(shè)備“沒反應(yīng)”而不是“翻譯錯(cuò)了”。注意WebRTC的關(guān)閉不是簡單調(diào)用close()就完事。在端側(cè)設(shè)備上必須顯式釋放AudioTrack、VideoTrack、PeerConnectionFactory等資源否則下次啟動(dòng)時(shí)會(huì)出現(xiàn)音頻設(shè)備被占用的情況。安卓端尤其明顯建議在onDestroy里按順序釋放先停軌道再關(guān)PeerConnection最后銷毀Factory。2.3 多模態(tài)AI的融合策略早期融合還是晚期融合多模態(tài)在這里指的是音頻、視頻、文本三種模態(tài)的聯(lián)合理解。寵物翻譯機(jī)主要用音頻視頻看寵物姿態(tài)嬰兒護(hù)理助手用音頻視頻看嬰兒動(dòng)作AI故事機(jī)用音頻文本故事內(nèi)容。融合策略有兩種早期融合是在特征層面拼接比如把音頻的MFCC特征和視頻的CNN特征拼成一個(gè)向量再送進(jìn)模型。優(yōu)點(diǎn)是模態(tài)間關(guān)聯(lián)建模充分缺點(diǎn)是要求各模態(tài)時(shí)間對齊非常嚴(yán)格而且任一模態(tài)缺失時(shí)模型退化嚴(yán)重。晚期融合是各模態(tài)獨(dú)立推理最后在決策層加權(quán)投票。優(yōu)點(diǎn)是魯棒性強(qiáng)音頻斷了視頻還能用缺點(diǎn)是丟失了跨模態(tài)的細(xì)粒度關(guān)聯(lián)。我的經(jīng)驗(yàn)是端側(cè)用晚期融合邊緣和云端用早期融合。端側(cè)算力有限晚期融合的獨(dú)立小模型更容易部署邊緣節(jié)點(diǎn)算力充?？梢宰隹缒B(tài)注意力。具體到嬰兒護(hù)理助手端側(cè)跑一個(gè)音頻分類模型哭聲/笑聲/咳嗽/背景音和一個(gè)輕量視頻姿態(tài)模型是否在動(dòng)/是否面部朝下兩個(gè)結(jié)果在邊緣節(jié)點(diǎn)做融合決策。3. 核心模塊拆解與實(shí)操要點(diǎn)3.1 音頻前端處理VAD、降噪與特征提取的端側(cè)實(shí)現(xiàn)音頻前端是整個(gè)鏈路的第一環(huán)也是最容易被低估的一環(huán)。很多團(tuán)隊(duì)直接拿原始PCM送進(jìn)模型結(jié)果發(fā)現(xiàn)模型在實(shí)驗(yàn)室表現(xiàn)很好一到真實(shí)環(huán)境就崩。原因很簡單真實(shí)環(huán)境的信噪比可能低到5dB以下寵物翻譯機(jī)放在客廳電視聲、空調(diào)聲、人說話聲全混在一起。VAD的作用是判斷“當(dāng)前幀有沒有有效聲音”。WebRTC自帶的VAD模塊webrtc::Vad是一個(gè)不錯(cuò)的選擇它基于GMM高斯混合模型計(jì)算量小在ARM Cortex-A系列上單幀處理耗時(shí)不到1ms。但它的閾值需要根據(jù)場景調(diào)嬰兒護(hù)理助手要敏感一些因?yàn)閶雰旱奈⑷鹾哌笠部赡苁侵匾盘枌櫸锓g機(jī)可以稍微遲鈍一點(diǎn)避免把環(huán)境噪聲誤判為寵物叫聲。降噪方面?zhèn)鹘y(tǒng)做法是譜減法或維納濾波現(xiàn)在更推薦用輕量級神經(jīng)網(wǎng)絡(luò)降噪比如RNNoise。RNNoise的模型只有85KB在端側(cè)跑實(shí)時(shí)降噪完全沒問題。我實(shí)測下來在信噪比10dB的環(huán)境下RNNoise能把語音可懂度提升約30%對后續(xù)的LLM語義理解幫助很大。特征提取環(huán)節(jié)如果后續(xù)要用LLM做語義理解建議提取log-Mel濾波器組特征幀長25ms幀移10msMel濾波器數(shù)量40個(gè)。這個(gè)配置在語音識別領(lǐng)域是經(jīng)過驗(yàn)證的既能保留足夠的信息又不會(huì)讓特征維度爆炸。提取出來的特征可以緩存在環(huán)形緩沖區(qū)里等VAD觸發(fā)后再打包送往后端。# 端側(cè)音頻特征提取的簡化示例實(shí)際部署需用C或Rust重寫 import numpy as np def extract_log_mel(audio_frame, sample_rate16000, n_mels40, frame_len400, hop_len160): # audio_frame: 一維numpy數(shù)組長度應(yīng)為frame_len # 加漢明窗 windowed audio_frame * np.hamming(frame_len) # FFT spectrum np.fft.rfft(windowed, n512) power np.abs(spectrum) ** 2 # Mel濾波器組簡化版實(shí)際需預(yù)計(jì)算濾波器矩陣 mel_basis np.random.randn(n_mels, len(power)) # 實(shí)際應(yīng)使用標(biāo)準(zhǔn)Mel濾波器 mel_energy np.dot(mel_basis, power) # 取對數(shù) log_mel np.log(mel_energy 1e-8) return log_mel實(shí)操心得端側(cè)特征提取的緩沖區(qū)大小很關(guān)鍵。太小會(huì)導(dǎo)致特征不完整太大會(huì)增加延遲。我的經(jīng)驗(yàn)是緩沖區(qū)設(shè)為3倍幀長即75ms這樣既能覆蓋一個(gè)完整的音素又不會(huì)引入明顯延遲。3.2 多模態(tài)推理的端云任務(wù)劃分與調(diào)度任務(wù)劃分的核心原則是能端側(cè)做的絕不傳云端能邊緣做的絕不傳中心。具體怎么分我通常用一個(gè)簡單的決策矩陣任務(wù)類型計(jì)算量延遲敏感度推薦部署位置VAD極低極高端側(cè)降噪低極高端側(cè)音頻分類哭聲/叫聲中高端側(cè)或邊緣視頻姿態(tài)估計(jì)中高中邊緣多模態(tài)融合高中邊緣LLM語義理解與生成極高中低云端TTS語音合成中高邊緣或端側(cè)這個(gè)矩陣不是固定的要根據(jù)具體硬件調(diào)整。比如如果端側(cè)用的是高通QCS6490這類帶NPU的芯片音頻分類完全可以放端側(cè)如果是低成本的ESP32那只能做VAD和簡單降噪。調(diào)度層面我推薦用優(yōu)先級隊(duì)列 超時(shí)降級的策略。音頻幀的優(yōu)先級最高視頻幀次之控制信令最低。如果云端LLM推理超過800ms還沒返回邊緣節(jié)點(diǎn)應(yīng)該直接觸發(fā)降級邏輯用預(yù)置的模板回復(fù)或者端側(cè)的輕量生成模型先頂上等云端結(jié)果回來后再?zèng)Q定是否替換。這個(gè)降級機(jī)制在AI故事機(jī)上特別有用孩子等不了那么久先出個(gè)聲音穩(wěn)住注意力后面再補(bǔ)細(xì)節(jié)。3.3 LLM在端到端鏈路中的接入方式與Prompt設(shè)計(jì)LLM不是直接吃音頻特征的它需要文本輸入。所以鏈路里必須有一個(gè)音頻到文本的轉(zhuǎn)換環(huán)節(jié)。這里有兩種做法一是用ASR自動(dòng)語音識別把音頻轉(zhuǎn)成文本再送LLM二是用多模態(tài)LLM直接吃音頻特征。目前多模態(tài)LLM的音頻理解能力還在快速演進(jìn)中但工程上更穩(wěn)妥的做法還是ASR LLM的兩段式。ASR環(huán)節(jié)端側(cè)可以用輕量級模型做關(guān)鍵詞喚醒和簡單命令識別復(fù)雜語句送云端ASR。云端ASR的延遲通常在200-400ms加上LLM的300-600ms總延遲在500-1000ms。要壓到500ms以內(nèi)必須做流式ASR 流式LLM也就是ASR一邊出部分結(jié)果LLM一邊開始推理而不是等ASR完全結(jié)束再送LLM。Prompt設(shè)計(jì)上寵物翻譯機(jī)和嬰兒護(hù)理助手的Prompt策略完全不同。寵物翻譯機(jī)的Prompt要限制輸出長度因?yàn)榉g結(jié)果太長用戶不會(huì)看而且TTS合成也慢。我的做法是在System Prompt里明確寫“輸出不超過15個(gè)字用口語化表達(dá)”。嬰兒護(hù)理助手的Prompt要強(qiáng)調(diào)安全邊界不能給出醫(yī)療診斷建議只能提示“可能餓了”“可能需要換尿布”這類觀察性描述。# 寵物翻譯機(jī)的Prompt模板示例 PET_TRANSLATOR_PROMPT 你是一個(gè)寵物行為翻譯助手。根據(jù)提供的音頻特征和視頻姿態(tài)信息 判斷寵物當(dāng)前的可能情緒或需求。輸出要求 1. 不超過15個(gè)字 2. 用口語化表達(dá)像朋友聊天 3. 如果不確定輸出“不太確定再看看” 4. 不要輸出任何醫(yī)療建議 當(dāng)前音頻特征{audio_features} 當(dāng)前視頻姿態(tài){video_pose} 注意LLM的輸出必須做安全過濾。AI故事機(jī)面向兒童任何暴力、恐怖、不當(dāng)內(nèi)容都要在輸出層攔截。我通常會(huì)在LLM后面加一個(gè)規(guī)則引擎對輸出做關(guān)鍵詞匹配和情感分析不通過就替換為安全回復(fù)。4. 完整實(shí)操流程從設(shè)備啟動(dòng)到一次完整交互4.1 設(shè)備啟動(dòng)與WebRTC連接建立設(shè)備上電后的啟動(dòng)流程決定了首次交互的延遲。我的優(yōu)化經(jīng)驗(yàn)是把WebRTC連接建立和模型加載并行化。傳統(tǒng)做法是先連網(wǎng)再加載模型串行下來要3-5秒。并行化之后WebRTC的ICE候選收集和DTLS握手可以和模型加載同時(shí)進(jìn)行總啟動(dòng)時(shí)間能壓到1.5秒以內(nèi)。具體步驟上電后立即初始化音頻設(shè)備和視頻設(shè)備啟動(dòng)本地環(huán)形緩沖區(qū)同時(shí)發(fā)起WebRTC連接創(chuàng)建PeerConnection添加音頻軌道在等待ICE連接的過程中加載端側(cè)模型VAD、降噪、分類ICE連接就緒后開始發(fā)送音頻流到邊緣節(jié)點(diǎn)邊緣節(jié)點(diǎn)收到第一幀音頻后回傳一個(gè)ready信令端側(cè)進(jìn)入交互狀態(tài)這個(gè)流程里最容易出問題的是音頻設(shè)備初始化。安卓端如果先初始化了媒體播放器再初始化錄音可能會(huì)出現(xiàn)采樣率不匹配導(dǎo)致錄音失真。建議錄音和播放使用同一個(gè)AudioManager實(shí)例統(tǒng)一采樣率為16kHz。4.2 一次完整交互的時(shí)序拆解以嬰兒護(hù)理助手為例一次完整的“哭聲檢測-分析-反饋”交互時(shí)序如下時(shí)間點(diǎn)事件耗時(shí)0ms嬰兒發(fā)出哭聲麥克風(fēng)采集到音頻幀-5ms端側(cè)VAD檢測到有效聲音5ms10ms端側(cè)降噪和特征提取完成5ms15ms端側(cè)音頻分類模型判斷為“哭聲”5ms20ms音頻幀通過WebRTC發(fā)送到邊緣節(jié)點(diǎn)-50ms邊緣節(jié)點(diǎn)收到音頻幀開始多模態(tài)融合30ms80ms邊緣節(jié)點(diǎn)視頻姿態(tài)模型判斷嬰兒是否在動(dòng)30ms100ms融合決策完成觸發(fā)云端LLM請求20ms400ms云端LLM返回分析結(jié)果300ms450ms邊緣節(jié)點(diǎn)TTS合成語音50ms480ms語音回傳到端側(cè)并播放30ms總延遲約480ms滿足500ms的目標(biāo)。這里的關(guān)鍵優(yōu)化點(diǎn)是邊緣節(jié)點(diǎn)的視頻姿態(tài)模型和音頻分類并行執(zhí)行而不是串行。另外TTS合成放在邊緣而不是云端省去了音頻回傳的延遲。4.3 關(guān)鍵參數(shù)配置與調(diào)優(yōu)記錄以下是我在實(shí)際項(xiàng)目中驗(yàn)證過的參數(shù)配置可以直接參考音頻采集參數(shù)采樣率16000Hz位深16bit通道單通道幀長20ms320個(gè)采樣點(diǎn)緩沖區(qū)3幀60msWebRTC參數(shù)音頻編碼Opus碼率24kbps帶內(nèi)FEC開啟抖動(dòng)緩沖最小50ms最大200msICE只使用UDP關(guān)閉TCP候選DTLS使用默認(rèn)加密套件端側(cè)模型參數(shù)VADWebRTC VAD aggressiveness2嬰兒場景或1寵物場景降噪RNNoise48kHz內(nèi)部處理輸出重采樣到16kHz音頻分類MobileNetV3-Small輸入40維log-Mel輸出5類邊緣節(jié)點(diǎn)參數(shù)視頻姿態(tài)YOLOv8n-pose輸入640×480置信度閾值0.5融合模型2層Transformer隱藏維度256注意力頭數(shù)4TTSVITS輕量版采樣率22050Hz實(shí)操心得WebRTC的抖動(dòng)緩沖不要設(shè)太小。我試過把最小抖動(dòng)緩沖設(shè)到20ms結(jié)果在網(wǎng)絡(luò)波動(dòng)時(shí)音頻斷斷續(xù)續(xù)用戶體驗(yàn)反而更差。50ms是一個(gè)比較穩(wěn)妥的下限如果網(wǎng)絡(luò)質(zhì)量好WebRTC會(huì)自動(dòng)降到這個(gè)值。5. 常見問題與排查技巧實(shí)錄5.1 音頻鏈路問題速查表現(xiàn)象可能原因排查方法解決方案端側(cè)無聲音采集麥克風(fēng)權(quán)限未授予檢查AndroidManifest或Info.plist動(dòng)態(tài)申請權(quán)限音頻斷斷續(xù)續(xù)抖動(dòng)緩沖過小查看WebRTC統(tǒng)計(jì)中的jitter值增大最小抖動(dòng)緩沖降噪后聲音失真RNNoise模型不匹配對比降噪前后頻譜更換降噪模型或調(diào)參VAD誤觸發(fā)頻繁閾值過低打印VAD置信度日志提高aggressiveness端到端延遲大LLM推理排隊(duì)查看云端推理隊(duì)列長度增加推理實(shí)例或降級5.2 LLM推理延遲波動(dòng)的應(yīng)對策略LLM推理延遲波動(dòng)是這套架構(gòu)里最不可控的因素。同樣長度的輸入延遲可能從200ms跳到800ms。我的應(yīng)對策略是三層降級第一層超時(shí)降級。設(shè)置800ms的超時(shí)閾值超過就用端側(cè)輕量模型的結(jié)果頂上。端側(cè)可以預(yù)置一個(gè)小的生成模型比如TinyLlama的量化版雖然質(zhì)量不如云端LLM但能保證有響應(yīng)。第二層緩存降級。對于高頻場景比如嬰兒哭聲把常見的分析結(jié)果緩存起來下次遇到相似特征直接返回緩存結(jié)果不走LLM。緩存的key可以用音頻特征的哈希值。第三層模板降級。如果前兩層都沒命中用預(yù)置的模板回復(fù)。模板回復(fù)雖然不夠個(gè)性化但至少不會(huì)讓用戶覺得設(shè)備“死了”。注意降級策略的觸發(fā)條件要仔細(xì)調(diào)。如果超時(shí)閾值設(shè)得太低會(huì)頻繁降級用戶體驗(yàn)下降設(shè)得太高又失去了降級的意義。我的經(jīng)驗(yàn)是超時(shí)閾值設(shè)為P95延遲的1.5倍這樣只有5%的請求會(huì)觸發(fā)降級。5.3 多模態(tài)融合中的時(shí)間對齊問題音頻和視頻的時(shí)間戳對齊是多模態(tài)融合的經(jīng)典難題。音頻幀是20ms一幀視頻幀是33ms一幀30fps兩者不是整數(shù)倍關(guān)系。如果直接按幀號對齊累積誤差會(huì)越來越大。我的做法是用絕對時(shí)間戳對齊而不是幀號。每個(gè)音頻幀和視頻幀都帶上采集時(shí)的系統(tǒng)時(shí)間戳單位微秒邊緣節(jié)點(diǎn)收到后按時(shí)間戳排序然后以音頻幀的時(shí)間戳為基準(zhǔn)找最近的視頻幀做融合。如果視頻幀的時(shí)間戳和音頻幀相差超過50ms就只用音頻模態(tài)視頻模態(tài)置空。這個(gè)策略在嬰兒護(hù)理助手上效果很好因?yàn)閶雰旱膭?dòng)作變化相對慢50ms的容差完全夠用。但在寵物翻譯機(jī)上寵物的動(dòng)作可能很快50ms容差可能導(dǎo)致姿態(tài)判斷錯(cuò)誤。所以寵物場景下我把容差降到了30ms代價(jià)是視頻模態(tài)的利用率降低但準(zhǔn)確率反而提升了。5.4 端側(cè)資源競爭與功耗控制端側(cè)設(shè)備通常資源有限音頻采集、視頻采集、模型推理、網(wǎng)絡(luò)傳輸同時(shí)跑很容易出現(xiàn)資源競爭。我遇到過最典型的問題是視頻采集占用了太多CPU導(dǎo)致音頻幀處理延遲增大。解決方案是給音頻鏈路最高優(yōu)先級。在Linux系統(tǒng)上可以用nice值調(diào)整進(jìn)程優(yōu)先級在安卓上可以用AudioRecord的setPerformanceMode設(shè)置低延遲模式。另外視頻采集可以動(dòng)態(tài)降幀當(dāng)音頻鏈路負(fù)載高時(shí)視頻幀率從30fps降到15fps釋放CPU資源。功耗方面端側(cè)模型推理是耗電大戶。我的經(jīng)驗(yàn)是用NPU而不是CPU跑模型功耗能降低60%以上。如果端側(cè)沒有NPU那就把模型量化到INT8功耗也能降30%左右。6. 架構(gòu)擴(kuò)展與后續(xù)演進(jìn)方向這套三級架構(gòu)不是終點(diǎn)。隨著端側(cè)算力提升和多模態(tài)模型小型化未來會(huì)有更多推理任務(wù)下沉到端側(cè)。我目前在做的一個(gè)實(shí)驗(yàn)是把輕量級LLM1B參數(shù)以下部署到端側(cè)用4bit量化在驍龍8 Gen 3上跑生成速度能達(dá)到15 tokens/s。這個(gè)速度對于寵物翻譯機(jī)和嬰兒護(hù)理助手的短文本輸出已經(jīng)夠用了。另一個(gè)方向是Agent化?，F(xiàn)在的架構(gòu)還是“請求-響應(yīng)”模式未來可以引入Agent機(jī)制讓設(shè)備主動(dòng)觀察和決策。比如嬰兒護(hù)理助手可以持續(xù)監(jiān)測嬰兒的狀態(tài)發(fā)現(xiàn)異常時(shí)主動(dòng)提醒而不是等家長問。這需要端側(cè)有一個(gè)常駐的輕量Agent做持續(xù)的狀態(tài)跟蹤和決策。WebRTC的角色也可能變化。隨著WebTransport的成熟未來端到邊緣的傳輸可能從WebRTC遷移到WebTransport后者基于HTTP/3在擁塞控制和多路復(fù)用上更有優(yōu)勢。但目前WebRTC的生態(tài)更成熟短期內(nèi)還是首選。我在實(shí)際項(xiàng)目中的體會(huì)是這套架構(gòu)的難點(diǎn)不在單個(gè)技術(shù)點(diǎn)而在鏈路的整體延遲控制和故障降級。每個(gè)環(huán)節(jié)優(yōu)化10ms加起來就是100ms每個(gè)環(huán)節(jié)都可能出故障必須有降級預(yù)案。把這兩個(gè)事情做好產(chǎn)品體驗(yàn)就不會(huì)差。