首页9月22日，高通在年度骁龙峰会上发布了两款旗舰手机处理器，骁龙8至尊版Gen 6与骁龙8旗舰版Gen 6，核心卖点直指AI。其中最值得RTC行业关注的，并非CPU或GPU的常规迭代，而是端侧语音处理能力的系统性下沉：旗舰版可在本地运行300亿参数MoE模型，标准版的感知中枢支持2亿参数模型本地跑通个人速记与说话人区分，两款芯片均内置端侧语音AI Agent与实时降噪“语音气泡”功能。
一. 高通新芯片的关键语音与AI能力拆解
先看两款芯片在语音与AI方面的具体能力。
旗舰版Extreme Gen 6的突出能力是本地运行300亿参数MoE模型。MoE（混合专家）架构的特点是：整体模型规模为300亿参数，但针对特定任务只激活其中一部分参数。这使端侧运行大模型在算力与功耗上变得可行。高通表示，该芯片可以运行完整的语音输入-输出Agent，即从语音识别、语义理解到语音合成的全链路都可以在端侧闭环完成。
标准版Gen 6则依托新的感知中枢（sensing hub），支持最高2亿参数的小模型本地运行。具体场景包括个人速记（personal scribe）和说话人区分（differentiate between speakers），并能基于用户使用习惯构建记忆，用于自动化任务的建议。感知中枢的定位是低功耗、常驻运行的轻量AI层，适合处理高频、短时、隐私敏感的语音任务。
实时降噪与“语音气泡”是另一条关键线索。两款芯片均可用AI增强人声、降低噪声，并搭载高通新的“语音气泡”（voice bubble）技术，在通话中隔离用户噪声。从描述看，语音气泡的目标是在嘈杂环境中为用户创造一个局部的、干净的语音通道——这本质上是一种芯片层的实时音频前处理能力。
作为参照，苹果在6月WWDC上发布了200亿参数MoE模型，是其第三代基础模型中最先进的一代。高通旗舰版300亿参数的本地运行能力，在规模上已经超过了苹果当前公开的端侧模型。端侧模型的参数竞赛正在加速。
二. 端侧实时语音处理下沉到芯片层的意义
把语音处理与降噪下沉到芯片层，带来的变化可以从三个维度理解。
延迟维度。传统RTC实时通讯链路中，语音采集后的降噪、声纹识别、语音识别、Agent推理等环节，相当一部分需要往返云端。每一次往返都引入网络延迟、抖动和排队等待。当降噪、说话人区分、轻量Agent推理在端侧闭环完成，实时对话、会议、游戏语音等场景的端到端延迟可以显著降低。尤其是“语音气泡”这类实时降噪能力，放在芯片层意味着它可以在音频采集的最前端完成处理，而不是等到数据上行后再由云端或应用层补救。
成本维度。云端GPU推理与带宽消耗是RTC服务商的主要成本项之一。高频、短时、隐私敏感的语音任务，比如持续的环境降噪、说话人区分、个人速记，如果全部上云，会带来持续的算力与带宽开销。端侧处理将这些任务转移到终端，云端可以更专注于大规模模型推理、跨端协同和复杂任务编排。成本结构从“云端集中承载”转向“端云分工”。
隐私与可用性。个人速记、说话人区分涉及生物特征与内容隐私，端侧处理减少了数据外传的必要性。同时，弱网或无网环境下，端侧仍可保留基础语音AI能力。
三. 端侧能跑大模型，但没那么简单
MoE架构省的是计算量，不是内存。一次推理只激活一小部分专家网络，算的量确实少了，但300亿参数的权重本身还是得整个放在手机能随时取用的地方，该占的内存空间一点没少。所以芯片厂商还得配合量化压缩这类手段，把训练时用的高精度权重压成更低比特的版本，才能真正塞进手机的内存预算里。
这一步压缩不是没有代价的，模型能力会打一点折扣，工程上是在”塞得进去”和”效果打几分折扣”之间找一个平衡点。就算这些都做到了，300亿参数在手机上跑，内存带宽和功耗还是绷得很紧，跑一会儿发烫、跑久了掉电快，这是物理层面的限制。感知中枢那颗2亿参数的小模型走的是另一条路：功耗压得住，但能干的事也窄，只够做语音速记、辨认说话人这类轻量任务，接不住复杂的多轮对话。
还有一层容易被忽略：芯片有这个能力，不代表马上就能用上。芯片厂商发布参考设计之后，手机厂商要把它集成进自己的系统固件，操作系统要把调用这个模型的接口开放给开发者，应用商店和运营商那边的审核认证也要跟上。这几层每一层都要时间，中间隔上大半年到一年很常见。今天发布会上演示的能力，和开发者真正能在自己的App里调用的接口，往往不是一回事。
四. 芯片管得着的只是手机自己收到的这段声音
手机本地这一段处理的其实是一条固定的流水线：麦克风阵列先把声音收进来，回声消除去掉本机听筒和外放漏回麦克风的声音，降噪模块把背景噪音摘掉，语音活动检测判断哪一段是人声、哪一段该丢弃，再往后才轮到转写和说话人识别。这一整条链路，输入是麦克风收到的声音，输出还是一段干净的音频或者文字，从头到尾没有离开这台设备。
打电话真正要做的动作是另一件事：把这段处理干净的音频编码打包，通过网络送到几千公里外另一台设备上，同时把对方发过来的音频包接收、解码、播放出来。这个过程要应对的麻烦，网络会抖动，链路会拥堵，包会丢，包到达的顺序会乱，跨运营商、跨国际线路的情况只会更复杂。而且这些问题是双向的：我这边的芯片再怎么把声音处理干净，只要中间这段网络出问题，对方收到的还是一段抖动、卡顿甚至丢字的声音，跟我手机里那颗芯片强不强没有关系。
四. 这段路，声网在管
声网这几年做的正是这段路上的事，核心是两层：怎么应对丢包，怎么选传输路径。
丢包这块用的是两种机制搭配着来。轻度丢包靠FEC前向纠错直接兜住：发送端在发原始包的同时顺带发一些冗余的纠错包，接收端发现丢了包，不用等一次网络来回，直接靠剩下的包和冗余包推算出来，延迟极低。丢包率明显升高、FEC的冗余量也补不上的时候，再靠ARQ针对性地重传：接收端发现某个关键包确实没到，向发送端请求单独重传这一个包，代价是要多等一次来回的延迟，但换来的是这个包一定能补上。这两种机制背后都依赖同一件事：持续监测当前链路的带宽、延迟、抖动和丢包率，用实时数据决定该用哪种手段、用多少冗余。
路径这块靠的是SD-RTN软件定义实时网。声网在全球铺了大量数据中心节点，调度系统的工作是拿这些节点当中转跳板，持续采集节点之间的链路质量、带宽和负载数据，动态算出一条延迟最低、最稳定的路径。这条路径不一定是两地之间物理距离最短的那条线路，网络状况更好的时候，宁可多绕一两跳节点也划算。一个人在纽约、一个人在上海，中间这条路怎么走最快最稳，靠的就是这套跨越国际链路和不同运营商网络的实时调度，而这恰恰是手机里那颗芯片管不到、也管不了的部分。
五. 写在最后
手机会越来越聪明，语音处理放到本地能省不少云端算力和延迟，这是好事。但两个人隔着几千公里说上话，靠的不是手机里那颗芯片，是声音出了手机之后走的那条网络。
