- 综合排序
- 最热优先
- 最新优先
- 来自专栏DeepHub IMBA
大模型如何训练百万 Token 上下文：上下文并行与 Ring Attention
模型大、上下文又长到几百万 Token，张量并行也顶不住。因为注意力的二次方内存增长太凶，激活值直接占满显存。128k 上下文的激活值内存是 8k 的 16 倍，这个目前没办法，因为就是这么夸张。 上下文并行更彻底：整个序列在所有模块里都切开，包括注意力。每个操作拿到的都是分区后的序列。百万级上下文的训练就靠这个，把激活值的内存占用分摊到各卡上。 单卡装不下的百万级 Token 上下文，只有靠这个才能训。 Ring Attention 把 GPU 排成环，每张卡一边算当前数据的注意力，一边把键值对往下传。 上下文并行在所有模块里都切序列，包括注意力。超过 128k Token 的上下文必须用后者，因为激活值内存二次方增长太猛了。 那么训练百万级 Token 上下文的模型需要什么硬件？ 多节点 GPU 集群，配 HBM 内存，加高速互连——NVIDIA NVLink 1.8TB/s 或者 InfiniBand。
37310编辑于 2026-02-27 - 来自专栏不二小段
百万 Token 上下文并不可靠？Chroma 揭秘大模型「上下文腐烂」真相
本文要点 • 超长上下文并非万能：尽管最新的大模型如 GPT-4.1、Gemini 2.5 宣称支持百万甚至千万级 Token，但它们的性能会随着输入长度的增加而显著下降，这种现象被称为「上下文腐烂」（ 一个百万 Token 的上下文窗口意味着什么？它相当于一次性处理四本厚厚的书籍，或者数小时的会议录音。 它们处理上下文的方式并非始终如一，随着输入长度的增加，其表现会变得越来越不可靠。 换言之，你以为给了模型百万 Token 的上下文，它就能像超人一样处理所有信息。 解决问题的正确出路：「上下文工程」 既然百万 Token 的上下文窗口并不能保证可靠的性能，我们该怎么办？ Chroma 的研究指向了一个关键结论：你需要工程化你的上下文。 理论上你可以使用多达一百万的 Token，但实际上，你的最佳上下文窗口要小得多。这变成了一个优化问题：你希望最大化相关信息的数量，同时最小化不相关内容的干扰。我们称这个过程为上下文工程。
29710编辑于 2026-04-09 百万 Token 上下文窗口的工程实现与实际瓶颈
本文将探讨如何在工程上实现百万Token的上下文窗口，并分析其中的实际瓶颈。 对于百万Token的上下文窗口，我们需要考虑如何高效地存储和访问这些数据。常见的数据结构如列表、字典等在处理大规模数据时可能会遇到性能瓶颈。 分块处理和并行计算原理为了进一步提高处理效率，可以将百万Token的上下文分成多个小块，分别进行处理。这种分块处理的方式可以利用多线程或多GPU进行并行计算，从而加速整个处理过程。 总结实现百万Token上下文窗口的工程挑战主要集中在高效的数据结构和算法、稀疏注意力机制、分块处理和并行计算以及内存优化和显存管理等方面。 总结本文深入探讨了百万 Token 上下文窗口的工程实现与实际瓶颈的相关技术，从原理到实践，从基础到进阶，希望能够帮助读者全面掌握这一技术。
25410编辑于 2025-12-24- 来自专栏DeepHub IMBA
DeepSeek-V4 深度解读：百万上下文背后的工程细节
百万上下文从演示用 demo，变成了可以日常跑的工作负载。 这就是开篇那个百万上下文能用了的基础保证。 三档 RL 时用不同的长度惩罚和上下文窗口训出来；Think Max 用专门的 system prompt 引导深度推理。 V4 的差异化定位是用更激进的架构换长上下文与推理效率，代价是工程复杂度——短期内别人不容易复刻。 真正的影响在另一面：当百万上下文从贵的玩具变成日常能跑的工作负载，下一波 agentic 应用、长 horizon 任务、在线学习的探索就有了新的基础设施。这才是 V4 系列的分量所在。
90610编辑于 2026-04-28 - 来自专栏量子位
百万token上下文窗口也杀不死向量数据库？CPU笑了
有网友便列举了长上下文窗口的四大通病（四个V）： Velocity（速度）：基于Transformer的大型模型，在检索长上下文时要想达到亚秒级的速度响应仍然具有挑战性。 Value（价值）：长上下文窗口毕竟属于大力出奇迹，但它高支出的特点对于日常应用来说，在成本上是不切实际的。 高性能：单索引支持千亿级向量数据规模，可支持百万级 QPS 及毫秒级查询延迟。 低成本：只需简单操作就可以创建向量数据库实例，全流程平台托管，不需要额外的开销成本。 从这些特性不难看出，它恰好补齐了我们刚才提到的上下文窗口方式的一些短板。 借助这一项项突破，腾讯云VectorDB不仅支持多种索引类型和相似度计算方法，还具有单索引支持千亿级向量规模、百万级每秒查询率（Queries-per-second，QPS）及毫秒级查询时延等优势。
53010编辑于 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的不同步骤中使用不同的模型。
3.1K51编辑于 2026-04-24 Claude百万token上下文实测窗口变大不等于效果变好
定价方面，Opus 4.6每百万token输入5美元、输出25美元。此前超过20万token的请求输入价格翻倍，现在200K以内统一定价了。 对比一下，GPT-5.5的上下文窗口上限只有100万token，而Claude 4.7已经达到150万。但这个数字有个前提——Anthropic自己在公告里写的是"测试版百万token上下文窗口"。 但"上下文腐烂"是真实存在的问题这是大多数人不知道的事。Anthropic自己在官方博客中明确提出了"上下文腐烂"这个概念——上下文越长，模型越蠢。机制不复杂。模型的注意力是有限资源。 当上下文快撑到上限时，系统会自动触发压缩——这恰恰是上下文最长、模型表现最差的时候。你让一个已经"走神"的模型来决定什么信息重要、什么可以丢掉。 趋势判断Anthropic把百万上下文从实验功能变成默认能力，信号很明确：长上下文不再是奢侈品，而是标配。但窗口大小的军备竞赛已经接近尾声。
12300编辑于 2026-06-02《记忆革命：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证明：结构化记忆能转化为推理能力。
39300编辑于 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 交互模式 问答式 自主规划 + 工具调用 上下文能力 短期记忆 全量知识库访问 任务复杂度 单步操作 多步骤工作流编排
5.8K20编辑于 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.9K100编辑于 2024-03-23 - 来自专栏量子位
GitHub热榜第一：百万token上下文，还能生成视频，UC伯克利出品
上下文窗口长度达到了100万token，持平了谷歌同时推出的王炸Gemini 1.5，伯克利出品。 百万上下文窗口，可看1小时视频 在测试过程中，研究人员用多段一个多小时的视频检验了LWM的长序列理解能力，这些视频由YouTube上不同的视频片段拼接而成。 在1百万token窗口的“插针”检索测试中，LWM取得了单针检索全绿的成绩。 它运用了“分而治之”的思想，将长文本分成多个块，用多个计算设备做序列并行处理，然后再进行叠加，理论上允许模型扩展到无限长的上下文。
49310编辑于 2024-02-22 - 来自专栏云服务业务
腾讯云代理商： TokenHub 上线 DeepSeek V4 百万上下文普惠企业
2026 年 4 月 24 日，国内大型语言模型领域迎来一次标志性进展 ——DeepSeek 正式推出 V4 预览版本，全线产品均具备 100 万 Token 的超长上下文处理能力，能够一次性解析 70 DeepSeek V4 的主要创新点，在于原生适配 100 万 Token 上下文长度，无需分割处理、逻辑保持连贯、细节完整保留，实现长文档 “整体理解、全面解析、准确生成”。 · V4-Flash：输入费用低至 0.14 美元 / 百万 Token，输出费用 0.28 美元 / 百万 Token，缓存命中低至 0.2 元 / 百万 Token；全球节点布局，低延迟高稳定同步开通国内节点与新加坡国际站点 全行业应用场景：挖掘长文档潜在价值依托 TokenHub 的便捷接入方式与 DeepSeek V4 的百万 Token 上下文能力，不同行业可迅速解锁人工智能新价值：· 金融投资研究：一次性加载完整年度报告 总结：DeepSeek V4 的百万 Token 上下文能力，是人工智能从 “短文本交互” 迈向 “全数据理解” 的关键进展；而腾讯云 TokenHub 的首发支持、平价普及、全生态适配，则让这项先进技术不再是大型企业的专属资源
59620编辑于 2026-04-29 - 来自专栏天意云&天意科研云&天意生信云
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 在检索、记忆上下文信息方面更加精准。 许多开发者在处理长上下文时的应用场景时，需要在上下文中进行多次逻辑跳跃，比如代码时在多个文件之间跳转，或者在回答复杂的法律问题时进行文档间的交叉引用。
98010编辑于 2025-04-16 DeepSeek-V4百万上下文来了，企业数据中心准备好了吗？
上周DeepSeek-V4发布，1.6T参数的Pro和284B的Flash两个版本，原生支持百万token上下文，Agent评测成绩逼近前沿闭源模型，还在技术报告里明确写了昇腾NPU的适配验证。 存储也是一个容易被忽略的瓶颈——百万token的KVCache即使压缩过了，对读写速度的要求仍然很高。
34910编辑于 2026-04-28重磅｜DeepSeek‑V4 今日开源：百万上下文普惠，性能直逼闭源顶流
本次发布最大亮点：全系标配 100 万 token 上下文，主打长上下文普惠，在 Agent、世界知识、推理性能 三大维度，站上开源与国内第一梯队。 DeepSeek‑V4‑Pro：性能比肩顶级闭源模型 • 参数规模：总参数 1.6T，激活参数 49B • 上下文：1M tokens 输入，最大输出 384K tokens • 核心能力 1. DeepSeek‑V4‑Flash：更快捷高效的经济之选 • 参数规模：总参数 284B，激活参数 13B • 上下文：同样标配 1M tokens，输出上限 384K tokens • 核心定位 • 长上下文真正普惠 100 万 token 不再是闭源专属，开源社区可低成本落地长文档、长对话、复杂 Agent 流程。 2. V4‑Flash • Claude 用户：直接替换 API 地址与 Key • 高吞吐生产部署：建议等待下半年昇腾 950 量产 总结 DeepSeek‑V4 不只是一次模型升级，更是开源大模型迈入百万上下文时代
23110编辑于 2026-06-01- 来自专栏运维有术
DeepSeek V4 发布：1.6T 参数、百万上下文，开源模型追平闭源
它的野心不是在某个 benchmark 上多刷 1 个点，而是把百万 token 上下文从加价奢侈品变成默认配置。这篇文章，我会从技术架构、评测数据、定价策略三个维度把 V4 拆开来看。 当上下文拉到百万 token 级别，这个计算量会直接炸掉。之前的做法要么截断上下文，要么加价卖算力。DeepSeek V4 的思路不同。 打个比方：原来跑百万上下文需要 10 张卡，现在可能 1-2 张就够。这不是渐进式优化，是数量级的变化。 百万上下文的效率突破是实打实的架构创新，不是参数堆叠。编程能力追平闭源是开源模型的历史性时刻。定价策略对整个行业都是一个冲击。 如果你关注 Agent 生态，V4 的百万上下文 + MIT 开源组合，是目前很有竞争力的底座选择。你觉得 V4 的哪个特性对你最有吸引力？评论区见。
1.1K40编辑于 2026-04-28 - 来自专栏网络安全攻防
DeepSeek-V4 预览版重磅登场，百万上下文从此普惠
两者全部标配100万token的超长上下文，相当于一次可以处理三部《三体》的体量。 实测数据很有说服力：在100 万token的上下文长度下，V4-Pro处理一个新token所需的算力仅为前代 V3.2 的 27%，KV缓存更是只有前代的 10%。 正是这种极致效率，才让 1M 上下文能够成为所有官方服务的标配 V4还在以下方面实现了技术升级： 预训练上下文长度从 32K 提升至 100 万 token 强化学习阶段采用 GRPO 算法，辅以 KL
68010编辑于 2026-05-07 - 来自专栏贾志刚-OpenCV学堂
百万token上下文登场，吞下整个代码库
OpenAI的GPT-4.1提供百万token统一定价，但最强的GPT-5.4上下文窗口上限只有25.6万token。 因为它意味着，百万上下文已经从「实验功能」变成默认能力！ 而百万上下文窗口，会把这一切推向更极端的地步。 首批用户的反馈已经很说明问题。 而百万级的上下文让他们可以一次性喂入完整的diff，用更简单的架构获得了更高质量的代码审查。 而有了百万上下文之后，搜索、聚合边界条件、提出修复方案，在一个窗口里就能全部完成。
38510编辑于 2026-04-02 DeepSeek V4 技术架构深度解析：1.6万亿参数、百万上下文与三大核心突破
一、发布概况：双版本齐发，百万上下文成标配 DeepSeek V4系列一次性推出两款MoE（混合专家）模型，全部原生支持100万Token超长上下文： 模型 总参数量 激活参数 预训练数据 上下文长度 关键定位：用更大的参数池承载更多知识，用更稀疏的激活控制推理成本，用全系标配的百万上下文把长文本处理从"高端功能"变成"基础设施"。 官方直言：从现在开始，一百万上下文将是DeepSeek所有官方服务的标配。 二、三大架构突破 2.1 混合注意力机制：CSA + HCA 这是V4最核心的创新。 ，后续扩展至1M——这种"先短后长"的上下文扩展策略也是V4能高效达成百万上下文的关键工程选择之一。 DeepSeek V4不是单一维度的参数竞赛，而是一次"参数规模 × 激活效率 × 上下文长度"三者重新平衡的系统性工程： 效率革命：百万Token上下文的推理成本降至前代的27%，让长文本应用真正普及
2.3K20编辑于 2026-04-28- 来自专栏AI大模型
DeepSeek-V4来了：百万上下文为什么是开源模型的分水岭
百万上下文如何实现？ 这是此前大多数模型止步于128K-200K上下文的核心原因。DSA稀疏注意力的解决思路是什么？ 从DeepSeek-V4开始，1M上下文将成为DeepSeek所有官方服务的标配。 这意味着：•整仓库代码分析：可以将完整的中大型代码库作为上下文输入•超长文档处理：支持数百页PDF、技术手册的一次性分析•多轮对话记忆：在Agent工作流中保持极长的任务上下文不丢失•跨文件重构：理解项目全局结构后做跨模块的代码重构 3.上下文配置：本地部署时1M上下文需要额外的显存规划，可根据实际需求调整最大上下文长度4.量化选项：对于显存受限的场景，可关注社区提供的量化版本DeepSeek-V4与竞品怎么选？
1.4K10编辑于 2026-04-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号