1. 七天假期七次心跳AI圈的节奏为什么停不下来国庆七天假普通人想着去哪儿玩、怎么避开人潮而AI圈的人打开手机发现每天都有新东西冒出来。不是某家发新模型就是某个开源项目突然冲上热榜再不然就是一篇技术报告把之前的认知推翻。你哪怕只是稍微关注一下这个领域都会有一种感觉这个圈子没有假期。我自己这几天基本是这么过的早上刷一遍信息流看看有没有新模型发布中午抽空跑一下刚下载的开源权重晚上再翻翻技术社区看看有没有人踩了坑、有没有新的微调方案出来。七天下来硬盘里多了几十个G的模型文件浏览器标签页开了三四十个笔记记了满满几页。说实话比上班还累但那种“每天都有新东西”的兴奋感确实让人停不下来。这篇文章不是要给你列一个“国庆AI新闻汇总”那种东西你随便搜一下就有。我想做的是另一件事把这七天里反复出现的几个核心方向拆开讲清楚它们背后的技术逻辑、实操门槛、以及如果你是一个开发者或者技术爱好者应该怎么跟上这个节奏。不管你是刚入门的新手还是已经在这个圈子里摸爬滚打了一段时间的老手都能从里面找到可以直接上手的东西。核心关键词其实就几个开源模型、多模态、推理优化、端侧部署、Agent框架。这几个词在这七天里几乎每天都会以不同的形式出现。下面我按自己的理解把它们一个一个拆开讲。2. 开源模型密集发布热闹背后的技术路线分化2.1 为什么大厂和社区都选在假期前后发模型这个现象其实不是第一次了。你如果留意过去一两年的节奏会发现一个规律重大版本发布往往集中在几个时间节点——长假前后、大型会议期间、以及竞争对手发布之后的一两周内。国庆这个节点尤其特殊因为国内团队有假期但海外团队不过这个节所以会出现一种“国内安静、海外热闹”的错位感。但今年不太一样。国内好几个团队也在假期期间放出了新东西有的是模型权重有的是技术报告有的是工具链更新。这说明什么说明竞争节奏已经不再跟着工作日走了。模型迭代的周期从过去的几个月压缩到了几周甚至几天谁也不敢停下来。从技术路线来看这七天里发布或更新的模型大致可以分成三类稠密模型继续卷参数效率不是单纯堆参数量而是在训练数据配比、注意力机制、激活函数上做文章目标是在同等参数下拿到更好的效果。混合专家模型MoE进一步普及通过激活部分参数来降低推理成本这个思路去年还比较新鲜现在已经成了中大型模型的主流选择之一。小参数模型专攻端侧1B到7B这个区间竞争非常激烈目标很明确——要在手机、平板、边缘设备上跑起来而且效果不能太差。这三条路线背后其实是同一个问题算力有限但需求无限。怎么在有限的资源下把效果做到最好是所有人都在解的题。2.2 稠密模型与MoE的选型逻辑到底该用哪个很多人在选模型的时候会纠结到底是用一个稠密的大模型还是用一个MoE架构的模型这个问题没有标准答案但有几个判断维度可以参考。先看推理成本。稠密模型每次推理都要激活全部参数所以显存占用和计算量是固定的。MoE模型虽然总参数量大但每次只激活一部分专家实际计算量可能只有总参数量的三分之一甚至更少。举个例子一个总参数70B的MoE模型如果每次激活8个专家中的2个那实际计算量大概相当于一个20B左右的稠密模型。这意味着在同等硬件条件下MoE可以让你跑一个“看起来更大”的模型。但MoE也不是没有代价。它的显存占用依然很高因为所有专家都需要加载到显存里只是计算时不全部用到而已。而且MoE的训练稳定性一直是个难题路由机制设计不好会导致专家负载不均衡有些专家被训练得很充分有些几乎没更新。这个问题在开源社区里讨论得很多目前比较常见的做法是加负载均衡损失或者用辅助路由来引导。再看微调难度。稠密模型的微调方案非常成熟LoRA、QLoRA、全量微调都有大量现成脚本可以参考。MoE模型的微调相对麻烦一些因为你要决定是只调路由、只调专家、还是全部调。不同的选择对最终效果影响很大而且社区里的最佳实践还在不断更新。我自己的经验是如果你只是想做推理部署MoE性价比很高如果你需要深度定制和微调稠密模型目前还是更稳妥的选择。当然这个判断会随着工具链的成熟而变化说不定再过几个月MoE的微调也会变得很简单。2.3 小参数模型的端侧部署实操要点小参数模型是这七天里另一个非常活跃的方向。1B、3B、7B这几个尺寸的模型几乎每天都有新版本或者新量化方案出来。为什么大家这么关注这个区间因为端侧部署的门槛正在快速降低。以前你想在本地跑一个模型至少得有张像样的显卡。现在不一样了通过量化技术一个7B的模型可以压缩到4GB左右在16GB内存的笔记本上就能跑起来。如果是1B到3B的模型量化之后甚至可以在手机上运行。但端侧部署有几个坑需要注意第一量化不是无损的。4bit量化虽然能把模型体积压到原来的四分之一但效果会有一定下降。下降多少取决于量化方法和模型本身。有些模型对量化很敏感4bit之后基本没法用有些模型则比较鲁棒4bit和16bit的差距很小。所以选模型的时候一定要看社区里的量化评测不要只看原始版本的跑分。第二推理框架的选择很关键。同样的模型用不同的推理框架跑速度可能差好几倍。目前比较主流的端侧推理框架有llama.cpp、MLC-LLM、ONNX Runtime等。llama.cpp的优点是支持格式多、社区活跃基本上新模型出来一两天就能支持MLC-LLM的优势是跨平台做得好一套代码可以在多种硬件上跑ONNX Runtime则在Windows生态里比较方便。第三内存带宽往往是瓶颈。端侧设备的内存带宽远不如服务器显卡所以模型推理速度很大程度上受限于内存读写速度而不是计算能力。这也是为什么小模型在端侧反而更有优势——参数少需要搬运的数据就少。实操建议如果你手头有一台16GB内存的笔记本想试试本地跑模型我的建议是从llama.cpp加一个4bit量化的7B模型开始。这个组合的兼容性最好社区文档也最全。跑通之后再尝试其他框架和更大的模型。3. 多模态能力下放从“能看”到“能用”还有多远3.1 多模态模型这七天的新变化多模态是这七天里另一个高频出现的词。几乎每个新发布的模型都会强调自己的视觉理解能力有的还加上了音频和视频。但如果你仔细看技术报告和实际评测会发现一个有意思的现象演示效果和实际可用性之间还有不小的差距。演示里模型可以准确地描述一张图片的内容、识别其中的文字、甚至回答关于图片的复杂问题。但你自己上手试的时候可能会发现它在某些场景下会犯一些很基础的错误比如数错人数、认错颜色、或者对空间关系的理解完全不对。这不是模型不行而是多模态任务的评测本身就很困难而且不同模型擅长的方向差异很大。这七天里我试了好几个多模态模型有一个明显的感受在文档理解和图表问答这个方向上进步非常明显。你给它一张包含表格的截图它能比较准确地提取出数据并回答相关问题。但在自然场景的细粒度识别上比如区分不同种类的鸟或者识别街景中的特定物体表现还是不太稳定。3.2 视觉编码器的选型与对齐策略多模态模型的核心组件其实就两个视觉编码器和语言模型。视觉编码器负责把图片变成语言模型能理解的向量语言模型负责根据这些向量生成回答。两者之间的对齐方式直接决定了模型的多模态能力上限。目前主流的视觉编码器有CLIP系列、SigLIP、以及一些专门训练的变体。CLIP的优点是通用性强、社区资源多SigLIP在训练效率和效果上有些优势最近被不少新模型采用。选哪个编码器主要看你的应用场景——如果是通用图文理解CLIP系列比较稳妥如果是需要处理高分辨率图片或者文档可能需要选支持更高输入分辨率的编码器。对齐策略方面常见的有两种投影层对齐和交叉注意力对齐。投影层对齐就是用一个简单的MLP把视觉向量映射到语言模型的维度空间实现简单、训练成本低但信息损失可能比较大。交叉注意力对齐则是在语言模型的每一层都插入对视觉特征的注意力效果通常更好但训练和推理成本都更高。我自己的体会是如果你只是想做图文问答或者图片描述投影层对齐基本够用如果你需要模型理解图片中的细节和空间关系交叉注意力对齐的优势会更明显。但后者对训练数据的要求也更高不是随便拿一批图文对就能训好的。3.3 多模态应用的落地场景与限制多模态模型能做什么这个问题看起来简单但实际落地的时候你会发现能做的事情很多能稳定做好的事情不多。目前比较靠谱的落地场景包括文档数字化把扫描件、截图、PDF里的文字和表格提取出来这个方向准确率已经比较高了。电商场景根据商品图片生成描述、分类、或者回答用户关于商品外观的问题。教育辅助识别题目中的图表、公式并给出解题思路。内容审核识别图片中的违规内容这个方向对准确率要求很高目前还需要人工复核。但也有一些场景目前还不太成熟比如医疗影像分析、自动驾驶的视觉感知、工业质检。这些场景对准确率和可靠性的要求极高多模态模型目前的水平还不足以独立承担。注意如果你打算把多模态模型用到生产环境一定要做充分的测试和兜底方案。不要因为演示效果好就认为它在你的场景里也能表现一样好。实际数据往往比演示数据复杂得多。4. 推理优化与成本控制每个团队都在算的账4.1 推理框架的选型对比这七天里好几个推理框架都发布了新版本。vLLM、TensorRT-LLM、SGLang、LMDeploy这几个主流框架各有更新竞争非常激烈。选哪个框架直接影响到你的推理成本和响应速度。框架优势适用场景注意事项vLLM吞吐量高、PagedAttention机制成熟高并发在线服务对自定义模型支持需要额外适配TensorRT-LLM延迟低、NVIDIA硬件优化好对延迟敏感的生产环境编译过程复杂、调试困难SGLang结构化生成支持好、RadixAttention有特色需要复杂输出格式的场景社区相对较新、文档还在完善LMDeploy国产硬件适配好、部署简单国内硬件环境功能丰富度略逊于前几个我自己的使用体验是如果你追求极致吞吐量vLLM目前是最稳妥的选择如果你对延迟要求极高而且用的是NVIDIA显卡TensorRT-LLM值得投入时间折腾如果你需要模型输出严格的JSON格式或者做复杂的推理链SGLang的RadixAttention确实能省不少事。4.2 量化、蒸馏、剪枝三种降本手段的实际效果推理成本是每个团队都要面对的问题。降低成本的常见手段有三种量化、蒸馏、剪枝。这三种方法各有优劣实际效果也因模型而异。量化是把模型参数从高精度比如FP16转换成低精度比如INT8或INT4。好处是模型体积和显存占用大幅下降推理速度通常也能提升。坏处是效果会有损失尤其是INT4量化在某些任务上下降比较明显。目前比较推荐的方案是AWQ和GPTQ这两种方法在4bit量化下效果保持得比较好。蒸馏是用一个大模型教师模型来指导一个小模型学生模型训练。好处是小模型的效果可以接近大模型而且推理成本低。坏处是蒸馏过程需要大量计算资源而且不是所有任务都适合蒸馏。我试过用70B的模型蒸馏7B的模型在通用对话任务上效果确实不错但在需要深度推理的任务上差距还是很明显。剪枝是去掉模型中不重要的参数或结构。好处是可以直接减少参数量坏处是剪枝后的模型往往需要重新训练才能恢复效果而且剪枝策略的设计很依赖经验。结构化剪枝比非结构化剪枝更容易获得实际加速但效果损失也可能更大。实操心得这三种方法可以组合使用。比如先剪枝再量化或者先蒸馏再量化。但组合使用的时候要小心每一步的损失会累积。我的建议是每次只做一种优化测好效果之后再考虑下一步。4.3 批处理与缓存策略的调优经验除了模型本身的优化推理服务的批处理和缓存策略对成本的影响也很大。这部分往往被忽视但实际调优之后效果非常明显。批处理的核心思想是把多个请求合并成一个批次一起推理从而提高GPU利用率。但批次不是越大越好因为批次太大会导致单个请求的延迟增加。你需要根据你的服务等级目标来找到平衡点。一般来说在线服务适合用较小的批次加动态批处理离线任务可以用大批次来追求吞吐量。缓存策略方面最常见的是KV缓存。把已经计算过的键值对缓存起来避免重复计算。这个技术已经很成熟了但怎么管理缓存、什么时候淘汰、缓存多大合适这些问题需要根据实际流量模式来调。我见过一些团队把KV缓存设得太大结果显存不够用反而导致请求排队也见过设得太小缓存命中率很低等于白做。还有一个容易被忽视的点是前缀缓存。如果你的应用场景里有很多请求共享相同的前缀比如相同的系统提示词把前缀的KV缓存复用起来可以大幅降低计算量。vLLM和SGLang都支持这个功能实际用下来能省不少资源。5. Agent框架的演进从玩具到工具的跨越5.1 这七天里Agent方向的新动向Agent这个词在过去一年里被提了太多次以至于很多人已经有点疲劳了。但这七天里确实有几个值得关注的进展。一个是工具调用格式的标准化另一个是多Agent协作框架的成熟。工具调用方面之前每个模型都有自己的格式有的用JSON有的用特定标记有的靠提示词硬编。这导致你换一个模型就要重写一遍工具调用的代码。现在社区在推动一种更统一的格式让模型输出的工具调用请求可以被不同框架直接解析。这个方向如果做成了对Agent的开发和部署效率会有很大提升。多Agent协作方面之前更多是演示性质的东西——几个Agent互相聊天看起来热闹但实际能做的事情有限。现在有一些框架开始认真解决任务分解、角色分配、结果验证这些核心问题。虽然离生产级还有距离但至少方向是对的。5.2 工具调用与函数注册的实操细节如果你要自己搭一个Agent工具调用是最核心的部分。我把自己踩过的坑总结一下第一工具描述要写得非常清楚。模型是根据你的描述来决定调用哪个工具的。如果描述模糊模型就会乱调。比如你有一个查天气的工具描述里要写清楚输入是城市名称输出是温度和天气状况支持哪些城市不支持哪些。写得越细模型调用得越准。第二参数校验不能省。模型输出的参数不一定符合你的预期。它可能把数字写成字符串可能漏掉必填参数可能传一个你根本没定义的值。所以在工具执行之前一定要做参数校验不合法就返回错误信息让模型重新生成。第三错误处理要友好。工具执行失败的时候不要直接抛一个堆栈信息给模型。要把错误转换成模型能理解的自然语言比如“城市名称不正确请提供有效的城市名”。这样模型才有机会纠正。第四工具数量不要太多。我试过给模型注册二十多个工具结果它经常选错。后来精简到五六个核心工具准确率明显提升。如果确实需要很多工具可以考虑分组或者分层让模型先选类别再选具体工具。5.3 多Agent协作的常见模式与避坑指南多Agent协作听起来很美好但实际做起来坑很多。目前比较常见的模式有三种流水线模式Agent A的输出作为Agent B的输入依次传递。这种模式最简单适合任务可以清晰分解的场景。辩论模式多个Agent对同一个问题给出不同答案然后通过讨论或投票来选出最佳答案。这种模式适合需要多角度分析的场景。主管模式一个主管Agent负责分解任务、分配给其他Agent、然后汇总结果。这种模式适合复杂任务但主管Agent的能力往往是瓶颈。我踩过的最大坑是Agent之间的通信开销。如果每个Agent都要把完整的上下文传给下一个AgentToken消耗会非常惊人。后来我改成只传关键信息比如任务描述、中间结果、约束条件Token消耗降了一半以上。另一个坑是死循环。两个Agent互相等待对方输出或者一个Agent反复调用同一个工具这些情况都需要有超时机制和最大轮次限制来兜底。实操建议如果你刚开始做多Agent建议从流水线模式开始两个Agent就够了。跑通之后再考虑增加Agent数量或者换更复杂的协作模式。一上来就搞五六个Agent互相协作调试起来会让你怀疑人生。6. 开发者该怎么跟上这个节奏6.1 信息筛选每天看什么、不看什么AI圈的信息量太大了如果什么都看一天下来什么也做不了。我的做法是分层筛选必看层主流开源模型的发布公告和技术报告。这些是基础不了解的话后面的事情都没法做。选看层推理框架的更新日志、量化方案的评测对比。这些跟实际部署相关需要的时候再深入。扫一眼层各种Demo和演示视频。看看思路就好不用花太多时间。不看层标题党、没有技术细节的“震惊体”、纯营销内容。另外技术报告要看原始版本不要只看二手解读。二手解读往往省略了关键细节有时候还会理解错。当然原始报告可能很长我的做法是先看摘要和图表觉得有价值再细读。6.2 动手优先级先跑通再优化很多人学AI的方式是先把理论搞懂再动手但我的经验是反过来更有效。先跑通一个最小的例子看到实际效果然后再去理解背后的原理。这样学习曲线更平缓也更容易保持动力。具体来说我建议的动手顺序是先跑一个量化后的小模型用llama.cpp或者类似工具感受一下本地推理的流程。再试一个多模态模型看看图片理解的实际效果和局限。然后搭一个简单的Agent注册两三个工具体验一下工具调用的流程。最后再考虑优化比如换推理框架、调批处理参数、试不同的量化方案。这个顺序的好处是每一步都有可见的成果不会因为一开始就陷入细节而放弃。6.3 长期跟进的几个关键指标如果你想长期跟进这个领域有几个指标值得持续关注模型效果与参数量的比值这个比值越高说明模型的训练效率越好。关注这个指标可以帮助你判断哪些技术路线更有前景。推理成本的变化趋势每百万Token的推理成本在过去一年里下降了一个数量级这个趋势还会继续。关注这个指标可以帮助你判断什么时候可以把某个应用从实验推向生产。端侧设备的推理能力手机和笔记本的NPU算力每年都在提升这个指标决定了多少应用可以完全离线运行。开源社区的活跃度一个项目的GitHub star数、issue响应速度、PR合并频率这些比任何评测都更能反映它的实际可用性。我自己每天花大概半小时到一小时在这些信息上剩下的时间用来动手实践。这个比例我觉得比较合理——信息是输入动手是输出两者缺一不可但输出更重要。最后分享一个我自己的小习惯每次试完一个新模型或者新工具我都会在笔记里记三件事——它解决了什么问题、它在什么场景下不好用、我下次用的时候要注意什么。这个习惯坚持了半年多现在翻回去看很多当时觉得复杂的东西现在已经很清晰了而当时忽略的一些细节反而成了后来踩坑的根源。这个领域变化太快但有些底层的经验和判断是可以积累的。
1. 七天假期七次心跳AI圈的节奏为什么停不下来国庆七天假普通人想着去哪儿玩、怎么避开人潮而AI圈的人打开手机发现每天都有新东西冒出来。不是某家发新模型就是某个开源项目突然冲上热榜再不然就是一篇技术报告把之前的认知推翻。你哪怕只是稍微关注一下这个领域都会有一种感觉这个圈子没有假期。我自己这几天基本是这么过的早上刷一遍信息流看看有没有新模型发布中午抽空跑一下刚下载的开源权重晚上再翻翻技术社区看看有没有人踩了坑、有没有新的微调方案出来。七天下来硬盘里多了几十个G的模型文件浏览器标签页开了三四十个笔记记了满满几页。说实话比上班还累但那种“每天都有新东西”的兴奋感确实让人停不下来。这篇文章不是要给你列一个“国庆AI新闻汇总”那种东西你随便搜一下就有。我想做的是另一件事把这七天里反复出现的几个核心方向拆开讲清楚它们背后的技术逻辑、实操门槛、以及如果你是一个开发者或者技术爱好者应该怎么跟上这个节奏。不管你是刚入门的新手还是已经在这个圈子里摸爬滚打了一段时间的老手都能从里面找到可以直接上手的东西。核心关键词其实就几个开源模型、多模态、推理优化、端侧部署、Agent框架。这几个词在这七天里几乎每天都会以不同的形式出现。下面我按自己的理解把它们一个一个拆开讲。2. 开源模型密集发布热闹背后的技术路线分化2.1 为什么大厂和社区都选在假期前后发模型这个现象其实不是第一次了。你如果留意过去一两年的节奏会发现一个规律重大版本发布往往集中在几个时间节点——长假前后、大型会议期间、以及竞争对手发布之后的一两周内。国庆这个节点尤其特殊因为国内团队有假期但海外团队不过这个节所以会出现一种“国内安静、海外热闹”的错位感。但今年不太一样。国内好几个团队也在假期期间放出了新东西有的是模型权重有的是技术报告有的是工具链更新。这说明什么说明竞争节奏已经不再跟着工作日走了。模型迭代的周期从过去的几个月压缩到了几周甚至几天谁也不敢停下来。从技术路线来看这七天里发布或更新的模型大致可以分成三类稠密模型继续卷参数效率不是单纯堆参数量而是在训练数据配比、注意力机制、激活函数上做文章目标是在同等参数下拿到更好的效果。混合专家模型MoE进一步普及通过激活部分参数来降低推理成本这个思路去年还比较新鲜现在已经成了中大型模型的主流选择之一。小参数模型专攻端侧1B到7B这个区间竞争非常激烈目标很明确——要在手机、平板、边缘设备上跑起来而且效果不能太差。这三条路线背后其实是同一个问题算力有限但需求无限。怎么在有限的资源下把效果做到最好是所有人都在解的题。2.2 稠密模型与MoE的选型逻辑到底该用哪个很多人在选模型的时候会纠结到底是用一个稠密的大模型还是用一个MoE架构的模型这个问题没有标准答案但有几个判断维度可以参考。先看推理成本。稠密模型每次推理都要激活全部参数所以显存占用和计算量是固定的。MoE模型虽然总参数量大但每次只激活一部分专家实际计算量可能只有总参数量的三分之一甚至更少。举个例子一个总参数70B的MoE模型如果每次激活8个专家中的2个那实际计算量大概相当于一个20B左右的稠密模型。这意味着在同等硬件条件下MoE可以让你跑一个“看起来更大”的模型。但MoE也不是没有代价。它的显存占用依然很高因为所有专家都需要加载到显存里只是计算时不全部用到而已。而且MoE的训练稳定性一直是个难题路由机制设计不好会导致专家负载不均衡有些专家被训练得很充分有些几乎没更新。这个问题在开源社区里讨论得很多目前比较常见的做法是加负载均衡损失或者用辅助路由来引导。再看微调难度。稠密模型的微调方案非常成熟LoRA、QLoRA、全量微调都有大量现成脚本可以参考。MoE模型的微调相对麻烦一些因为你要决定是只调路由、只调专家、还是全部调。不同的选择对最终效果影响很大而且社区里的最佳实践还在不断更新。我自己的经验是如果你只是想做推理部署MoE性价比很高如果你需要深度定制和微调稠密模型目前还是更稳妥的选择。当然这个判断会随着工具链的成熟而变化说不定再过几个月MoE的微调也会变得很简单。2.3 小参数模型的端侧部署实操要点小参数模型是这七天里另一个非常活跃的方向。1B、3B、7B这几个尺寸的模型几乎每天都有新版本或者新量化方案出来。为什么大家这么关注这个区间因为端侧部署的门槛正在快速降低。以前你想在本地跑一个模型至少得有张像样的显卡。现在不一样了通过量化技术一个7B的模型可以压缩到4GB左右在16GB内存的笔记本上就能跑起来。如果是1B到3B的模型量化之后甚至可以在手机上运行。但端侧部署有几个坑需要注意第一量化不是无损的。4bit量化虽然能把模型体积压到原来的四分之一但效果会有一定下降。下降多少取决于量化方法和模型本身。有些模型对量化很敏感4bit之后基本没法用有些模型则比较鲁棒4bit和16bit的差距很小。所以选模型的时候一定要看社区里的量化评测不要只看原始版本的跑分。第二推理框架的选择很关键。同样的模型用不同的推理框架跑速度可能差好几倍。目前比较主流的端侧推理框架有llama.cpp、MLC-LLM、ONNX Runtime等。llama.cpp的优点是支持格式多、社区活跃基本上新模型出来一两天就能支持MLC-LLM的优势是跨平台做得好一套代码可以在多种硬件上跑ONNX Runtime则在Windows生态里比较方便。第三内存带宽往往是瓶颈。端侧设备的内存带宽远不如服务器显卡所以模型推理速度很大程度上受限于内存读写速度而不是计算能力。这也是为什么小模型在端侧反而更有优势——参数少需要搬运的数据就少。实操建议如果你手头有一台16GB内存的笔记本想试试本地跑模型我的建议是从llama.cpp加一个4bit量化的7B模型开始。这个组合的兼容性最好社区文档也最全。跑通之后再尝试其他框架和更大的模型。3. 多模态能力下放从“能看”到“能用”还有多远3.1 多模态模型这七天的新变化多模态是这七天里另一个高频出现的词。几乎每个新发布的模型都会强调自己的视觉理解能力有的还加上了音频和视频。但如果你仔细看技术报告和实际评测会发现一个有意思的现象演示效果和实际可用性之间还有不小的差距。演示里模型可以准确地描述一张图片的内容、识别其中的文字、甚至回答关于图片的复杂问题。但你自己上手试的时候可能会发现它在某些场景下会犯一些很基础的错误比如数错人数、认错颜色、或者对空间关系的理解完全不对。这不是模型不行而是多模态任务的评测本身就很困难而且不同模型擅长的方向差异很大。这七天里我试了好几个多模态模型有一个明显的感受在文档理解和图表问答这个方向上进步非常明显。你给它一张包含表格的截图它能比较准确地提取出数据并回答相关问题。但在自然场景的细粒度识别上比如区分不同种类的鸟或者识别街景中的特定物体表现还是不太稳定。3.2 视觉编码器的选型与对齐策略多模态模型的核心组件其实就两个视觉编码器和语言模型。视觉编码器负责把图片变成语言模型能理解的向量语言模型负责根据这些向量生成回答。两者之间的对齐方式直接决定了模型的多模态能力上限。目前主流的视觉编码器有CLIP系列、SigLIP、以及一些专门训练的变体。CLIP的优点是通用性强、社区资源多SigLIP在训练效率和效果上有些优势最近被不少新模型采用。选哪个编码器主要看你的应用场景——如果是通用图文理解CLIP系列比较稳妥如果是需要处理高分辨率图片或者文档可能需要选支持更高输入分辨率的编码器。对齐策略方面常见的有两种投影层对齐和交叉注意力对齐。投影层对齐就是用一个简单的MLP把视觉向量映射到语言模型的维度空间实现简单、训练成本低但信息损失可能比较大。交叉注意力对齐则是在语言模型的每一层都插入对视觉特征的注意力效果通常更好但训练和推理成本都更高。我自己的体会是如果你只是想做图文问答或者图片描述投影层对齐基本够用如果你需要模型理解图片中的细节和空间关系交叉注意力对齐的优势会更明显。但后者对训练数据的要求也更高不是随便拿一批图文对就能训好的。3.3 多模态应用的落地场景与限制多模态模型能做什么这个问题看起来简单但实际落地的时候你会发现能做的事情很多能稳定做好的事情不多。目前比较靠谱的落地场景包括文档数字化把扫描件、截图、PDF里的文字和表格提取出来这个方向准确率已经比较高了。电商场景根据商品图片生成描述、分类、或者回答用户关于商品外观的问题。教育辅助识别题目中的图表、公式并给出解题思路。内容审核识别图片中的违规内容这个方向对准确率要求很高目前还需要人工复核。但也有一些场景目前还不太成熟比如医疗影像分析、自动驾驶的视觉感知、工业质检。这些场景对准确率和可靠性的要求极高多模态模型目前的水平还不足以独立承担。注意如果你打算把多模态模型用到生产环境一定要做充分的测试和兜底方案。不要因为演示效果好就认为它在你的场景里也能表现一样好。实际数据往往比演示数据复杂得多。4. 推理优化与成本控制每个团队都在算的账4.1 推理框架的选型对比这七天里好几个推理框架都发布了新版本。vLLM、TensorRT-LLM、SGLang、LMDeploy这几个主流框架各有更新竞争非常激烈。选哪个框架直接影响到你的推理成本和响应速度。框架优势适用场景注意事项vLLM吞吐量高、PagedAttention机制成熟高并发在线服务对自定义模型支持需要额外适配TensorRT-LLM延迟低、NVIDIA硬件优化好对延迟敏感的生产环境编译过程复杂、调试困难SGLang结构化生成支持好、RadixAttention有特色需要复杂输出格式的场景社区相对较新、文档还在完善LMDeploy国产硬件适配好、部署简单国内硬件环境功能丰富度略逊于前几个我自己的使用体验是如果你追求极致吞吐量vLLM目前是最稳妥的选择如果你对延迟要求极高而且用的是NVIDIA显卡TensorRT-LLM值得投入时间折腾如果你需要模型输出严格的JSON格式或者做复杂的推理链SGLang的RadixAttention确实能省不少事。4.2 量化、蒸馏、剪枝三种降本手段的实际效果推理成本是每个团队都要面对的问题。降低成本的常见手段有三种量化、蒸馏、剪枝。这三种方法各有优劣实际效果也因模型而异。量化是把模型参数从高精度比如FP16转换成低精度比如INT8或INT4。好处是模型体积和显存占用大幅下降推理速度通常也能提升。坏处是效果会有损失尤其是INT4量化在某些任务上下降比较明显。目前比较推荐的方案是AWQ和GPTQ这两种方法在4bit量化下效果保持得比较好。蒸馏是用一个大模型教师模型来指导一个小模型学生模型训练。好处是小模型的效果可以接近大模型而且推理成本低。坏处是蒸馏过程需要大量计算资源而且不是所有任务都适合蒸馏。我试过用70B的模型蒸馏7B的模型在通用对话任务上效果确实不错但在需要深度推理的任务上差距还是很明显。剪枝是去掉模型中不重要的参数或结构。好处是可以直接减少参数量坏处是剪枝后的模型往往需要重新训练才能恢复效果而且剪枝策略的设计很依赖经验。结构化剪枝比非结构化剪枝更容易获得实际加速但效果损失也可能更大。实操心得这三种方法可以组合使用。比如先剪枝再量化或者先蒸馏再量化。但组合使用的时候要小心每一步的损失会累积。我的建议是每次只做一种优化测好效果之后再考虑下一步。4.3 批处理与缓存策略的调优经验除了模型本身的优化推理服务的批处理和缓存策略对成本的影响也很大。这部分往往被忽视但实际调优之后效果非常明显。批处理的核心思想是把多个请求合并成一个批次一起推理从而提高GPU利用率。但批次不是越大越好因为批次太大会导致单个请求的延迟增加。你需要根据你的服务等级目标来找到平衡点。一般来说在线服务适合用较小的批次加动态批处理离线任务可以用大批次来追求吞吐量。缓存策略方面最常见的是KV缓存。把已经计算过的键值对缓存起来避免重复计算。这个技术已经很成熟了但怎么管理缓存、什么时候淘汰、缓存多大合适这些问题需要根据实际流量模式来调。我见过一些团队把KV缓存设得太大结果显存不够用反而导致请求排队也见过设得太小缓存命中率很低等于白做。还有一个容易被忽视的点是前缀缓存。如果你的应用场景里有很多请求共享相同的前缀比如相同的系统提示词把前缀的KV缓存复用起来可以大幅降低计算量。vLLM和SGLang都支持这个功能实际用下来能省不少资源。5. Agent框架的演进从玩具到工具的跨越5.1 这七天里Agent方向的新动向Agent这个词在过去一年里被提了太多次以至于很多人已经有点疲劳了。但这七天里确实有几个值得关注的进展。一个是工具调用格式的标准化另一个是多Agent协作框架的成熟。工具调用方面之前每个模型都有自己的格式有的用JSON有的用特定标记有的靠提示词硬编。这导致你换一个模型就要重写一遍工具调用的代码。现在社区在推动一种更统一的格式让模型输出的工具调用请求可以被不同框架直接解析。这个方向如果做成了对Agent的开发和部署效率会有很大提升。多Agent协作方面之前更多是演示性质的东西——几个Agent互相聊天看起来热闹但实际能做的事情有限。现在有一些框架开始认真解决任务分解、角色分配、结果验证这些核心问题。虽然离生产级还有距离但至少方向是对的。5.2 工具调用与函数注册的实操细节如果你要自己搭一个Agent工具调用是最核心的部分。我把自己踩过的坑总结一下第一工具描述要写得非常清楚。模型是根据你的描述来决定调用哪个工具的。如果描述模糊模型就会乱调。比如你有一个查天气的工具描述里要写清楚输入是城市名称输出是温度和天气状况支持哪些城市不支持哪些。写得越细模型调用得越准。第二参数校验不能省。模型输出的参数不一定符合你的预期。它可能把数字写成字符串可能漏掉必填参数可能传一个你根本没定义的值。所以在工具执行之前一定要做参数校验不合法就返回错误信息让模型重新生成。第三错误处理要友好。工具执行失败的时候不要直接抛一个堆栈信息给模型。要把错误转换成模型能理解的自然语言比如“城市名称不正确请提供有效的城市名”。这样模型才有机会纠正。第四工具数量不要太多。我试过给模型注册二十多个工具结果它经常选错。后来精简到五六个核心工具准确率明显提升。如果确实需要很多工具可以考虑分组或者分层让模型先选类别再选具体工具。5.3 多Agent协作的常见模式与避坑指南多Agent协作听起来很美好但实际做起来坑很多。目前比较常见的模式有三种流水线模式Agent A的输出作为Agent B的输入依次传递。这种模式最简单适合任务可以清晰分解的场景。辩论模式多个Agent对同一个问题给出不同答案然后通过讨论或投票来选出最佳答案。这种模式适合需要多角度分析的场景。主管模式一个主管Agent负责分解任务、分配给其他Agent、然后汇总结果。这种模式适合复杂任务但主管Agent的能力往往是瓶颈。我踩过的最大坑是Agent之间的通信开销。如果每个Agent都要把完整的上下文传给下一个AgentToken消耗会非常惊人。后来我改成只传关键信息比如任务描述、中间结果、约束条件Token消耗降了一半以上。另一个坑是死循环。两个Agent互相等待对方输出或者一个Agent反复调用同一个工具这些情况都需要有超时机制和最大轮次限制来兜底。实操建议如果你刚开始做多Agent建议从流水线模式开始两个Agent就够了。跑通之后再考虑增加Agent数量或者换更复杂的协作模式。一上来就搞五六个Agent互相协作调试起来会让你怀疑人生。6. 开发者该怎么跟上这个节奏6.1 信息筛选每天看什么、不看什么AI圈的信息量太大了如果什么都看一天下来什么也做不了。我的做法是分层筛选必看层主流开源模型的发布公告和技术报告。这些是基础不了解的话后面的事情都没法做。选看层推理框架的更新日志、量化方案的评测对比。这些跟实际部署相关需要的时候再深入。扫一眼层各种Demo和演示视频。看看思路就好不用花太多时间。不看层标题党、没有技术细节的“震惊体”、纯营销内容。另外技术报告要看原始版本不要只看二手解读。二手解读往往省略了关键细节有时候还会理解错。当然原始报告可能很长我的做法是先看摘要和图表觉得有价值再细读。6.2 动手优先级先跑通再优化很多人学AI的方式是先把理论搞懂再动手但我的经验是反过来更有效。先跑通一个最小的例子看到实际效果然后再去理解背后的原理。这样学习曲线更平缓也更容易保持动力。具体来说我建议的动手顺序是先跑一个量化后的小模型用llama.cpp或者类似工具感受一下本地推理的流程。再试一个多模态模型看看图片理解的实际效果和局限。然后搭一个简单的Agent注册两三个工具体验一下工具调用的流程。最后再考虑优化比如换推理框架、调批处理参数、试不同的量化方案。这个顺序的好处是每一步都有可见的成果不会因为一开始就陷入细节而放弃。6.3 长期跟进的几个关键指标如果你想长期跟进这个领域有几个指标值得持续关注模型效果与参数量的比值这个比值越高说明模型的训练效率越好。关注这个指标可以帮助你判断哪些技术路线更有前景。推理成本的变化趋势每百万Token的推理成本在过去一年里下降了一个数量级这个趋势还会继续。关注这个指标可以帮助你判断什么时候可以把某个应用从实验推向生产。端侧设备的推理能力手机和笔记本的NPU算力每年都在提升这个指标决定了多少应用可以完全离线运行。开源社区的活跃度一个项目的GitHub star数、issue响应速度、PR合并频率这些比任何评测都更能反映它的实际可用性。我自己每天花大概半小时到一小时在这些信息上剩下的时间用来动手实践。这个比例我觉得比较合理——信息是输入动手是输出两者缺一不可但输出更重要。最后分享一个我自己的小习惯每次试完一个新模型或者新工具我都会在笔记里记三件事——它解决了什么问题、它在什么场景下不好用、我下次用的时候要注意什么。这个习惯坚持了半年多现在翻回去看很多当时觉得复杂的东西现在已经很清晰了而当时忽略的一些细节反而成了后来踩坑的根源。这个领域变化太快但有些底层的经验和判断是可以积累的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
