写在前面的碎碎念

最近是刚换了工作，在这份工作还没进入状态之前，也正好把这一整年的内容给回顾一下，顺便从当前工作(主要是大模型的应用方面(包含大语言模型和多模态模型))的视角来看对26年要做的一些事情做点方向性的讨论。

结合当前的经济情况，当前的学术界和工业界，大概率会更加分化，正如一些人所讲述的那样，应用型研究要更与工业界的落地结合，但这一类工作本身并不需要有创新(业界主要看效果反馈)，所以也可能很难去发表论文；另一方面，学术界的研究受限于资源，场景和数据，所以应该更关注理论部分，虽然学术界本身有论文评价那一套体系，甚至能够自己旋转起来，但要想真的做出点内容，理论这一块应该是少不了的。

对于业界的工作，其评价体系早已和业务指标相关，虽然最近也看到一些新闻说是，需要由企业承担一定的研究责任，但感觉至少短期内，由于惯性的存在，应该还是保持类似的业务指标为主的存在，如何工程化，如何在一些特定领域上的指标有提升，则成为了业界需要关心的问题。

不过对于个人博客的内容来说，下一年关于业务的内容大概率不是主线内容，26年大概率主要还是针对当前的技术了解，熟悉(以各种 mini-,nano-,tiny- 为主)，跟踪新的技术，也同时花点时间去回过头去看看一些比较扎实的工作，顺带的再去做点可能做的补充性工作。

对25年所做的工作总结

从整体来看，25年(包括24年后半段)算是半个混乱的状态，但这个混乱的状态并不是由我所引起的，而是企业转型中所必然引发的混乱。或者说，企业在这之前本身算是一个稳定的状态，没有遇到太多的混乱的状态，所以也很难从中抓住什么有用的东西，毕竟很多东西一直发生变化，而如果只是盯着变化，把太多的资源和时间都在这个变化之中而没有找到那条主线，很容易对自身产生怀疑，这些对于时间，资源，方法，技术，人员配置要求都太高，甚至似乎陷入某种死循环：

没有从变化中抓住重要的内容，就没办法往下走；而没办法往下走，就没办法跟上这些变化。

从而不断地往后退，退到当前人员和资源所能够尝试做点内容的位置上。而对于之前的组织，其实一直一个主要目标是

主要目标

如何利用当前的先进技术(大模型)优化当前的某些流程。

其实这个目标是可以解读出很多内容的：

将当前先进技术还是看做一种优化内部流程的工具，而不是拓宽或者稳定业务。
企业的重心也不在于拓宽业务，而在于减少成本。

所以在这个背景下，那时候的主要工作方向，就是朝着如何优化一些流程逻辑出发。只不过，在真实具体往下优化的过程中，一方面优化这些流程本身就是重新以这一套思路再走一遍已经做过的事，但实际上这一块稍微是有一个悖论:

流程优化的成本悖论

流程优化，本质上是降低流程的成本(一般展示形式是以更高效形式执行该流程)，但是要优化已有的流程，仍然是需要成本的，甚至这种成本在初期投入会比执行当前流程的成本更大。

为什么？在这里，我们可以用一个数学建模来简单理解这个问题。首先我们有搜索空间的假设，同时假设这里有一个任务，在做这个任务之前，我们并不知道这个搜索空间和可能性有什么，所以在前期，就是有什么就做什么，所以能够获得对应的做法和对应的效果。

但现在，我们相当于又要重新去做这个问题，所以这个成本至少是：新的探索空间成本，试错成本，新一批人力成员的成本等等。

那么在这样的背景下，主要做的事情自然就是两方面的事情：熟悉新技术和尝试利用新技术去“优化流程”，对于前者来说，大家都比较有热情，但是对于后者来说，大家全都小白，没有动力，这一点还是挺有意思的。在这个过程中，对于新的这一块，主要是模型部署与推理优化，而对于优化流程，则是软件工程。

模型部署与推理优化

为什么要做这一块的工作

这实际上是一个很常见的需求，从实际应用来看，模型与外界交互的方式，在当前互联网技术背景下，主要还是通过服务(servers)来进行交互的，即知道某个ip和端口，通过get，post等方式进行信息传递交互。由于不知道用户什么时候对该ip和端口进行请求，所以该服务自然需要时时刻刻运行。

在这里会有一些成本和具体实践上的考量。比如，前期为了快速验证功能可行性，我们可以快速实现一个最简单的版本去确定是这个功能以后，就能够上线了。而随着后续发展，用户访问请求越来越多，则开始考虑对相关服务进行优化。

所以一般情况下，前期注重功能，而后期注重性能。那么对应当前的流程自然就是，前期为模型部署，后期为模型优化(包括效果优化和性能优化)。

模型部署

模型部署，顾名思义，就是将模型部署成一个对应的服务。这在之前的也稍微聊过，在工作中，其主要的流程就是：

确定模型，通过pytorch运行该模型，通过测试案例确定功能。
服务开发，这主要有两部分，一部分是服务启动(主要是模型启动)，一部分是模型运行(负责接受用户请求，处理过程和返回处理结果)。

而我这一年的工作，实际上大部分都是这一块的内容。这是因为，对于这一块，大家几乎都没有人知道什么情况，为什么？因为整个团队对于互联网这一块的技术几乎是比较欠缺(这一块又可以开另一个话题了)。

所以，我今年的工作实际上分为两块：

模型部署环境建设：包括容器化，资源调度，开发流程固定等。
模型功能开发部署，包括各种模型的部署，主要以AIGC模型为主。

前者是因为，多个模型背后的环境大部分相同，但有少部分类似，所以类似Docker这种容器化技术就出现了，可以在一些基础镜像上构建该模型的运行环境；而多个模型之间资源会争夺，以及多个设备之间是否能够协同调度等，当前可以采用k8s来进行构建。最后就是，不同的模型，由于模型参数比较大，基本形式正如上述类似，服务启动=模型启动，服务运行=模型接收请求，处理，返回。

所以在这个过程中，为了了解模型部署，还熟悉了Torchserve, TritonServer等模型推理框架(2020年左右还是比较热门的，这里还有一个小插曲，在我以Torchserve为基础框架开发的时候，Torchserve已经停止维护了，为此我还稍微调研了一下推理框架的小插曲，能够看到在发展中，定位什么也是很重要的。)，在这个基础上扩展到ML System，甚至稍微到了当前比较热门的AI Intra领域。

(推理)计算优化

本来想直接叫做推理优化的，但我认为，这一块针对训练也是一样的思路，所以在这里就以(推理)时就按优化作为这个子标题。

事实上，如果从服务功能开发的视角来看，模型部署完毕以后，实际上任务就已经结束了。但对于深度学习视角，这一块又和传统的服务不一样，是因为深度学习模型是一种“计算密集型”的任务，特别是现在大模型的背景下，模型运行是需要调用硬件进行大量计算，所以哪怕只是单纯运行一次任务，也需要比较多的时间进行计算，但是从服务的视角来看，用户感受是不太友好的，因为用户总是倾向，更快更好地服务请求，而时间越久，则越容易失去兴趣。

所以这和传统的服务还不一样的是，深度学习模型哪怕针对一个用户进行优化，也是有价值的，因为这是能够降低访问延迟，减少用户等待，提升用户交互流畅感。

为什么能够做这件事呢？

这是因为大部分的模型的运行后端主要是pytorch(huggingface的后端也有pytorch)，pytorch本身也是用python做解释器，这就会产生大量地计算冗余。举个最简单的例子，在python中，不同的网络层可以被看做是很多个函数计算有：

$\begin{equation} Y_{\text{output}} = F_1 (F_2...F_N(X_{\text{input}})). \end{equation}$

它需要依次计算每一层函数，将得到的结果传入下一层。但如果这些函数能够被复合(有常量合并，算式合并等)成一个函数，则该式子就可以重新写成：

$\begin{equation} Y_{\text{output}} =F(X_{\text{input}}). \end{equation}$

中比如(常量折叠)和可以合并成，其中 $，$ , 中间就减少了很多冗余计算。

上述是针对本身的计算进行优化，这一块是关于模型计算的优化，大部分也叫做计算图，一些计算操作则叫做算子。另一方面python的运行效率本身低，从本质上来说就是硬件的利用率低，所以，我们还可以针对硬件也需要去优化，也就是编译(compile)。在pytorch的2.0版本以后，官方甚至为了加速训练和部署，自己也出了一套编译函数torch.comile，当然这些内容也不是横空出世，而是在1.0版本就有类似的工作，只不过在2.0被重视和重构，以及变得更好用了。

在这里，由于当前主流的模型部署都在英伟达显卡上，所以我们经常会听到类似CUDA，算子这些名词，其实就可以理解是在CUDA上计算的时候，对当前模型不断地优化的一些操作。

而在当今的模型参数巨大的情况下，不只是单张卡上的优化，多张卡上也需要优化，包括多卡、多机之间的通信，存储上的访问，等等，这些当前也逐渐被形成一种岗位——AI基建(AI Infrastructure, AI Infra)。

这一块实际上，我感觉既可以看做是之前ML System(这一块是专门关心模型如何构建训练数据，如何从这些数据下训练出来，以及如何合理地部署在上体上)在大模型下受到传统基建，HPC和硬件发展的影响上逐渐诞生出来的一种岗位。后面有机会也会多去介绍这一块的内容，至少在大模型下，这一块的内容应该是很难避开的。

传统软件开发(软件工程)

而这一部分，实际上本身我并不是特别想做，做这一块，主要是感受，在该组织中，由于没有计算机基础建设，所以很多内容需要反复重新做，而这个桥梁目前还是软件工程。而由于之前都没有经验，所以这一块基本上是能够推就推，工期和效果都非常的紧张，导致一个人要做的内容特别地多，特别地夸张。

当前我所干的相关的内容，也算是稍微感受了一下超全栈的体验，这个超全栈指的是，不只是开发技术本身，诸如，前端，后端(已经包括测试)，运维等，还包括产品，需求分析，项目控制等等，从理论上来说，已经可以算是某种一人成军。而且，在这边由于配合得不是很好，很多时候不只是一个项目一个人负责，大多数都是一个人负责好几个项目，当然也不是所有的项目都要“全栈”，但基本上什么都要知道。

当然，我认为这个熟悉是很重要的一个环节，只不过，最后没有办法和时间将其转变成真正可用的软件服务，这是比较遗憾的一件事。不过，这一块也有类似的事情，或者说，软件开发处处皆是，并不需要在意一定要在某个地方才能做点什么。

而至于项目本身，我认为，当前能够比较说得有价值的项目相对较少，或者说，大部分的项目还处在思想验证，demo阶段，还在落地上去碰一碰。

当前对深度学习的总体判断

也顺便，既然对25年做了一点总结，那么也稍微能够对深度学习领域做一点总结。顺便也对概念做一些澄清，对未来的发展做点个人所理解的预期预测。

对机器学习整个领域的回顾

上一年我并没有追踪热点，一方面是所处的环境，另一方面当前主要大模型能力上的迭代更新，没有本质上的范式转换。

首先，我们能够明显区分机器学习和深度学习这两个概念。因为机器学习更侧重是机器如何学习，而深度学习是机器学习的某个子类，以多层感知机(Multilayer Perceptron，MLP)为主的技术路线。机器学习有其曾经热门的技术，比如聚类学习，支持向量机，集成学习(从大模型角度来说，集成学习是否也是一种大模型？)等。而深度学习，是在以MLP为典型的，有着前向传播和反向传播的形式上针对不同领域设计的所设计对应的模型。而从机器学习分类学范畴下，深度学习大部分还是有监督学习（supervised learning）的，这也是为什么当前的大模型，每一个环节都需要构造监督信号。

至少从这个视角来看，当前的大模型并没有从根本上突破这一块，大模型只是在这个基础上去不断去整合当前的数据，所以大家期许，能够让模型通过大量地学习，学到这一个领域“真正的本质”。但说实话，我认为这是比较困难的(因为相关的数据本身还是需要通过人类生成出来再映射到模型身上，这之间就会产生信息损失，以及模型是否能够真正意义上习得这些数据也是一个问题)，所以数据的质量就成为了制约大模型的瓶颈。

所以，具身智能(不一定是人类形状的机器人)，则是将数据获取作为一种机器本身应该掌握的能力去执行，这些机器要什么数据自己主动去获得就好了，只不过目前这一块肯定有很多困难。

而从大模型的结构上来看，当前大语言模型最舒服的应用实际上还是“信息查询”，我认为是因为里面的结构由于是QKV，Q就是查询，K是模型的“知识”，V是知识的“整合”，

大语言模型舒适区

所以我们每一次去询问模型，本质上就是，通过我们的询问(Q)去匹配模型存储的知识(K)，然后再整合起来(V)输出出来。

如果“Q”构造得足够好的，那么就能够得到我们想要的“K”，并且输出出来“V”。从这个角度来说，为什么模型会倾向认同用户，是因为它其实也不是在认同用户，而只是这样做能够匹配出最合适的信息，你想看到这些信息，它就给你匹配出来罢了。

所以对比传统的搜索引擎，有类似的特征，比如大家都针对“Q”去匹配存在知识库的信息”K”，然后对“K”进行排序返回给用户展示，此时的“V”就需要用户自行筛选和完成。

当前的矛盾或者说不舒服的点就在于，信息整合的“V”到底如何控制，如何自动化地完成，以及这一部分如果都能够自动完成，是否会代替很多人的工作。

推导到当前的AI Agent，AI Agent就是尝试将“K”转换成不同的工具(调用方式)，通过对任务“Q”的拆解，尝试拆解任务流“Q1,Q2,…”进而用不同的“K1,K2,…”完成得到结果“V”。

所以，从这个基础上，未来深度学习的研究应当是，对“QKV”结构的额外尝试，或者说，我们能够理解，为什么大语言模型备受关注，这可能是信息查询的红利仍在发光发热，以及对“QK”后的“V”到底能够做什么的一次尝试。而另一方面，当前的更进一步的探索，则是QKV形式上的探索：

Q还能怎么变：Prompt工程，微调等。
K还能怎么变：基础模型构建
V还能怎么变：信息整合等
QKV整体概念的变化：AI Agent等

那么大语言模型就更有用了吗？我认为这仍然是比较困难，因为从上述的讨论来说，它并没有比之前的深度学习有更深入的突破，而且大量要做的内容仍然是数据本身(对于QKV的转换可能仍然是工程上的考量)，虽然现在存在“左脚踩右脚”的情况，也就是利用一些已经训练好的模型去“匹配”合适的数据。所以这有一个模糊地带，原始数据训练以后早已模糊了，通过这种匹配得到的数据，到底有多大程度值得信赖？

对比“对比学习”和传统的数据增广来看，通过设计好的提示词来规范一批数据，这些数据的形式仍然是之前的该模型训练的数据中去“Q”出来的，从结构上来看，并没有出现没出现的数据（模型无法想象出自己没见过的内容），最多是数据的分布发生了改变，比如一些可能专业的内容的数据被大量地结构生成出来了。

对当前领域发展的一个预测

从这个角度来说，大模型实际上甚至并没有给深度学习“续命”，反倒从事实上给做硬件底层和基建的有了更多的空间，比如如何部署大模型，更好更稳定地训练大模型等。但是大模型从结构上并没有产生更多可以动的空间，大量地基于大模型的工作甚至只能在Prompt上，虽然很多社科类，文字类的工作受到了冲击，但是大模型本身能够做的并不多，甚至有时候成本代价很大，比如模型结构的改动，重新训练等等。

短期(3-5年)

通过Prompt，微调等方式，利用一些已经被训练好的模型进行数据提纯，在某一些领域上做得更好。在通用(大量)数据和少量高质量数据之间进行平衡，利用专有数据对一些领域做一些特殊化的产品。

中期(5年以后)

我认为还是要回到结构上的探索，只不过这种结构上的探索大概率也是要匹配领域的，成为领域特有的专有结构，类似CNN结构能够做图像这种标志。但更可能还是需要去探索一种基本方法论，类似软件工程的领域软件开发一般，能够形成领域特殊性。

而Attention等相关的模型，就类似新时代的“数据库”一般，还能够继续做，往小做，就是变成自己的数据库；往大做就是类似搜索引擎网站，能够检索相关的信息。

预期2026年可能会推进的一些内容

所以基于上述的讨论，对自身当前状态的定位和环境的判断，再结合2025年了解和做的一些工作，感觉2026年会往这些方向熟悉和了解一下。

大规模参数的深度学习

当前我并不把大模型(Large Model, LM)新开一个分类，虽然它在学术和讨论上似乎已经成为一个被区分开来的分类，但从概念上其仍然只是深度学习模型的一个子集，并且并没有显著地和其他结构有明显的差异。

所以在这里，它与传统深度学习模型之间最大的差异就是，参数规模巨大，在这参数规模巨大下，能够如何把这个模型给训出来，中间存在什么技术是需要去了解的。而在这个基础上，由于个人并没有那么多的资源，所以会以各种小的，mini, nano, tiny等方式去探索一个有对应特点的内容。

而对于大模型所对接的业务，这一块在当前的岗位一定是会有大量的现实的任务去做，所以这一块我倒是并不担心有什么额外的问题。

对于一些内容的深入

说实话，本来这一块想写点阅读论文的，但是看着现代的论文似乎都没有阅读下去的欲望，所以这一块改成读一些比较有水平的内容。相较于跟踪前沿，我认为可能现在是时候是需要回头看，去重新理解之前的内容是否还有没有被解读出来的情况，更彻底地理解这些范畴之间的关系。还是认为自己的基础并不扎实，所以还有很多课是需要补的。

对25年的总结和对未来的调整