1.[转]Megatron-LM源码系列(八)： Context Parallel并行
2.元象大模型XVERSE支持vLLM和llama.cpp 加速低成本部署丨附教程
3.vllm vs TGI 部署 llama v2 7B 踩坑笔记
4.使用全套开源工具构建 LLM 应用实战：在 Dify 调用 Baichuan 开源模型能力
5.[fastllm]fastllm源码结构解析
6.LLM训练06 流水线并行

[转]Megatron-LM源码系列(八)： Context Parallel并行

       原文链接： Megatron-LM源码系列(八)： Context Parallel并行

       Context Parallel并行(CP)与sequence并行(SP)相比，源码核心差异在于SP只针对Layernorm和Dropout输出的源码activation在sequence维度进行切分，而CP则进一步扩展，源码对所有input输入和所有输出activation在sequence维度上进行切分，源码形成更高效的源码并行处理策略。除了Attention模块外，源码mkoline 源码其他如Layernorm、源码Dropout等模块在CP并行中无需任何修改，源码因为它们在处理过程中没有涉及多token间的源码交互。

       Attention模块之所以特殊，源码是源码因为在计算过程中，每个token的源码查询(query)需要与同一sequence中其他token的键(key)和值(value)进行交互计算，存在内在依赖性。源码因此，源码在进行CP并行时，源码计算开始前需要通过allgather通信手段获取所有token的KV向量，反向计算时则通过reduce_scatter分发gradient梯度。

       为了降低显存使用，前向计算阶段每个GPU仅保存部分KV块，反向阶段则通过allgather通信获取全部KV数据。这些通信操作在特定的rank位置（相同TP组内）进行，底层通过send和recv等操作实现allgather和reduce_scatter。

       以TP2-CP2的transformer网络为例，CP并行的通信操作在Attention之前执行，其他则为TP通信。AG表示allgather，RS表示reduce_scatter，AG/RS表示前向allgather反向reduce_scatter，RS/AG表示前向reduce_scatter反向allgather。

       TP2对应为[GPU0, GPU1], [GPU2, GPU3]，CP2指的就是TP组相同位置的rank号，即[GPU0, GPU2], [GPU1, GPU3]。CP并行类似于Ring Attention，但提供了OSS与FlashAttention版本，并去除了冗余的low-triangle causal masking计算。

       LLM常因序列长度过长而导致显存耗尽（OOM）。传统解决方法包括重计算或扩大TP（tensor parallel）大小，但各自存在计算代价增加或线性fc计算时间减少与通信难以掩盖的问题。CP则能更高效地解决这一问题，每个GPU处理一部分序列，同时减少CP倍的通信和计算量，同时保持TP不变，使得activation量也减少CP倍。性能优化结果展示于图表中，用户可通过指定--context-parallel-size在Megatron中实现CP。web防线源码

       具体源码实现以Megatron-Core 0.5.0版本为例进行说明。

       

参考资料：

[链接]

元象大模型XVERSE支持vLLM和llama.cpp 加速低成本部署丨附教程

       元象大模型一次性推出了款开源的量化版本，全免费供商业用途，目标是通过高度压缩的模型权重，保持高性能，为众多中小企业和开发者提供更灵活且成本效益高的部署选项，加速大模型的实际应用进程。

       量化技术通过优化内存使用和降低数据访问成本，优化模型推理性能。通过精细的量化策略，可以在推理效率和模型表现之间找到最佳平衡。以XVERSE-B-GPTQ-Int4为例，量化后的模型大小缩小%，但性能提升了1.5倍，模型能力仍保持在%以上。

       可以直接从Hugging Face下载元象大模型，包括ModelScope魔搭和Github上的开源资源。元象模型兼容主流框架如vLLM和llama.cpp，提供全量化解决方案，无需额外配置即可使用，显著降低了部署成本。开发者可根据自身需求和技术水平，选择适合的推理框架和数据精度。

       对于vLLM，它是一个针对大语言模型推理的高效库，特别适合长输出和高并发场景。环境配置和模型下载指南包括从源代码构建和使用pip安装的步骤，以及XVERSE-7B-Chat-GPTQ-Int4模型的下载示例。vLLM的推理效果展示其高效性能。

       llama.cpp则是一款轻量级的C++库，专为快速部署和最小化测试设计，支持多种硬件平台。GGUF格式提供了优化的模型文件加载速度和跨平台兼容性。XVERSE开源的GGUF模型大小供用户根据硬件资源选择。视频演示了在Mac M2 GB机器上运行XVERSE推理服务的实际效果。

vllm vs TGI 部署 llama v2 7B 踩坑笔记

       本文旨在对比vllm和TGI这两个开源方案在部署LLaMa v2 7B模型时的性能和体验。测试环境为单卡 + i9-K。结果表明，TGI (0.9.3) 在吞吐量上略胜vllm (v0.1.2)一筹。

       vllm的部署遇到了不少挑战，包括网络和依赖问题，最终通过定制化的Dockerfile解决了安装难题。为了确保使用最新的fastchat时拥有对应的消息模板，用户需手动调整entrypoints.openai.api_server中的文华源码用法引入方式。部署后，通过http://{ host}:{ port}/generate发送POST请求，并在body中提供参数。

       TGI同样提供了方便的部署方式，推荐通过Docker或本地源码安装。对于本地测试，Ubuntu环境下的安装步骤包括安装protoc和调整cargo源。部署成功后，用户可通过text-generation-launcher启动服务。TGI的参数配置较为丰富，尤其对于服务部署而言，提供了更多灵活性。

       为了评估模型性能，我们分别使用vllm和TGI进行了基准测试。结果显示，vllm的平均输出速度为. tokens/s，吞吐量为4. requests/s，相当于每分钟处理.7个序列。JMeter模拟测试表明，每个用户发送消息后，接收到LLM回复的延迟在ms以内，平均每轮对话的回复速度在- tokens/s。因此，使用单张显卡，可以部署一个支持约人正常使用的7B LLM模型。

       除了vllm和TGI，还有其他LLM服务部署仓库可供选择，如lmdeploy等。受限于设备条件，本文仅对单卡部署7B模型进行了测试。在之前的LLaMa量化文章中，提到使用GPTQ量化后推理速度提高了近3倍。但当批量大小较大时，GPTQ的批量推理效率低于fp，因此采用GPTQ的吞吐量提升可能有限。目前，TGI对exllama的支持尚不完善，未来将关注其性能改进。

使用全套开源工具构建 LLM 应用实战：在 Dify 调用 Baichuan 开源模型能力

       在当前开源大语言模型的热潮中，许多开发者希望本地部署开源LLM（大型语言模型），用于研究LLM或构建基于开源LLM的应用。笔者也尝试通过开源社区的项目，本地部署服务构建自己的LLM应用。那么，爱艺影视源码本地部署开源LLM构建聊天应用需要哪些准备呢？本文将详细介绍步骤与工具，包括本地环境准备、大型语言模型、推理服务以及使用开源平台Dify.AI快速构建应用。

       本地环境的准备：

       为了部署高性能的开源大模型，需要一台配备高性能大显存NVIDIA显卡、大容量高速内存和大容量固态硬盘的本地机器。以Baichuan-chat-B模型为例，建议配置为：i9-K CPU、GTX双卡、GB内存和2TB固态硬盘。

       大型语言模型：

       大型语言模型是构建应用的基础，不同模型根据预训练数据和任务目标的不同，其结构和知识学习也不同。在Hugging Face等热门AI社区，可以寻找感兴趣的开源LLMs进行尝试和能力对比。

       本地部署推理服务：

       推理服务将预训练模型加载至本地服务器，提供模型预测接口，支持本地化使用LLM进行NLP任务，无需依赖云服务。使用GitHub上的一流开源项目，如LocalAI、openLLM等，一键部署热门开源模型。

       Dify.AI：“LLM操作系统”：

       使用开源平台Dify.AI，构建基于不同LLM能力的AI应用变得简单。Dify支持快速调用和切换开源模型，包括托管在HuggingFace和Replicate上的所有模型，支持本地部署，通过Xorbits inference推理服务构建AI应用。

       以下为实操步骤，从零开始介绍环境配置、安装CUDA、WSL2准备、Docker部署等。

       环境准备：

       基本的conda和Python环境推荐使用conda管理。首先安装conda，初始化Python3.环境。安装CUDA，推荐从官网直接下载Windows 版本。WSL2环境准备，安装Ubuntu版本并配置代理脚本。安装Docker Desktop，选择使用WSL2，海源码头图片确保WLS和Docker正常运行。配置WSL，安装WSL的CUDA，安装PyTorch。

       部署推理服务Xinference：

       根据Dify部署文档，Xinference支持多种大型语言模型。选择Xinference部署Baichuan-chat-3B模型。在WSL中安装Xinference基础依赖，并配置模型。启动Xinference并下载部署模型。使用Xinference管理模型查看已部署模型的uid。

       部署Dify.AI：

       参考Dify官网部署文档，CloneDify源代码，启动Dify，检查容器运行状态。在浏览器访问部署结果。

       接入Xinference配置模型供应商：

       在Dify设置中填入Xinference模型信息，注意SeverUrl使用局域网IP，获取WSL的IP地址。配置Baichuan-chat模型，创建应用。

       后记：

       本地部署结合Dify.AI，快速构建基于开源LLM的AI应用成为可能。通过持续迭代和优化，提升应用性能。Dify提供了一个完整的LLM应用技术栈，简化了构建和管理过程，支持数据清洗、标注等服务。LLM应用的场景和能力将进一步丰富，门槛降低。

[fastllm]fastllm源码结构解析

       fastllm源码结构解析

       主要文件结构和继承关系如下：

       main包含factoryllm工厂，用于生成各种llm模型实例，basellm作为基类，包含通用方法和参数，所有模型使用相同的命名空间，fastllm为基本类，定义数据格式、权重映射和基础算子操作。

       fastllm类属性解析：

       SetThreads(int t): 设置线程数

       SetLowMemMode(bool m): 设置低内存模式

       LowBitConfig: 包含量化参数，提供量化与反量化方法

       DataType: 包括浮点、int8、int4等数据类型

       DataDevice: 包含CPU与CUDA

       WeightType: 包括LINEAR、EMBEDDING和None

       Data: 包括形状、大小、扩容信息，量化配置等，提供复制、分配、预扩容等功能

       Tokenizer: 包含TrieNode链表和token-to-string字典，提供插入、编码和解码函数

       WeightMap: 存储模型名称与数据内存，支持从文件加载和保存低位量化权重

       core类操作分析：

       Embedding: 根据输入与权重计算输出

       RMSNorm: L2归一化后乘以权重

       LayerNorm: 使用gamma、beta进行层归一化

       Linear: 线性变换

       Split: 按轴分割数据

       Cat: 按轴拼接数据

       MatMulTransB: 多线程下矩阵转置乘法

       Softmax: 激活函数

       Silu: SiLU激活函数

       GeluNew: 新型Gelu激活函数

       Mul: 矩阵与浮点数乘法

       MulTo: 点乘

       AddTo: 点加操作（带alpha和不带alpha）

       AttentionMask: 根据mask值替换

       Permute: 数据通道转换

       ToDevice: 数据迁移至GPU

       basellm作为抽象类，继承自fastllm，包含纯虚函数如加载权重、模型推理、保存低比特模型、热身等。

       chatglm、moss和vicuna继承自basellm，实现具体模型，函数与basellm类似。

       fastllm结构体与属性解析：

       FileBuffer: 文件读写操作，包括读取各种类型数据和文件写操作

       Data操作: 包括数据拷贝、统计、扩容、转置、计算权重和等

       Tokenizer方法: 包括初始化、清空、插入、编码和解码

       WeightMap方法: 包括从文件加载和保存低位量化权重

       fastllm方法: 包括矩阵转置、通道转换、数据迁移、多线程乘法、激活函数等

LLM训练 流水线并行

       分布式训练的多部分组成包括通信、显存占用分析、高效训练方法、数据并行、ZeRO系列、流水线并行、张量并行以及Megatron-LM的源码分析。本文聚焦于流水线并行的概念与实现。

       在朴素的模型并行中，假设我们有K个GPU，将一个L层的模型分为K个部分，每GPU负责L/K层。数据在GPU之间依次进行前向与反向计算，形成类似串行的流程。然而，这种实现存在资源浪费的问题。

       为解决此问题，引入了数据并行的概念。具体地，将一个小批量的数据分割成M个微批量。每个微批量在GPU上进行计算，梯度在微批量间累积，这种策略称为GPipe。在GPipe中，数据拆分为多个微批次，前向计算从第一个微批次开始，直到所有微批次都完成前向计算，才会启动反向计算。此策略显著减少了空闲气泡的大小。

       在GPipe中，每个GPU需要存储M个微批量的中间激活值。若不引入重计算，每个GPU的中间激活值占用量为每层数据量乘以层数。通过引入重计算，每个GPU只需保留一份中间值（边界层的中间值）和一份完整的输入数据。这样，每个GPU的中间激活值占用量降低至1.5倍数据量。

       GPipe将模型分解至不同GPU，其切分方法依据算力进行。例如，Megatron-LM直接按照层数进行切分。实际实现中，GPipe会生成相应的代码。

       针对GPipe存在的GPU利用率低和显存占用大的问题，PipeDream提出了解决方案。PipeDream通过采用1F1B策略来优化训练流程。1F1B策略指在完成一个微批次的前向传播后立即启动反向传播，以此提前释放中间激活值，进而优化内存使用。

       在1F1B策略下，训练过程中的前向与反向传播是交错进行的，可能导致同一微批次数据在不同阶段使用不同版本的模型参数。为解决此问题，PipeDream引入了Weight Stashing方法与Vertical Sync方法。Weight Stashing方法在前向传播后保存当前权重版本，用于同一微批次的后续反向传播。Vertical Sync方法则确保了不同阶段间的参数一致性，确保同一微批次数据在不同阶段使用同一版本的参数。

       具体实现上，PipeDream提供了非交错式与交错式两种调度模式。非交错式调度默认采用前向与反向交替的策略，而交错式调度允许在不同阶段间进行前向与反向的交错执行。这两种调度模式在Megatron-LM中分别对应不同的方法。

       通过上述分析与改进，分布式训练的效率与资源利用得到了显著提升，流水线并行成为提升大规模模型训练效率的关键技术之一。

Open-WebUI（原Ollama_WebUI）Windows上源码安装配置记录

       在探索多种LLM加速软件中，Ollama凭借其出色的速度和简洁的操作脱颖而出。发现Open-WebUI（原Ollama_WebUI）与ollama服务的配合更佳，因此决定尝试安装。Open-WebUI的GitHub地址为GitHub - open-webui/open-webui: User-friendly WebUI for LLMs (Formerly Ollama WebUI)，其主要特点在于通过Docker快速启动，但务必注意在Docker命令中包含"-v open-webui:/app/backend/data"，以防数据丢失。

       对于需要利用CUDA加速的用户，官方推荐使用带或标签的ollama图像，并确保在Linux/WSL系统上安装Nvidia CUDA容器工具包。如果Ollama在本地，使用以下命令；如果在远程服务器，将OLLAMA_BASE_URL替换为服务器URL。

       我的安装策略是选择源码方式，尽管文档推荐Docker。在安装过程中，我加入了国内的pip源以优化下载速度。安装完成后，需要修改.env文件中的ollama地址和backend/config.py中的相应设置。

       在Linux或Windows环境下启动Open-WebUI后，可以轻松设置语言，它与ollama的集成十分顺畅。总的来说，使用Open-WebUI为LLM提供了便捷的界面，特别是配合ollama，体验良好。

vllma环境安装及部署测试

       前阶段使用ollama部署LLM服务，取得良好效果，详情参考<北方的郎：Linux上部署Ollama，启动Mistral-7B及Gemma-7B服务，测试效果。

       在寻找类似应用时发现vllma，查阅了其Github地址（GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs）和文档（docs.vllm.ai/），发现vLLM是一款高效、易于使用的LLM推理与服务库。

       对比测试显示，vLLM在速度和使用灵活度上表现优异，且支持多种Hugging Face模型。

       使用pip或源码安装vLLM，文档建议新建env。直接使用pip安装，启动服务简单。需要注意的是，对于T4等较老GPU，启动时需添加`--dtype=half`选项。

       简单测试显示，vLLM连接成功并支持本地调用。对于特定模型，可能需要添加`--trust-remote-code`选项，并安装额外库如tiktoken。

       在尝试与新应用集成过程中，发现vLLM依赖较老版本的PyTorch（torch 2.1.2），导致与其他应用冲突。因此，建议使用独立env。

       新模型测试显示，vLLM能有效启动并调用新整合模型，结果令人满意。此外，对于ModelFactory生成的Lora和全量训练模型，vLLM表现稳定。

       性能参数方面，通过命令查看性能指标，vLLM在高吞吐量和内存效率方面展现优势。

自主LLM机器人(Agent)原理和实现

       上个月，Devin 成为科技界热门话题，它是一个能自主决策并修复 bug 的 AI 机器人，在 SWE-bench 基准测试中，Devin 能够解决 .% 的问题，而 GPT-4 只能处理 1.%。开源界迅速跟进复现，swe-Agent、openDevin、devika 等项目相继出现，引起广泛关注。

       通过阅读这些项目源码，发现它们基于自我反思与 reAct 模式扩展，但实现细节差异显著。以 opendevin 为例，这类机器人基于 reAct 模式，实现更全面的扩展，如搜索、计算、浏览网页等，同时具备记忆、沙盒环境与权限管理功能。

       opendevin 的沙盒环境开放了丰富的命令执行权限，允许执行如 curl、wget、git 等操作，甚至支持在 Debian 系统中执行任何命令，且能自主安装依赖，如 nodejs。此外，它采用压缩记忆机制处理过长上下文，通过独白、短记忆与长记忆管理，有效控制机器人动作链路。

       提示词是理解机器人动作链路的关键，包括动作指令、独白与执行动作指令。提示词帮助机器人理解任务与上下文，同时通过压缩记忆机制，机器人能在不增加动作链路的情况下处理过长的上下文。

       自主机器人依赖底层大模型的理解能力，理解能力强的模型能快速生成高效指令。沙盒环境的开放性与模型的代码理解能力相结合，使得机器人在解决复杂问题时更加有效。在资源有限的场景下，自主决策机器人的应用将依赖于更精准的指令设计与模型能力优化。

       总结而言，自主机器人依赖大模型的理解能力、全面的沙盒环境与有效的记忆管理，通过优化提示词设计，能在不同资源条件下实现自主决策与问题解决。然而，实验过程中遇到的高昂 Token 成本提醒我们，自主 Agent 的实际应用需考虑成本与资源的有效利用。