1. 为什么AI眼镜和AI耳机需要一个统一的模型接入层最近圈子里聊AI眼镜和AI耳机的人明显多起来了但大部分人聊的都是硬件本身——镜片多重、续航多久、音质怎么样。真正上手做过之后你会发现这些设备能不能用起来核心瓶颈根本不在硬件而在AI能力怎么接。我自己的经历是这样的手上有某品牌的AI眼镜用的语音交互又入了一款开放式AI耳机主打实时翻译和会议纪要。两台设备各自的App都做得挺漂亮但问题在于——它们各自只接了一个模型。眼镜接的是A厂商的语音模型耳机接的是B厂商的对话模型。A厂商的模型在某些场景下表现不错但另一些场景明显不如其他模型B厂商的模型倒是全能但价格贵、响应慢。这让整个体验非常割裂。更麻烦的是我偶尔想自己折腾一些功能比如让耳机在听音乐时自动生成播放列表、让眼镜在会议中识别PPT上的公式——原生App根本不给你这种自由度。后来我琢磨出一套方案效果比我预想的好不少。简单说就是在设备和大模型之间加一层统一的API网关让所有AI眼镜、AI耳机都通过这一个网关去调用不同的大模型。这个思路不算新鲜但真正在硬件设备上落地坑比想象中多。这篇文章就把整个方案从头到尾拆开讲一遍包括为什么这么设计、网关怎么搭、设备端怎么改、实测效果如何以及我踩过的那些坑。适合手里有AI眼镜或AI耳机、想自己把模型接入权拿回来的开发者也适合做硬件产品、正在纠结模型选型的工程师。先放结论这套方案不只解决了多个模型任意切换的问题它还顺带解决了设备离线策略、成本控制、响应速度抖动、多设备统一管理等一系列问题。基本上属于一次改造、长期受益的类型。2. 三个模型接入方案的对比如今市面上搞模型接入大致有三条路可以走。2.1 方案A设备App直连某一个模型这是绝大多数AI眼镜、AI耳机默认的做法。设备厂商在自己的App里内置了一个模型SDK用户只能用它提供的对话能力不能改、不能换。优点很直接省事。厂商只要调一次API不用管太多适配问题用户拿到手就能用也不用配置什么。缺点也显而易见模型能力被锁死了。A模型在某些场景比如中文诗词创作很强但在另一些场景比如实时翻译就很一般B模型翻译很强但语音交互的延迟又偏高。对于普通用户来说这些差异可能感知不明显但对于想把设备用出花来的开发者这种绑定就是天花板。还有一个隐性问题厂商选型时通常考虑的是成本和稳定性而不是具体某个场景的能力上限。所以你会看到很多眼镜、耳机产品宣传时说的是搭载某大模型但对用户来说真正重要的是这个模型在我想用的场景里到底行不行。2.2 方案B设备端本地跑一个小模型有些设备开始尝试在端侧部署小参数模型比如1B、3B级别的。眼镜和耳机这类设备计算能力有限端侧模型主要用于关键词唤醒、简单指令识别复杂的推理还是得靠云端。这个方案的优点是没有网络时也能跑一部分功能隐私性好一点。但缺点也很致命小模型的智商上限摆在那里。你可以让它在本地判断用户说拍照还是播放音乐但没法让它在本地写一篇结构完整的文章、总结一份复杂的会议纪要。我实际测过设备端3B模型的总结能力跟云端大模型比差距还是很明显的。所以端侧模型更适合做推理前置而不是作为主能力来源。2.3 方案C统一API网关按需路由到不同模型我的做法就是方案C。核心思路是在设备与多个模型之间插入一个网关服务这个服务负责接收来自设备端的统一格式请求根据请求类型、场景、成本预算、模型实时状态决定将请求转发给哪一个模型将模型的返回结果再统一包装后送回设备端相当于做了一个模型路由器。设备端不需要关心背后用的是哪个模型它只需要知道我发一个标准格式的请求就能拿到标准格式的回复。在具体实现上我选的是FastAPI写网关服务通过OpenAI兼容格式对外暴露接口然后在网关内部按场景路由到不同模型。这个方案的好处是兼容性极好——现在的模型厂商基本都提供了OpenAI兼容的接口格式等于天然适配。为什么不用别的格式因为如果每个模型都用自己的SDK和协议网关内部就要维护一堆不同格式的适配器工作量和出错概率成倍增长。OpenAI兼容格式已经是大模型API领域的事实标准就像当年USB接口逐渐统一了外设连接一样虽然它不完美但生态最广。2.4 为什么我不建议直接用第三方聚合平台可能有人会问市面上不是已经有模型聚合平台了吗直接调用它们不也能实现多个模型切换这里我想说几句掏心窝的话。第三方聚合平台确实省事它们帮你封装好了统一接口甚至还能自动路由。我自己也用过在某些场景下确实好用。但我在实际项目里遇到几个问题第一平台规则不可控。聚合平台经常调整模型供应商、调整价格策略有时候你依赖的某个模型在平台上突然下线了你只能等平台恢复没有任何谈判余地。第二链路太长了。设备端请求要经网关转发到聚合平台聚合平台再转发到真正的模型服务商中间多了两跳网络延迟对眼镜、耳机这类需要实时交互的设备影响明显。第三自定义能力受限。我需要针对不同请求类型做不同策略比如翻译类请求优先用低成本模型、创意写作类请求跳过高成本模型这类细粒度控制在聚合平台上实现起来比较别扭。所以最终我确定了自己搭网关这条路。虽然前期要多写一点代码但后面每次新增模型、调整路由策略都完全由自己掌控。3. 网关架构拆解一个请求从眼镜发出到拿到回答的全过程这套架构用一张图就能说清楚。但考虑到读者口味差异我还是先把整个链路拆成几个部分逐层来讲。3.1 设备端与网关之间的通信协议先说设备端AI眼镜/耳机和网关之间的通信。这一步最核心的问题不是选什么通讯协议而是让设备端发请求这件事变得足够简单。我最终选定的方案是设备端通过WebSocket或HTTPS向网关发送一个JSON格式的请求内容包括{ device_id: glasses_01, device_type: smart_glasses, session_id: 8f9a2c3e, scene: translation, text: 把这句话翻译成英文今天天气怎么样, audio: false, extra: {} }这里有几个字段值得单独说明device_id和device_type用于标识是哪台设备。网关拿到后可以决定不同的路由策略比如眼镜用视觉理解模型、耳机用语音对话模型。scene字段是路由的关键。我目前在用的场景包括translation、summarization、creative_writing、chat、vision_description等。网关根据场景来选模型。audio字段是布尔值。有些设备支持直接传音频网关再转成文本处理不支持的设备就先把音频在设备端转成文本再走文本接口。session_id用于多轮对话上下文管理。网关侧会缓存这个会话的历史记录保证连续对话有记忆。网关返回的格式也很简单{ status: success, response: The weather is nice today., model_used: glm-4-plus-fast, latency_ms: 812, tokens: 23 }增加model_used字段是后来才想到的但非常实用。通过它我可以直观看到每一次请求实际被路由到了哪个模型方便调试和成本核算。这里要特别提醒一点设备端的SDK不需要也不能感知模型细节。设备端永远只发我需要什么样的结果的请求而不关心这个结果由谁产生。这样后期就算你换掉所有模型设备端代码一行都不用改。3.2 网关的路由决策逻辑网关的核心是一套路由决策逻辑。我把它做成一个可配置的规则引擎核心判断维度有这么几个按场景路由上面提到的scene字段是最高优先级的判断条件。比如translation场景我默认路由到低延迟模型summarization场景路由到高理解能力模型。按模型健康状态路由网关会定时检查各个模型服务的可用性。如果某个模型连续失败次数超过阈值自动把请求切到备用模型。这个机制解决了我之前遇到的某个模型服务商临时故障导致设备完全不可用的窘境。按成本预算路由我在网关里做了简单的成本控制。每个设备每天有配额比如眼镜的免费额度是300次/天超过之后自动路由到更便宜的模型或者直接返回提示。这个功能对于团队共享设备、限制滥用非常有用。按用户自定义规则路由这里是最灵活的部分。我支持通过配置文件或管理接口增加自定义路由规则。比如指定眼镜在所有场景下都走模型P或者翻译场景如果文本长度大于500字切换到模型Q。到这一步路由策略已经可以从写死在代码里变成随时可调整的配置。我后来把配置放到了环境变量和远程配置中心调策略不用重新发版update设备时会自动拉取最新配置。3.3 不同模型API的适配层网关中最脏最累的活就是对接不同模型的服务商API。我这里的设计思路是先定义一个内部的统一模型调用接口所有具体模型都实现这个接口。接口大概长这样class BaseModelProvider: def chat(self, messages, streamFalse, temperature0.7, max_tokensNone): raise NotImplementedError def health_check(self): raise NotImplementedError def get_metric(self): raise NotImplementedError不同的模型服务商各自实现这个类。比如对接ChatGLM服务的做一个Provider对接DeepSeek服务的做另一个Provider。每个Provider内部把厂商特有的API格式转换为统一格式。这里必须提一个重要经验几乎所有主流模型服务商都提供了OpenAI兼容接口。这大大减少了适配工作量。如果你对接的某个服务商不支持OpenAI兼容格式那就要单独写适配代码这也是为什么选型时我优先选有兼容接口的模型。为了节省时间我建议用一个现成的SDK——我目前用的是LiteLLM这个库。它可以统一调用各种模型服务商而且天然支持OpenAI兼容格式。如果你是自己搭网关完全不用自己造轮子去适配各家API直接用这种库能省掉至少两周时间。3.4 会话上下文管理AI眼镜和AI耳机使用场景有一个特别之处它们是长时间佩戴的设备对话天然是连续的上下文必须在多轮之间保持。比如你在眼镜上问这个建筑是什么风格的紧接着问它有多少年历史了如果网关不保存上下文第二句就完全没法回答。我的做法是在网关里维护一个session存储session_manager.set(session_id, {history: history_list})默认每个session保留最近10轮对话超过后按最早优先淘汰。存储可以用内存如Redis也可以用本地磁盘。考虑到眼镜、耳机设备经常处于移动状态、网络可能不稳定我用的是Redis加本地双写防止服务重启丢上下文。这里有一个值得注意的细节不是所有请求都需要完整上下文。比如翻译场景你把完整上下文带上传给模型翻译出来的结果可能更准确但Token开销也更大而像唤醒词校验这种请求完全不需要历史。所以我在request里增加了一个context_mode字段值为full、summary、none三种。网关根据这个字段决定是否携带上下文能省不少成本。4. 设备端如何改造AI眼镜、AI耳机的接入实操很多人以为设备端改造很难其实只要你选的产品支持应用层开发改起来没有想象中复杂。我以我自己用的眼镜和耳机为例讲一下改造要点。4.1 AI眼镜的接入实操我用的眼镜自带了一个开放的SDK支持自定义语音识别和自定义意图处理。改造思路是这样的把SDK默认的语音→模型这一链路改成语音→文本→网关。第一步关掉SDK内置的模型调用。在眼镜的App配置里找到AI服务选项将它切换为自定义或关闭内置模式。第二步配置WebSocket地址。SDK里通常有一个setServiceUrl(url)方法把网关的WebSocket地址填进去。第三步在眼镜端实现一个准备请求的逻辑把语音识别后的文本、当前场景信息、设备ID等打包成JSON发送到网关。第四步处理网关的返回值。网关返回JSON后眼镜端解析出response字段进行TTS播报。如果返回的是多模态结果比如图片描述眼镜端可以显示在镜片上或直接语音播报。我实际用下来眼镜端改造代码量非常少大概200行不到一个下午就能搞定。最花时间的反而不是改代码而是调整语音识别ASR的质量——眼镜的麦克风离嘴比较远识别准确率没有手机高这个问题需要用降噪后处理来弥补。4.2 AI耳机的接入实操耳机比眼镜稍微复杂一点因为耳机通常不只做对话还涉及实时翻译、会议纪要等场景。我用的耳机支持蓝牙连接手机AppApp里也有一个自定义服务端点配置。操作逻辑类似把内置AI改为自定义服务把HTTP或WebSocket地址指向网关。还有一个比较特殊的场景是耳机上的物理按键。比如按两下唤醒AI、长按进入翻译模式这些按键事件本质上是SDK内部触发的意图我通过SDK提供的回调接口在回调里转为对网关的请求。这部分代码也不复杂核心点在于快速双击唤醒对话场景标记为chat长按进入实时翻译模式场景标记为translation同时开启麦克风持续收音按三下暂停/恢复上下文这个功能在开会时很好用防止耳机把周围人的闲聊也记到上下文里耳机端的难点在于流式交互。翻译和对话场景下用户希望边说边出结果而不是等整句说完才回复。所以我让网关接口支持streamtrue模型结果以流式方式返回耳机端边收边播用户感知到的延迟能降低一大截。具体做法是网关返回SSEServer-Sent Events格式的数据流耳机端用SDK的事件回调逐段处理文本。实测下来这种流式方案比一次性返回的平均延迟降低了30%以上。4.3 TTS和ASR的处理位置选择这里有一个可能被忽略、但影响体验极大的决定语音识别ASR和语音合成TTS放在设备端做还是放在云端做我一开始把ASR放在了云端思路是设备端只录原始音频云端统一处理。结果很不理想眼镜和耳机的麦克风差异大音频质量参差不齐云端识别错误率高而且音频数据上传消耗大量带宽和电量。后来我改成设备端本地ASR——眼镜和耳机都带有不错的本地语音识别能力哪怕稍微弱一点识别成文本后再发给网关。这样网络传输的数据量大幅减少成本也低了。TTS则是反过来网关返回文本后在设备端本地做TTS播报效果比云端TTS返回音频数据要自然。一是因为在设备端做TTS可以在语音播报的同时保留语义理解的中间结果二是因为音频文件的传输延迟比文本高很多。总结一下我的经验ASR天然适合在设备端做因为音频数据量太大了传云端既慢又贵。TTS在设备端做效果好、延迟低但如果你对音色有特殊要求比如需要名人音色那还是走云端TTS。5. 实测效果延迟、成本、稳定性三项指标对比架构搭好之后我做了几轮实测。这里把关键数据放出来给大家一个直观参考。5.1 延迟对比我测试了一个典型场景眼镜上看一张图片并问这张图片里有什么。整个过程包括眼镜端拍照→图片上传到网关→网关解析图片→调用视觉模型→生成描述→返回文本→眼镜端TTS播报。模型方案平均端到端延迟设备App内置单一模型2.8s网关路由到轻量模型1.9s网关路由到重量级模型3.6s结论很明显网关本身带来的额外延迟大约在100ms以内但通过合理的路由选择整体延迟反而可以比内置单一模型更低。关键就在于针对场景选模型——翻译、简单问答这类轻场景用轻量模型就能把延迟压到2秒以内。5.2 成本对比我统计了使用网关前后一周的成本场景内置单一模型成本网关路由后成本日常对话1200次/天约2.1元/天约0.8元/天实时翻译300次/天约0.6元/天约0.3元/天图片理解80次/天约1.2元/天约0.9元/天省下来的主要原因是大部分日常对话居然走便宜模型也能得到不错的效果。以前内置模型是一刀切类型选贵的就是贵的选便宜的就是便宜的现在有了路由我可以做到便宜的应对日常、贵的只留给真正需要的场景。5.3 稳定性对比我在使用过程中记录了一周的失败率数据内置单一模型方案平均失败率0.6%最高单日失败率1.8%。网关路由方案带健康检查平均失败率0.3%没有出现单日超过0.8%的情况。原因是网关的健康检查会在某个模型服务异常时自动切换备用模型。比如某天某个模型服务商因为大规模调用超时导致响应变慢网关在检测到连续三次失败后自动把所有流量切到了另一个模型最终用户感知不到任何中断。6. 常见问题与踩坑全记录这部分是我最想写的内容因为整个搭建过程中踩的坑比顺利的部分多得多。6.1 坑一设备端SDK隐藏了模型类型信息我一开始天真地以为设备端SDK会把用的是哪个模型暴露给开发者结果发现不是。大部分消费级AI眼镜、AI耳机的SDK里模型类型是写死的你只能调用内置模型接口不能直接指定或替换模型。解决办法有两个方向一是看SDK是否有开发模式或自定义模式开关。我身边有朋友用的设备恰好支持这种模式直接在设置里打开然后填入自定义服务地址即可。二是更简单粗暴在设备端做一层代理。设备端请求仍然发给原本的SDK服务但我用抓包工具把这个请求转发到自己搭的网关上。这种方式实现起来麻烦一点需要懂点网络调试但胜在几乎所有设备都能这样处理。6.2 坑二模型返回结果格式不统一不同模型服务商的返回格式差异很大。有的返回纯文本有的返回JSON里嵌着文本有的返回结构化列表。我在网关适配层上花的时间远超预期。我的建议是不要在网关内部做太复杂的格式解析。最稳妥的做法是网关统一把它们转换为一个标准结构然后设备端再统一使用这个标准结构。如果某个模型返回了额外的结构化信息比如对话中抽取的实体、情感标签这些额外信息先存到extra字段里设备端按需取用。6.3 坑三耳机端流式返回时的断句问题流式返回时模型是一段一段返回文本的。耳机端需要判断什么时候该停止播报以及什么时候该插入停顿。如果处理不好用户听到的话会糊成一团像舌头打了结。我最终的做法是网关在处理SSE流时根据返回的标点符号和模型自带的finish_reason信号自动在适当位置加一个segment_end标记。耳机端在收到这个标记时才做断句和播报这样听感接近自然语言停顿。6.4 坑四模型供应商的速率限制大模型服务商普遍有速率限制Rate Limit比如每分钟请求上限、每千Token成本上限等。如果眼镜、耳机这类设备高频调用很容易触到限制导致返回429错误。我的应对策略是在网关层做请求排队和滑动窗口限流每个模型独立维护一个令牌桶如果某个模型桶里的令牌空了等待100ms再重试。同时在网关层统计每个设备分钟级请求数超过阈值直接返回友好提示而不是继续发请求。这样既避免了对模型服务的骚扰也保护了用户体验。6.5 坑五眼镜端多模态请求的上传格式眼镜端的图片理解体验很好但在网络不稳定时会出大问题。我一开始把图片用Base64编码直接塞进JSON里结果一张2MB的图片让整个请求体膨胀到2.7MB弱网下几乎无法使用。后来改成两步式设备端先把图片上传到独立的文件存储服务获得一个image_url。网关收到请求时携带image_url调用视觉模型。这样图片上传和文字请求解耦弱网环境也能正常使用而且还可以对图片做压缩和缓存后期成本进一步下降。7. 不同模型的选型建议与分工这部分给大家一个我实测过的模型分工建议仅供参考。模型更新很快最终选型还是要根据你实际测试的情况来定。7.1 日常对话类场景建议使用通用对话模型关键是响应速度要快、中文能力要稳。我在实际测试中发现某些便宜模型在中英文混说场景下会突然疯掉或者出现很明显的AI味这种就果断换掉。7.2 翻译类场景翻译场景我用下来排名靠前的是专精翻译的模型。相同的一句话通用模型和翻译专用模型译出来的差距在专业术语多的句子里特别明显。翻译场景还要特别注意一个问题不要携带完整上下文。带上下文虽然能提升译文连贯性但如果你在酒吧、地铁等嘈杂环境里开实时翻译噪声文本混进上下文翻译质量反而大降。我的经验是翻译场景用context_modenone配合设备端ASR的降噪能力效果更好。7.3 图片理解类场景多模态大模型是另一个赛道。这类模型特别吃参数规模和训练数据质量。在实际测试中我发现眼镜拍照理解桌面上的杯子是什么品牌背影识别率高的模型往往也是参数规模更大的模型但参数大意味着贵且慢所以我的策略是图片理解场景只在白天工作时段用大模型夜间自动切到轻量模型配合定时规则省成本。7.4 总结与纪要类场景会议纪要、摘要生成这类场景强调的是逻辑连贯性和信息抽取能力。模型选型上我建议选择上下文长度够长、长文本能力强的模型不要选那些只适合短对话的模型。另外这类场景一次性Token消耗很高所以在scenesummarization时我在网关里加了独立的额度限制每个session最多3次/分钟防止开会时手机放桌上被误触调用白白烧Token。7.5 备用模型策略无论你怎么选永远要给自己留一个备用模型。这个备用模型不一定是最好的但一定是最稳定的。我有一个专门剩余的备用额度模型用于当所有主要模型都不可用时兜底。因为我的业务逻辑设在网关上切换备用模型时用户甚至感知不到变化——他们只是觉得今天响应稍微慢了一点点而已。8. 进一步扩展网关还可以做什么网关搭好之后它不只是模型路由器它还是一个非常灵活的中控层。我后期在这个基础上加了不少功能这里挑几个有价值的方向。8.1 多设备统一管理眼镜、耳机、甚至手机App都在同一个网关注册。我可以在网关的管理面板看到所有设备的实时状态、请求数量、模型分布、成本走势。如果公司或团队里有多个测试设备这个功能能帮你快速定位哪台设备出问题了。8.2 自动日志与回放网关把所有请求和响应都记了日志。出现问题后我可以拉出某台设备某个时间段的完整对话记录复现当时的上下文和模型路由决定。这个能力在排查刚才为什么回答得不对时非常有用——你不需要去问设备厂商自己就能查清楚。8.3 基于反馈的自适应路由这是我现在正在做的一个方向。网关记录用户对每个回答的反馈比如语音评价这个回答不错或很差然后定期汇总出哪个模型在哪个场景下用户满意度更高据此自动调整路由权重。思路类似A/B测试但它是持续运行、自动收敛的。8.4 离线兜底策略虽然网关依赖网络但我在网关层设计了离线兜底策略网关监测到网络连接异常时返回一个缓存或规则驱动的简单应答而不是直接报错。比如当眼镜问到现在几点了这类固定问题网关可以在本地规则库直接命中返回完全不需要调用模型。这个功能在电梯、地下车库等弱网场景下很实用至少不会让用户感觉设备死了。9. 写在最后这套方案的局限性与我的建议最后说几句实在话。这套方案不是万能的。它的最大限制在于设备端SDK是否允许你自定义服务地址。如果你手上的AI眼镜、AI耳机完全不给开发者任何自定义入口那就只能通过逆向或抓包改请求来做门槛高很多也不稳定。所以如果你正要购买设备建议优先考虑那些开放能力好、支持自定义服务的型号。还有一个局限是网关本身是一个需要维护的服务。你得有台服务器哪怕是轻量云主机还得保证它稳定运行。如果你只是偶尔玩玩可能不值当但如果你像我一样每天都要用眼镜、耳机做不少AI任务这个投入是值得的。最后给一点选型建议使用OpenAI兼容格式的模型能让你少走90%的弯路。用到现在我最直观的感受是AI眼镜、AI耳机接入多个大模型这件事技术门槛真没有想象中那么高但需要你有耐心去处理设备端的各种限制和模型方的各种差异。网关本质上是一个翻译层和调度层它解决的不是某一个具体功能而是整套设备接入AI的底层问题。一旦这层打通后面加功能、换模型、调策略全都变成了配置操作而不是重新开发。
1. 为什么AI眼镜和AI耳机需要一个统一的模型接入层最近圈子里聊AI眼镜和AI耳机的人明显多起来了但大部分人聊的都是硬件本身——镜片多重、续航多久、音质怎么样。真正上手做过之后你会发现这些设备能不能用起来核心瓶颈根本不在硬件而在AI能力怎么接。我自己的经历是这样的手上有某品牌的AI眼镜用的语音交互又入了一款开放式AI耳机主打实时翻译和会议纪要。两台设备各自的App都做得挺漂亮但问题在于——它们各自只接了一个模型。眼镜接的是A厂商的语音模型耳机接的是B厂商的对话模型。A厂商的模型在某些场景下表现不错但另一些场景明显不如其他模型B厂商的模型倒是全能但价格贵、响应慢。这让整个体验非常割裂。更麻烦的是我偶尔想自己折腾一些功能比如让耳机在听音乐时自动生成播放列表、让眼镜在会议中识别PPT上的公式——原生App根本不给你这种自由度。后来我琢磨出一套方案效果比我预想的好不少。简单说就是在设备和大模型之间加一层统一的API网关让所有AI眼镜、AI耳机都通过这一个网关去调用不同的大模型。这个思路不算新鲜但真正在硬件设备上落地坑比想象中多。这篇文章就把整个方案从头到尾拆开讲一遍包括为什么这么设计、网关怎么搭、设备端怎么改、实测效果如何以及我踩过的那些坑。适合手里有AI眼镜或AI耳机、想自己把模型接入权拿回来的开发者也适合做硬件产品、正在纠结模型选型的工程师。先放结论这套方案不只解决了多个模型任意切换的问题它还顺带解决了设备离线策略、成本控制、响应速度抖动、多设备统一管理等一系列问题。基本上属于一次改造、长期受益的类型。2. 三个模型接入方案的对比如今市面上搞模型接入大致有三条路可以走。2.1 方案A设备App直连某一个模型这是绝大多数AI眼镜、AI耳机默认的做法。设备厂商在自己的App里内置了一个模型SDK用户只能用它提供的对话能力不能改、不能换。优点很直接省事。厂商只要调一次API不用管太多适配问题用户拿到手就能用也不用配置什么。缺点也显而易见模型能力被锁死了。A模型在某些场景比如中文诗词创作很强但在另一些场景比如实时翻译就很一般B模型翻译很强但语音交互的延迟又偏高。对于普通用户来说这些差异可能感知不明显但对于想把设备用出花来的开发者这种绑定就是天花板。还有一个隐性问题厂商选型时通常考虑的是成本和稳定性而不是具体某个场景的能力上限。所以你会看到很多眼镜、耳机产品宣传时说的是搭载某大模型但对用户来说真正重要的是这个模型在我想用的场景里到底行不行。2.2 方案B设备端本地跑一个小模型有些设备开始尝试在端侧部署小参数模型比如1B、3B级别的。眼镜和耳机这类设备计算能力有限端侧模型主要用于关键词唤醒、简单指令识别复杂的推理还是得靠云端。这个方案的优点是没有网络时也能跑一部分功能隐私性好一点。但缺点也很致命小模型的智商上限摆在那里。你可以让它在本地判断用户说拍照还是播放音乐但没法让它在本地写一篇结构完整的文章、总结一份复杂的会议纪要。我实际测过设备端3B模型的总结能力跟云端大模型比差距还是很明显的。所以端侧模型更适合做推理前置而不是作为主能力来源。2.3 方案C统一API网关按需路由到不同模型我的做法就是方案C。核心思路是在设备与多个模型之间插入一个网关服务这个服务负责接收来自设备端的统一格式请求根据请求类型、场景、成本预算、模型实时状态决定将请求转发给哪一个模型将模型的返回结果再统一包装后送回设备端相当于做了一个模型路由器。设备端不需要关心背后用的是哪个模型它只需要知道我发一个标准格式的请求就能拿到标准格式的回复。在具体实现上我选的是FastAPI写网关服务通过OpenAI兼容格式对外暴露接口然后在网关内部按场景路由到不同模型。这个方案的好处是兼容性极好——现在的模型厂商基本都提供了OpenAI兼容的接口格式等于天然适配。为什么不用别的格式因为如果每个模型都用自己的SDK和协议网关内部就要维护一堆不同格式的适配器工作量和出错概率成倍增长。OpenAI兼容格式已经是大模型API领域的事实标准就像当年USB接口逐渐统一了外设连接一样虽然它不完美但生态最广。2.4 为什么我不建议直接用第三方聚合平台可能有人会问市面上不是已经有模型聚合平台了吗直接调用它们不也能实现多个模型切换这里我想说几句掏心窝的话。第三方聚合平台确实省事它们帮你封装好了统一接口甚至还能自动路由。我自己也用过在某些场景下确实好用。但我在实际项目里遇到几个问题第一平台规则不可控。聚合平台经常调整模型供应商、调整价格策略有时候你依赖的某个模型在平台上突然下线了你只能等平台恢复没有任何谈判余地。第二链路太长了。设备端请求要经网关转发到聚合平台聚合平台再转发到真正的模型服务商中间多了两跳网络延迟对眼镜、耳机这类需要实时交互的设备影响明显。第三自定义能力受限。我需要针对不同请求类型做不同策略比如翻译类请求优先用低成本模型、创意写作类请求跳过高成本模型这类细粒度控制在聚合平台上实现起来比较别扭。所以最终我确定了自己搭网关这条路。虽然前期要多写一点代码但后面每次新增模型、调整路由策略都完全由自己掌控。3. 网关架构拆解一个请求从眼镜发出到拿到回答的全过程这套架构用一张图就能说清楚。但考虑到读者口味差异我还是先把整个链路拆成几个部分逐层来讲。3.1 设备端与网关之间的通信协议先说设备端AI眼镜/耳机和网关之间的通信。这一步最核心的问题不是选什么通讯协议而是让设备端发请求这件事变得足够简单。我最终选定的方案是设备端通过WebSocket或HTTPS向网关发送一个JSON格式的请求内容包括{ device_id: glasses_01, device_type: smart_glasses, session_id: 8f9a2c3e, scene: translation, text: 把这句话翻译成英文今天天气怎么样, audio: false, extra: {} }这里有几个字段值得单独说明device_id和device_type用于标识是哪台设备。网关拿到后可以决定不同的路由策略比如眼镜用视觉理解模型、耳机用语音对话模型。scene字段是路由的关键。我目前在用的场景包括translation、summarization、creative_writing、chat、vision_description等。网关根据场景来选模型。audio字段是布尔值。有些设备支持直接传音频网关再转成文本处理不支持的设备就先把音频在设备端转成文本再走文本接口。session_id用于多轮对话上下文管理。网关侧会缓存这个会话的历史记录保证连续对话有记忆。网关返回的格式也很简单{ status: success, response: The weather is nice today., model_used: glm-4-plus-fast, latency_ms: 812, tokens: 23 }增加model_used字段是后来才想到的但非常实用。通过它我可以直观看到每一次请求实际被路由到了哪个模型方便调试和成本核算。这里要特别提醒一点设备端的SDK不需要也不能感知模型细节。设备端永远只发我需要什么样的结果的请求而不关心这个结果由谁产生。这样后期就算你换掉所有模型设备端代码一行都不用改。3.2 网关的路由决策逻辑网关的核心是一套路由决策逻辑。我把它做成一个可配置的规则引擎核心判断维度有这么几个按场景路由上面提到的scene字段是最高优先级的判断条件。比如translation场景我默认路由到低延迟模型summarization场景路由到高理解能力模型。按模型健康状态路由网关会定时检查各个模型服务的可用性。如果某个模型连续失败次数超过阈值自动把请求切到备用模型。这个机制解决了我之前遇到的某个模型服务商临时故障导致设备完全不可用的窘境。按成本预算路由我在网关里做了简单的成本控制。每个设备每天有配额比如眼镜的免费额度是300次/天超过之后自动路由到更便宜的模型或者直接返回提示。这个功能对于团队共享设备、限制滥用非常有用。按用户自定义规则路由这里是最灵活的部分。我支持通过配置文件或管理接口增加自定义路由规则。比如指定眼镜在所有场景下都走模型P或者翻译场景如果文本长度大于500字切换到模型Q。到这一步路由策略已经可以从写死在代码里变成随时可调整的配置。我后来把配置放到了环境变量和远程配置中心调策略不用重新发版update设备时会自动拉取最新配置。3.3 不同模型API的适配层网关中最脏最累的活就是对接不同模型的服务商API。我这里的设计思路是先定义一个内部的统一模型调用接口所有具体模型都实现这个接口。接口大概长这样class BaseModelProvider: def chat(self, messages, streamFalse, temperature0.7, max_tokensNone): raise NotImplementedError def health_check(self): raise NotImplementedError def get_metric(self): raise NotImplementedError不同的模型服务商各自实现这个类。比如对接ChatGLM服务的做一个Provider对接DeepSeek服务的做另一个Provider。每个Provider内部把厂商特有的API格式转换为统一格式。这里必须提一个重要经验几乎所有主流模型服务商都提供了OpenAI兼容接口。这大大减少了适配工作量。如果你对接的某个服务商不支持OpenAI兼容格式那就要单独写适配代码这也是为什么选型时我优先选有兼容接口的模型。为了节省时间我建议用一个现成的SDK——我目前用的是LiteLLM这个库。它可以统一调用各种模型服务商而且天然支持OpenAI兼容格式。如果你是自己搭网关完全不用自己造轮子去适配各家API直接用这种库能省掉至少两周时间。3.4 会话上下文管理AI眼镜和AI耳机使用场景有一个特别之处它们是长时间佩戴的设备对话天然是连续的上下文必须在多轮之间保持。比如你在眼镜上问这个建筑是什么风格的紧接着问它有多少年历史了如果网关不保存上下文第二句就完全没法回答。我的做法是在网关里维护一个session存储session_manager.set(session_id, {history: history_list})默认每个session保留最近10轮对话超过后按最早优先淘汰。存储可以用内存如Redis也可以用本地磁盘。考虑到眼镜、耳机设备经常处于移动状态、网络可能不稳定我用的是Redis加本地双写防止服务重启丢上下文。这里有一个值得注意的细节不是所有请求都需要完整上下文。比如翻译场景你把完整上下文带上传给模型翻译出来的结果可能更准确但Token开销也更大而像唤醒词校验这种请求完全不需要历史。所以我在request里增加了一个context_mode字段值为full、summary、none三种。网关根据这个字段决定是否携带上下文能省不少成本。4. 设备端如何改造AI眼镜、AI耳机的接入实操很多人以为设备端改造很难其实只要你选的产品支持应用层开发改起来没有想象中复杂。我以我自己用的眼镜和耳机为例讲一下改造要点。4.1 AI眼镜的接入实操我用的眼镜自带了一个开放的SDK支持自定义语音识别和自定义意图处理。改造思路是这样的把SDK默认的语音→模型这一链路改成语音→文本→网关。第一步关掉SDK内置的模型调用。在眼镜的App配置里找到AI服务选项将它切换为自定义或关闭内置模式。第二步配置WebSocket地址。SDK里通常有一个setServiceUrl(url)方法把网关的WebSocket地址填进去。第三步在眼镜端实现一个准备请求的逻辑把语音识别后的文本、当前场景信息、设备ID等打包成JSON发送到网关。第四步处理网关的返回值。网关返回JSON后眼镜端解析出response字段进行TTS播报。如果返回的是多模态结果比如图片描述眼镜端可以显示在镜片上或直接语音播报。我实际用下来眼镜端改造代码量非常少大概200行不到一个下午就能搞定。最花时间的反而不是改代码而是调整语音识别ASR的质量——眼镜的麦克风离嘴比较远识别准确率没有手机高这个问题需要用降噪后处理来弥补。4.2 AI耳机的接入实操耳机比眼镜稍微复杂一点因为耳机通常不只做对话还涉及实时翻译、会议纪要等场景。我用的耳机支持蓝牙连接手机AppApp里也有一个自定义服务端点配置。操作逻辑类似把内置AI改为自定义服务把HTTP或WebSocket地址指向网关。还有一个比较特殊的场景是耳机上的物理按键。比如按两下唤醒AI、长按进入翻译模式这些按键事件本质上是SDK内部触发的意图我通过SDK提供的回调接口在回调里转为对网关的请求。这部分代码也不复杂核心点在于快速双击唤醒对话场景标记为chat长按进入实时翻译模式场景标记为translation同时开启麦克风持续收音按三下暂停/恢复上下文这个功能在开会时很好用防止耳机把周围人的闲聊也记到上下文里耳机端的难点在于流式交互。翻译和对话场景下用户希望边说边出结果而不是等整句说完才回复。所以我让网关接口支持streamtrue模型结果以流式方式返回耳机端边收边播用户感知到的延迟能降低一大截。具体做法是网关返回SSEServer-Sent Events格式的数据流耳机端用SDK的事件回调逐段处理文本。实测下来这种流式方案比一次性返回的平均延迟降低了30%以上。4.3 TTS和ASR的处理位置选择这里有一个可能被忽略、但影响体验极大的决定语音识别ASR和语音合成TTS放在设备端做还是放在云端做我一开始把ASR放在了云端思路是设备端只录原始音频云端统一处理。结果很不理想眼镜和耳机的麦克风差异大音频质量参差不齐云端识别错误率高而且音频数据上传消耗大量带宽和电量。后来我改成设备端本地ASR——眼镜和耳机都带有不错的本地语音识别能力哪怕稍微弱一点识别成文本后再发给网关。这样网络传输的数据量大幅减少成本也低了。TTS则是反过来网关返回文本后在设备端本地做TTS播报效果比云端TTS返回音频数据要自然。一是因为在设备端做TTS可以在语音播报的同时保留语义理解的中间结果二是因为音频文件的传输延迟比文本高很多。总结一下我的经验ASR天然适合在设备端做因为音频数据量太大了传云端既慢又贵。TTS在设备端做效果好、延迟低但如果你对音色有特殊要求比如需要名人音色那还是走云端TTS。5. 实测效果延迟、成本、稳定性三项指标对比架构搭好之后我做了几轮实测。这里把关键数据放出来给大家一个直观参考。5.1 延迟对比我测试了一个典型场景眼镜上看一张图片并问这张图片里有什么。整个过程包括眼镜端拍照→图片上传到网关→网关解析图片→调用视觉模型→生成描述→返回文本→眼镜端TTS播报。模型方案平均端到端延迟设备App内置单一模型2.8s网关路由到轻量模型1.9s网关路由到重量级模型3.6s结论很明显网关本身带来的额外延迟大约在100ms以内但通过合理的路由选择整体延迟反而可以比内置单一模型更低。关键就在于针对场景选模型——翻译、简单问答这类轻场景用轻量模型就能把延迟压到2秒以内。5.2 成本对比我统计了使用网关前后一周的成本场景内置单一模型成本网关路由后成本日常对话1200次/天约2.1元/天约0.8元/天实时翻译300次/天约0.6元/天约0.3元/天图片理解80次/天约1.2元/天约0.9元/天省下来的主要原因是大部分日常对话居然走便宜模型也能得到不错的效果。以前内置模型是一刀切类型选贵的就是贵的选便宜的就是便宜的现在有了路由我可以做到便宜的应对日常、贵的只留给真正需要的场景。5.3 稳定性对比我在使用过程中记录了一周的失败率数据内置单一模型方案平均失败率0.6%最高单日失败率1.8%。网关路由方案带健康检查平均失败率0.3%没有出现单日超过0.8%的情况。原因是网关的健康检查会在某个模型服务异常时自动切换备用模型。比如某天某个模型服务商因为大规模调用超时导致响应变慢网关在检测到连续三次失败后自动把所有流量切到了另一个模型最终用户感知不到任何中断。6. 常见问题与踩坑全记录这部分是我最想写的内容因为整个搭建过程中踩的坑比顺利的部分多得多。6.1 坑一设备端SDK隐藏了模型类型信息我一开始天真地以为设备端SDK会把用的是哪个模型暴露给开发者结果发现不是。大部分消费级AI眼镜、AI耳机的SDK里模型类型是写死的你只能调用内置模型接口不能直接指定或替换模型。解决办法有两个方向一是看SDK是否有开发模式或自定义模式开关。我身边有朋友用的设备恰好支持这种模式直接在设置里打开然后填入自定义服务地址即可。二是更简单粗暴在设备端做一层代理。设备端请求仍然发给原本的SDK服务但我用抓包工具把这个请求转发到自己搭的网关上。这种方式实现起来麻烦一点需要懂点网络调试但胜在几乎所有设备都能这样处理。6.2 坑二模型返回结果格式不统一不同模型服务商的返回格式差异很大。有的返回纯文本有的返回JSON里嵌着文本有的返回结构化列表。我在网关适配层上花的时间远超预期。我的建议是不要在网关内部做太复杂的格式解析。最稳妥的做法是网关统一把它们转换为一个标准结构然后设备端再统一使用这个标准结构。如果某个模型返回了额外的结构化信息比如对话中抽取的实体、情感标签这些额外信息先存到extra字段里设备端按需取用。6.3 坑三耳机端流式返回时的断句问题流式返回时模型是一段一段返回文本的。耳机端需要判断什么时候该停止播报以及什么时候该插入停顿。如果处理不好用户听到的话会糊成一团像舌头打了结。我最终的做法是网关在处理SSE流时根据返回的标点符号和模型自带的finish_reason信号自动在适当位置加一个segment_end标记。耳机端在收到这个标记时才做断句和播报这样听感接近自然语言停顿。6.4 坑四模型供应商的速率限制大模型服务商普遍有速率限制Rate Limit比如每分钟请求上限、每千Token成本上限等。如果眼镜、耳机这类设备高频调用很容易触到限制导致返回429错误。我的应对策略是在网关层做请求排队和滑动窗口限流每个模型独立维护一个令牌桶如果某个模型桶里的令牌空了等待100ms再重试。同时在网关层统计每个设备分钟级请求数超过阈值直接返回友好提示而不是继续发请求。这样既避免了对模型服务的骚扰也保护了用户体验。6.5 坑五眼镜端多模态请求的上传格式眼镜端的图片理解体验很好但在网络不稳定时会出大问题。我一开始把图片用Base64编码直接塞进JSON里结果一张2MB的图片让整个请求体膨胀到2.7MB弱网下几乎无法使用。后来改成两步式设备端先把图片上传到独立的文件存储服务获得一个image_url。网关收到请求时携带image_url调用视觉模型。这样图片上传和文字请求解耦弱网环境也能正常使用而且还可以对图片做压缩和缓存后期成本进一步下降。7. 不同模型的选型建议与分工这部分给大家一个我实测过的模型分工建议仅供参考。模型更新很快最终选型还是要根据你实际测试的情况来定。7.1 日常对话类场景建议使用通用对话模型关键是响应速度要快、中文能力要稳。我在实际测试中发现某些便宜模型在中英文混说场景下会突然疯掉或者出现很明显的AI味这种就果断换掉。7.2 翻译类场景翻译场景我用下来排名靠前的是专精翻译的模型。相同的一句话通用模型和翻译专用模型译出来的差距在专业术语多的句子里特别明显。翻译场景还要特别注意一个问题不要携带完整上下文。带上下文虽然能提升译文连贯性但如果你在酒吧、地铁等嘈杂环境里开实时翻译噪声文本混进上下文翻译质量反而大降。我的经验是翻译场景用context_modenone配合设备端ASR的降噪能力效果更好。7.3 图片理解类场景多模态大模型是另一个赛道。这类模型特别吃参数规模和训练数据质量。在实际测试中我发现眼镜拍照理解桌面上的杯子是什么品牌背影识别率高的模型往往也是参数规模更大的模型但参数大意味着贵且慢所以我的策略是图片理解场景只在白天工作时段用大模型夜间自动切到轻量模型配合定时规则省成本。7.4 总结与纪要类场景会议纪要、摘要生成这类场景强调的是逻辑连贯性和信息抽取能力。模型选型上我建议选择上下文长度够长、长文本能力强的模型不要选那些只适合短对话的模型。另外这类场景一次性Token消耗很高所以在scenesummarization时我在网关里加了独立的额度限制每个session最多3次/分钟防止开会时手机放桌上被误触调用白白烧Token。7.5 备用模型策略无论你怎么选永远要给自己留一个备用模型。这个备用模型不一定是最好的但一定是最稳定的。我有一个专门剩余的备用额度模型用于当所有主要模型都不可用时兜底。因为我的业务逻辑设在网关上切换备用模型时用户甚至感知不到变化——他们只是觉得今天响应稍微慢了一点点而已。8. 进一步扩展网关还可以做什么网关搭好之后它不只是模型路由器它还是一个非常灵活的中控层。我后期在这个基础上加了不少功能这里挑几个有价值的方向。8.1 多设备统一管理眼镜、耳机、甚至手机App都在同一个网关注册。我可以在网关的管理面板看到所有设备的实时状态、请求数量、模型分布、成本走势。如果公司或团队里有多个测试设备这个功能能帮你快速定位哪台设备出问题了。8.2 自动日志与回放网关把所有请求和响应都记了日志。出现问题后我可以拉出某台设备某个时间段的完整对话记录复现当时的上下文和模型路由决定。这个能力在排查刚才为什么回答得不对时非常有用——你不需要去问设备厂商自己就能查清楚。8.3 基于反馈的自适应路由这是我现在正在做的一个方向。网关记录用户对每个回答的反馈比如语音评价这个回答不错或很差然后定期汇总出哪个模型在哪个场景下用户满意度更高据此自动调整路由权重。思路类似A/B测试但它是持续运行、自动收敛的。8.4 离线兜底策略虽然网关依赖网络但我在网关层设计了离线兜底策略网关监测到网络连接异常时返回一个缓存或规则驱动的简单应答而不是直接报错。比如当眼镜问到现在几点了这类固定问题网关可以在本地规则库直接命中返回完全不需要调用模型。这个功能在电梯、地下车库等弱网场景下很实用至少不会让用户感觉设备死了。9. 写在最后这套方案的局限性与我的建议最后说几句实在话。这套方案不是万能的。它的最大限制在于设备端SDK是否允许你自定义服务地址。如果你手上的AI眼镜、AI耳机完全不给开发者任何自定义入口那就只能通过逆向或抓包改请求来做门槛高很多也不稳定。所以如果你正要购买设备建议优先考虑那些开放能力好、支持自定义服务的型号。还有一个局限是网关本身是一个需要维护的服务。你得有台服务器哪怕是轻量云主机还得保证它稳定运行。如果你只是偶尔玩玩可能不值当但如果你像我一样每天都要用眼镜、耳机做不少AI任务这个投入是值得的。最后给一点选型建议使用OpenAI兼容格式的模型能让你少走90%的弯路。用到现在我最直观的感受是AI眼镜、AI耳机接入多个大模型这件事技术门槛真没有想象中那么高但需要你有耐心去处理设备端的各种限制和模型方的各种差异。网关本质上是一个翻译层和调度层它解决的不是某一个具体功能而是整套设备接入AI的底层问题。一旦这层打通后面加功能、换模型、调策略全都变成了配置操作而不是重新开发。
