- 综合排序
- 最热优先
- 最新优先
- 来自专栏DeepHub IMBA
大模型如何训练百万 Token 上下文：上下文并行与 Ring Attention
模型大、上下文又长到几百万 Token，张量并行也顶不住。因为注意力的二次方内存增长太凶，激活值直接占满显存。128k 上下文的激活值内存是 8k 的 16 倍，这个目前没办法，因为就是这么夸张。 上下文并行更彻底：整个序列在所有模块里都切开，包括注意力。每个操作拿到的都是分区后的序列。百万级上下文的训练就靠这个，把激活值的内存占用分摊到各卡上。 单卡装不下的百万级 Token 上下文，只有靠这个才能训。 Ring Attention 把 GPU 排成环，每张卡一边算当前数据的注意力，一边把键值对往下传。 上下文并行在所有模块里都切序列，包括注意力。超过 128k Token 的上下文必须用后者，因为激活值内存二次方增长太猛了。 那么训练百万级 Token 上下文的模型需要什么硬件？ 多节点 GPU 集群，配 HBM 内存，加高速互连——NVIDIA NVLink 1.8TB/s 或者 InfiniBand。
28910编辑于 2026-02-27 - 来自专栏不二小段
百万 Token 上下文并不可靠？Chroma 揭秘大模型「上下文腐烂」真相
本文要点 • 超长上下文并非万能：尽管最新的大模型如 GPT-4.1、Gemini 2.5 宣称支持百万甚至千万级 Token，但它们的性能会随着输入长度的增加而显著下降，这种现象被称为「上下文腐烂」（ 一个百万 Token 的上下文窗口意味着什么？它相当于一次性处理四本厚厚的书籍，或者数小时的会议录音。 它们处理上下文的方式并非始终如一，随着输入长度的增加，其表现会变得越来越不可靠。 换言之，你以为给了模型百万 Token 的上下文，它就能像超人一样处理所有信息。 解决问题的正确出路：「上下文工程」 既然百万 Token 的上下文窗口并不能保证可靠的性能，我们该怎么办？ Chroma 的研究指向了一个关键结论：你需要工程化你的上下文。 理论上你可以使用多达一百万的 Token，但实际上，你的最佳上下文窗口要小得多。这变成了一个优化问题：你希望最大化相关信息的数量，同时最小化不相关内容的干扰。我们称这个过程为上下文工程。
15310编辑于 2026-04-09 百万 Token 上下文窗口的工程实现与实际瓶颈
本文将探讨如何在工程上实现百万Token的上下文窗口，并分析其中的实际瓶颈。 对于百万Token的上下文窗口，我们需要考虑如何高效地存储和访问这些数据。常见的数据结构如列表、字典等在处理大规模数据时可能会遇到性能瓶颈。 分块处理和并行计算原理为了进一步提高处理效率，可以将百万Token的上下文分成多个小块，分别进行处理。这种分块处理的方式可以利用多线程或多GPU进行并行计算，从而加速整个处理过程。 总结实现百万Token上下文窗口的工程挑战主要集中在高效的数据结构和算法、稀疏注意力机制、分块处理和并行计算以及内存优化和显存管理等方面。 总结本文深入探讨了百万 Token 上下文窗口的工程实现与实际瓶颈的相关技术，从原理到实践，从基础到进阶，希望能够帮助读者全面掌握这一技术。
20310编辑于 2025-12-24- 来自专栏量子位
百万token上下文窗口也杀不死向量数据库？CPU笑了
有网友便列举了长上下文窗口的四大通病（四个V）： Velocity（速度）：基于Transformer的大型模型，在检索长上下文时要想达到亚秒级的速度响应仍然具有挑战性。 Value（价值）：长上下文窗口毕竟属于大力出奇迹，但它高支出的特点对于日常应用来说，在成本上是不切实际的。 高性能：单索引支持千亿级向量数据规模，可支持百万级 QPS 及毫秒级查询延迟。 低成本：只需简单操作就可以创建向量数据库实例，全流程平台托管，不需要额外的开销成本。 从这些特性不难看出，它恰好补齐了我们刚才提到的上下文窗口方式的一些短板。 借助这一项项突破，腾讯云VectorDB不仅支持多种索引类型和相似度计算方法，还具有单索引支持千亿级向量规模、百万级每秒查询率（Queries-per-second，QPS）及毫秒级查询时延等优势。
46010编辑于 2024-03-20 - 来自专栏大模型系列
打造你的百万上下文AI智能体：OpenClaw深度集成DeepSeek V4全攻略—— 解锁 DeepSeek-V4 的百万上下文与 MoE 架构
在众多可选模型中，DeepSeekV4以其万亿参数的MoE架构、百万token的超长上下文、卓越的代码与推理能力以及极具竞争力的开源与定价策略，成为了2026年最具吸引力的选择之一。 发送测试消息:选择该模型，并发送一条简单的消息，例如：“你好，请介绍一下你自己，并说明你当前的上下文长度是多少？” 观察响应:如果一切配置正确，您将收到来自DeepSeekV4的回复，并且它会自豪地告诉您它支持1,000,000tokens的上下文。 5.2利用超长上下文DeepSeekV4的百万token上下文是其杀手锏。在OpenClaw中，您可以通过Skills（技能）系统来充分利用这一点。 成本极低（根据官方信息，输出定价约为2元人民币/百万token），性价比极高。您可以根据任务需求，在OpenClaw中灵活切换这两个模型，甚至可以在同一个Agent的不同步骤中使用不同的模型。
1.4K50编辑于 2026-04-24 《记忆革命：Gemini 1.5如何让Transformer突破百万级上下文枷锁》
在传统Transformer架构中，上下文窗口如同一个狭窄的走廊——模型只能记住最近几百或几千个token，更早的信息被无情丢弃。 而Google DeepMind的Gemini 1.5却打破了这一宿命，首次实现百万级token的上下文处理能力，相当于让AI同时阅读《战争与和平》全集并记住每一个细节。 在极端测试中，Gemini 1.5展现出惊人能力： 长文档理解：准确回答百万token技术手册中的嵌套问题（如“第3章第5节提到的实验参数，在第8章的验证结果如何？”）。 Gemini 1.5的突破暗示了AI认知范式的转变： 传统模型将长上下文视为计算累赘，而Gemini证明：结构化记忆能转化为推理能力。
35400编辑于 2025-05-29Claude Opus 4.6 正式发布：百万级别上下文，秒了 GPT5
与前代相比，Opus 4.6 在三个维度实现突破： 上下文革命：首次为 Opus 级别模型提供 1M token 超长上下文（Beta） Agent 能力跃迁：复杂任务规划、并行子任务执行、长时间会话维持 编程能力登顶：Terminal-Bench 2.0 评测中成为全球最强编码模型 二、核心技术创新详解 2.1 1M Token 超长上下文：从“记忆碎片”到“全量知识库” Opus 4.6 首次在 Opus 级别引入 1M token 上下文窗口（Beta），标准版仍为 200K，但已足够支撑： 完整代码仓库分析（10 万行+ 代码） 百页级法律/金融文档处理 跨会话长期记忆维持 关键突破：在 8-needle 七、总结与展望 7.1 Opus 4.6 的三大范式转移 维度 传统 LLM Opus 4.6 交互模式 问答式 自主规划 + 工具调用 上下文能力 短期记忆 全量知识库访问 任务复杂度 单步操作 多步骤工作流编排
4.6K20编辑于 2026-04-09- 来自专栏掘金安东尼
国内大模型 T1 —— Kimi，解析二百万上下文无压力
两位百万？怎么做到的？ 前段时间写过一篇文章:# GPT4-Turbor 128k ？ 还不够？还不够！ 记得 GPT4-T 的上下文参数量 128k，也就大概 100 万英文字符、50 万汉字字符，kimi 是如何做到 double 的？ 真的能做到吗？ 上下文的扩充有尽头吗？ 白话来说就是将上下文提示语分块、分析、加权重、插入到提示，那么：如果能无限扩充上下文长度，RAG 技术还有意义吗？ Kimi 背后原理，官网做出了解释：# Kimi Chat 公布“大海捞针”长文本压测结果 这里的“针”就是“大上下文提示语”的核心，我们需要提取的、解析的核心： 有几个有意思的数据： 1、GPT-4 两点： 1、数据的精准性-各行业 2、计算能力、解析能力-这里的大文本上下文解析就算！
3.8K100编辑于 2024-03-23 - 来自专栏量子位
GitHub热榜第一：百万token上下文，还能生成视频，UC伯克利出品
上下文窗口长度达到了100万token，持平了谷歌同时推出的王炸Gemini 1.5，伯克利出品。 百万上下文窗口，可看1小时视频 在测试过程中，研究人员用多段一个多小时的视频检验了LWM的长序列理解能力，这些视频由YouTube上不同的视频片段拼接而成。 在1百万token窗口的“插针”检索测试中，LWM取得了单针检索全绿的成绩。 它运用了“分而治之”的思想，将长文本分成多个块，用多个计算设备做序列并行处理，然后再进行叠加，理论上允许模型扩展到无限长的上下文。
44510编辑于 2024-02-22 - 来自专栏天意云&天意科研云&天意生信云
GPT 4.1 模型上线，支持百万token上下文，性能吊打 GPT 4o ，性价比超高！
长上下文：在评估多模态长上下文理解能力的 Video-MME 测试中，GPT 4.1 创下了新的最先进成绩——在长时长无字幕类别中得分 72.0%，比 GPT 4o 提高了 6.7 个百分点。 长上下文性能对于多模态应用场景同样重要，例如处理长视频。 超长上下文 除了性能方面的提升，此次新推出的 GPT 4.1 把上下文处理能力扩展到百万级 token，这意味着 GPT 4.1 可以处理100万个 token 上下文，非常适合处理大型代码库或大量长文档 此外，GPT 4.1 相较于 GPT 4o 在检索、记忆上下文信息方面更加精准。 许多开发者在处理长上下文时的应用场景时，需要在上下文中进行多次逻辑跳跃，比如代码时在多个文件之间跳转，或者在回答复杂的法律问题时进行文档间的交叉引用。
87310编辑于 2025-04-16 - 来自专栏贾志刚-OpenCV学堂
百万token上下文登场，吞下整个代码库
OpenAI的GPT-4.1提供百万token统一定价，但最强的GPT-5.4上下文窗口上限只有25.6万token。 因为它意味着，百万上下文已经从「实验功能」变成默认能力！ 而百万上下文窗口，会把这一切推向更极端的地步。 首批用户的反馈已经很说明问题。 而百万级的上下文让他们可以一次性喂入完整的diff，用更简单的架构获得了更高质量的代码审查。 而有了百万上下文之后，搜索、聚合边界条件、提出修复方案，在一个窗口里就能全部完成。
23610编辑于 2026-04-02 - 来自专栏又见苍岚
上下文
所以业务上下文变更需要慎之又慎。 运行程序上下文 大家应该对一句话有印象：（进程/线程）上下文切换开销很大。这里的上下文一般指的就是运行程序的上下文。 这里的通信问题就是进程上下文切换开销大的缘故。 方法/类所在的上下文（作用域） 方法上下文可以理解为方法所在的作用域。类亦如此。 还有一些比较特殊的概念实际上也是和方法上下文相关。 比如worker语言特性中，需要监听message事件，这实质上，就是在当前上下文监听另一个上下文的状态。再比如回调函数。实际上是因为上下文变更后，对原有上下文访问的一种编程手段。 从这个角度看，闭包实质上也是对上下文的一种操作手段：返回一个函数，该函数在当前上下文可以操作闭包上的上下文。 执行上下文：当函数或方法被调用时，它会创建一个执行上下文，这个上下文包括了局部变量、参数、返回地址等信息。在JavaScript等语言中，执行上下文还包括this的值。
73310编辑于 2024-07-31 - 来自专栏新智元
百万token上下文能力碾压GPT-4
1,000,000 token上下文能干啥？ 众所周知，模型的上下文窗口越大，它处理给定提示时能够接纳的信息就越多——这就使得它的输出更加连贯、相关和实用。 如今，谷歌成功把这个领域「卷」到了100万token（极限为1000万token），创下了最长上下文窗口的纪录。 在这个基础之上，很多之前难以想象的应用都成为了现实。
31210编辑于 2024-02-26 - 来自专栏深度学习与python
刚刚，谷歌发布 Gemini 3：百万上下文 + 全链路 Agent直接封神！Claude 被秒成渣了
它特别适用于需要：智能体性能、高级编码、长上下文和 / 或多模态理解，以及 / 或算法开发的应用。 Gemini 从一开始就旨在无缝整合任何主题的多模态信息，包括文本、图像、视频、音频和代码。 Gemini 3 结合了其先进的推理、视觉和空间理解能力、领先的多语言性能以及百万级上下文窗口，相比之下，Claude Sonnet 4.5 和 GPT 5.1 的最大输出量停留在数万或者数十万级别。 在他看来，未来系统将依赖更长上下文、更深的工具链整合以及更强的自动化能力去完成复杂工作流，而编码能力正是这一切的地基。 如果能推出一款产品，在内存容量、上下文窗口大小上超越 GPT-5.1将极具竞争力。 一旦技术性能的增长进入平台期，企业就必须通过功能创新实现差异化，或是通过降低成本来维持竞争力。
1.2K21编辑于 2025-11-26 DeepSeek-V4-Pro 深度解析:一次面向百万级上下文的开源大模型迭代
KVCache是长上下文推理的最大成本来源——它随着上下文长度线性增长,直接吃掉显存。把它压到原来的十分之一,这是从"能跑1M上下文"到"能在合理硬件上跑1M上下文"的关键差别。 2.Manifold-ConstrainedHyper-Connections(mHC)为了让超深网络在百万级上下文中依然保持稳定的信号传播,V4引入了流形约束超连接(mHC)。 ThinkMax模式下建议上下文窗口至少384K。 第二,长上下文的成本结构被改写了。27%FLOPs、10%KVCache是非常激进的数字。 如果工程实测能贴近这个理论值,DeepSeek-V4-Pro可能成为长文档处理、代码仓库分析等场景的默认选择,因为同样的硬件能跑更长的上下文,或者同样的上下文能服务更多并发。
4900编辑于 2026-04-26- 来自专栏大模型系列
解密DeepSeek-V4 预览版Engram 记忆模块、mHC 稳定训练与百万Token稀疏注意力的三大突破——百万Token上下文的智能压缩引擎
上下文瓶颈（ContextBottleneck）：长文本处理成本高昂→DSA稀疏注意力。 提升长上下文稳定性：无论关键信息位于1MToken上下文的任何位置，Engram都能确保其被完整、无损地检索到。 第四章：第三大突破——DSA稀疏注意力：百万Token上下文的智能压缩引擎4.1挑战：O(n²)复杂度的诅咒标准的自注意力机制（Self-Attention）的计算和内存复杂度均为O(L²)，其中L是序列长度 对于1MToken的上下文，这意味着需要处理1万亿个注意力权重，这在计算和内存上都是完全不可行的。 4.4革命性成果百万上下文平民化：V4原生支持1MToken上下文，并将其作为所有官方服务的标配。资源消耗锐减：相比于V3.2，单Token的计算量（FLOPs）降低了3-10倍，显存占用大幅减少。
27620编辑于 2026-04-24 - 来自专栏AgenticAI
马斯克家Grok-4-Fast多模态推理正式发布，2百万上下文，可白嫖！
马斯克家xAI发布grok-4-fast，2M上下文，多模态推理模型，OpenRouter限时免费！ 在lm arena的search榜单斩获第一，在Text上斩获第8。 他们家自己提供的api价格大概在每百万Token输入0.2美元，每百万输出token为0.5美元。
45410编辑于 2025-11-26 - 来自专栏大模型系列
万字长文解读 DeepSeek-V4：百万上下文、万亿参数、开源免费，国产大模型迎来JPEG时刻—解密 Engram 记忆模块、MHC 稳定训练与百万Token
4月24日，DeepSeek-V4 预览版正式发布并同步开源，其核心亮点——百万Token（1M）超长上下文作为所有官方服务的标配，瞬间引爆了全球AI社区。 DSA/NSA 稀疏注意力：让百万上下文成为可能处理百万Token的上下文，最大的挑战在于 注意力机制 的计算复杂度。 中小企业、个人开发者甚至高校实验室，都能以极低的门槛使用百万上下文的顶级模型，极大地加速了AI应用的创新和落地。重塑行业工作流：法律：律师可以一次性上传整本案卷，让AI进行深度分析和摘要。 编程：理解并操作包含数百万行代码的超大型项目。 它通过“记忆-计算分离”的双轴稀疏设计，巧妙地绕开了大模型发展的传统瓶颈，将超长上下文、顶级性能和极致性价比融为一体。百万字长文对话只是起点。
1.3K100编辑于 2026-04-24 - 来自专栏运维开发故事
cpu上下文
进程的上下文 用户级上下文: 正文、数据、用户堆栈以及共享存储区；寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；系统级上下文: 进程控制块task_struct 它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。 进程上下文切换 ? 每当内核压入一个新的系统上下文层时，它就要保存一个进程的上下文。 特别是当系统收到一个中断，或一个进程执行系统调用，或当内核做上下文切换时，就要对进程的上下文进行保存。上下文切换情况： 一个进程结束，需要从队列中重新选择一个进程运行。 从逻辑上讲，新上下文层的核心栈不同于前一上下文层的核心栈。 这些指令恢复前一上下文层的寄存器上下文和核心栈，使它们和中断发生时的情况一样，并恢复该上下文层的运行。
1.1K20发布于 2021-08-13 2026年3月全球大模型全景：国产登顶、百万上下文、智能体爆发，AI进入实用新纪元
从百万Token上下文成为标配，到原生多模态与电脑控制能力成熟，再到AI智能体（Agent）从概念走向规模化商用，大模型正式告别“参数内卷”，进入效率优先、场景为王、生态重构的实用主义时代。 Anthropic Claude 4.6：百万上下文免费开放，多模态能力跃升 Anthropic于3月25日更新Claude 4.6，最大亮点是取消100万Token上下文的长文本溢价，用户可免费使用超长文本处理功能 在编程场景中，Claude 4.6可直接生成完整项目代码、排查复杂Bug，配合百万上下文，能轻松处理大型代码库的重构与优化，成为程序员的“高效助手”。 上下文：百万Token成标配，超长文档处理常态化 无论是海外巨头还是国产厂商，3月发布的新版本均已支持百万Token上下文窗口，具体对比如下： 模型名称 上下文窗口 核心优势 GPT- 百万上下文、原生多模态、Agent能力成熟，标志AI正式从“炫技”走向“实用”，成为重构全球产业与生活方式的核心引擎。
1K10编辑于 2026-04-22
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号