介绍RWKV：线性Transformers的兴起和探索替代方案
以下是我在RWKV播客中的一些想法摘要：https://www.latent.space/p/rwkv#details为什么替代方案的重要性如此突出？随着2023年的人工智能革命，Transformer架构目前正处于巅峰。然而，由于人们急于采用成功的Transformer架构，所以会容易忽视可以借鉴的替代品。作为工程师，我们不应该采取一刀切的方法，对每个问题都使用相同的解决方案。我们应该在每一个情况下权衡利弊；否则将会被困在特定平台的限制范围内，同时因不知道有其他选择而感到“满足”，这可能会使发展一夜回到
以下是我在RWKV播客中的一些想法摘要：https://www.latent.space/p/rwkv#details
为什么替代方案的重要性如此突出？
随着2023年的人工智能革命，Transformer架构目前正处于巅峰。然而，由于人们急于采用成功的Transformer架构，所以会容易忽视可以借鉴的替代品。
作为工程师，我们不应该采取一刀切的方法，对每个问题都使用相同的解决方案。我们应该在每一个情况下权衡利弊；否则将会被困在特定平台的限制范围内，同时因不知道有其他选择而感到“满足”，这可能会使发展一夜回到解放前
这个问题并不是人工智能领域独有的，而是一种从古到今都在重复的历史模式。
SQL战争历史的一页，是关于数据库管理系统之间的竞争和对抗的故事。在这个故事中，各种数据库管理系统如Oracle、MySQL和SQL Server等，为了争夺市场份额和技术优势，展开了激烈的竞争。这些竞争不仅体现在性能和功能方面，还涉及到商业策略、市场推广以及用户满意度等多个方面。这些数据库管理系统不断地推出新的功能和改进，以吸引更多的用户和企业选择他们的产品。SQL战争历史的一页，见证了数据库管理系统行业的发展和变革，也为我们提供了宝贵的经验和教训
最近在软件开发中有一个值得注意的例子是，当SQL服务器开始受到物理限制时，就出现了NoSQL的趋势。世界各地的初创企业都因为"规模"的原因转向了NoSQL，尽管它们远未达到这些规模
然而，随着时间的推移，随着最终一致性和NoSQL管理开销的出现，以及硬件功能在SSD速度和容量方面的巨大飞跃，SQL服务器最近又出现了回归的趋势，因为它们使用简单性，并且现在90%以上的初创公司都有足够的可扩展性
SQL和NoSQL是两种不同的数据库技术。SQL是结构化查询语言的缩写，主要用于处理结构化数据。NoSQL则是指非关系型数据库，适用于处理非结构化或半结构化数据。 虽然有人认为SQL比NoSQL更好，或者反之亦然，但实际上这只是意味着每种技术都有自己的优缺点和适用场景。在某些情况下，SQL可能更适合处理复杂的关系型数据，而NoSQL则更适合处理大规模的非结构化数据。 然而，这并不意味着只能选择其中一种技术。实际上，许多应用程序和系统在实践中使用了SQL和NoSQL的混合解决方案。根据具体的需求和数据类型，可以选择最适合的技术来解决问题。 因此，重要的是理解每种技术的特点和适用场景，并根据具体情况做出明智的选择。无论是SQL还是NoSQL，都有其独特的学习点和首选用例，可以在类似技术中相互借鉴和交叉传播
目前Transformer架构最大的痛点是什么？
通常，这包括计算、上下文大小、数据集和对齐。在本次讨论中，我们将重点讨论计算和上下文长度：
- 由于使用/生成的每个令牌的O（N^2）增加而导致的二次计算成本。这使得大于10万的上下文大小非常昂贵，从而影响推理和训练。
- 当前的GPU短缺加剧了这个问题。
- 上下文大小限制了Attention机制，严重限制了“智能代理”用例（如smol-dev），并强制解决问题。较大的上下文需要较少的解决方法。
那么，我们该如何解决这个问题呢？
介绍RWKV：一种线性Transformer/现代大型RNN
RWKV和微软RetNet是被称为“线性Transformer”的新类别中的第一个
它通过支持以下内容直接解决了上述三个限制：
- 线性计算成本，与上下文大小无关。
- 在CPU（尤其是ARM）中，允许以更低的要求在RNN模式下输出合理的令牌/秒。
- 没有作为RNN的硬上下文大小限制。文档中的任何限制都是指导原则——您可以对其进行微调。
随着我们不断将人工智能模型扩大到100k及以上的上下文大小，二次方计算成本开始呈指数级增长。
然而，线性Transformer并没有放弃递归神经网络架构及解决其瓶颈，这迫使它们被取代。
不过，重新设计的RNN吸取了Transformer可扩展的经验教训，使RNN能与Transformer工作方式类似，并消除了这些瓶颈。
在训练速度方面，用Transformer让它们重返赛场——允许它们在O（N）成本下高效运行，同时在训练中扩展到10亿个参数以上，同时保持类似的性能水平。
图表：线性Transformer计算成本按每个令牌线性缩放与变换器的指数增长
当你将平方比例应用于线性缩放时，你会在2k令牌计数时获得10倍以上的增长，在100k令牌长度时获得100倍以上的增长
在14B参数下，RWKV是最大的开源线性Transformer，与GPT NeoX和其他类似数据集（如the Pile）不相上下。
RWKV模型的性能与类似规模的现有变压器模型相当，各种基准显示
但用更简单的话来说，这意味着什么？
优点
- 在较大的上下文大小中，推理/训练比Transformer便宜10倍甚至更多
- 在RNN模式下，可以在非常有限的硬件上缓慢运行
- 与相同数据集上的Transformer性能相似
- RNN没有技术上下文大小限制（无限上下文！）
缺点
- 滑动窗口问题，有损内存超过某一点
- 尚未证明可扩展到14B参数以上
- 不如变压器优化和采用
因此，尽管RWKV还没有达到LLaMA2那样的60B+参数规模，但只要有正确的支持和资源，它有可能以更低的成本和更广泛的环境来实现这一目标，特别是在模型趋向于更小、更高效的情况下
如果您的用例对效率很重要，请考虑这一点。然而，这并非最终解决方案——关键在于健康的替代品
我们应该考虑学习其他替代方案以及它们的好处
扩散模型：文本训练速度较慢，但对多时期训练具有极高的弹性。找出原因可以帮助缓解令牌危机。
生成对抗性网络/代理：可以在没有数据集的情况下，使用技术将所需的训练集训练到特定目标，即使是基于文本的模型。
原文标题：Introducing RWKV: The Rise of Linear Transformers and Exploring Alternatives，作者：picocreator
https://hackernoon.com/introducing-rwkv-the-rise-of-linear-transformers-and-exploring-alternatives
了解DeepSeek V4.1 Flash 1017的Agent Arena指标、约0.20美元任务成本中位数，以及Terminal-Bench 4.0和ProgramBench成绩变化与适用边界。
了解DeepSeek模型权重与DeepInfer推理框架的对象差异，查看官方项目入口，并从价格竞争、开发者协作和小团队参与三个角度理解开源策略。
理清幻方量化与DeepSeek的发展脉络，关键在于区分早期萤火二号的A100集群积累与DeepSeek-V3的H800训练配置。本文解析软硬件协同工程在其中的作用，避免将资金投入简单等同于模型能力。
了解 Kimi K3.1 Pro 案例费用、SKY-001 零件构建耗时和 Mercury 3 测试表的限定条件，查看经核实的官方产品说明入口。
想了解Laper AI的真实工资待遇？本文教你如何通过多渠道交叉验证岗位薪资，识别招聘话术中的水分，获取更准确的收入预期参考。
解析字节旗下豆包App、火山引擎、Seedance、TRAE及飞书的定位差异。通过官方文档核对云服务、视频模型、编程工具与办公AI的功能边界，帮助读者准确选择适合的产品入口。
认识AI Agent、Genie 4与机器人的区别：任务输入不等于完成结果，世界模拟不等于现实执行，装载机动作展示也不能替代完整工程验收。
想了解Claude怎么收费？本文梳理了Claude Free、Pro及Team版的最新月费价格、消息限额与高级功能权益，并对比了不同层级的性价比，助你快速找到适合的AI办公伙伴。
本周AI领域热点集中在DeepSeek编程效率、可灵30秒视频生成及特斯拉Roadster飞行演示。本文不罗列参数，而是从普通用户视角出发，分析如何正确评估编程助手的真实成本、视频生成的控制能力以及硬件展示的落地限制，助你透过现象看本质。
了解 Harness Engineering 的核心定义及其与提示词工程、上下文工程的关系。文章通过分层视角，解释如何从问题表达、信息组织到系统搭建，全面理解智能体的运行机制。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
