-
吐血整理 Bolt.diy 部署与应用攻略 1.前言 以前总是有很多人无代码基础的人总是在幻想，如何不要自己写代码就可以建立一个自己的创意网站呢？之前总觉得异想天开不可能，屏幕前的你是不是也是这么想的呢，没有想到，Bolt.diy帮你实现了，快来看看怎么回事吧！ 领取免费额度，一键部署Bolt.diy：https://image.baidu.com/search/down?url=https://www.aliyun.com/solution/tech-solution/fc-bolt-diy?utm_content=g_1000403257 想怎么建就怎么建。 2.Bolt.diy是什么？ \*\官方说法：\\*Bolt.diy 是 Bolt.new 的一个开源版本，它提供了更高的灵活性和可定制性，通过自然语言交互简化开发流程，并提供全栈开发支持，同时允许用户二次开发。本方案基于函数计算 FC 搭建，集成了阿里云百炼模型服务，旨在实现 Bolt.diy 的快速云端部署。 本人通俗理解：就是你把它当作一个程序员，而你是产品经理，而且它是那种不会反抗、抱怨、听话的程序员，你把你的需求告诉它，它就会帮你一一实现。 3.准备工作 开始部署前，请按以下指引完成账号申请、账号充值。 3.1账号准备 1.如果您还没有阿里云账号，请访问阿里云账号注册页面，根据页面提示完成注册。 2.百炼提供的新人免费额度可以完全覆盖本教程所需资源消耗。额度消耗完后按 token 计费，相比自行部署大模型可以显著降低初期投入成本。 3.函数计算提供的试用额度（点此领取）可以完全覆盖本教程所需资源消耗。额度消耗完后按量计费，对于本教程所涉及的Web服务，只在有访问的情况下才会产生费用。 3.2资源准备 1.如果您是首次访问阿里云百炼服务平台，请按照以下步骤进行开通。 （1）登录阿里云百炼大模型服务平台。 （2）根据页面提示签署阿里云百炼服务协议，然后单击页面顶部的开通服务按钮，并按照提示进行开通。 2.如果是首次使用函数计算，请先开通函数计算服务。 （1）登录函数计算服务控制台，根据页面提示完成开通。 （2）开通后，登录函数计算服务控制台，完成阿里云服务授权。 3.3部署应用 1.请点击前往部署打开我们提供的云原生应用开发平台 CAP 项目模板，参数选择默认配置，然后单击部署项目，最后在弹出面板中单击确认部署，部署预计等待 1 分钟。 说明 首次使用云原生应用开放平台 CAP 会自动跳转到访问控制快速授权页面，滚动到浏览器底部单击"确认授权"按钮，等待授权结束后单击返回控制台。宏哥就是首次使用，如下图所示： 2.部署完成后，如下图所示： 3.4访问应用 1.经过前边步骤的操作，应用已经部署好了，我们来访问一下，看是否部署成功。按照下图找到访问地址。也就是部署完成的那个界面，如下图所示： 2.点击访问地址，在浏览器中，会自动跳转为 HTTPS 链接地址。提示安全证书警告或错误，可以选择点击高级选项，然后点击继续前往以访问该网站。如下图所示： 3.即可访问到我们部署的应用网站，如下图所示： 3.5接入百炼大模型 因为解决方案要通过API来接入百炼大模型，所以为了安全访问百炼大模型，我们需要我登录阿里云百炼大模型服务平台，创建并复制了 API-KEY，才可以访问百炼大模型。如果你在其他应用接入过，那么这里的操作就和之前的差不多，非常简单。具体操作步骤如下：1.登录阿里云百炼大模型服务平台。单击顶部应用，在左侧导航栏单击API-Key。选择全部API-KEY或我的API-KEY，然后创建或查看API-KEY。单击操作列中的复制按钮，复制API KEY。如下图所示： 配置百炼 API-KEY。将其粘贴到 Bolt.diy 的配置界面中完成百炼 API-KEY 的设置。如下图所示： 3.配置完成，变成绿色，如下图所示： 4.然后，我们就可以调用百炼大模型，单击提示词就可以就行创作了。如下图所示： 5.以下就是根据你的提示词，建立的网站，如下图所示： 6.当然了，你也可以输入自己的提示词，搭建自己想要的网站。 4.部署完成后，使用Bolt.diy进行了哪些尝试？ 部署成功后，我尝试了几种不同的应用场景来测试Bolt.diy的功能： 快速原型设计：利用简单的自然语言指令，比如"创建一个展示商品列表的React组件"，Bolt.diy迅速生成了相应的前端代码。这极大地加快了从想法到具体实现的过程。参考Prompt："请帮我写一段React代码，用于显示一组产品信息。" 教育工具开发：考虑到Bolt.diy非常适合教学目的，我还构建了一个小型在线学习平台，其中包含课程管理、学生进度跟踪等功能。这个过程同样依赖于Bolt.diy提供的全栈开发支持。参考Prompt："为我的在线课程网站添加用户注册功能。" 企业级应用：最后，为了探索更复杂的应用场景，我尝试着整合了一些内部业务逻辑，比如客户关系管理系统(CRM)的部分模块。虽然这部分工作相对复杂，但Bolt.diy依然表现出了良好的适应性和扩展性。参考Prompt："集成一个联系人导入导出功能到现有的CRM系统中。" 5.结合个人背景，如何使用Bolt.diy？ 作为一名软件开发者，我认为Bolt.diy可以在以下几个方面发挥重要作用： 加速项目启动 ：无论是个人小项目还是团队合作的大工程，Bolt.diy都能帮助我们快速搭建起基础架构，节省大量时间。 促进学习交流 ：对于初学者而言，它提供了一个直观的学习平台；而对于经验丰富的工程师来说，则是一个分享知识的好工具。 提高工作效率：特别是在面对重复性任务时，通过自动化代码生成可以显著提升生产力。 6.体验过程中遇到的问题 在整个部署和使用过程中，我发现的主要挑战在于理解各个云服务之间的相互作用机制。尽管文档提供了详尽指导，但对于新手来说可能仍有一定难度。此外，某些高级功能的配置也需要更多实践才能完全掌握。希望未来能有更多针对不同水平用户的教程资料发布。 -
-
超融合虚拟化和容器环境 GPU 支持性能测试：基于 NVIDIA T4 与 A30 我们在 DeepSeek 解决方案文章中提到，SmartX AI 基础设施支持虚拟化及容器环境下的两种 GPU 使用方式，即 GPU 直通与 vGPU，为多种大模型应用场景提供灵活、高性能的 GPU 资源。 为帮助用户进一步了解 SmartX 超融合 GPU 直通与 vGPU 功能的性能表现， 近期我们基于两款 GPU 卡（NVIDIA T4 和 A30），测试了 SmartX 超融合在虚拟化和容器环境（采用 SMTX Kubernetes 服务）下基于多种 AI 测试工具的具体性能，并与物理机/裸金属环境的性能进行对比。 重要结论： 在虚拟化和容器（SKS 和 Docker）环境下，SmartX 超融合采用 GPU 直通与 vGPU 功能，均可为两款 GPU 卡提供良好的性能支持，在多个模型测试中获得接近物理机环境的性能（基本在 90%-110% 范围内浮动）。 物理机、超融合虚拟化、SKS、裸金属 Kubernetes 支持 GPU 的性能表现差异不明显，验证了 SmartX 超融合虚拟化和容器环境均可为 GPU 应用场景提供良好的性能支持。 1 基于 NVIDIA T4 的性能测试 1.1 测试目标 测试 SmartX 超融合在虚拟化、容器环境下采用 GPU 直通和 vGPU 功能的性能表现（vGPU 采用不同的切分方式，验证 vGPU 算力的切分是否线性，以及多实例环境下的性能表现）。 对比物理机和裸金属环境下，SmartX 超融合在虚拟化、容器环境下 GPU 的等算力池化方案损耗情况。 综合 GPU 算力利用率和算力分配的灵活度，讨论基于 SmartX 超融合最佳的 GPU 算力使用方案。 1.2 测试环境 1.2.1 测试硬件 以物理 GPU 所在节点为例： 1.2.2 基础平台软件及版本 1.2.3 测试工具及版本 （1）TensorFlow Benchmark TensorFlow Benchmark 是一个开源的基准测试框架，包含了 PerfZero 和 scripts/tf_cnn_benchmarks。本次测试主要采用 PerfZero，PerfZero 是 TensorFlow 基准测试框架中最先进且全面的子项目，提供吞吐量、延迟、内存使用等详细的性能指标，支持自定义测试场景和指标。本次测试主要关注 PerfZero Throughput（吞吐量）的输出结果，包括每秒处理的样本数量（exp_per_second），以及模型在每秒内平均能处理的样本数量（avg_exp_per_second）。这两个指标的单位均为 examples/sec，数据越大性能越好。其中，avg_exp_per_second 是在所有迭代完成后计算得出的平均值，能够反映模型的整体性能表现。而通过观察 exp_per_second 的变化，我们可以进一步分析模型性能在不同阶段的波动情况，从而为性能优化提供有力依据。 （2）AI Benchmark AI Benchmark 是一个开源 Python 库，用于评估各种硬件平台（包括 CPU、GPU 和 TPU）的 AI 性能。AI Benchmark 的输出结果通常包含总评分（Overall Score）以及各个单项测试的得分。本次测试主要关注 train score（训练得分） 、Inference（推理得分）和 Device AI Score，其中后者是前两项得分的总和，旨在衡量设备在训练和推理两个关键环节上的综合能力。分数越高，设备的 AI 处理能力越强。 （3）GPU Burn GPU Burn 是测试 GPU 稳定性和性能的压力测试工具，通过长时间让 GPU 运行密集计算任务，来测试显卡在高负载条件下的表现，从而评估显卡的散热能力、性能极限，以及在长时间高负荷下是否会出现问题（如崩溃、过热、降频等）。本次测试主要关注性能（FLOPS）的输出结果，GPU Burn 会输出浮点运算每秒（FLOPS）的值（单位：Gflop/s），表示 GPU 在测试期间执行的计算量，数值越大，代表 GPU 性能越好。 1.3 测试项目及步骤 ::: hljs-center 备注：16Q 表示该虚拟 GPU（vGPU）配备了 16GB 的显存，8Q 代表 8GB 显存，4Q 代表 4GB 显存。后缀 “Q” 标识这些 vGPU 使用的是 Q 系列切分方式。 ::: 1.4 测试结果 1.4.1 实测性能数据 1.4.2 单实例性能折损数据 为了更准确地计算和分析不同超融合环境相对于裸金属环境的性能损耗，将每个单实例测试项下的数值与物理机环境下的数值进行对比，计算每个配置相对于物理机环境的性能百分比，并据此得出性能损耗。 对于每个单实例测试项目，使用以下公式来计算性能百分比：性能百分比=(特定配置下的值/物理机环境下的值) * 100%。 性能损耗可以通过以下公式计算：性能损耗=100%-性能百分比 ::: hljs-center 负值表示超融合/裸金属 Kubernetes 环境中的性能数值高于物理机环境。 ::: 可以看到： 超融合 vGPU 能力表现： vGPU 的不同配置（4Q, 8Q, 16Q）在多数测试中能够提供接近裸金属水平的性能，基本在 90% 至 105% 的范围内波动，而不同 vGPU 配置之间的性能差异也较小。无论是在何种配置下，vGPU 都能有效地分配和利用资源，确保用户获得稳定的性能体验。 超融合 GPU 直通能力表现： VM GPU 直通功能在多项测试中表现优秀，尤其是在 AI Benchmark 和 PerfZero Rest56 模型测试中，超融合 GPU 直通性能与物理机环境基本持平，甚至有时还能超越。同样地，SKS GPU 直通性能也比较出色，尤其在 AI Benchmark 测试中的表现突出。 虚拟化环境 GPU 性能表现： 在以上基准测试中，大多数虚拟化环境支持 GPU 所达到的性能与物理机环境性能相当或略优，基本保持在物理机环境性能的 90% 至 110% 之间。在 GPU Burn 的测试中，虽然虚拟化环境的性能普遍略低于物理机环境，但性能损失控制在 10% 以内。 Kubernetes 环境 GPU 性能表现： 在 Kubernetes 环境中，无论是裸金属还是 SKS，GPU 支持能力都得到了充分验证。裸金属 Kubernetes 和 SKS 在大部分测试中表现优异，特别是在 AI Benchmark 测试中达到了最佳性能，而在其他两项测试中则与物理机环境基本持平或略有差距。 性能一致性： 总体而言，无论是虚拟化环境还是 Kubernetes 环境，SmartX 超融合 GPU 直通和 vGPU 功能在各种测试项目中展现出高度一致的性能表现，几乎所有关键指标均稳定在物理机环境的 90% 至 110% 区间内。 1.4.3 多实例并发测试数据 为了验证多实例并发场景下，vGPU 切分后各实例间资源分配是否均衡，以及多实例的并发性能与单实例性能有何区别，我们还测试了 8Q – 2 实例（2 个虚拟机/SKS 实例各占 8Q 资源）和 4Q – 4 实例（4 个虚拟机/SKS 实例各占 4Q 资源）场景下各实例的性能表现，并与 16Q 单实例场景性能进行对比。 实例间性能差异 = (实例 A – 实例 B )/ 实例 B 各实例占单实例环境性能比例 = 实例 N / 单实例环境性能（理论上，2 实例测试中各实例性能应为 16Q 单实例环境下性能的 50%，4 实例测试中各实例性能应为 16Q 单实例环境下性能的 25%） 并发性能总和/单实例环境性能 = (实例 A + 实例 B + … + 实例 N )/ 单实例环境性能 通过以上数据，可以看到： 实例间性能差异： 在不同环境和不同切分配置下，多实例测试中各实例间性能差异均在 10% 以下，绝大部分集中在 1%-5%，实例间性能差异较小，说明多实例场景下各实例性能表现稳定均衡，资源分配比较平均。 多实例测试与单实例测试性能差异： 在不同环境和切分配置下，多实例测试中各实例的性能表现与单实例环境的理论性能占比（50% 或 25%）基本吻合，部分测试中甚至超越了理论比例，表明各实例不仅能够有效利用 GPU 资源，而且在某些情况下还能实现更高效的资源利用。在并发性能方面，8Q 配置多实例在 PerfZero 和 AI Benchmark 并发测试中的表现要优于单实例环境；而在进行 GPU Burn 测试时，由于存在算力资源抢占的情况，并发性能之和仅达到单实例环境约 80%，说明不同的 vGPU 配置和不同的任务类型会对多实例性能产生一定影响。总体而言，无论是虚拟化还是容器环境，两种切分配置均表现出较高的 GPU 资源利用率。 1.5 重点测试结论 在大多数性能测试中，SmartX 超融合平台对 GPU 的多种使用模式性能表现与物理机环境基本相当，充分展示了 SmartX 原生虚拟化平台 ELF 和容器管理服务 SKS 的成熟度和可靠性。 使用 SmartX 超融合 vGPU 功能时，不同 vGPU 配置之间的性能差异较小，意味着各种资源划分方案都能有效地利用分配给它们的计算能力。多实例测试中，各实例间资源分配也比较均衡，在部分测试场景中多实例并发性能高于单实例环境，可提高 GPU 资源利用率。 SKS（GPU 直通和 vGPU）和裸金属 Kubernetes 支持 GPU 的性能与虚拟化和物理机环境差异不大，验证了 SmartX 超融合虚拟化和容器环境均可为 GPU 应用场景提供良好的性能支持。 2 基于 NVIDIA A30 的性能测试 2.1 测试目标 测试 SmartX 超融合虚拟化（采用 GPU 直通）搭配 Docker 支持 NVIDIA A30 GPU 卡的性能表现。 对比裸金属环境下（物理机+Docker），超融合虚拟化+Docker 支持 GPU 的等算力池化方案损耗情况。 2.2 测试环境 2.2.1 物理机环境配置 2.2.2 虚拟化环境配置 2.2.3 软件环境配置 Guest OS: Centos 7.9 Docker-CE: 26.1.4 Nvidia Driver: 535.183.06 Nvidia CUDA: 12.5 PyTorch: 24.07 2.2.4 测试工具和模型 使用 transformers-benchmarks 测试物理机/超融合+Docker 支持 GPU 卡的基准性能及不同模型下的性能表现。Transformer 是一种用于自然语言处理（NLP）的深度学习模型，通过自注意力机制（self-attention）来处理序列数据。本次测试用到的 AI 模型包括 BERT、GTP-2 和 T5，与 Transformer 关系如下： 2.3 测试项目及步骤 通过给定不同的参数，测试不同环境最佳的 AI 计算性能，包括以下几个方面： 计算性能： 测试 GPU 在 PyTorch 下的最大计算性能，统计单位为 TFLOPS（Tera Floating Point Operations Per Second），表示每秒能够执行的万亿次浮点运算，数值越大，代表性能越好。本次分别测试 16 位和 32 位浮点数下的性能。 显存性能： 测试 GPU 在 PyTorch 下的最大显存性能，统计单位为浮点数的传输带宽（GB/s），数值越大，代表性能越好。 BERT 模型测试： 训练 BERT（Large）模型并测试不同参数下的性能表现，统计单位为 TFLOPS。 GTP-2 模型测试： 训练 GTP-2（Medium）模型并测试不同参数下的性能表现，统计单位为 TFLOPS。 T5 模型测试： 训练 T5（Large）模型并测试不同参数下的性能表现，分别统计编码（Encoder）和解码（Decoder）的性能，统计单位为 TFLOPS。 注：BERT、GTP-2、T5 为单个 Layer 的性能测试，既自注意力机制和前馈神经网络，通过前向传播和反向传播的性能测量，可以了解模型在不同序列长度和批量大小下的计算效率。 2.4 测试结果 计算公式：性能折损 =（物理机环境性能 – 超融合虚拟化环境性能）/ 超融合虚拟化环境性能 ::: hljs-center 负值表示超融合虚拟化 + Docker 环境中的性能数值高于物理机 + Docker 环境。 ::: 可以看到，SmartX 超融合虚拟化 + Docker 环境支持 GPU 的性能表现，在计算性能、BERT、GPT-2、T5 模型测试中与物理机 + Docker 环境表现基本持平，在显存性能测试中与物理机 + Docker 环境差距在 10% 左右。 2.5 重点测试结论 在基于多种模型的测试中，SmartX 超融合虚拟化 + Docker 环境支持 GPU 的性能表现与物理机 + Docker 环境性能差异不明显，验证了 SmartX 超融合虚拟化 GPU 直通功能的可靠性能。 总结 通过测试可以看到，在虚拟化和容器（SKS 和 Docker）环境下，SmartX 超融合采用 GPU 直通与 vGPU 功能均可良好支持多款 GPU 卡，并在多个场景中获得接近物理机和裸金属 Kubernetes 的性能，为企业用户多种 AI 应用场景提供高性能、一致性的 IT 基础架构支持。
-
「DeepSeek-V3 技术解析」：DeepSeek-V3-Base 预训练阶段解析 编者按： 这篇技术解析详细阐述了 DeepSeek-V3-Base 的预训练阶段所采用的关键技术。 文章重点介绍了三项核心技术：Document Packing 技术有效解决了输入序列长度差异导致的资源浪费问题；Fill-in-the-Middle（FIM）采用 PSM 框架和特殊 tokens，使模型具备上下文感知的中间内容生成能力；基于 YaRN 的长上下文窗口扩展技术则通过频率插值策略解决了位置编码的扩展挑战。 随后，文章详细描述了 DeepSeek-V3-Base 的预训练过程，包括数据构建、训练策略和评估结果。 评估显示，这些技术组合使 DeepSeek-V3 每训练 1T token 仅需 180K NVIDIA H800 GPU 小时数，并在“大海捞针”测试中展现卓越的长文本理解能力，为后续 RL 阶段奠定了优质基座。 作者 | Shirley Li 编译 | 岳扬 这是 DeepSeek 系列文章的第五篇，也是首篇聚焦 DeepSeek-V3 [1, 2] 训练流程的文章。 如下图所示，DeepSeek-V3 的训练分为多个阶段： 产出 DeepSeek-V3-Base 基础模型的预训练阶段 基于 DeepSeek-V3-Base，通过大规模强化学习（RL）分别训练出 DeepSeek-R1-Zero（无需监督式微调冷启动）和 DeepSeek-R1（含有监督式微调） 利用 DeepSeek-R1 生成推理数据，用于 DeepSeek-V3 的监督式微调（SFT），接着是未在图中展示的 RL 阶段。 图 1. DeepSeek-V3 训练流程示意图（由原文作者绘制） 本文将重点关注产出 DeepSeek-V3-Base 的预训练阶段，阐述该阶段实现高效预训练的关键技术。后续文章将涵盖： 群组相对策略优化（GRPO）[7] DeepSeek-R1-Zero 和 DeepSeek-R1 的训练细节 DeepSeek-V3 的后训练阶段（监督式微调与 RL 阶段） 目录 技术背景：解析 DeepSeek-V3 预训练阶段的相关技术，包括 Document Packing，Fill-in-Middle 和 long context extension。 预训练阶段：详解如何构建预训练数据、强调一些关键的训练策略，并回顾评估结果。 总结 参考文献 01 技术背景 本节将介绍预训练 DeepSeek-V3 过程中使用的几种技术，包括 document packing、Fill-in-the-Middle（FIM）和基于 YaRN 的长上下文窗口扩展技术。 1.1 Document Packing 要理解为什么需要 document packing，我们首先需要回顾一下 Transformer 模型是如何构建输入序列 tokens 的。 Transformer 模型默认情况下需要固定长度的 token 序列作为输入，然而同一 batch 的文本输入往往长度不同。为了适应这种情况，文本输入通常需要经过以下预处理步骤： 将所有原始文本输入分词为 token 序列 将 token 序列截断或填充到预定义的固定长度（max_seq_len）：若原始序列过长则截断，否则用特殊 [PAD] token 进行填充 生成掩码 IDs 使模型在训练时能忽略填充的 token 为了更清晰地展示这个过程，以下这个示例我们将使用 GPT-2 [10]的分词器处理两个句子： 运行上述脚本后，会得到如下输出，其中： 第一句话被填充了 4 个额外的 padding token，体现在 input_ids 和 mask_ids 中； 第二句被截断，因此无需添加 padding token。 图 2. 填充操作示例（此图由作者绘制） 上述截断和填充方法虽然能让模型处理不同长度的输入，但当输入序列长度差异过大时（这在 LLM 训练中非常常见）会引发一系列问题： 对超长序列，截断可能导致有用信息丢失 对较短的序列，填充过多 token 会造成计算资源浪费 因此，LLM 训练通常采用 document packing 技术来处理输入序列。 更具体地说，如果给定若干长度不同的文档，我们首先将其分割为较小的块（chunk），如下图所示（用不同颜色代表不同文档）： 图 3. 文档分割（图片改编自文献[3]） 随后，我们将不同文档的块（chunk）进行拼接，以避免对长文档进行截断和对短文档进行填充： 图 4. 传统拼接方式（图片改编自文献[3]） 在上例中： 第一个输入（译者注：图 4 第一行）仅包含文档 1 的 tokens 第二个输入（译者注：图 4 第二行）拼接自文档 1 和文档 2 的 tokens 第三个输入（译者注：图 4 第三行）拼接自文档 2 和文档 3 的 tokens 第四个输入（译者注：图 4 第四行）拼接自文档3、4、5 的 tokens 这种方法虽能在一定程度上避免进行填充和截断，但由于仅按数据中的相对顺序拼接来自不同文档的块（chunks），无法控制最终输入序列的构建方式。 例如：文档 3（紫色）被不必要地分割为两部分，尽管其实际长度小于 max_seq_len，可以完整放入。 为了解决这个问题，文献 [3] 提出了 Best-fit Packing 技术，通过两个步骤完全消除不必要的分割： Step 1：将每个文档分割为更小的块。 Step 2：以一种智能的方式将这些块（chunks）分组为训练序列，确保在不进一步分割任何块（chunks）的前提下生成最少量的序列。 图 5. Best-fit packing技术（此图改编自文献[3]） 1.2 Fill-in-the-Middle（FIM） 在传统的自回归生成中，只能以从左到右的方式训练模型，即模型只能根据前面的 tokens 预测下一个 token。然而在实际应用中，模型常需根据上下文生成中间缺失的内容。 尤其在代码生成场景中 —— 我们常会给定输入/输出和部分代码片段，要求模型填充中间逻辑，如下例所示： 为了适配此类需求，文献 [4] 提出了一种简单有效的方法，称为 “fill-in-the-middle”：即将文档随机切分为 prefix、middle 和 suffix 三部分，然后将 middle 部分移至末尾： 由于数据组织形式为 "Prefix-Suffix-Middle"，该方法常被称为 PSM 框架。实际实现时通过添加特殊 token 来标记各部分的边界： 其中： <|fim_begin|>和<|fim_hole|>标记 prefix 部分 <|fim_hole|>和<|fim_end|>标记 suffix 部分 <|fim_end|>和<|eos_token|>标记 middle 部分 以如下输入为例： 若需模型预测第二行代码，可将该行作为 middle 部分，并构造 FIM 输入如下： 图 6. PSM 框架示意图（此图由作者绘制） 此时模型的预期输出应为： 1.3 基于 YaRN 的长上下文窗口扩展技术 现代 LLM 常需处理极长的提示词（如整个代码仓库），但直接使用 128K 等长上下文窗口进行预训练并不现实。多数 LLM 采用分阶段渐进式扩展策略：先在较小的上下文窗口进行预训练，再分多个阶段逐步扩展到更长的上下文窗口，从而大大降低训练成本。 例如，在 DeepSeek-V3 中，模型首先使用 4K 的上下文窗口完成预训练，然后再分两阶段扩展到 128K： 第一阶段：从 4K 到 32K（1000 steps） 第二阶段：从 32K 到 128K（再 1000 steps） 需特别指出的是，这种扩展不能通过简单调大上下文窗口实现，而需借助基于旋转位置编码（RoPE）改进的 YaRN（Yet another RoPE extensioN）技术对位置编码进行修改。 关于 RoPE 的详细介绍，请参阅我们之前的文章《「DeepSeek-V3 技术解析」：多头潜在注意力机制（MLA）》。 RoPE 是一种相对位置编码方法，其核心思想是通过使用复杂的旋转嵌入修改 Query 和 Key，使得二者的内积依赖于它们的相对位置： 然而，由于余弦函数和正弦函数是周期性的，(pos_i, pos_j) 之间的内积可能看起来与 (pos_i, pos_k) 之间的内积相似，因此在固定 θ 的情况下，仅使用 1K tokens（即位置索引 1~1000） 进行预训练的模型在测试时可能会混淆，因为测试时遇到的位置索引（如 5K 或 10K）可能远远超出了预训练时的上下文窗口。 下图展示了这种现象：当 32K 上下文窗口的预训练模型在超出该窗口的位置测试时，困惑度（Perplexity）急剧上升： 图 7. 困惑度与上下文窗口的关系（此图由作者绘制） 那么，YaRN 是如何应对这一挑战的呢？ 既然外推法（extrapolate）效果欠佳，YaRN 转而采用插值频率（interpolate the frequency）的策略。 假设我们有一个在 4 个 token 长度的输入上训练的模型，希望将其扩展到 8 个 token，且基础频率 θ=0.5。 对于原始 RoPE，直接使用 cos(θ×pos) 和 sin(θ×pos) 对 Query 和 Key 进行旋转即可。 而对于 YaRN： 首先，计算扩展后的上下文长度与原始长度的比值作为缩放因子，本例中为 2。 然后，生成新频率 θ' = θ / 2 = 0.25。 再使用新频率对 Query 和 Key 进行旋转，即 cos(θ'×pos) 和 sin(θ'×pos)。 下图对比了 RoPE 与 YaRN 的 cos 和 sin 值： 图 8. YaRN 工作原理示意图（此图由作者绘制） 通过该图可观察到： 在 RoPE 中，cos 和 sin 值会随位置索引的增加而快速振荡，导致扩展到更长的上下文时出现问题。 而在 YaRN 中，原始的余弦和正弦函数通过频率缩放被插值到扩展后的上下文长度（如蓝色高亮区域所示），实现了更平滑的过渡，使得模型能够更有效地处理长序列。 下图展示了 DeepSeek-V3 在"大海捞针"（Needle In A Haystack，NIAH）测试中的表现，表明其在 128K 以下的上下文窗口长度中均表现出色： 图 9. DeepSeek-V3 的"大海捞针"测试结果（引自文献[2]） 02 预训练阶段 本节将介绍 DeepSeek-V3-Base 的训练方法，重点解析数据构建流程，并强调预训练阶段中的一些关键策略。 2.1 数据构建 数据规模与质量对 LLM 训练至关重要。DeepSeek-V3 的预训练语料库通过持续优化策略构建，具体优化路径如下： 在 DeepSeek 67B [8] 中，训练语料采用去重-过滤-再混合策略构建。 首先对 Common Crawl 语料进行去重，随后通过严格的文档质量评估标准进行过滤，最后通过数据再混合阶段解决数据不平衡问题。 在 DeepSeek-V2 [9] 中，通过以下方式扩展训练语料：1) 增加更多中文数据及来自不同来源的高质量数据；2) 通过优化数据清洗流程，恢复大量此前在文献 [8] 的策略中被删除的数据。同时，通过改进基于质量的过滤算法提升数据质量。 在 DeepSeek-V3 [2] 中，预训练语料进一步扩充，加入更多数学与编程样本，以及除中英文之外的多语言样本。 收集的预训练语料会通过前文提出的 Prefix-Suffix-Middle（PSM）框架结合 FIM（Fill-in-Middle）策略进行预处理，并应用 document-packing 技术。 2.2 训练策略 原论文[2]对预训练参数进行了详细描述，此处我们仅强调几个关键点： 长上下文窗口扩展：首先在 14.8T token 上以 4K 上下文窗口进行预训练，随后通过 1000 steps 扩展到 32K 上下文，最终再通过 1000 steps 扩展到 128K 上下文。 多词元预测：如我们本系列前一篇文章《「DeepSeek-V3 技术解析」：多词元预测技术（Multi-Token Prediction, MTP）》所述，DeepSeek-V3 采用了优化版的多词元预测机制，允许模型同时解码多个词元（tokens），以加速训练中的解码过程。 以 FP8 精度进行训练：DeepSeek-V3 采用混合精度计算提升效率，对部分计算使用低精度格式（如 8-bit 浮点数），在不过度影响精度的前提下减少内存占用并加速计算。 学习率的调度：在前 2K steps 中，学习率（learning rate）从 0 线性增长至 2.2e–4，并在 10T token 的训练过程中保持恒定；随后在 4.3T token 的训练过程中按照余弦曲线下降至 2.2e-5；在最后 500B token 的训练过程中，前 333B token 保持恒定的学习率，剩余 167B token 进一步降至 7.3e-6。 Batch size 的调度：在前 469B token 的训练过程中，Batch size 从 3072 逐步提升至 15360，后续训练中保持恒定。 2.3 评估结果 下表对比了 DeepSeek-V3 与其他开源基座模型在不同任务上的表现。其中 DeepSeek-V3 在多数数据集上都取得了最佳性能，尤其是在数学与代码相关的任务中表现突出。 需特别说明，得益于本系列文章中介绍的各项创新技术，DeepSeek-V3 的优异性能是在极高的训练效率下实现的。具体而言，DeepSeek-V3 每训练 1T token 仅需 180K H800 GPU hours，远低于训练 72B 或 405B 稠密模型的成本。 文献[2]中的表 3 文献 [2] 还通过全面的消融实验验证了无辅助损失函数的负载均衡、多词元预测等关键技术。由于我们已在前文中讨论过相关内容，此处不再赘述。 03 总结 本文探讨了 DeepSeek-V3 预训练策略中的关键创新，旨在提升效率、可扩展性与性能。由此产生的 DeepSeek-V3-Base 模型成为更高级推理模型（如 DeepSeek-R1-Zero 和 DeepSeek-R1）的基础，而这些模型又通过知识蒸馏反哺优化 DeepSeek-V3。 除此前讨论的架构创新 —— 多头潜在注意力（Multi-head Latent Attention）、DeepSeekMoE、无辅助损失函数的负载均衡及多词元预测（Multi-token Prediction）外，本文还引入了包括 document packing、Fill-in-the-Middle（FIM）和基于 YaRN 的长上下文窗口扩展在内的多项技术。 这些技术共同推动了大语言模型效率与可扩展性边界的突破，为高性能 AI 模型设立了新标杆。 参考文献 [1] DeepSeek（https://www.deepseek.com/） [2] DeepSeek-V3 Technical Report（https://github.com/deepseek-ai/DeepSeek-V3/blob/main/DeepSeek_V3.pdf） [3] Fewer Truncations Improve Language Modeling（https://arxiv.org/abs/2404.10830） [4] Efficient Training of Language Models to Fill in the Middle（https://arxiv.org/abs/2207.14255） [4] DeepSeek-Coder: When the Large Language Model Meets Programming — The Rise of Code Intelligence（https://arxiv.org/abs/2401.14196） [5] DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence（https://arxiv.org/abs/2406.11931） [6] YaRN: Efficient Context Window Extension of Large Language Models（https://arxiv.org/abs/2309.00071） [7] DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models（https://arxiv.org/abs/2402.03300） [8] DeepSeek LLM: Scaling Open-Source Language Models with Longtermism（https://arxiv.org/pdf/2401.02954） [9] DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model（https://arxiv.org/abs/2405.04434） [10] Language Models are Unsupervised Multitask Learners（https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf） Thanks for reading! Hope you have enjoyed and learned new things from this blog! About the author Shirley Li I am a Machine Learning Engineer working on building multi-modality models to solve real-world problems. END 本期互动内容 当前位置编码方案（RoPE/YaRN）已支持 128K 上下文，但人类书籍平均长度约 200K tokens。要实现真正无损的长文档理解，您认为下一代位置编码需要突破哪些理论瓶颈？ 原文链接： https://medium.com/data-science-collective/deepseek-explained-5-deepseek-v3-base-86c078ed5504
-
-
百度文心快码：IT界的职场必备神器 作为一名有8年多全栈开发经验的程序员，这些年里，我见证过太多项目因为开发成本失控而烂尾。毕竟，国内程序员的人工成本这些年一直水涨船高，而客户的需求也变得越来越复杂甚至“刁钻”。直到最近接触了百度文心快码（Baidu Comate），降低开发成本的方法终于被我找到。就拿我上一个医疗数据平台项目为例，通过引入百度文心快码，我们团队节省了约30%的开发成本，项目质量还让客户十分满意。 今天，我就来和大家聊聊，百度文心快码（Baidu Comate）这个IT界的职场必备神器是如何帮我们实现降本增效的。 记得2016年我刚入行时，团队还在用SVN管理代码。现在回头看，当时的开发方式就像手工匠人打铁——每个功能都要从零敲代码，光是处理一个DICOM医学影像的IO操作，就得写200多行重复性代码，费时费力还容易出错。 但这些年，随着人工智能技术的发展，我发现时代真的变了。就拿我们刚接到的一个医疗AI项目来说。这个项目需要处理CT影像数据，在过去，我们需要全手工写DICOM解析器代码。而现在，用上了百度文心快码这个基于文心大模型的深度学习编程助手的我们，一切都不一样了。 大家都知道，处理DICOM文件需要大量固定套路的代码。以前的我，会从旧项目里复制一些代码段，但总存在版本兼容的问题。现在，只需要向百度文心快码输入“使用pydicom读取DICOM文件并提取患者信息”，文心快码瞬间就生成了相对于的代码。 这还不算，更惊艳的是，它还能根据我的编码习惯自动补全代码，并对异常问题进行智能处理，大大减少了代码测试、优化的工作量。 除了对项目开发、测试等实际编程工作的帮助外，通过这段时间的使用我还发现，百度文心快码还能帮助团队进行知识沉淀。目前，我们让它连接了公司的GitLab，很快文心快码就学会了我们的编码规范。现在，团队中新人提交的PR基本都能通过ESLint检查，新手的培训成本也有了明显的下降。 相信很多公司都在寻找降低开发成本的方法，文心快码值得大家一试。
-
-
使用prometheus全链路监控docker容器 Prometheus 监控 Docker 容器 Prometheus 可以通过 cAdvisor 或 node_exporter + docker daemon metrics 监控 Docker 容器的状态，包括 CPU、内存、网络流量等。 方法 1：使用 cAdvisor（推荐） cAdvisor（Container Advisor）是 Google 开发的一个工具，专门用于收集 Docker 容器的资源使用情况，并以 Prometheus 格式提供指标数据。 1.1 运行 cAdvisor 使用 docker run 方式运行： docker run -d \ --name=cadvisor \ --restart=always \ -p 8080:8080 \ --privileged \ -v /:/rootfs:ro \ -v /var/run:/var/run:rw \ -v /sys:/sys:ro \ -v /var/lib/docker/:/var/lib/docker:ro \ --detach \ gcr.io/cadvisor/cadvisor:latest 访问 cAdvisor http://<你的服务器IP>:8080 你可以在 Web 页面看到所有 Docker 容器的详细信息。 1.2 配置 Prometheus 采集 cAdvisor Prometheus 配置： sudo nano /etc/prometheus/prometheus.yml 添加以下内容： scrape_configs: - job_name: 'cadvisor' static_configs: - targets: ['127.0.0.1:8080'] 重启 Prometheus： sudo systemctl restart prometheus 方法 2：使用 node_exporter + docker daemon metrics 2.1 启用 Docker Daemon Metrics Docker 配置： sudo nano /etc/docker/daemon.json 添加： { "metrics-addr": "127.0.0.1:9323", "experimental": true } 重启 Docker： sudo systemctl restart docker 测试是否开启成功 curl http://127.0.0.1:9323/metrics 如果返回 Prometheus 格式的监控数据，说明 Docker Metrics 已启用。 2.2 配置 Prometheus 采集 Docker Metrics Prometheus 配置： sudo nano /etc/prometheus/prometheus.yml 添加： scrape_configs: - job_name: 'docker' static_configs: - targets: ['127.0.0.1:9323'] 重启 Prometheus： sudo systemctl restart prometheus 配置 Grafana 监控看板 安装 Grafana sudo yum install -y grafana sudo systemctl enable --now grafana-server 访问 Grafana http://<你的服务器IP>:3000 默认账号/密码：admin / admin 添加 Prometheus 数据源 进入 Data Sources 选择 Prometheus 设置 URL：http://127.0.0.1:9090 点击 Save & Test 导入 Grafana Docker 监控面板 进入 Dashboards → Import 输入 Dashboard ID： cAdvisor 监控面板：13639 Docker Daemon 监控面板：1229 选择 Prometheus 作为数据源 点击 Import 即可看到 Docker 监控数据
-
15分钟高效渗投测试打点实战指南 ENScan_G0(一款基于各大企业信息API的工具)下载链接:https://github.com/wgpsec/ENScan_GO subfinder(快速被动子城名枚举工具)下载链接:https://github.com/projectdiscovery/httpx httpx(快速资产识别工具)下载链接:https://github.com/projectdiscovery/httpx Ehole(红队重点公鸡系统指纹探测工具)下载链接:https://github.com/EdgeSecurityTeam/EHole enscan-v1.2.1.exe -n 自动导出xlsx 导出xlsx的内容 subfinder.exe -dL url.txt 结果在urls.txt subfinder.exe -dL url.txt -o urls.txt httpx.exe urls.txt -status-code -title -web-server -tech-detect -threads 100 -o result.html threads #线程 被动跑出来肯定是很多不存在的，所以还要用脚本去跑一下响应码。 指纹识别模块 EHole_windows_amd64.exe finger -h ##帮助命令 EHole_windows_amd64.exe finger -h EHole_windows_amd64.exe finger -l url.txt 看看域名里面有没有cms，有的话就可以利用这个工具去打。 做黑盒测试一定要多搜集一些然后一点点的去排查有用信息。
-