企业官网建设流程全解析

你可能也刷到了这条消息：继一位重量级研究者公开表达对规模扩展的怀疑之后，KAN 论文的作者也明确抛出了类似论断——Scaling（规模扩展）终将撞上铁壁。这句话在我所在的几个技术讨论群里来回转了好几轮，有人觉得是泼冷水，有人觉得是风向标，还有人直接搬出过去几年的大模型进展来反驳：如果规模扩展行不通，那前几年的性能跃升又怎么解释？

这确实不是一个能靠一两句话下结论的话题。作为从深度学习时代一路跟过来的从业者，我自己也经历了从“网络越大越好”到“开始怀疑边际收益”的心态转变。这些年我做过不少模型训练和推理优化的项目，眼看着训练集群从单机走向大规模并行，也亲身体会过数据、算力、能源这三座大山压在工程头上是什么感觉。这篇文章不打算站队，而是想把这个争论本身拆开来看：Scaling 到底在扩展什么？KAN 这种“换架构”的思路凭什么让行业震动？所谓“铁壁”如果真的存在，它到底长什么样？以及最重要的一点——这场争论对普通开发者、算法工程师和技术决策者来说，意味着什么。

1. 信“规模越大越强”的过去十年是怎么被验证的

在讨论“撞墙”之前，得先搞清楚一件事：Scaling 这套信仰到底是怎么建立起来的。它不是某个人拍脑袋想出来的口号，而是过去十多年被大量实验结果反复验证过的一条经验规律。

1.1 幂律曲线背后的工程直觉

Scaling laws 的核心表述其实很朴素：当模型的参数量、训练数据量和计算量同步提升时，模型在任务上的表现会按照幂律关系稳定提升。用大白话说，就是你喂给模型更多参数、更多数据、更多算力，它的能力就会跟着涨——不是线性涨，而是在对数坐标下呈一条近似直线的上涨曲线。

这条规律之所以让人信服，是因为它在多个尺度上都站得住脚。从小规模实验到大集群训练，从语言模型到多模态模型，很多团队都观察到了类似的趋势。我自己印象最深的一件事，是早期在某图像任务上做实验，把模型参数从几百万涨到几千万时，效果提升非常明显；等到了上亿参数量，提升斜率虽然放缓，但依然存在。这种“规律稳定、可预测”的特性非常诱人，因为它给了工程一个明确的方向：想要更好的效果，就按比例放大。

这也是为什么行业会把大量资源砸向模型堆叠、数据采集和算力建设。在相当长一段时间里，这是一种风险极低、收益确定的投资策略——你不需要搞出什么惊天动地的算法创新，只需把规模做上去，性能就会跟着上去。这种确定性，在充满不确定性的研究领域里，显得极其珍贵。

1.2 从预训练扩展到后训练扩展

但严格来说，行业对 Scaling 的理解也在不断变化。早期大家主要盯着预训练阶段的模型参数量和训练数据量，即“预训练扩展”。到后来，人们发现单纯扩大预训练规模的边际收益开始下滑，于是把目光转向了推理阶段——让模型在回答问题时消耗更多计算量，比如多步推理、自我校验、思维链等机制。这个方向被形象地称为“后训练扩展”或“推理时扩展”。

我特别想强调这个转变，因为它是理解“Scaling 撞墙”争论的关键背景。当预训练规模的增长变得越来越昂贵、越来越难以持续时，行业自然会去寻找新的“扩展维度”。后训练扩展就是这样一个新维度：它不需要无限堆参数，而是通过让模型“思考更久”来换取更强的能力。这种思路的应用场景已经很常见了——很多智能问答、复杂任务处理系统里，模型都会内部生成多轮中间步骤，再给出最终答案。

所以你看，Scaling 并不是一个固定不变的概念，它本身就在演化。而正是因为每个阶段都能找到新的扩展维度，人们对“规模信仰”的坚持才如此牢固。可问题也恰恰出在这里：如果有一天，所有已知维度的边际收益都趋近于零呢？那堵墙，就是标题里说的“铁壁”。

2. KAN 论文最大冲击不是效果，而是“换个变量”的思路

KAN 论文之所以能在行业里引起巨大讨论，绝不仅仅是因为它宣称看到了 Scaling 的边界，更关键的是它提出了一个截然不同的技术方向——与其继续堆规模，不如重构网络的基本构件。这种“换变量”的思路，在大家习惯性想着“继续加大”的行业氛围里，确实像一记惊雷。

2.1 KAN 在改什么：从固定激活到可学习激活

KAN 的全称是 Kolmogorov-Arnold Networks，它的理论根基是数学里的一个经典结论——多元函数可以分解为若干单变量函数的叠加。这个结论听起来很抽象，但落到神经网络上，它的含义非常直接：传统网络结构（比如 MLP）是把每个神经元上的激活函数固定死的，训练过程中只调整层与层之间的权重矩阵；而 KAN 的思路是，把激活函数本身也变成可以学习的参数，让网络在训练中自动找到最适合当前任务的非线性变换。

打个生活化的比方，传统 MLP 像是给你一套固定形状的乐高积木，你只能通过不同的拼法去搭出各种结构；KAN 则像是把积木的形状也变成了可调参数，每块积木可以自动弯曲、拉伸成最合适的样子。从理论上说，这种设计在表达能力上更灵活，在小规模问题上也可能用更少的参数达到与传统结构相近的效果。

当然，KAN 背后涉及的数学机理和实现细节要深得多，这里不展开。重点在于，它给了行业一个非常明确的信号：在我们埋头堆了这么多年参数之后，网络骨架本身的可塑性可能被严重低估了。传统结构的表达能力真的要靠宽度和深度硬扛吗？有没有可能，改变激活函数的组织方式，就能以更小的代价获得更强的智能？

2.2 这场争论真正有价值的地方在哪

KAN 的论文发出后，讨论的热度极高。支持者认为这是对主流范式的一次正面挑战，反对者则指出它在超大模型上的表现还缺乏充分验证，很难立刻撼动现有工程体系。这两种声音放在一起，恰恰暴露出一个问题：行业对“继续扩大规模”这件事的依赖，已经深入到了骨髓。

我个人的看法是，KAN 的价值不在于它能否立刻取代现有架构，而在于它把“是否还有其他路可走”这个问题摆到了台面上。过去这些年，大部分团队的技术路线几乎是被 Scaling 信仰统一塑造的：有算力就堆算力，有数据就堆数据，效果不好就继续加码。这种路径依赖让整个行业变成了一个巨大的“规模竞赛”。可一旦有人指出，我们也许可以在结构本质上做文章，这个看似铁板一块的共识就出现了裂缝。

这不是说 Scaling 一定是错的，而是说，它不再被理所当然地视为唯一解。KAN 作者选择在这个时间点抛出“撞铁壁”的论断，本质上是在提醒大家：如果所有公司都在同一条道路上血拼资源，那当这条路走到尽头时，整个行业都会同时撞墙。提前思考替代路径，是必要的风险对冲。

3. 数据墙、算力墙与能耗墙：把“铁壁”翻译成工程问题

“Scaling 撞墙”这种说法听起来有点哲学，但如果把它翻译成工程问题，其实非常具体：数据不够用了，算力贵得离谱了，电费扛不住了。这三堵墙，是我在实际项目中每天都能感知到的东西。

3.1 数据墙：高质量文本并非取之不尽

大模型的第一口粮是数据。尤其是语言模型，每一代更强的模型都意味着更大规模、更高质量的训练语料。可问题在于，互联网上真实存在的高质量文本总归是有限的。行业里早就有估算，按当前训练数据的消耗速度，高质量文本数据在数年内就可能被集中采尽。这个说法到底准不准确不好说，但趋势是明确的：数据采集的成本在上升，新数据的边际价值在下降。

当真实人类数据开始枯竭，行业转向了两个方向：一是用合成数据自我迭代——让模型生成训练语料，再拿这些语料训练下一代模型；二是探索更多元的数据形态，比如图像、视频、音频、传感器数据。合成数据的思路有得通，但存在风险，包括内容质量不稳定、多样性不足，乃至在迭代中放大模型自身的偏见和错误。我自己在做数据工程时也经常遇到类似问题——模型生成的数据看起来流畅，但细看会发现逻辑漏洞和事实错误，远不如精心整理的真实语料可靠。

数据墙的可怕之处在于，它不是一堵突然出现的墙，而是一条缓缓逼近的地平线。你总觉得还有距离，但每推进一代模型，距离就缩短一截。当数据增长的速度跟不上模型规模增长的速度，Scaling 的根基就已经开始松动。

3.2 算力墙：规模翻倍的边际成本正在上扬

再来看算力墙。过去这些年，训练集群的规模从几十块卡扩展到几千块甚至更多，通信开销、故障恢复、分布式调度这些问题，让训练一个超大模型的工程复杂度呈指数级上升。简单地说，从单机训练到集群训练，你需要处理的不只是“更多计算”，而是“更复杂的协作”。

我自己在做分布式训练时最深的体会是：当你把集群规模扩大一倍，训练吞吐量往往达不到两倍，中间会有大量算力消耗在节点通信、数据同步、等待慢节点这件事情上。集群越大，木桶效应越明显，某个节点的故障可能让整轮训练功亏一篑。这意味着，算力成本不是线性增长的，它是向上弯曲的曲线——越往上堆，每一分新算力换来的实际收益就越薄。

更现实的问题在于，算力本身的获取也在变难。高端芯片的供给、集群建设的周期、散热和运维的复杂度，这些都构成了隐形的天花板。当行业里几乎每家头部团队都在同时抢购算力资源时，价格会被推高，交付周期会被拉长。一个技术团队即便有钱，也很难在短时间内把算力规模再翻一番。

3.3 能耗墙：电力供给开始影响发展节奏

算力墙和能耗墙其实是一对双胞胎。更大的集群意味着更多的电力消耗，而电力供给早就不是“交钱就有电”那么简单的事情了。大规模训练集群的能耗水平，已经达到了足以影响地区电网负载的程度。有几家大型数据中心在选址时，首要考虑因素已经从“网络便利性”变成了“电力冗余度”。

能耗问题对行业的影响是结构性的。它推高了训练成本，压缩了创业团队的生存空间，也迫使很多团队去探索高效训练、模型压缩、推理加速等省电方案。讽刺的是，这些“省电方案”本质上也能提升模型效率，但它们最初的动机，往往不是因为对 Scaling 的怀疑，而是因为电费真的扛不住了。

这三堵墙合在一起，构成了“铁壁”的物理含义。它不是某一项技术无法突破，而是数据、算力、能源三个维度同时逼近物理与经济的极限。你可以暂时绕过其中一堵，但三堵墙同时逼近时，继续沿着老路走，成本会越来越高，收益会越来越低。

下面这个表可以更直观地看出三堵墙的工程影响：

维度 | 具体表现 | 对工程团队的影响 数据墙 | 真实高质量数据增速放缓，合成数据成熟度有限 | 数据清洗、语料治理、多模态数据采集成为主战场 算力墙 | 集群扩大带来通信、故障、调度等非计算开销 | 训练框架优化、容灾设计、资源调度的权重显著上升 能耗墙 | 电力供给与散热成本成为硬约束 | 成本模型不再只是算力租金，更要考虑能耗与碳排放

4. 行业里的三种立场：信仰派、转向派与并行派

“Scaling 会不会撞墙”这个问题在行业里分成三派，各有拥趸。我把这三派的逻辑梳理一遍，你会发现，它的指向比表面看起来要复杂得多。

4.1 信仰派：挡板与铁壁是两回事

信仰派的观点很直接：过去十几年，每一次有人喊“模型到头了”，最后都被更大的模型打脸。他们承认数据、算力和能耗确实在收紧，但不认为这会从根本上终结规模扩展。理由也很现实：我们还没用尽所有可用的扩展维度。

多模态数据还没有被完全挖掘，合成数据的质量还在快速提升，模型架构和训练算法也远没到没有优化空间的地步。在信仰派看来，现在撞的顶多是一块挡板，而不是铁壁。只要改造输入信号、优化训练方式、提高数据利用效率，规模扩展就还能再走很远。他们往往比较乐观地认为，Scaling 的终点只取决于人类的工程创造力和资源投入，而不是某种先验的“极限”。

4.2 转向派：架构创新的窗口正在打开

转向派则从另一条逻辑出发。他们认为，既然数据、算力、能耗都有物理上限，那么解决行业瓶颈的关键就不可能在“更大”上，而应该在“不同”上。KAN 这类研究的意义，正在于打开了“不同”这扇窗。

转向派并不是说传统架构已经失败了，而是说，当规模扩展的边际收益变平之后，投入产出比会逼迫行业去重估架构创新的价值。过去，一个架构上的改良可能因为效果差异不够明显而被忽略；但当大家都卷不动规模时，任何一点结构上的效率提升都会变得极具竞争力。转向派相信，接下来的大突破不太可能来自“把模型再放大一倍”，而更可能来自“用更聪明的方式组织参数和计算”。

4.3 并行派：规模与架构会相互牵引

并行派的态度相对折中，也是我私下比较认可的一种判断。他们认为，规模和架构并不是对立关系，而是相互牵引的关系。更好的架构可以让同样规模的模型变得更强，更强的模型又会在更大规模上释放新的能力。换句话说，架构创新的价值，恰恰需要通过规模扩展来放大。

在这个视角下，Scaling 撞不撞墙根本不是关键问题。关键是，你手里有没有足够强的架构杠杆。如果 KAN 这类方向在更大规模上被验证有效，那它就意味着新的扩展空间；如果它在超大参数场景下失效，那我们大概率就只能继续在现有结构上修修补补。行业真正需要担心的是没有备选方案的单一依赖，而不是某一条路本身的长短。

这场争论最有价值的贡献，是把三种立场都摆在了明面上。不管是信仰派、转向派还是并行派，其实都已经承认了同一个事实：单纯堆规模的路线，已经不再像几年前那样是最优策略。这个共识本身，就是最近行业里最值得关注的思想变化。

5. 我不建议普通从业者站队，但建议做这几件事

作为一个不算一线的算法从业者，我没有资格给整个行业指方向。但要说这场争论对个人和中小团队有什么启示，我还是有点实打实的体会的。我的建议很简单：别急着站队，但一定要调整自己做事的优先级。

5.1 从“跟热点”调整为“跟指标”

我见过太多团队，热点一出来就急着往上扑——今天换新模型，明天改新架构，后天再追新算法。但真正能把业务做起来的，往往是那些盯着自家核心指标死磕的团队。

在 Scaling 争论的背景之下，这一点变得更加重要。你要做的第一件事，是画一画你自己任务上的收益曲线：模型参数量从一千万涨到一亿，再从一亿涨到十亿，你的关键指标到底涨了多少？如果斜率已经很平，那就说明在这个任务上，继续堆规模不是你该走的路。如果斜率还很陡，那说明规模红利还在，你完全没必要被“撞墙”的说法带偏节奏。

5.2 把数据工程放在比调参更高的优先级

很多人沉迷于调整模型结构、精调训练超参，却对数据本身没有足够的敬畏。根据我自己踩过的坑，绝大多数模型效果不佳的根源，其实都是数据问题——噪声太多、分布不均、样本重复、标签错误。你把模型从千万参数换到亿级参数，都不如把数据集里的三成垃圾数据清掉收获大。

在数据墙逼近的当下，这一点尤其重要。既然新数据越来越难找，那我们能做的就是把手头的数据用尽用透。我通常会先做一轮全面的数据审计，统计类别分布、长度分布、重复度、噪声率，再决定清洗策略。这一步看似不性感，但回报率极高。如果你有富余的资源，不妨也试试少量合成数据与真实数据混合训练的实验，这能帮你提前判断未来如何应对真实语料枯竭的问题。

5.3 保持对推理成本的敏感

训练成本是显性成本，大家都看得见；推理成本却是隐性成本，很容易被忽视。但一个模型真正规模化落地后，推理成本往往是长期运营里的大头。很多团队在做技术选型时只看训练效果，忽略了对推理阶段计算量的约束，结果上线后发现成本远超预期，不得不中途返工。

所以我建议，在做模型选型或自研架构时，把“推理时计算开销”作为一个明确指标来跟踪。KAN 这类方向的吸引力之一，就在于它有可能用更少参数达到同等效果，这意味着推理成本可能更低。当然，这还处在早期探索阶段，但提前在架构层面关注这类收益，长期来看不会吃亏。

5.4 为架构变化留好接口

最后一条是我经历过不少痛苦教训后总结出来的：代码和系统架构的抽象能力，决定了你是否能被新思路接住。如果你把所有模块都硬编码成某个具体模型专用，那么当新架构出现时，你的迁移成本会高到让人放弃尝试。

我在自己的项目里会刻意把数据处理、模型层、推理服务设计成可插拔的接口。哪怕暂时用不到 KAN，也会在模型注册层留好位置；哪怕暂时不做推理时扩展，也会在请求链路里预留控制开关。这个习惯帮我节省过非常多的返工时间。当前模型还能打，不代表未来永远是它；一旦架构创新成熟，能最快接住新范式的人，一定是早早在代码里留好余地的团队。

说到底， Scaling 这场争论最大的意义，不是告诉我们哪条路会死，而是提醒每个人：技术世界随时可能变轨，而准备永远在机会到来之前更值钱。