您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[未知机构]:谈一些自己关于端侧AI的思考旨在抛砖引玉引发更多讨论与指正 - 发现报告
当前位置:首页/会议纪要/报告详情/

谈一些自己关于端侧AI的思考旨在抛砖引玉引发更多讨论与指正

2024-07-08未知机构土***
谈一些自己关于端侧AI的思考旨在抛砖引玉引发更多讨论与指正

1.不管端侧还是云侧,算力的优先级永远是第一的,内存、互联都是为算力服务,没必要被一些显性但无关紧要的信息所吸引,而忽略芯片设计架构可能带来的巨大变化,从重要性和价值量来看都应排在首位; 2.从云侧去看,本身transformer的模型结构规模很大,但核心计算单元其实并不多,如 果仅从加速模型角度去设计芯片,是可能将其做到极致的加速,性价比上超过谈一些自己关于端侧AI的思考,旨在抛砖引玉,引发更多讨论与指正:1.不管端侧还是云侧,算力的优先级永远是第一的,内存、互联都是为算力服务,没必要被一些显性但无关紧要的信息所吸引,而忽略芯片设计架构可能带来的巨大变化,从重要性和价值量来看都应排在首位; 2.从云侧去看,本身transformer的模型结构规模很大,但核心计算单元其实并不多,如 果仅从加速模型角度去设计芯片,是可能将其做到极致的加速,性价比上超过英伟达,但是从商业角度考虑,英伟达的系统级优势太大,用于训练还是很难撼动,但是在端侧推理,不用考虑集群互联,用与模型更匹配的设计架构在终端以较低cost将高性能的模型进行部署,是可行的优化方案,毕竟2C 的业务,能带来体验提升,用户买单即可;3.苹果的本地模型、私有云模型、第三方大模型的三层AI架构设计,虽然从体验上我认为对每个用 户不一定是最好的,但是考虑到品牌影响力和市场占有率,由苹果来引领、承担用户的教育成本,其他厂商可以避免犯错或资源浪费,除非是有一套更突出的方案所以大概率其他厂商会参考这套设计,形成事实上行业短期的标准,基本上也就划定了本地模型的应用场景跟能力的边界,尽可能去优化提升性能触及到边界上限,就是未来所有端侧模型、芯片设计最重要的工作方向;4.相比起云侧,端侧模型的性能提升很难单纯的靠硬件的堆砌来提升,主要受两方面的制约,一是功耗,二是增加成本后能否顺利向用户传导,尤其是功耗,在端侧为了提升性能而带来功耗大幅增加,从设计角度是不可接受的,所以在功耗跟成本这个边界内,能优化的方向基本上就只剩下模型算法跟芯片架构;5.端侧模型算法优化上,大概也就几个方向,除了模型压缩、蒸馏等,前一段传阅度较高的苹果的《LLMinaflash》侧重于内存受限情况下的优化,虽然这篇解读为应用在iPhone 上的卖方点评很多,但是比较大的可能跟iPhone无关,另外也有利用推理过程的高度局部性,采 用GPU-CPU混合计算的方式,降低GPU的门槛。 但是不管模型采用什么算法,最终实现需要占用本来纯粹用于推理的算力,比如CPU,所以针对算法单独增加硬件实现,例如一片SoC或MCU,而不占用CPU\GPU\NPU的算力成为一种可行 方案;6.说是可行方案是如果按照KK级别量产来看增加的成本可能在几十块钱,成本传导可控,同时还带来了性能的提升。 同时,在确定模型方案后,终端厂商可以采取定制化的要求找产业伙伴适配开发,降低研发成本。 适配开发的芯片设计公司的价值体现在,因为跟对应终端模型算法匹配,所以设计的芯片具备唯一性而不具备普适性,没有办法应用在其他客户或终端上,所以往往这种合作具备排他性,收益完全取决于合作客户最终的销量,而采取这种方案的基本上是头部客户。 同时,具备这种适配开发能力后,未来也有可能收获潜在的中尾部客户的定制适配需求;OMT:因为上面提到的应用场景跟能力的边界,以及功耗和成本传导的边界,端侧模型跟芯片设计其实优化、性能提升的空间非常有限,可以理解成”屎上雕花“,也有人觉得端侧3B跟50B的模型最 终效果上没有本质区别,通俗点举例就是特别简单的需求都能实现,特别难的也实现的都错的离谱。讲道理确实是这样,但是从产业信息看已经有在做这个方向的实现,预计再过一两个月就有终端大客户的适配。 站在这样的产业事实面前再去思考,端侧优化方案的意义可能不在于实现应用场景上限的突破。 我自己认为有可能在日常高频次使用上带来的体验感差异,用户对性能的感知往往在日常的频繁交互中形成。 举个例子,一天数十次的向小艺提起的需求就是比Siri实现的要好,或者反过来,这大概就是这类优化提升端侧性能方案的价值。