心法利器
本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
2023年新的文章合集已经发布，获取方式看这里：又添十万字-CS的陋室2023年文章合集来袭，更有历史文章合集，欢迎下载。
往期回顾
心法利器[127] | 24年算法思考-特征工程和经典深度学习
心法利器[128] | 2024年算法小结-个人成长-打开思路-生日
心法利器[129] | deepseek-R1自测效果分析和选择建议
心法利器[130] | RAG效果调优经验
心法利器[131] | 盘点踩过大模型多轮对话的坑
前沿重器[48-54] 合集：四万字聊搜索系统
最近做了一些大模型系统的设计，让大模型在多个场景进行了应用，当然也发现了不少问题，今天给大家分享一些性能优化的经验。
注意，我这里专门提到了trick，而且是大模型系统，本文不会聊通过模型架构内部的性能优化，包括量化之类的方式来做，更多是通过系统调度、小模型替代之类的方式来做。
实时转非实时
内容聚合定制
大模型降级
大模型工作并行化
后记
实时转非实时
比较直接的大模型使用，基本都是在用户的请求进来后，就直接开始请求大模型来开始跑，这对高并发的场景而言压力可谓是巨大，尤其是一些几十ms的高耗时常见，毕竟一般的大模型正常跑能压缩到秒级就已经非常极限了，此时一个比较基本的思路是，把一些工作可以提前做提前做，而不要等到用户请求的时候再来做。
举一个例子，推荐系统场景，如果等用户去刷新页面，才从头开始去做用户embedding、所有的内容理解，显然并不现实，然而，如果把工作拆解，例如一些比较固定的用户理解工作，物料的理解工作，放到非实时完成，实时只需要把embedding拿出来做物料召回、排序啥的，此时在线的耗时就会大大降低，离线我们有充足的时间去做计算，这块的技术在大模型有之前就已经有比较完善的探索研究工作，毕竟推荐系统发展已经很久，在海量数据的压力下，离线高并发并行处理，类似的大数据工作早有经验，大模型相关的流程也同样可以放在其中。
这一个例子继续展开，在上一篇文章里（前沿重器[59] | 淘宝LLM落地电商推荐实践启示），对商品物料的理解，一些字段内容的结构化，这些内容对实时性要求并不是很高，单独安排并发和资源来跑即可，跑完再来上线。
此处值得注意的是，离线跑只代表可以暂缓，但并不代表可以无限期地等待，需要确认离线这个方式下，在一个周期内是否能跑完，例如某个大模型任务是T+1，即次日能出就行，那就要确认，目前的大模型资源下，跑一天的内容（例如大概1万条），能不能跑完，如果是不能跑完，则要考虑增加并行调度的资源，否则日复一日只能越来越多，堆积起来跑不完。
实时转非实时是一种整体功能的迁移，而下面说的这个方式则是强行把问题压缩后的提前计算。
内容聚合定制
我们可以通过把一些高频出现的内容聚合成比较简单通用的格式，提前通过大模型把问题给回复了，在线实时推理的是可以看是否有命中这些聚合的内容，此时能大程度地解决这些问题。
举个例子，在一些情况，对在线比较高频的问题，按照28法则，很大部分的请求都是集中在少数几个问题里，此时我们可以考虑把问题进行汇总整合，提前回答好，进行缓存来完成，例如一些高频的意图、问法，甚至是一些标签。
简单地说一条完整的思路吧，把在线的问法拿一大批下来，不去重直接向量化（例如用bge啥的）后聚类（粗暴地，不聚类也行，直接统计次数拿TOPN），经过一些人工的筛查后得到一批高频的问题，这些高频的问题提前跑，跑完存数据库里放到在线，在线在用到大模型之前，先做一次检索（可以是向量检索，也可以是k-v的精准匹配等，不过尽量简化会更好）直接就把结果查出来了，前后不到50ms就能轻松解决一个高频问题，快的甚至10ms以内就解决，结合在线可能80%的问题可能都集中在这类型的需求上，在线会有80%甚至更多的收益。
这个思路某种程度其实也很像早年类似搜索产品爱用的cache功能，对短期甚至激进地每天的搜索结果提前存入数据库，次日的所有query在进行正式搜索之前现在库里查查有没有类似的，这样能大幅降低搜素全流程的成本，类似百度应该有类似的功能，现在百度首条大模型的生成，应该也有用到这个功能，有些搜索词下的AI生成内容是直出的，大概率就是缓存得到的。
大模型降级
我们清楚，大模型能做到很多事，但不代表所有事都非大模型不可，在agent里我们可能可以很轻易地用大模型把一些流程给串起来完成，这种方式虽然对干活的人是很爽的，但是在用户的等待时间、大模型运转资源上，都无疑是非常难受的，因此在用大模型完成baseline后，有些不必要的任务可以降级为一些简单的模型甚至规则，用以提升响应效率，降低大模型成本。
继续举例，例如agent里有做转发的路由，或者有些要做语义理解、意图识别的工作，在早期数据比较匮乏的时候，用大模型确实是一个很快的选择，但在有一定时间和数据积累后，用小模型同样能得到非常好的效果，甚至在效果上还可能有提升，此时弄个小模型来解决这类型问题绝对非常有用。
大模型工作并行化
完成一个任务可能需要不止一次的大模型请求，但如果没有前后依赖，则可以在并发允许的前提下，尽量考虑并行处理，从而降低在线推理的时间。
举例，对一个RAG任务，可能用到大模型的有意图识别、实体抽取、大模型总结这3个步骤，意图识别和实体抽取如果两者互不依赖，则可以大胆地并行发请求以加快整个推理的速度，而最终的大模型总结这事，因为依赖检索结果而无法并行，那也没有办法，但时间上终究从3次请求转为2次，是有收益的。
后记
我们可能会因为很多原因而去使用大模型，最近因为热点的尝试、老板客户的要求、技术实践的便捷性、效果上限的突破等，但终究绕不开一个问题，系统肯定会朝着越来越好的方向去迭代，更好的体验、更低的成本、更快的速度、更强的产品力等等，我的各种文章里一直有强调，大模型不是唯一的方法，我们要打开思路去考虑更多的方式，别没了大模型就没招了。
而且，最近也发现有这样的迹象，大模型热点过去后，用户客户都会开始留意到大模型的缺点，对大模型这个事本身不那么追求，因为这些用户和客户最终目标是追求更好的体验，而非用没用大模型，他们只是知道用了大模型会效果好而已，所以我们总要留后招，能选择更好的方式解决更多的问题，甚至能把问题解决的更彻底，我们可以选择大模型，但不是只有大模型。
再者，我们也要突破思维定式，不是只有在线的推理才叫做“用大模型”，离线的挖掘、提前的计算、非实时的推理，都可以算是应用，在目前的热点下用户所追求的大模型，本质只是“知道大模型用的效果好”而已，与其说是对技术的认可，更多是品牌效应，毕竟扎心的，也不是任何场景、任何事、任何人用大模型效果就会突然变好。
