如何将 LLM 的上下文扩展至百万级?

长上下文LLM训练技术:挑战与优化策略 大型语言模型(LLM)的上下文长度扩展是提升模型理解长文档、视频和多轮对话能力的关键技术。Transformer架构的O(n²)计算复杂度带来了内存爆炸和通信开销等核心挑战,通过激活重计算、上下文并行等工程优化可显著提升训练效率。在视频生成、法律文档分析等实际场景中,结合Flash Attention和RoPE位置编码等技术,能够实现百万token级别的长上下文处理。这些优化策略不仅解决了LLM训练中的显存瓶颈问题,也为复杂推理、低资源翻译等应用提供了新的可能性。 阅读详情

在2023年初,即便是当时最先进的GPT-3.5,其上下文长度也仅限于2k。然而,时至今日,1M的上下文长度已经成为衡量模型技术先进性的重要标志之一。

如果把 LLM 比作新时代的操作系统,上下文窗口便是它的「内存」。一个现代的操作系统需要足够大的内存才能完成各种各样的复杂任务。与之类似,一个优秀的 LLM 也需要足够长的上下文长度来完成各种复杂的任务。

基于此种观念,GLM 技术团队经过不断的技术迭代,从最初的仅支持2K上下文的ChatGLM-6B,发展到ChatGLM2-6B(32K)、ChatGLM3-6B(128K),直至现在的GLM4-9B(1M),始终在追求最领先的上下文技术能力。特别是GLM4-9B-Chat-1M,它集成了我们在长文本领域的大量研究成果。

本文将以 GLM4-9B 系列模型为例,详细介绍 GLM 团队将预训练模型的上下文扩展至百万量级的相关技术。

一、评测

我们先看 GLM4-9B 在四个评测中的效果:

1.1 LongBench-Chat 评测

这是一个 128K 长度的评测集,由人工标注问题和答案,更偏实际场景。GLM4-9B-Chat-1M 可以取得与更大参数模型接近的性能。

img

1.2 InfiniteBench

该评测是一个主要针对 100K-200K 长度的评测集,包含 12 类任务。在该评测中, GLM4-9B-Chat-1M 效果仅次于 GPT-4。

img

数据来自 InfiniteBench官方和 MInference 论文

1.3 Ruler

该评测主要用来评估模型真实的上下文长度。可以看出 GLM4-9B-Chat-1M 模型即使在 128K 依然有着良好的表现。

img

数据来自Ruler官方,有效长度指分数 >85 时的长度

1.4 大海捞针

大海捞针实验,作为评估 LLM 长文本信息处理能力最著名的实验,核心思想为在长文本中随机插入一个与文本内容不相关的句子,然后观察模型是否能够准确地从文本中提取出这个隐藏的句子。从下图可以看出,GLM-4-9B-Chat-1M 模型在 1M 的上下文长度下进行了“大海捞针”实验,达到了无损信息处理的能力。

img

二、训练流程

1M 的上下文能力,并非一蹴而就,需要经过多个阶段,来逐步激活和保持模型的长文本能力。

img

此外,在继续预训练、SFT和RLHF阶段,我们进行了小心地混合训练,来保持模型在短文本上的通用能力。

2.1 继续预训练

经过海量 Token 的预训练(Pre-Training)之后,Base Model 具备了卓越的信息捕获和推理能力。为了将这种能力泛化到长文本上,我们需要用少量长文本的 Token 对 Base Model 进行继续预训练(Continue Pre-Training)。

这一步对于激发模型处理长文本的能力至关重要。

img

具体来说,针对 GLM4-9B-Chat-1M 模型,考虑到从 8K 上下文直接跃升至 1M 的跨度过于庞大,我们采用了分两阶段的继续预训练策略。

首先,在第一阶段,我们将上下文长度扩展至128K;随后,在第二阶段,再将上下文长度扩展至1M。

当然对于 GLM4-9B-Chat模型,则仅需进行第一阶段的训练即可。

数据

为了在激活模型处理长文本能力的同时,维持其现有的通用处理能力,我们对继续预训练的数据进行了精心的混合采样策略。

具体而言,针对第一阶段扩展至128K的训练数据,其构成主要包括以下几部分:

  • 原始分布的预训练数据,大约包含4B Token;
  • 基于预训练数据,对超过8K长度的数据进行上采样,这部分数据大约有3B Token;
  • 同样基于预训练数据,对超过32K长度的数据进行上采样,这部分数据也大约有3B Token。

在处理这两类上采样数据时,我们尽量确保每个长度区间内的Token总量保持一致。例如,28K至36K区间与60K至68K区间内的总Token数应当相近。在这种均衡原则下,60K至68K区间内的数据条数大约是28K至36K区间数据条数的一半。

在构建扩展至 1M 的第二阶段训练数据时,我们遇到了一个挑战:预训练语料库中,原始文本长度超过 1M 的数据非常稀少,且分布极为狭窄,主要来源于书籍类资料。若直接沿用第一阶段训练数据的方法,将对模型性能产生不利影响。

针对这一问题,我们引入了一种新型的数据——人造长文本数据。这类数据是通过拼接现有数据而生成的,包括预训练语料中的数据和公开可获取的文档类数据。为了确保拼接数据的合理性,我们设计了一个两阶段的聚类策略:

首先,我们采样文档数据,利用语言模型对其进行分类;

然后,在各个分类下,我们使用Embedding模型获取数据的向量表示。

通过这种方法,我们在8K至1M的长度区间内,确保了每个区间内Token总量的均衡,从而生成了所需的人造长文本数据。

最终的训练数据分布如下:

  • 原始分布的预训练数据,大约包含3.5B Token;
  • 基于预训练数据,对超过8K长度的数据进行上采样,这部分数据大约有1.5B Token;
  • 基于预训练数据,对超过32K长度的数据进行上采样,这部分数据也大约有1.5B Token;
  • 基于预训练数据,对超过128K长度的数据进行上采样,这部分数据同样大约有1.5B Token;
  • 人造长文本数据,大约包含2B Token。

训练

在继续预训练阶段,我们沿用了与预训练相同的方法,但针对位置编码进行了调整和优化。

自2023年起,针对位置编码的外推研究有许多,这些研究在无需训练即可直接外推的应用场景中表现有较大的差异。然而,经过充分的继续预训练后,这些方法之间的性能差异变得相对较小。

基于这一观察,我们选择了更为简洁的一种方法,即通过调整 Rope 位置编码的 Base,对其进行扩展,以提高在处理长文本时的位置编码分辨率。

img

此外,类似于 Llama 3的预训练阶段,我们实施了带有 Attention 分隔的 Packing 训练策略。以第一阶段 128K 上下文窗口为例,每个训练样本可能由多个不同长度的独立文本组成,这些文本在 Attention 计算过程中互不干扰(采用基于Flash Attention的 Varlen 实现)。这种 Attention 分隔对于激活模型处理长文本的能力至关重要。与直接应用 128K 全注意力相比,它有效避免了建立许多无效的长距离依赖关系。

2.2 SFT

在 SFT 阶段,我们同样为长文本专门搜集了相应的 SFT 数据,并将这些数据与通用 SFT 数据进行了恰当的混合,以实现训练,确保模型在提升长文本处理能力的同时,保持其通用性。

img

数据

长文本SFT数据的质量对于提升模型处理长文本的能力极为关键。

相较于仅需从文档中抽取片段信息即可回答的简单问答问题,那些需要综合文档多处事实才能作答的复杂问题更能有效激发模型的长文本推理能力。

针对这一点,我们根据长文本的实际应用场景,筛选并区分了相应的数据来源和任务类型,并指导标注人员标注出尽可能复杂的问题及其对应答案,从而构建了我们的长文本SFT数据集。鉴于标注的难度和成本,我们仅对128K长度以内的数据进行标注。

对于GLM4-9B-Chat模型,我们可以直接使用这些标注的128K以内的长文本SFT数据。然而,对于GLM4-9B-Chat-1M模型,这些数据在长度上显然不足。因此,我们提出了三种方法,利用短窗口语言模型(SCM)来构建更长的SFT数据:

  • 单片段自我指导(Single chunk self-instruct,SCI):在给定的文本中随机选取一个片段,其长度与SCM模型的上下文窗口相匹配。从多种长文本任务模板中选择一个,让SCM模型生成一个具有挑战性的问题及其答案。最终的SFT数据由原始文本、问题和答案拼接而成。
  • 多片段自我指导(Multi-chunk self-instruct,MCI):在给定的文本中随机选取多个片段,这些片段的总长度与SCM模型的上下文窗口相当,且若文本由多个文档组成,片段应均匀分布在各个文档中。然后,从长文本任务模板中选择一个,让SCM模型生成一个需要综合多个片段信息的问题及其答案。最终的SFT数据同样由原始文本、问题和答案拼接而成。
  • 多级摘要:在给定的文本中,根据摘要总结类任务模板选择一个,将文本分割成多个短于SCM上下文窗口的片段,并要求SCM模型为每个片段生成摘要。最后,将摘要汇总,并根据任务模板的提示生成答案。最终的SFT数据由原始文本、问题和答案拼接组成。

为了验证这些方法的有效性,我们使用标注的128K长度以内的SFT数据训练了一个16K上下文窗口的模型,作为SCM模型,自动生成了新的128K长度的SFT数据。

在LongBench-Chat等下游评测集上的实验结果显示,使用新的128K长度SFT数据训练得到的模型与使用标注的128K长度SFT数据训练得到的模型性能相近,这证明了我们基于SCM模型的方法可以几乎无损地构建更长的SFT数据。

在最终的数据构建过程中,我们采用GLM4-128K作为SCM模型,生成了最大长度为1M,最小长度为128K的SFT数据。这些数据与标注的128K长度以内的SFT数据共同构成了GLM4-9B-Chat-1M模型的长文本SFT数据集。

训练

在训练过程中,我们将通用 SFT 数据与长文本 SFT 数据进行了混合训练,并采纳了一种创新的训练方法 —— Sorted Packing。正如 LongAlign 论文所述,长短文本混合 SFT 的高效训练方法主要有两种:Packing 和 Sorted Batching。Sorted Batching 可能会引入某些先验知识,即同一批次内的数据长度趋于一致,这有可能导致不良的训练效果。相比之下,Packing 策略能够直接利用 Flash Attention 的 Varlen 实现,效率较高,因此被 Megatron-LM 等主流训练框架所采用。

img

然而,在长文本 SFT 阶段,Packing 内部的不均匀复杂性可能导致大量的 GPU 空闲时间,即所谓的“气泡时间”。以下图为例,两个均为 128K 的 Pack 序列,一个由四个 32K 的序列组成,另一个由一个 110K 和一个 18K 的序列组成,它们的计算量(图中深色部分)差异显著。这导致两个 Pack 序列的计算时间存在较大差异,即计算速度快的副本需等待计算速度慢的副本完成梯度同步,从而产生了显著的 GPU 气泡时间。

img

从下图中可以看出,如果直接采用 Packing 训练,训练时间的波动较大。

img

这种现象在短文本的 Packing SFT 训练中并不明显,原因在于计算量的差异较小,且 Attention 计算在总计算量中所占比例不高。但在超长文本的训练中,这一现象就比较明显了。为了解决这一问题,我们融合了 Packing 和 Sorted Batching 的优点,提出了 Sorted Packing 训练方法。我们根据计算量来构建同一批次内的 Pack,确保同一批次中各个 Pack 数据的计算量相近,从而减少了气泡时间。此外,我们还引入了梯度累积技术,以避免排序带来的偏差。

最后,正如 LongAlign 论文所指出的,不同 Pack 包含的数据量不同,可能会导致 loss 计算的不均衡。因此,我们也采用了 Loss Reweighting 策略,对 loss 进行重新平衡。

2.3 RLHF(DPO)

在 RLHF 阶段,我们采用 DPO 来尽可能降低训练 Infra 所面临的挑战。在此阶段,我们主要需要解决的问题是如何构建长文本 DPO 数据。

我们沿用与短文本相同的 Reward 模型来对长文本的答案进行评分。为了防止超出 Reward 模型的上下文限制,我们仅保留了问题和答案,而舍弃了文档等长输入。我们还尝试了使用 GLM4-128K 等语言模型作为长文本的 Reward 模型,以便基于所有输入自动生成最终的回答排序。

然而,实验结果显示,长文本语言模型直接作为 Reward 模型时,结果波动较大,并未产生预期的效果,不如直接使用短文本的 Reward 模型。

我们认为,对于长文本 RLHF 而言,训练长文本 Reward 模型至关重要。但目前,长文本 Reward 模型的数据标注极具挑战性,我们仍需持续探索,以寻找合理的训练长文本 Reward 模型的途径。

三、训练 Infra

在大型模型的长文本训练中,Infra 层面面临的主要挑战是中间变量 Activation 的显存占用显著增加。然而,我们对现有主流的 3D 并行策略进行分析后发现,它们在解决这一问题上均存在一定的不足之处:

  • 张量并行 TP:能够降低 Activation 的显存占用,但由于通信量过大,通常不适合跨机使用,且并行度一般不超过 8;
  • 流水线并行 PP:为了保持效率,通常需要增加 micro batch,但在保证效率的同时,对减少 Activation 的显存占用并无显著效果;
  • 数据并行 DP:并不能减少单个数据样本的显存占用。

此外,还有一些方法可以直接减少 Activation 的显存占用,例如 Activation Checkpointing。然而,这种方法的帮助是有限的,为了确保效率,通常不会将所有的 Activation 都释放后重新计算。另外,当输入序列过长时,可能在 Forward 阶段就已经出现了显存不足的问题,这是 Activation Checkpointing 技术也无法解决的。

3.1 序列并行

为了解决这个问题,一种新的并行方法——序列并行(Sequence Parallelism)被提了出来。其核心动机在于:在 Transformer 架构中,只有进行 Attention 计算时,token 之间才需要进行交互,而在其他部分,token 之间是相互独立的。基于这一观察,序列并行仅在 Attention 部分进行并行处理,而在其他模块中,则将一个长序列视为多条数据,类似于数据并行 DP 进行处理。

目前,序列并行主要有两种主流实现方式,即 Ring Attention 和 DeepSpeed Ulysses。其中,Ring Attention 在 Megatron-LM 中得到了优化实现,并被命名为 Context Parallel。这两种主流的序列并行方法各有其优势和不足之处。

Ring Attention:

优点:并行度的扩展性较好,没有明显的限制;在使用 GQA 时,通信仅限于 Group 内的 kv,通信量相对较小;

缺点:需要计算和通信之间有较好的掩盖才能达到较高的效率;对 Sparse Attention 及其他 Attention 变种的改动不够友好,它侵入式地修改了 Attention 的实现。

DeepSpeed Ulysses:

优点:没有侵入式地修改 Attention 的实现,对各种 Sparse Attention 及相关改动较为友好;通信次数较少。

缺点:所有并行副本都需要完整的模型参数,对 ZeRO 之外的并行分切策略不太友好;并行度相对有限,一般不超过 GQA 的 Group 数量,否则需要额外的通信。

3.2 变长序列并行

为了与主流的 Megatron-LM 训练框架兼容,GLM4-9B-Chat-1M 在训练中采用了 Context Parallel,即 Ring Attention 的序列并行方式。然而,正如前文所述,模型在多数阶段都需要采用 Packing 的变长训练,而这一点在 Ring Attention 中并非原生支持。为了实现变长训练,我们使用了以下三种解决策略。

循环变长

对于包含多个序列的 Pack 数据,我们可以将每个序列单独拆分,并循环应用 Ring Attention 来计算每个序列的 Attention 结果。最后,将输出结果按顺序拼接即可。当 Pack 中的序列数量较少时(例如,128K 的 Pack 中包含 4 个 32K 的序列),这种方法的效率较高,因为无需引入额外计算,循环的时间开销相对较小,且每个子序列都能充分利用 GPU 的并行计算能力。然而,当 Pack 中的序列数量较多时(例如,128K 的 Pack 中包含 128 个 1K 的序列),这种方法效率会显著下降。由于每个子序列较短,无法充分利用 GPU 的并行计算能力,循环引入的开销变得不容忽视。

原生变长

原生变长序列并行是指对 Ring Attention 进行相应修改,使其能够原生支持变长序列的 Ring Attention 计算。与循环变长相比,这种方法在效率上有了显著提升,无论是 Pack 中包含的子序列多还是少,都能保持高效的计算效率。然而,当上下文长度极长(如 1M)且 Pack 内的子序列长度差异较大时,这种方法的显存占用会大幅增加,显著高于循环变长的实现。因此,我们无法直接使用原生变长的 Ring Attention 来训练具有超长上下文的大语言模型(如 GLM4-9B-Chat-1M)。

分治变长

为了克服超长上下文训练的挑战,我们结合了上述两种变长策略,提出了一种新的分治变长序列并行方法。对于包含 128 个子序列的 Pack,我们将其分为若干个子 Pack,例如分为 4 个子 Pack,每个子 Pack 包含若干子序列。在这里,我们会尽量均匀地将子序列分配到各个子 Pack 中。然后,我们分别对每个子 Pack 使用原生变长循环计算输出,最后将 Attention 的输出拼接在一起。分治变长序列并行在充分利用 GPU 并行计算能力的同时,降低了显存的峰值使用,使得变长训练能够扩展到超长上下文的训练中。

(完)
​

如何学习大模型

现在社会上大模型越来越普及了,已经有很多人都想往这里面扎,但是却找不到适合的方法去学习。

作为一名资深码农,初入大模型时也吃了很多亏,踩了无数坑。现在我想把我的经验和知识分享给你们,帮助你们学习AI大模型,能够解决你们学习中的困难。

下面这些都是我当初辛苦整理和花钱购买的资料,现在我已将重要的AI大模型资料包括市面上AI大模型各大白皮书、AGI大模型系统学习路线、AI大模型视频教程、实战学习,等录播视频免费分享出来,需要的小伙伴可以扫取。

一、AGI大模型系统学习路线

很多人学习大模型的时候没有方向,东学一点西学一点,像只无头苍蝇乱撞,我下面分享的这个学习路线希望能够帮助到你们学习AI大模型。

在这里插入图片描述

二、AI大模型视频教程

在这里插入图片描述

三、AI大模型各大学习书籍

在这里插入图片描述

四、AI大模型各大场景实战案例

在这里插入图片描述

五、结束语

学习AI大模型是当前科技发展的趋势,它不仅能够为我们提供更多的机会和挑战,还能够让我们更好地理解和应用人工智能技术。通过学习AI大模型,我们可以深入了解深度学习、神经网络等核心概念,并将其应用于自然语言处理、计算机视觉、语音识别等领域。同时,掌握AI大模型还能够为我们的职业发展增添竞争力,成为未来技术领域的领导者。

再者,学习AI大模型也能为我们自己创造更多的价值,提供更多的岗位以及副业创收,让自己的生活更上一层楼。

因此,学习AI大模型是一项有前景且值得投入的时间和精力的重要选择。

突破大模型极限!GLM-4-long百万长文本模型上线bigmodel.cn 最近业务上多了长文本的需求,因为要在prompt里面塞进比较多的rag内容,以供决策,且这些召回的内容,都有可能用到。智谱果然是国产大模型开源事业的排头兵,如果把国产化大模型看成一个整体的话,开源确实会继续整个群体的智力水平和互相交流不断进步,把整个行业的蛋糕越做越大,最终使整个群体收益。“第一个,就是你之前bert时候打比赛中常用的,batch sort方法,让一个batch中的样本尽量对齐,这样需要packing的空间就很少了,提高资源利用率。对了,我刚刚给你说的那些,之前开源的技术报告里都有。 阅读详情

相关推荐

小白学大模型:L-Eval 长文本评测

Coursera:这个数据集来源于Coursera网站上的公共课程,特别是与大数据和机器学习相关的课程。输入的长文档是视频的字幕,问题和正确答案由作者标注。Coursera数据集的特点是采用多项选择的指令格式,并设置了多个正确选项,这增加了任务的难度。SFcition:这个子任务是为了测试LCLM对输入上下文的忠实度。作者认为,在LCLM中,上下文知识(存储在长输入中)比参数知识(在预训练期间获得)更为重要。

2401_85324918的博客 949

GLM-4-Long:一百万字符的智能处理与应用探索

GLM-4-Long是BigModel.cn推出的一款先进语言模型,专为应对超长文本处理挑战而设计。与传统语言模型不同,GLM-4-Long致力于提升处理大规模文本的效率和准确性,能够处理长度达到一百万字符的文本,为大规模数据处理提供了强大的支持。为了对文档进行处理,我们使用GLM-4-Long模型进行总结和多轮问答。client = ZhipuAI(api_key="your_api_key") # 替换为你的API Key。

不想宅的冷同学 4371

标签噪声:综述 Learning from Noisy Labels with Deep Neural Networks: A Survey

Learning from Noisy Labels with DNN: Robust architecture, robust regularization, robust loss function, loss adjustment, sample selection

doctor_strange**** 1万+

如何将大模型的上下文扩展至百万级

最近这一两周看到不少互联网公司都已经开始秋招提前批了。不同以往的是,当前职场环境已不再是那个双向奔赴时代了。求职者在变多,HC 在变少,岗位要求还更高了。最近,我们又陆续整理了很多大厂的面试题,帮助一些球友解惑答疑,分享技术面试中的那些弯弯绕绕。在2023年初,即便是当时最先进的GPT-3.5,其上下文长度也仅限于2k。然而,时至今日,1M的上下文长度已经成为衡量模型技术先进性的重要标志之一。如果把 LLM 比作新时代的操作系统,上下文窗口便是它的「内存」。

机器学习社区 1658

LLM记忆终极指南:从上下文窗口到高级智能体记忆系统

AI记忆技术的演进,本质上是让机器从"健忘的工具"成长为"有持续认知的伙伴"。这一旅程始于对上下文窗口限制的理解,经过缓冲、总结、检索等阶段,最终迈向能构建知识网络、主动调用记忆的智能体。

llm_way的博客 9815

【深度学习新浪潮】什么是上下文长度?

大型语言模型(LLM)的上下文长度是指模型在处理当前输入时能够有效利用的历史文本长度,通常以token(如单词、子词或标点)为单位衡量。例如,GPT-4支持128K token的上下文,而Llama 4 Scout甚至达到了10M token的惊人规模。这一指标直接影响模型在长文档理解、多轮对话等复杂任务中的表现。

专注:太空算力、AI infra、异构调度、大模型成本工程 666

深度思考:当 LLM 进化到能够处理百万级 Token 后,‘分块(Chunking)’这个概念是否会从 RAG 中消失?

各位同仁,下午好!今天,我们齐聚一堂,探讨一个在RAG(Retrieval Augmented Generation,检索增强生成)领域中既基础又充满变革潜力的话题:当大型语言模型(LLM)的上下文窗口拓展至百万级Token时,我们今天所熟知的“分块(Chunking)”概念,是否会从RAG的工作流中彻底消失?作为一个在编程领域深耕多年的专家,我将从技术和工程实践的角度,为大家剖析这一演进对我们未来系统设计可能带来的深远影响。

weixin_41455464的博客 880

cut&tag学习笔记

上图是我得到的结果,下图是教程的结果,比对结果有一些差异,我也不知道具体原因是啥。谷歌了一下,发现原因可能是因为环境变量的问题,系统不知道picard的具体位置,需要设置全局环境变量,遂查了一下picard的位置。我发现我做出来的结果测序深度一致,但是比对的结果有一点差异,不知道是我的操作问题,还是参考基因组更新了导致比对结果出现了些许不同。上图是我得到的结果,下图是教程的结果,除了IgG_rep1外比对结果一致。上图是我的结果,下图是教程的结果,结果不太一致,不知道是具体的原因是什么。

weixin_52073820的博客 2423

TensorRT-LLM推理性能实测:Blackwell架构下的极致优化

基于NVIDIA TensorRT-LLM在Blackwell GPU上的实测数据,深入分析FP4量化、N-Gram投机解码与分布式扩展对大模型推理性能的影响。结果显示单卡吞吐提升达275%,多轮对话延迟降低90%,为Llama、DeepSeek等大模型提供高性价比部署方案。

weixin_35019679的博客 723

iPad秒变Mac副屏的隐藏技巧:用BetterDisplay实现无线竖屏+90度锁定

本文详细介绍了如何利用BetterDisplay软件突破苹果原生“随航”(Sidecar)功能的限制,将iPad无线设置为Mac的竖屏副屏,并实现90度方向锁定。通过创建虚拟显示器、配置分辨率与旋转参数,并校准鼠标指针,用户可以高效利用iPad的纵向空间进行文档阅读、编码等工作,显著提升多屏协作效率。

weixin_29266647的博客 603

自考计算机系统原理(第六章计算机系统概论)-13015

名词解释 I/O 硬件 I/O软件 用户空间I/O软件 内核空间I/O 软件 系统调用处理程序 系统调用服务例程 设备驱动程序 中断服务程序 系统级1/O函数 虚拟文件系统 文件描述符 文件元数据 流缓冲区 索引节点 目录文件 目录项 系统打开文件表 磁盘高速缓存 高速缓存 RAM I / O 控制方式 程序直接控制I/O 就绪状态 中断控制I/O 中断屏蔽字 多重中断 中断嵌套 DMA 方式 DMA 控制器 设备控制器 I/O端口 控制端口 数据端口 状态端口 I/O 地址空间 独立编址方式 统一编址方

qq_23872947的博客 1150

智谱运气是差一点点,视觉Token研究又和DeepSeek撞车了

芝士 AI 吃鱼这不巧了吗……智谱和DeepSeek,又双叒撞车了。太卷了,DeepSeek-OCR刚发布不到一天,智谱就开源了自家的视觉Token方案——Glyph。或许你也会对我们的工作感兴趣。发论文就发论文,怎么还争上宠了。(doge)网友调侃be like:AI界也有自己的霸总爱情片。

wwlsm_zql的博客 956

SAPGUI excel 导出时遇到的运行时错误:STRING_SIZE_TOO_LARGE

当报表导出需求远超单一 XLSX 文件的物理承载力时,与其在 SAPGUI 中硬拼 2 GB 限制,不如把分页、过滤、流式写入作为设计前提。掌握 ABAP2XLSX 或 CSV + Power Query 等工具链,既能满足审计合规,又能让应用服务器远离的噩梦。祝你在下一次导出海量数据时,既高效又优雅。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 641

Browser-Bridge 新版本中关于 MCP 和 CLI 的设计取舍

这篇文章讲述了作者在开发Browser-Bridge工具时集成方式的思考过程。最初受一篇文章影响,作者为避免系统提示词过长占用宝贵上下文窗口,选择了CLI+SKILL的集成方式。但在实践中发现Agent无法智能调用工具,需要用户手动触发。后来意识到随着大模型上下文窗口的扩大(从4K到1M),原先的优化变得不再必要,于是推翻原有设计,改为支持MCP集成方式。这一转变反映了作者对"真正优化"认知的变化:不应过早做减法,而应保留足够空间。最终版本支持了MCP调用,使工具功能更易被模型理解。

Dkisser的博客 263

Java与OSG的梦幻联动:深入编译OpenSceneGraph的Java JNI桥梁,开启3D视觉盛宴的奇幻之旅

🔥关注墨瑾轩,带你探索编程的奥秘!🚀🔥超萌技术攻略,轻松晋级编程高手🚀🔥技术宝库已备好,就等你来挖掘🚀🔥订阅墨瑾轩,智趣学习不孤单🚀🔥即刻启航,编程之旅更有趣🚀在编译OpenSceneGraph (OSG) 的Java版本时,首先需要了解OSG本身是一个主要用于3D图形和视觉仿真的开源库,它主要支持C++。然而,OSG 也支持通过JNI(Java Native Interface)与Java集成,这允许Java程序调用OSG的C++库。

java专栏 870

【电源专题】LDO基础——热性能2

对于LDO散热而言,选择合适的元件并不是一件简单的任务。为了实现高效、尺寸得当并成本低的散热解决方案,我们在早期设计阶段就需要确保所有器件都可用并且已经考虑到元件和各种特性。

一点硬件 895

SGLang适合哪些场景?这5种用法最实用

本文介绍了如何在星图GPU平台上自动化部署SGLang-v0.5.6镜像,高效支撑结构化数据提取等生产级AI应用。通过该镜像,开发者可快速实现客服对话意图识别、RAG元数据抽取等典型场景,显著提升API输出稳定性与推理吞吐效率。

weixin_35755562的博客 423

有道龙虾LobsterAI vs. OpenClaw:对比与安装部署攻略

LobsterAI是"中国版OpenClaw",更注重易用性和中文场景适配;OpenClaw是技术极客的玩具,需要大量命令行操作。

lpfasd123的博客 2396

LLM 的「上下文长度扩展」

大语言模型的上下文扩展机制

ChinaLiaoTian的博客 1254

【Windows Server 2019】活动目录 (Active Directory) ——理论

博文介绍了活动目录 (Active Directory) 的定义,作用以及与 DNS 的关系。同时也介绍了AD的组织结构,包括域控制器,子域,对象,属性,容器,组织单位,域间信任等术语的解释,实验拓扑图。

VMware, Windows, Linux, Cisco, Container, Kubernetes, Kali 7747

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

全面了解LLM上下文工程(三):揭开AI拥有百万级token的谎言

在上一篇中,我们探讨了“上下文腐烂”(Context Rot)这一现象,揭示了大模型在面对超长上下文时表现不稳、性能退化的现实挑战。

huang9604的博客 1483

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

阿里 Qwen2 模型开源,教你如何将 Qwen2 扩展到百万级上下文

这个也是阿里开源的,特别是在本地使用 Qwen2-0.5B、Qwen2-1.5B 这类上下文长度有限的模型时,通过 Qwen-Agent 框架,能够把处理的上下文扩展到 1M,整体采用的是代理式 RAG(Agentic RAG)思路,具体的做法分为三步。例如,将用户查询转为{"信息": ["自行车是什么时候发明的"], "指令": ["回答时用 2000 字", "尽量详尽", "用英文回复"]}。英文": ["bicycles", "invented", "when"], "关键词。

具身机器人和通用AI 1954

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

NVIDIA Rubin CPX:为百万级Token上下文工作负载加速推理性能与效率

NVIDIA在COMPUTEX 2024推出Rubin平台,其核心创新是专为LLM预填充阶段设计的CPX处理器。该处理器与Rubin GPU协同工作,通过异构计算解决百万级Token上下文带来的计算瓶颈。CPX针对预填充阶段的计算密集型特性进行优化,与GPU分工协作:CPX处理预填充,GPU专注于生成阶段。这种架构使预填充性能提升4倍,整体推理性能提升3倍,同时能效提高1.5倍。平台采用MGX模块化设计,支持NVLink 6高速互连,并配合TensorRT-LLM和NIM软件生态,为超长上下文AI应用提供端

专注于人工智能领域的小何尚 1272

当大模型上下文窗口扩展到100万Token:业务场景的颠覆性变革

当大模型上下文窗口扩展到100万Token:业务场景的颠覆性变革

嗨,欢迎来到我的 优快云 博客小天地!一名深耕多年的技术发烧友。在这里,我将把日常工作中积累的宝贵经验,从复杂架构设计的精妙之处,到代码优化的实战技巧,毫无保留地分享给大家。 7035

闻达LLM平台:百万级知识库检索性能优化终极指南

闻达是一个针对特定环境高效内容生成的大规模语言模型调用平台,专注于解决个人和中小企业的计算资源局限性和知识安全私密性问题。本文将深入探讨如何优化闻达平台的百万级知识库检索性能,让您的LLM应用实现质的飞跃!🚀 ## 知识库架构与性能瓶颈分析 闻达平台支持多种知识库模式,其中RTST(本地离线向量库)模式是处理百万级数据的核心方案。该模式基于sentence_transformers+fais

gitblog_00772的博客 1209
上一篇: 万字干货|复杂表格多Agent方案:从LLM洞察、系统性思考到实践经验总结
下一篇: 真不夸张!这是我读过最通透的LangChain大模型神书!《​基于LangChain进行生成式AI开发》
少喝冰美式
博客等级 码龄3年 6839粉丝 517原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值