RDMA技术手册:面向AI场景的深度解析
RDMA技术手册:面向AI场景的深度解析 目录 概述 RDMA原理与架构 2.1 RDMA基本原理 2.2 RDMA网络类型与协议 2.3 RDMA编程模型与Verbs接口 2.4 GPUDirect RDMA技术 RDMA在AI场景的应用实践 3.1 RDMA在分布式训练中的应用 3.2 RDMA在推理服务中的应用 3.3 RDMA在存储与数据IO中的应用 3.4 RDMA在Kubernetes中的集成与实践性能优化与最佳实践 4.1 RDMA性能优化策略 4.2 性能测试与基准工具 4.3 典型问题与调优案例总结与展望 第1章 概述 背景与需求: 随着人工智能(AI)模型规模的爆炸式增长,训练和推理过程对网络通信提出了前所未有的高要求。传统基于TCP/IP的网络通信在延迟和带宽上已难以满足大规模分布式训练的需求。远程直接内存访问(Remote Direct Memory Access,RDMA)技术应运而生,它通过绕过操作系统内核,实现网络接口直接访问应用内存,从而极大降低了通信延迟、提高了吞吐量。在现代AI数据中心中,RDMA已成为加速分布式训练和大规模推理的关键网络技术。...
大规模训练任务与推理服务编排、离线混部及资源调度技术手册
大规模训练任务与推理服务编排、离线混部及资源调度技术手册 目录 概述 原理基础 2.1 Kubernetes调度基础 2.2 大规模训练任务的调度挑战 2.3 推理服务调度的特殊需求 2.4 离线混部的基本原理核心技术与实现 3.1 Kubernetes在训练任务编排中的应用 3.2 Kubernetes在推理服务调度中的应用 3.3 离线混部的实现方式案例与实践 4.1 案例一:基于Kubeflow和Volcano的分布式训练任务编排 4.2 案例二:基于KServe和Triton的推理服务部署与自动扩缩 4.3 案例三:离线混部场景下的资源调度优化总结与展望 第1章 概述 随着人工智能(AI)和深度学习的飞速发展,训练大规模模型和部署高并发推理服务已成为常态。这些工作负载对底层基础设施提出了独特且严苛的要求,远非传统Web应用可比。在训练任务方面,一个深度学习训练作业往往由成百上千个协同工作的子任务组成,需要同时调度大量计算节点,可能涉及GPU等异构资源,并且训练周期长、资源需求波动大。而推理服务则要求低延迟、高吞吐,需要根据请求流量动态扩缩容,并确保服务级别协议(SLA)。...
记录一次claude code->litellm->openrouter->claude/gpt模型调用bug的修复
记录一次claude code->litellm->openrouter->claude/gpt模型调用bug的修复 12345678910111213141516171819 lvzhongrenjie@MacBook-Pro ~/python_project/litellm-roger main claude ▐▛███▜▌ Claude Code v2.1.69▝▜█████▛▘ claude-opus-4.6 · API Usage Billing ▘▘ ▝▝ ~/python_project/litellm-roger /model to try Opus 4.6❯ list the files in the directory ⎿ API Error: 400 {"error":{"message":"litellm.BadRequestError: OpenAIException - {\"error\":...
八字命理之贵人篇
八字命理之贵人篇 “贵人”在八字里是一大类“吉神”的统称,核心意思都是:逢凶化吉、遇人提携、办事顺遂。 不同贵人星侧重点不同:有的主官贵,有的主学术,有的主健康、衣食、车马等等。 它们都要在整体五行格局、喜忌的基础上看,不是“带个贵人星就富贵”。 下面按“是什么–有哪些–怎么查–怎么用”系统讲一遍,尽量全面细致。 一、总体概念:贵人是什么? 本质:代表“助力、保护、转机”的吉神 在子平法里,“贵人”属于神煞系统的一类,多是从天干地支组合中取象,象征: 遇事有人帮、逢凶化吉; 易得提携、机会多; 人缘好、能逢凶化吉。 地位:是“象义”,不是断命的唯一依据 古今共识:五行生克制化、格局喜用才是主线,神煞(贵人)只是辅助象义。 同一个贵人星,在不同命局里,可以是: 真贵人:为喜用、无破,助力大; 假贵人:为忌神或被刑冲破害,助力很有限,甚至变成“负担”或“虚名”。 大原则:贵人星要“有用”才贵 喜用神同宫、得生旺、不被冲破:贵人力量大。 为忌神、或落空亡、被刑冲:贵人“打折”,甚至变成“贵人多生病、多事端”。 二、贵人星的大致分类 先给你一个整体框架,方便有个总...
🦌 DeerFlow - 字节跳动开源的超级智能体框架
🦌 DeerFlow - 字节跳动开源的超级智能体框架 初步简介 GitHub: https://github.com/bytedance/deer-flow 📌 一句话介绍 DeerFlow 是一个开源的 SuperAgent Harness(超级智能体框架),能够研究、编码、创作——通过沙箱、记忆、工具、技能和子代理,处理从几分钟到几小时的复杂任务。 🎯 核心定位 DeerFlow 不是一个简单的聊天机器人框架,而是一个完整的智能体运行环境: 传统 Agent DeerFlow 只有工具调用 有自己的沙箱计算机 无状态对话 长期记忆,越用越懂你 单一任务 子代理并行,复杂任务分解 需要手动组装 开箱即用,技能可扩展 🚀 主要功能 1. 技能系统 (Skills) 1234567内置技能:├── research/ # 深度研究├── report-generation/ # 报告生成├── slide-creation/ # PPT 制作├── web-page/ # 网页生成├── ...
OpenClaw解析
OpenClaw解析 https://zhuanlan.zhihu.com/p/2000850539936765122 记忆系统尤其关注下 https://zhuanlan.zhihu.com/p/1999989672403812713
OpenClaw记忆系统分析
OpenClaw记忆系统深度解析:构建AI代理的长期记忆能力 摘要 OpenClaw作为一个多通道AI代理平台,其核心能力之一就是为AI代理提供长期记忆功能。本文深入分析OpenClaw记忆系统的架构设计、实现原理和技术细节,涵盖从本地向量存储到外部记忆系统集成的完整技术栈。 1. 记忆系统架构概览 OpenClaw的记忆系统采用分层架构设计,主要包含以下核心组件: 1.1 核心架构图 graph TB A[记忆系统] --> B[MemoryIndexManager] B --> C[嵌入向量层] B --> D[存储引擎层] B --> E[搜索算法层] C --> C1[OpenAI嵌入] C --> C2[Gemini嵌入] C --> C3[本地模型] D --> D1[SQLite向量存储] D --> D2[FTS5全文检索] D --> D3[文件系统索引] E --> E1[混合搜索算法] E --> E2[相关性排序] E --...
AI Infra相关
AI Infra相关 K8S 异构容错 会有一些挑战: 大规模分布式训练任务为了适应国产芯片需要更大规模 原因在于国产卡的算力比不上N卡,自然需要更大规模 大模型分布式训练任务频繁中断 目前几乎所有的大模型训练方式都是同步训练(DDP/MPI),训练的进程共同使用一个通信拓扑,当某一个进程发生错误时,其他进程也会相继退出 异构芯片及服务器集群的故障率与集群规模成正比,且随着集群规模的扩大训练任务的中断次数成倍增加 BLOOM 176B的训练, 在大约400个GPU的新集群上,平均每周都会遇到1-2个GPU故障。 字节的大规模训练也呈现相应的特征。[from MegaScale] 大模型分布式训练任务出错原因难排查 net ib? socket timeout gpu ecc error 这些问题靠重新调度是无法解决的,需要准确定位到节点出错的位置,这需要花费数小时甚至数天的时间(可观测性建设) 日益凸显。 为了解决这些痛点,Kubernetes 推出了 Dynamic Resource Allocation (DRA)。该特性在 v1.34 版本中已正式进入 GA(General Availability) 阶段,标志着 K8s 进入了异构资源管理的 2.0 时代。 一、 为什么需要 DRA?(痛点分析) 在 DRA 出现之前,Device Plugin 是管理硬件的主力,但它有三个致命伤: 静态分配:资源请求只能是整数(如 nvidia.com/gpu: 1),难以实现 GPU 分片或复杂的组合请求。 网络与存储隔离:硬件驱动无法深度参与调度决策,导致调度器可能把 Pod 调度到一个虽然有 GPU 但网络带宽不足的节点上。 API...
万亿参数大模型训练的网络架构革新:Rail-only 旋转星云式拓扑深度解读
万亿参数大模型训练的网络架构革新:Rail-only 旋转星云式拓扑深度解读 随着生成式人工智能(GenAI)的爆发,大型语言模型(LLM)的参数规模已从百亿量级迅速跨越至万亿量级 1。2020 年发布的 GPT-3 模型需要 NVIDIA V100 GPU 运行 355 个 GPU 年才能完成训练,而当前的 GPT-4 等模型估计拥有超过一万亿个参数,训练周期长达数月 1。在摩尔定律放缓的背景下,单枚加速器的算力增长速度已无法跟上模型规模及计算需求的指数级飙升,这使得超大规模 GPU 集群的部署成为必然趋势。行业领先的机器学习架构师预测,下一代 LLM 训练可能需要超过 30,000 个 GPU 的计算能力才能在合理时间内完成 1。然而,如何高效、低成本地连接这些数以万计的 GPU,已成为制约人工智能发展的关键基础设施瓶颈。 算力中心的基石:GPU 互连域的划分 在理解 Rail-only 架构之前,必须深入剖析当前超大规模 GPU 数据中心的设计范式。现代 GPU 集群通常被划分为两个截然不同的通信域:高带宽域(High-Bandwidth Domain, HBD)和网络接口...






