模型并行针对大模型:单卡装不下,就把模型拆开,不同的层放不同的卡上,按顺序跑。405B 这种规模只能这样,并且下游的卡得等上游算完中间是有空转的。 张量并行更极端:连单个矩阵乘法都塞不进一张卡。 模型大、上下文又长到几百万 Token,张量并行也顶不住。因为注意力的二次方内存增长太凶,激活值直接占满显存。128k 上下文的激活值内存是 8k 的 16 倍,这个目前没办法,因为就是这么夸张。 上下文并行更彻底:整个序列在所有模块里都切开,包括注意力。每个操作拿到的都是分区后的序列。百万级上下文的训练就靠这个,把激活值的内存占用分摊到各卡上。 Ring Attention 就是来解决这个问题的,让多节点多卡的大模型训练和推理能在大规模数据中心里跑起来。 那么训练百万级 Token 上下文的模型需要什么硬件? 多节点 GPU 集群,配 HBM 内存,加高速互连——NVIDIA NVLink 1.8TB/s 或者 InfiniBand。
本文要点 • 超长上下文并非万能:尽管最新的大模型如 GPT-4.1、Gemini 2.5 宣称支持百万甚至千万级 Token,但它们的性能会随着输入长度的增加而显著下降,这种现象被称为「上下文腐烂」( • 三大核心挑战:实验证明,在长上下文中,模型的性能会受到语义模糊性、干扰信息和上下文结构的严重影响,即使是简单的任务也会失败。 他们将这种随着输入 Token 增加,大模型性能逐渐下降甚至崩溃的现象,命名为上下文腐烂(Context Rot)。 它们处理上下文的方式并非始终如一,随着输入长度的增加,其表现会变得越来越不可靠。 换言之,你以为给了模型百万 Token 的上下文,它就能像超人一样处理所有信息。 Chroma 的研究正是从这里切入,设计了一系列实验,系统性地探究了上下文腐烂的成因。 大模型性能如何随着上下文变长而「腐烂」?
两位百万?怎么做到的? 前段时间写过一篇文章:# GPT4-Turbor 128k ? 还不够?还不够! 记得 GPT4-T 的上下文参数量 128k,也就大概 100 万英文字符、50 万汉字字符,kimi 是如何做到 double 的? 真的能做到吗? 上下文的扩充有尽头吗? 白话来说就是将上下文提示语分块、分析、加权重、插入到提示,那么:如果能无限扩充上下文长度,RAG 技术还有意义吗? Kimi 背后原理,官网做出了解释:# Kimi Chat 公布“大海捞针”长文本压测结果 这里的“针”就是“大上下文提示语”的核心,我们需要提取的、解析的核心: 有几个有意思的数据: 1、GPT-4 内部成员的回复: 思考: 以后的大模型比拼什么?两点: 1、数据的精准性-各行业 2、计算能力、解析能力-这里的大文本上下文解析就算!
一、项目概览DeepSeek-V4是DeepSeek团队推出的新一代开源混合专家(MoE)大语言模型系列。 二、三大架构升级DeepSeek-V4在架构层面相比V3.2做了三项核心改动,目的明确:把"长上下文"做得既能用、又便宜。 这套机制带来的直接收益非常可观:在1Mtoken的上下文场景下,DeepSeek-V4-Pro相较V3.2,单token推理FLOPs仅需27%,KVCache仅需10%。 2.Manifold-ConstrainedHyper-Connections(mHC)为了让超深网络在百万级上下文中依然保持稳定的信号传播,V4引入了流形约束超连接(mHC)。 第二,长上下文的成本结构被改写了。27%FLOPs、10%KVCache是非常激进的数字。
特别是,当相关信息出现在输入上下文的开头或结尾时,性能往往最高,而当模型必须在长上下文中间获取相关信息时,性能会明显下降,即使是明确的长上下文模型也是如此。 这项研究的分析使人们更好地了解语言模型如何使用输入上下文,并为未来的长上下文语言模型提供了新的评估协议。 实验结果显示,模型在处理相关信息位于输入上下文的开头或结尾时表现最好,而当相关信息位于输入上下文的中间时,模型的表现显著下降。 因此,本研究提供了对语言模型如何使用输入上下文的更深入的理解,并为未来的长上下文语言模型提供了新的评估方法。 这篇论文的研究结果和分析提供了一个更好的理解语言模型如何使用其输入上下文,并为未来的长上下文模型提供了新的评估协议。
在大语言模型的使用中,“支持32k上下文”的意思是该模型可以处理并记住最多32,000个标记(tokens)的输入。这些标记通常是文本的最小组成部分,可以是一个字符、一个单词,或一个词组的部分。 GPT模型的上下文窗口在自然语言处理任务中,语言模型有一个“上下文窗口”(contextwindow)的概念。上下文窗口是模型能够记住的输入范围,超出这个范围的内容,模型将无法直接关联。 支持32k上下文的模型展示了未来大语言模型的发展方向,也给业界带来了更多思考空间。如何在保证高效推理的同时处理海量上下文信息,仍然是未来模型优化的重要方向。一种可能的技术优化方法是分层记忆机制。 随着GPT模型和其他大语言模型的不断演进,支持更大上下文窗口的能力将继续扩展。 它不仅提高了模型处理长文本和复杂任务的能力,还展示了大语言模型在各个领域中的广泛应用潜力。从法律文本分析、代码生成到复杂对话和长篇写作,32k上下文为这些任务提供了强大的支持。
最近,老婆又又又刷到一条新闻(PS:也不知道为什么总是看新闻):“大模型靠上下文理解能力碾压传统 AI!”她一脸懵地问我:上下文不是写作文要首尾呼应吗?难道 AI 还要学语文课? 而具备上下文能力的大模型,就像贴心的助理,立刻明白“她”指代上文的罗琳。上下文的本质想象一下,上下文能力让 AI 拥有了“时间线管理术”。它不仅能记住你说过的话,还能像侦探一样串联线索。 但传统模型有三大死穴:失忆症晚期:传统模型处理完上句话立刻“格式化记忆”。比如你说“我海鲜过敏”,5 秒后问“推荐三亚美食”,它可能脱口而出“龙虾刺身”。逻辑断裂:无法理解跨句子的隐藏联系。 上下文的秘诀大模型实现上下文能力的核心,是靠两大法宝:1. 注意力织布机(Attention):自动给关键信息打高光。 上下文的局限但上下文能力并非无懈可击,仍有三大难关:记忆长度有限:就像人类只能记住最近 7 件事,以DeepSeek为例,推理模型和对话模型的最大上下文窗口均为64K tokens(约6万多个汉字),
至于 长上下文多模态场景 的大模型应用,虽然归为“浅水区”方向,但它的复杂度介于两者之间:比智能客服复杂,但又不如深水区需要极高的策略设计能力。 本文将以Qwen-long 为例,详细展示如何在 长上下文多模态场景 中发挥大模型的潜力。 需求场景为了深入展示 长上下文多模态大模型 在实际场景中的应用潜力,我们以 招标文档解读 作为示例,探索如何利用大模型高效解析长篇复杂文档并提取核心信息。 长上下文与多模态技术的基本原理长上下文(Long Context)技术旨在使模型能够处理和理解超长文本序列。传统的自然语言处理模型通常受限于固定的上下文窗口,无法有效捕捉长距离依赖关系。 其主要特点包括:超长上下文支持:Qwen-Long 模型支持最大 10,000,000 个 tokens 的上下文长度,约合 1,500 万字,能够处理超长文档和多文档对话场景,适用于代码审查、论文分析等复杂任务
从百万Token上下文成为标配,到原生多模态与电脑控制能力成熟,再到AI智能体(Agent)从概念走向规模化商用,大模型正式告别“参数内卷”,进入效率优先、场景为王、生态重构的实用主义时代。 同时,配套推出Veo 3视频生成模型,实现原生音频生成、首尾帧可控、多机位视觉一致性三大突破,生成1080P视频的时长上限提升至10分钟,视频生成正式进入“高保真+可编辑”时代,可直接用于短视频创作、产品演示等场景 Anthropic Claude 4.6:百万上下文免费开放,多模态能力跃升 Anthropic于3月25日更新Claude 4.6,最大亮点是取消100万Token上下文的长文本溢价,用户可免费使用超长文本处理功能 上下文:百万Token成标配,超长文档处理常态化 无论是海外巨头还是国产厂商,3月发布的新版本均已支持百万Token上下文窗口,具体对比如下: 模型名称 上下文窗口 核心优势 GPT- 百万上下文、原生多模态、Agent能力成熟,标志AI正式从“炫技”走向“实用”,成为重构全球产业与生活方式的核心引擎。
模型上下文协议(MCP)通过提供标准化接口满足此需求,使 LLM 能与外部资源交互。该协议是实现一致和可预测集成的关键机制。 这本质上就是模型上下文协议(MCP)的功能。 MCP 与工具函数调用 模型上下文协议(MCP)和工具函数调用是使 LLM 能与外部能力(含工具)交互并执行操作的不同机制。 对远程连接,利用 Web 友好协议如可流式 HTTP 和服务器发送事件(SSE)实现持久高效客户端-服务器通信 模型上下文协议使用客户端-服务器模型标准化信息流。 对具有固定有限数量预定义函数的简单应用程序,直接工具函数调用可能足够 可视化摘要 图 1:模型上下文协议 关键要点 以下是本章核心要点: 模型上下文协议(MCP)是开放标准,促进 LLM 与外部应用程序
背景 随着人工时代的到来及日渐成熟,大模型已慢慢普及,可以为开发与生活提供一定的帮助及提升工作及生产效率。所以在新的时代对于开发者来说需要主动拥抱变化,主动成长。 LLAMA介绍 llama全称:Large Language Model Meta AI是由meta(原facebook)开源的一个聊天对话大模型。 ~all~sobaiduend~default-1-106591160-null-null.142^v88^control,239^v2^insert_chatgpt&utm_term=windows10% Linux图: 下载羊驼模型(有点大) 先建一个文件夹:path_to_original_llama_root_dir 在里面再建一个7B文件夹并把tokenizer.model挪进来。 -f prompts/alpaca.txt -ins -c 2048 --temp 0.2 -n 256 --repeat_penalty 1.3 结果 最后 我知道很多同学可能觉得学习大模型需要懂
背景 在过去几年里,逐渐膨胀的大模型上下文,使得LLM的性能受到巨大的挑战。另外,LLM的上下文窗口有限,也使得其丢失记忆的情况很常见。 丢失细节比较容易理解,而大模型的性能,会因为压缩的上下文所提供的背景信息,以及本身也在逐渐膨胀的消息列表,仍然会比较低。 因此,寻找一种更优的大模型上下文工程方案,是我本篇文章的目标。 保留聊天的细节,让大模型记忆不丢失,甚至得到增强。2. 大模型性能不受损。关注我的公众号 wwwtangshuangnet,一起探讨Agent架构优化。 在当前的所有方案中,它们需要输出非常长的聊天历史,来遵照大模型的API接口设计。但是,目前公开研究发现,丢掉所有聊天历史,在没有历史记忆的情况下,大模型所驱动的Agent会有更准确的效果表现。 但是,这并不绝对,因为通过精准的意图识别,可以减少上下文的长度,剔除无用的信息,这又可以提升大模型首个token响应时间。
Llama 2系列又上新,这回是Meta官方出品的开源编程大模型Code Llama。 模型一发布,官方直接给贴了个“最强”标签,还强调了一把“免费可商用”。 关键是,Code Llama支持10万token上下文,这可把网友们乐坏了:这是一口气读6000行Python代码不费劲的节奏啊。 支持10万token上下文 具体而言,Code Llama可以说是Llama 2的代码专用版,你既可以通过聊天的方式让它生成代码、解决编程问题,也可以用它来调试代码。 而最受网友关注的一个功能亮点是,Code Llama的全系列模型都进行了长序列上下文微调,最长支持10万token上下文。 有网友就提到,目前GPT-4、GitHub Copliot在实际使用中的一大问题,就是上下文窗口太短,理解不了项目的整体需求。
request上下文 应用上下文和请求上下文都是存放在一个‘LocalStack’的栈中,和应用app相关的操作就必须要用到应用上下文,比如通过current_app获取当前的这个app的名字。 如果想要在视图函数外面执行相关的操作,name就必须要手动推入相关的上下文 手动推入请求上下文:推入请求上下文到栈中,会首先判断有没有应用上下文,如果没有那么就会先推入应用上下文到栈中,然后再推入请求上下文到栈中 app上下文 from flask import Flask,current_app app = Flask(__name__) #如果在视图函数外部访问,则必须手动推入一个app上下文到app上下文栈中 # 手动推入一个请求上下文到请求上下文栈中 # 如果当前应用上下文栈中没有应用上下文 # 那么会首先推入一个应用上下文到栈中 print(url_for('my_list')) 使用哪个请求上下文的时候,就把对应的请求上下文放到栈的顶部,用完了就要把这个请求上下文从栈中移除掉。
for Large-scale Learning)是一个高效且用户友好的强化学习库,专为不同类型用户设计,它不仅能够在各种硬件资源条件下高效完成多样化的训练目标,还特别针对需要大规模 GPU 资源的大语言模型 ROLL在诸如人类偏好对齐、复杂推理和多轮自主交互场景等关键领域显著提升了大语言模型的性能。 (4)质陪解决方案由中关村科金得助智能开发,创造性地融合成熟的AI大模型质检与陪练系统,推出了全面高效的“质陪解决方案”。智能质检采用大小模型结合的方式,对销售人员的销售行为进行全方位监测和分析。 (5)上下文工程上下文工程指通过为任务提供完整的背景信息,让大模型能够合理解决问题。在AI智能体的兴起发展过程中,上下文工程才是决定大多数AI智能体成败的关键而并非模型。 上下文工程致力于设计和构建动态系统而并非字符串,这些系统在恰当的时机提供信息和工具,从而让LLM拥有完成任务所需的一切。
宣布新一代 GPT 4.1 系列模型上线,此次新模型分为3个版本 —— GPT 4.1(主力旗舰)、GPT 4.1 mini(高效轻量)、GPT 4.1 nano(超小型极速),目前只能通过 API 访问 OpenAI 开发了一个用于评估模型指令遵循能力的内部评估系统,涵盖多个维度和几个关键类别,包括: 格式遵循:要求模型以特定格式(如 XML、YAML、Markdown 等)输出。 长上下文性能对于多模态应用场景同样重要,例如处理长视频。 超长上下文 除了性能方面的提升,此次新推出的 GPT 4.1 把上下文处理能力扩展到百万级 token,这意味着 GPT 4.1 可以处理100万个 token 上下文,非常适合处理大型代码库或大量长文档 许多开发者在处理长上下文时的应用场景时,需要在上下文中进行多次逻辑跳跃,比如代码时在多个文件之间跳转,或者在回答复杂的法律问题时进行文档间的交叉引用。
如何让自己使用的大模型能够像 Manus 一样,胜任各种复杂任务,应该采取哪些措施? 这就需要一种方法把各种工具和助手整合到一起。 01—什么是模型上下文协议 MCP(模型上下文协议)是一种大模型时代出现的开放协议,旨在标准化应用程序向大型语言模型 (LLMs) 提供上下文(数据)的方式。 例如,这是一个 PostgreSQL MCP Server 工具,可以让大模型能够基于 PostgreSQL 中的数据来回答问题。 如果使用API让大模型与外部工具对接,开发者需要为每个API编写独立的代码,包括文档解析、认证方式、错误处理和后期维护,费时又费力。 通过分离模型、上下文和协议,开发人员可以: 在不破坏整个系统的情况下更换不同的 AI 模型。 动态地引入新的上下文(例如,使 NLP 模型适应新的语言或行业)。 为 AI 模型编排定义强大的协议。
技术不是万能的,但没有技术却可能是万万不能的,对于大模型可能也是如此。 基于大模型的应用设计需要聚焦于所解决的问题,在自然语言处理领域,大模型本身在一定程度上只是将各种NLP任务统一成了sequence 到 sequence 的模型。 利用大模型, 我们是在解决具体的生产和生活中的问题,产品和技术上的设计仍然不可或缺。 那么,如果大模型正在重新构建软件工程的未来,我们是否应该遵循一些基本原则呢? 1. 如果输入的数据是模糊、不准确或不完整的,那么模型输出的答案也可能同样如此。 因此,为了确保LLM模型能够给出高质量、有深度的答案,需要确保输入的数据是准确、详尽且上下文丰富的。 因此,只要我们对模型进行适当的控制和引导,它就能成为我们工作中得力的“助手”。而这种控制的基础,就是我们对模型内部机制和特点的深入了解和掌握。 10.
基于笔者近年来的探索与实践,这里列举了面向大模型应用系统架构设计的10个挑战。 1. 生产环境的挑战——推理框架的选择 对于大模型应用而言,生成环境的运行时是一个推理架构。 此方法适用于需要较大上下文的任务,如文档摘要或内容提取。 递归分块:这涉及到重复地将数据分解成更小的块,通常用于分层数据结构。递归组块有利于需要多级分析的任务,如主题建模或层次聚类。 语义分块:根据意义而非结构元素对文本进行分组对于需要理解数据上下文的任务至关重要。语义块利用诸如句子嵌入等技术来确保每个块代表一个连贯的主题或想法。 尽管我们已经有了一些探索,例如《大模型应用的10个架构模式》(https://mp.weixin.qq.com/s? 虽然大模型在人工智能领域具有广泛的应用前景,但并不是所有场景都适合使用大模型。在设计系统架构时,我们需要根据具体需求和技术挑战来判断是否需要引入大模型,以确保系统的高效性和可靠性。 10.
在 DeepSeek-V4 问世之前,大模型领域长期被两大“魔咒”所困扰:规模魔咒 (Scale Curse):模型参数越大,训练过程就越像在搭建一座违章建筑,稍有不慎就会“塌方”(训练不稳定)。 此外,参数效率与上下文长度之间也存在着不可调和的矛盾。传统稠密架构的大模型,在处理长文本时,面临着算力利用率低、显存开销巨大、关键信息易丢失等核心痛点。 DSA/NSA 稀疏注意力:让百万上下文成为可能处理百万Token的上下文,最大的挑战在于 注意力机制 的计算复杂度。 中小企业、个人开发者甚至高校实验室,都能以极低的门槛使用百万上下文的顶级模型,极大地加速了AI应用的创新和落地。重塑行业工作流:法律:律师可以一次性上传整本案卷,让AI进行深度分析和摘要。 它通过“记忆-计算分离”的双轴稀疏设计,巧妙地绕开了大模型发展的传统瓶颈,将超长上下文、顶级性能和极致性价比融为一体。百万字长文对话只是起点。