[{"data":1,"prerenderedAt":1931},["ShallowReactive",2],{"home-news-zh":3,"mail-list-zh":1809,"home-whitepapers-zh":1824,"home-docs-zh":1844},[4,36,56,76,95,115],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"date":11,"cover":12,"type":13,"body":14,"_type":30,"_id":31,"_source":32,"_file":33,"_stem":34,"_extension":35},"\u002Fzh\u002Fnews\u002Fsimu-class1","news",false,"","灵衢协议仿真平台公开课-面向灵衢的超节点AI训推性能仿真",null,"2026\u002F07\u002F23 12:00","\u002Fcategory\u002Fnews\u002Fsimu-class\u002Fclass1-cover.jpg","events",{"type":15,"children":16,"toc":27},"root",[17],{"type":18,"tag":19,"props":20,"children":21},"element","p",{},[22],{"type":18,"tag":23,"props":24,"children":26},"img",{"alt":23,"src":25},"\u002Fcategory\u002Fnews\u002Fsimu-class\u002Fclass1.png",[],{"title":8,"searchDepth":28,"depth":28,"links":29},4,[],"markdown","content:zh:news:simu-class1.md","content","zh\u002Fnews\u002Fsimu-class1.md","zh\u002Fnews\u002Fsimu-class1","md",{"_path":37,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":38,"description":10,"date":39,"cover":40,"type":13,"body":41,"_type":30,"_id":53,"_source":32,"_file":54,"_stem":55,"_extension":35},"\u002Fzh\u002Fnews\u002Flive-public-class9","灵衢协议解码公开课-安全解读","2026\u002F06\u002F10 18:00","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class9-cover.jpg",{"type":15,"children":42,"toc":51},[43],{"type":18,"tag":19,"props":44,"children":45},{},[46],{"type":18,"tag":23,"props":47,"children":50},{"alt":48,"src":49},"安全解读公开课内容图","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class9.jpg",[],{"title":8,"searchDepth":28,"depth":28,"links":52},[],"content:zh:news:live-public-class9.md","zh\u002Fnews\u002Flive-public-class9.md","zh\u002Fnews\u002Flive-public-class9",{"_path":57,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":58,"description":10,"date":59,"cover":60,"type":13,"body":61,"_type":30,"_id":73,"_source":32,"_file":74,"_stem":75,"_extension":35},"\u002Fzh\u002Fnews\u002Flive-public-class8","灵衢协议解码公开课-资源管理解读","2026\u002F06\u002F09 18:00","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class8-cover.jpg",{"type":15,"children":62,"toc":71},[63],{"type":18,"tag":19,"props":64,"children":65},{},[66],{"type":18,"tag":23,"props":67,"children":70},{"alt":68,"src":69},"内存管理公开课内容图","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class8.jpg",[],{"title":8,"searchDepth":28,"depth":28,"links":72},[],"content:zh:news:live-public-class8.md","zh\u002Fnews\u002Flive-public-class8.md","zh\u002Fnews\u002Flive-public-class8",{"_path":77,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":78,"description":10,"date":79,"cover":80,"type":13,"body":81,"_type":30,"_id":92,"_source":32,"_file":93,"_stem":94,"_extension":35},"\u002Fzh\u002Fnews\u002Flive-public-class7","灵衢协议解码公开课-内存管理解读","2026\u002F06\u002F04 18:00","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class7-cover.jpg",{"type":15,"children":82,"toc":90},[83],{"type":18,"tag":19,"props":84,"children":85},{},[86],{"type":18,"tag":23,"props":87,"children":89},{"alt":68,"src":88},"\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class7.jpg",[],{"title":8,"searchDepth":28,"depth":28,"links":91},[],"content:zh:news:live-public-class7.md","zh\u002Fnews\u002Flive-public-class7.md","zh\u002Fnews\u002Flive-public-class7",{"_path":96,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":97,"description":10,"date":98,"cover":99,"type":13,"body":100,"_type":30,"_id":112,"_source":32,"_file":113,"_stem":114,"_extension":35},"\u002Fzh\u002Fnews\u002Flive-public-class6","灵衢协议解码公开课-事务层+功能层解读","2026\u002F05\u002F30 18:00","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class6-cover.jpg",{"type":15,"children":101,"toc":110},[102],{"type":18,"tag":19,"props":103,"children":104},{},[105],{"type":18,"tag":23,"props":106,"children":109},{"alt":107,"src":108},"img1","\u002Fcategory\u002Fnews\u002Flive-public-class\u002Flive-public-class6.jpg",[],{"title":8,"searchDepth":28,"depth":28,"links":111},[],"content:zh:news:live-public-class6.md","zh\u002Fnews\u002Flive-public-class6.md","zh\u002Fnews\u002Flive-public-class6",{"_path":116,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":117,"description":118,"date":119,"cover":120,"type":6,"body":121,"_type":30,"_id":1806,"_source":32,"_file":1807,"_stem":1808,"_extension":35},"\u002Fzh\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology","UB核心优势之内存池化｜大规模AI集群内存访问机制技术深度解读","AI模型规模、上下文长度和推理链路持续增长，内存系统正在从单卡容量问题转变为跨卡、跨节点协同问题。仅增加单卡HBM容量，难以解决集群中内存分布不均、远端访问开销高和权限隔离复杂等问题。","2026\u002F05\u002F28 18:00","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Fcover.png",{"type":15,"children":122,"toc":1790},[123,143,149,153,158,163,170,175,188,200,212,217,222,306,312,317,322,332,342,352,364,370,375,381,386,409,414,419,424,430,435,454,460,465,475,485,495,500,505,524,530,535,547,552,571,577,582,594,599,604,649,654,659,665,670,675,680,688,693,698,703,708,727,733,738,743,753,763,768,773,874,880,885,890,909,915,920,925,931,936,941,946,951,956,962,967,1039,1044,1049,1054,1060,1065,1070,1075,1084,1089,1095,1100,1105,1117,1122,1128,1133,1138,1209,1214,1233,1238,1276,1281,1325,1330,1343,1348,1354,1359,1364,1370,1382,1387,1392,1397,1402,1407,1413,1418,1423,1428,1433,1438,1457,1462,1669,1675,1680,1690,1700,1710,1720,1725,1731,1736,1741,1746,1751,1756,1761,1784],{"type":18,"tag":19,"props":124,"children":125},{},[126],{"type":18,"tag":127,"props":128,"children":129},"i",{},[130,133,141],{"type":131,"value":132},"text","编者按：文章转载自FreedomChips自由芯，原文链接接 ",{"type":18,"tag":134,"props":135,"children":139},"a",{"href":136,"rel":137},"https:\u002F\u002Fmp.weixin.qq.com\u002Fs\u002FJo2ftTk3Ncea9IsnlVpFpA",[138],"nofollow",[140],{"type":131,"value":136},{"type":131,"value":142}," 。",{"type":18,"tag":144,"props":145,"children":147},"h2",{"id":146},"引言",[148],{"type":131,"value":146},{"type":18,"tag":19,"props":150,"children":151},{},[152],{"type":131,"value":118},{"type":18,"tag":19,"props":154,"children":155},{},[156],{"type":131,"value":157},"UB（UnifiedBus，灵衢）协议从硬件栈底层定义跨节点内存访问机制。它把地址翻译、权限校验和Load\u002FStore访问语义扩展到跨节点范围，使远端HBM能够以受控、可验证、低CPU介入的方式参与计算。",{"type":18,"tag":19,"props":159,"children":160},{},[161],{"type":131,"value":162},"本文聚焦UB协议中的关键能力：跨节点内存池化。文章先提炼AI集群内存系统的主要约束，再梳理UB的设计思路、协议架构和硬件模块，随后通过一个两卡共享内存案例串联核心机制，最后回到AI负载场景分析其价值。",{"type":18,"tag":164,"props":165,"children":167},"h1",{"id":166},"一ai集群内存系统的三重困境",[168],{"type":131,"value":169},"一、AI集群内存系统的三重困境",{"type":18,"tag":19,"props":171,"children":172},{},[173],{"type":131,"value":174},"要理解UB的价值，需要先看清内存池化要解决的三个核心约束：容量、资源利用率和访问开销。",{"type":18,"tag":19,"props":176,"children":177},{},[178,180,186],{"type":131,"value":179},"第一是",{"type":18,"tag":181,"props":182,"children":183},"strong",{},[184],{"type":131,"value":185},"容量墙",{"type":131,"value":187},"。大模型权重、KV Cache、激活值和优化器状态会共同占用大量显存。单卡容量增长有限，模型部署越来越依赖多卡和多节点协同。",{"type":18,"tag":19,"props":189,"children":190},{},[191,193,198],{"type":131,"value":192},"第二是",{"type":18,"tag":181,"props":194,"children":195},{},[196],{"type":131,"value":197},"资源孤岛",{"type":131,"value":199},"。不同加速卡或节点上的HBM通常归属各自设备，空闲显存难以被其他计算任务直接使用。即使集群总显存充足，单个任务仍可能因本地显存不足而受限。",{"type":18,"tag":19,"props":201,"children":202},{},[203,205,210],{"type":131,"value":204},"第三是",{"type":18,"tag":181,"props":206,"children":207},{},[208],{"type":131,"value":209},"通信墙",{"type":131,"value":211},"。远端数据访问如果停留在显式搬运模式，应用需要处理注册、同步、鉴权、重试和调试等复杂流程。对于高频小粒度访问，软件提交与轮询路径还会引入额外CPU开销。",{"type":18,"tag":19,"props":213,"children":214},{},[215],{"type":131,"value":216},"这三个约束叠加后形成一个明确的工程矛盾：AI集群规模在增长，但跨卡、跨节点的有效内存协作能力没有同步提升。UB内存池化要解决的正是这种规模与协作能力之间的落差。",{"type":18,"tag":19,"props":218,"children":219},{},[220],{"type":131,"value":221},"表1汇总了三类约束及其根本原因。",{"type":18,"tag":223,"props":224,"children":225},"table",{},[226,250],{"type":18,"tag":227,"props":228,"children":229},"thead",{},[230],{"type":18,"tag":231,"props":232,"children":233},"tr",{},[234,240,245],{"type":18,"tag":235,"props":236,"children":237},"th",{},[238],{"type":131,"value":239},"困境",{"type":18,"tag":235,"props":241,"children":242},{},[243],{"type":131,"value":244},"表现",{"type":18,"tag":235,"props":246,"children":247},{},[248],{"type":131,"value":249},"根本原因",{"type":18,"tag":251,"props":252,"children":253},"tbody",{},[254,272,289],{"type":18,"tag":231,"props":255,"children":256},{},[257,262,267],{"type":18,"tag":258,"props":259,"children":260},"td",{},[261],{"type":131,"value":185},{"type":18,"tag":258,"props":263,"children":264},{},[265],{"type":131,"value":266},"单卡HBM难以承载持续增长的模型状态",{"type":18,"tag":258,"props":268,"children":269},{},[270],{"type":131,"value":271},"模型权重、KV Cache和训练状态增长快于单卡容量",{"type":18,"tag":231,"props":273,"children":274},{},[275,279,284],{"type":18,"tag":258,"props":276,"children":277},{},[278],{"type":131,"value":197},{"type":18,"tag":258,"props":280,"children":281},{},[282],{"type":131,"value":283},"集群总显存充足但局部设备显存紧张",{"type":18,"tag":258,"props":285,"children":286},{},[287],{"type":131,"value":288},"远端内存难以直接进入本地地址空间",{"type":18,"tag":231,"props":290,"children":291},{},[292,296,301],{"type":18,"tag":258,"props":293,"children":294},{},[295],{"type":131,"value":209},{"type":18,"tag":258,"props":297,"children":298},{},[299],{"type":131,"value":300},"高频小粒度远端访问开销高",{"type":18,"tag":258,"props":302,"children":303},{},[304],{"type":131,"value":305},"缺少统一的硬件级访问、翻译和权限校验语义",{"type":18,"tag":164,"props":307,"children":309},{"id":308},"二ub的架构哲学",[310],{"type":131,"value":311},"二、UB的架构哲学",{"type":18,"tag":19,"props":313,"children":314},{},[315],{"type":131,"value":316},"面对这三重困境，UB从硬件栈底层重新思考远端内存如何以接近本地内存的方式被访问，并围绕地址翻译、访问语义和权限校验建立完整机制。",{"type":18,"tag":19,"props":318,"children":319},{},[320],{"type":131,"value":321},"三个关键设计选择决定了UB的构造定位。",{"type":18,"tag":19,"props":323,"children":324},{},[325,330],{"type":18,"tag":181,"props":326,"children":327},{},[328],{"type":131,"value":329},"第一，把远端内存纳入硬件级地址翻译体系。",{"type":131,"value":331}," 在UB中，远端内存不仅是可传输的数据区域，也可以通过受控地址语义被访问。这要求接收方在每次访问时完成地址翻译与权限校验。执行该工作的模块是UMMU（UB Memory Management Unit），可以理解为CPU MMU跨节点语义的延伸。",{"type":18,"tag":19,"props":333,"children":334},{},[335,340],{"type":18,"tag":181,"props":336,"children":337},{},[338],{"type":131,"value":339},"第二，同时支持同步和异步两种访问语义。",{"type":131,"value":341}," UB提供URMA异步接口，也提供Load\u002FStore同步语义：CPU的一条mov指令可以触发远端HBM读写，访问方式与本地内存访问保持一致。这依赖发起侧的UBDecoder硬件，它把本地物理地址反向翻译为远端地址和描述符。",{"type":18,"tag":19,"props":343,"children":344},{},[345,350],{"type":18,"tag":181,"props":346,"children":347},{},[348],{"type":131,"value":349},"第三，把身份管理从数据面剥离。",{"type":131,"value":351}," UB引入分层标识符体系：CNA（Compact Network Address）表示路由到节点，EID（Entity identifier）定位到实体，TokenID指向内存段，UBA精确到字节，TokenValue验证权限。这些标识符各司其职，分别由UBFM（UB Fabric Manager）固件、UMMU硬件和应用软件等角色分配和使用。应用侧重点从网络路径管理转向凭据持有与访问语义。",{"type":18,"tag":19,"props":353,"children":354},{},[355,357,362],{"type":131,"value":356},"这三个设计选择共同构建了UB内存池化的基础：",{"type":18,"tag":181,"props":358,"children":359},{},[360],{"type":131,"value":361},"全局统一地址空间 + 双模态访问语义 + 硬件权限校验",{"type":131,"value":363},"。下一节我们从协议整体架构出发，看这三个设计如何落地到具体的硬件和协议层次上。",{"type":18,"tag":164,"props":365,"children":367},{"id":366},"三从协议架构看跨节点内存池化",[368],{"type":131,"value":369},"三、从协议架构看跨节点内存池化",{"type":18,"tag":19,"props":371,"children":372},{},[373],{"type":131,"value":374},"UB是一套完整的协议栈，规范将其定义为六层结构加上两个横向协作的独立模块。要理解内存池化，必须先建立对整体架构的直观认识，再从中识别出直接参与池化的功能单元。",{"type":18,"tag":144,"props":376,"children":378},{"id":377},"_31-ub协议整体架构",[379],{"type":131,"value":380},"3.1 UB协议整体架构",{"type":18,"tag":19,"props":382,"children":383},{},[384],{"type":131,"value":385},"规范第2.2章节描绘的UB协议栈从下往上依次是物理层、数据链路层、网络层、传输层、事务层和功能层，另有UMMU作为内存访问的旁路验证模块，UBFM作为全局资源管理的控制面实体。其抽象表达如下：",{"type":18,"tag":387,"props":388,"children":390},"div",{"style":389},"text-align: center;margin:24px 0;",[391,399],{"type":18,"tag":19,"props":392,"children":393},{},[394],{"type":18,"tag":23,"props":395,"children":398},{"alt":396,"src":397},"图1","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig1-ub-protocol-stack.png",[],{"type":18,"tag":19,"props":400,"children":401},{},[402],{"type":18,"tag":403,"props":404,"children":406},"span",{"style":405},"opacity: 0.8",[407],{"type":131,"value":408},"图1 UB协议栈与内存池化相关模块",{"type":18,"tag":19,"props":410,"children":411},{},[412],{"type":131,"value":413},"功能层把Load\u002FStore同步访问和URMA异步访问并列为两种合法的编程模型。应用既可以通过异步队列提交批量传输，也可以通过本地指针语义触发远端HBM细粒度访问。",{"type":18,"tag":19,"props":415,"children":416},{},[417],{"type":131,"value":418},"事务层把内存访问单列为一类事务，与消息传递、维护操作、管理消息并列。规范定义的Write（TAOpcode=0x03）、Read（0x06）、Atomic（0x07-0x0F）等事务类型都属于此类，它们是内存池化的直接协议承载。",{"type":18,"tag":19,"props":420,"children":421},{},[422],{"type":131,"value":423},"UMMU与UBFM作为协议栈旁路的独立模块存在。UMMU参与事务层的接收处理，承担地址翻译与权限校验；UBFM不参与任何单次事务处理，但负责全局身份分配和路由建立。它们不是协议栈的层，却是内存池化不可或缺的协作方。",{"type":18,"tag":144,"props":425,"children":427},{"id":426},"_32-ub系统的硬件组成",[428],{"type":131,"value":429},"3.2 UB系统的硬件组成",{"type":18,"tag":19,"props":431,"children":432},{},[433],{"type":131,"value":434},"再看规范第2.1章节图2-1描绘的UB Domain系统组成。一个UB Domain由若干UBPU（UB Processing Unit，UB协议处理单元）通过UB Link互联构成UB Fabric。每颗UBPU内部是计算核（CPU\u002FNPU\u002FGPU\u002F存储等不同类型）加上UB协议处理硬件的组合：",{"type":18,"tag":387,"props":436,"children":437},{"style":389},[438,446],{"type":18,"tag":19,"props":439,"children":440},{},[441],{"type":18,"tag":23,"props":442,"children":445},{"alt":443,"src":444},"图2","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig2-ub-domain-hardware.png",[],{"type":18,"tag":19,"props":447,"children":448},{},[449],{"type":18,"tag":403,"props":450,"children":451},{"style":405},[452],{"type":131,"value":453},"图2 UB Domain硬件组成",{"type":18,"tag":144,"props":455,"children":457},{"id":456},"_33-从架构到池化相关模块的角色定位",[458],{"type":131,"value":459},"3.3 从架构到池化：相关模块的角色定位",{"type":18,"tag":19,"props":461,"children":462},{},[463],{"type":131,"value":464},"把协议栈视图和硬件视图叠加起来，与内存池化直接相关的功能模块可以梳理为三组。",{"type":18,"tag":19,"props":466,"children":467},{},[468,473],{"type":18,"tag":181,"props":469,"children":470},{},[471],{"type":131,"value":472},"协议栈上的池化承载层。",{"type":131,"value":474}," 功能层暴露Load\u002FStore和URMA两种编程入口；事务层通过MAETAH（Memory Access Extended Transaction Header）扩展头承载UBA与TokenID，通过TVETAH（Token Value Extended Transaction Header）承载32-bit权限凭证，TVETAH的携带与否由BTAH中的TV_EN位控制，只有启用权限校验的事务才会附带它；传输层为内存访问提供可靠（RTP）、轻量（CTP）或直通（TP Bypass）三种传输语义；网络层负责跨节点路由并通过FECN实现拥塞感知；数据链路层与物理层则是向远程显存发出和接收字节流的基础承载。",{"type":18,"tag":19,"props":476,"children":477},{},[478,483],{"type":18,"tag":181,"props":479,"children":480},{},[481],{"type":131,"value":482},"UBPU内的池化专用硬件。",{"type":131,"value":484}," UB Controller是协议栈的主执行者，负责封包\u002F解包与Jetty管理；UMMU是接收方的地址翻译与权限校验引擎，是整个池化机制的守门员；UB Decoder位于发起方，在Load\u002FStore场景下把本地物理地址反向翻译为UBMD，让CPU的mov指令可以直达远端HBM；UB Switch是多端口的转发单元，负责ECMP路由与FECN标记。",{"type":18,"tag":19,"props":486,"children":487},{},[488,493],{"type":18,"tag":181,"props":489,"children":490},{},[491],{"type":131,"value":492},"控制平面的协调者。",{"type":131,"value":494}," UBFM作为运行在某颗UBPU上的固件，承担拓扑枚举、CNA\u002FEID分配、路由表下发等全局任务；OS驱动负责Jetty创建、内存段注册、UB Decoder页表维护等节点级管理。",{"type":18,"tag":19,"props":496,"children":497},{},[498],{"type":131,"value":499},"这三组模块不是孤立存在的，它们在内存池化的每个环节都有精确分工。接下来的章节将深入最核心的几个抽象。",{"type":18,"tag":19,"props":501,"children":502},{},[503],{"type":131,"value":504},"在展开细节之前，把后面反复出现的五个标识符先放在一张图上。内存池化的很多混淆都源于这套标识符体系。它们粒度由粗到细，分别回答访问谁的五个子问题：",{"type":18,"tag":387,"props":506,"children":507},{"style":389},[508,516],{"type":18,"tag":19,"props":509,"children":510},{},[511],{"type":18,"tag":23,"props":512,"children":515},{"alt":513,"src":514},"图3","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig3-ub-identifier-layers.png",[],{"type":18,"tag":19,"props":517,"children":518},{},[519],{"type":18,"tag":403,"props":520,"children":521},{"style":405},[522],{"type":131,"value":523},"图3 UB内存访问标识符分层",{"type":18,"tag":164,"props":525,"children":527},{"id":526},"四内存池化的核心抽象",[528],{"type":131,"value":529},"四、内存池化的核心抽象",{"type":18,"tag":19,"props":531,"children":532},{},[533],{"type":131,"value":534},"从协议细节回到概念层面，UB内存池化的运行可以归结为一个简洁模型加上三层协作机制。",{"type":18,"tag":19,"props":536,"children":537},{},[538,540,545],{"type":131,"value":539},"UB规范第九章首先建立了",{"type":18,"tag":181,"props":541,"children":542},{},[543],{"type":131,"value":544},"Home-User访问模型",{"type":131,"value":546},"：注册并提供内存资源的一方称为Home；访问远端内存的一方称为User。模型本身很直白，但意义深远：它把跨节点共享内存定义为两个分布式系统中常被误解的概念，还原为谁拥有、谁使用的清晰主客体关系。任何一次跨节点内存访问，在规范术语中都可以简化为User持凭据访问Home的过程。后面的所有讨论都在这一模型之上展开：Home通过内存注册生产凭据，User通过凭据发起访问，硬件在两侧分别完成各自的翻译与校验工作。",{"type":18,"tag":19,"props":548,"children":549},{},[550],{"type":131,"value":551},"围绕这个模型，三层机制层层递进：凭据系统让User能够精确表达我要访问哪块内存；翻译引擎在Home侧和User侧分别完成地址的正反翻译与权限校验；全局管理为前两者准备好网络身份与路由基础。三者环环相扣，缺一不可。",{"type":18,"tag":387,"props":553,"children":554},{"style":389},[555,563],{"type":18,"tag":19,"props":556,"children":557},{},[558],{"type":18,"tag":23,"props":559,"children":562},{"alt":560,"src":561},"图4","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig4-home-user-model.png",[],{"type":18,"tag":19,"props":564,"children":565},{},[566],{"type":18,"tag":403,"props":567,"children":568},{"style":405},[569],{"type":131,"value":570},"图4 Home-User访问模型",{"type":18,"tag":144,"props":572,"children":574},{"id":573},"_41-ubmd跨节点访问的凭据系统",[575],{"type":131,"value":576},"4.1 UBMD：跨节点访问的凭据系统",{"type":18,"tag":19,"props":578,"children":579},{},[580],{"type":131,"value":581},"UBMD（UB Memory Descriptor，UB内存描述符）是UB规范定义的三元组：",{"type":18,"tag":583,"props":584,"children":588},"pre",{"className":585,"code":587,"language":131,"meta":8},[586],"language-text","UBMD = { EID, TokenID, UBA }\n",[589],{"type":18,"tag":590,"props":591,"children":592},"code",{"__ignoreMap":8},[593],{"type":131,"value":587},{"type":18,"tag":19,"props":595,"children":596},{},[597],{"type":131,"value":598},"再配上一个独立传递的TokenValue，就构成了一次跨节点内存访问的完整凭据。",{"type":18,"tag":19,"props":600,"children":601},{},[602],{"type":131,"value":603},"这四个字段可以按访问定位与权限校验的层次来理解：",{"type":18,"tag":605,"props":606,"children":607},"ul",{},[608,619,629,639],{"type":18,"tag":609,"props":610,"children":611},"li",{},[612,617],{"type":18,"tag":181,"props":613,"children":614},{},[615],{"type":131,"value":616},"EID",{"type":131,"value":618},"标识目标内存归属的Entity。一颗UBPU可以承载多个Entity，每个Entity拥有独立资源配额，可服务不同租户或业务。",{"type":18,"tag":609,"props":620,"children":621},{},[622,627],{"type":18,"tag":181,"props":623,"children":624},{},[625],{"type":131,"value":626},"TokenID",{"type":131,"value":628},"标识Entity内的共享内存段。一个Entity可以注册多块内存段，TokenID用于选择对应的翻译与权限上下文。",{"type":18,"tag":609,"props":630,"children":631},{},[632,637],{"type":18,"tag":181,"props":633,"children":634},{},[635],{"type":131,"value":636},"UBA",{"type":131,"value":638},"（UB Address）表示段内逻辑地址。它由Home侧规划，不是物理地址，也不是User本地虚拟地址，而是Home Entity维护的地址空间，由UMMU翻译为真实物理地址。",{"type":18,"tag":609,"props":640,"children":641},{},[642,647],{"type":18,"tag":181,"props":643,"children":644},{},[645],{"type":131,"value":646},"TokenValue",{"type":131,"value":648},"是运行时权限凭据。它不属于UBMD本身，可独立轮换，用于细粒度权限管理。",{"type":18,"tag":19,"props":650,"children":651},{},[652],{"type":131,"value":653},"这四者缺一不可：EID定位实体，TokenID定位内存段，UBA定位段内字节，TokenValue负责权限验证。任一字段不匹配都会导致访问失败，这是多租户场景下硬件级隔离的基础。",{"type":18,"tag":19,"props":655,"children":656},{},[657],{"type":131,"value":658},"一个值得注意的细节：规范允许MAPTE（MAPT Entry）同时存储主和备两个TokenValue。初始注册时两者可以相同也可以不同。这个设计为权限管理保留了更灵活的操作空间。若不同User或租户被分配了不同的TokenValue，需要撤销某个用户但保留其他用户的访问时，只需替换对应TokenValue即可，无需销毁整个内存段。这使权限回收可以在不销毁内存段的情况下完成，在大规模多租户环境下具有实际价值。",{"type":18,"tag":144,"props":660,"children":662},{"id":661},"_42-ummu与ub-decoder地址翻译的两端",[663],{"type":131,"value":664},"4.2 UMMU与UB Decoder：地址翻译的两端",{"type":18,"tag":19,"props":666,"children":667},{},[668],{"type":131,"value":669},"UMMU（UB Memory Management Unit）位于每个Home侧UBPU内部，是内存池化的核心硬件执行者。它和CPU的MMU在功能上高度相似，都负责虚拟地址到物理地址的翻译和权限校验，区别在于CPU MMU服务于本机进程的虚拟地址空间，UMMU服务于跨节点访问产生的虚拟地址请求。",{"type":18,"tag":19,"props":671,"children":672},{},[673],{"type":131,"value":674},"每当一个远端访问请求到达UMMU，它会在硬件流水线中完成四步验证，避免让CPU介入单次权限判断。首先按DEID查TECT（Target Entity Configuration Table），获得该Entity对应的TCT基址；然后按TokenID查TCT（Target Context Table），获得该内存段对应的MATT基址与MAPT基址；接着按UBA走MATT（Memory Address Translation Table）的多级页表，翻译出真实物理地址；最后按UBA查MAPT（Memory Address Permission Table），比对请求携带的TokenValue是否匹配MAPTE中的主\u002F备锁，并校验Permission是否包含请求的访问类型。四步全部通过后，DMA引擎才会实际访问物理内存。",{"type":18,"tag":19,"props":676,"children":677},{},[678],{"type":131,"value":679},"UMMU的设计中还有一个特别值得一提的细节：它支持两阶段地址翻译。Stage 1把UBA翻译为IPA（中间物理地址），Stage 2把IPA翻译为PA（真实物理地址）。这不仅完整对齐了ARM SMMU在虚拟化场景下的地址转换语义，一个Entity被直通给虚拟机时，Stage 1由Guest OS控制，Stage 2由Hypervisor控制，多租户的虚拟化隔离由硬件直接保证。这让UB Entity的虚拟化直通成为一种自然的硬件能力，而不是软件模拟出来的效果。",{"type":18,"tag":19,"props":681,"children":682},{},[683],{"type":18,"tag":181,"props":684,"children":685},{},[686],{"type":131,"value":687},"User侧：UB Decoder的反向翻译。",{"type":18,"tag":19,"props":689,"children":690},{},[691],{"type":131,"value":692},"单靠UMMU只能解决Home如何验证外来请求的问题。要让Load\u002FStore同步访问成立，还需要在User侧有一个反向的翻译机制，这就是UB Decoder的角色。",{"type":18,"tag":19,"props":694,"children":695},{},[696],{"type":131,"value":697},"UB Decoder管理一套两级本地页表（L0\u002FL1 PTE），把本地物理地址范围映射到远端UBMD。当CPU发出一条mov指令访问某个内存地址时，UB Decoder拦截这次访问，查本地页表得到{EID, TokenID, UBA_BASE, TokenValue}，把本地物理地址的低位拼到UBA_BASE上形成完整的UBA。这组信息交给UB Controller封包发送，对CPU而言整个过程完全透明，从CPU视角看，这仍然是一次Load\u002FStore访问；跨芯片细节由UB Decoder和UB Controller处理。",{"type":18,"tag":19,"props":699,"children":700},{},[701],{"type":131,"value":702},"UMMU和UB Decoder的关系可以这样概括：User侧UB Decoder把物理地址反向翻译为UBMD（PA到UBMD），Home侧UMMU把UBMD正向翻译为物理地址（UBMD到PA）。两端各自管理各自的页表，互不干扰。URMA异步访问则只走Home侧UMMU这一半，因为应用已经直接在WQE里提供了UBMD，不需要UB Decoder做反向翻译。",{"type":18,"tag":19,"props":704,"children":705},{},[706],{"type":131,"value":707},"这里有一个根本的工程哲学：内存池化的权限控制必须在硬件完成，不能依赖软件。AI训练场景下单秒可能有数百万次远端内存访问，如果每次都需要CPU介入校验，软件根本扛不住。UMMU与UB Decoder的硬件化设计把单次翻译与校验从CPU调用路径中移出，让低CPU开销的池化访问从愿望变成现实。",{"type":18,"tag":387,"props":709,"children":710},{"style":389},[711,719],{"type":18,"tag":19,"props":712,"children":713},{},[714],{"type":18,"tag":23,"props":715,"children":718},{"alt":716,"src":717},"图5","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig5-ummu-verification-flow.png",[],{"type":18,"tag":19,"props":720,"children":721},{},[722],{"type":18,"tag":403,"props":723,"children":724},{"style":405},[725],{"type":131,"value":726},"图5 UMMU四步验证流水",{"type":18,"tag":144,"props":728,"children":730},{"id":729},"_43-ubfm全局资源的调度中枢",[731],{"type":131,"value":732},"4.3 UBFM：全局资源的调度中枢",{"type":18,"tag":19,"props":734,"children":735},{},[736],{"type":131,"value":737},"凭据系统和翻译引擎解决的是单次访问怎么做，但任何一次跨节点访问成立的前提是：两颗芯片都已经拥有网络身份，路由表已经配好，Entity上下文已经建立。这些全局性的准备工作落在UBFM（UB Fabric Manager）身上。",{"type":18,"tag":19,"props":739,"children":740},{},[741],{"type":131,"value":742},"UBFM是运行在某颗UBPU上的固件，负责超节点级的全局管理。它不参与任何单次数据访问，但没有它的前期工作，内存池化根本无从建立。UBFM的工作可以概括为三件事。",{"type":18,"tag":19,"props":744,"children":745},{},[746,751],{"type":18,"tag":181,"props":747,"children":748},{},[749],{"type":131,"value":750},"枚举与身份分配：",{"type":131,"value":752}," 系统上电后UBFM通过拓扑查询命令发现每颗UBPU，按规划分配Primary CNA与EID，并通过Configure CNA与Entity Registration命令写入各UBPU的配置空间。CNA决定网络中这个UBPU被如何寻址；EID决定这个软件实体被如何标识。",{"type":18,"tag":19,"props":754,"children":755},{},[756,761],{"type":18,"tag":181,"props":757,"children":758},{},[759],{"type":131,"value":760},"路由表与分区：",{"type":131,"value":762}," UBFM基于拓扑生成路由与多路径信息，生成路由表并下发到各UB Switch的1GB路由表区。协同与维护、Entity注册、UPI分区、热插拔、故障恢复等事件都由UBFM协调处理。",{"type":18,"tag":19,"props":764,"children":765},{},[766],{"type":131,"value":767},"一个不常被注意到的事实是：UBFM本身跑在UB内部，它使用的网络正是它自己在管理的网络。这种自举设计需要UBFM通过一些特殊的Bootstrap机制，如保留的UPI=0x7FFF管理分区，在网络完全就绪之前也能工作。控制面和数据面共享物理链路，但通过保留特权身份避开了鸡生蛋的循环依赖。",{"type":18,"tag":19,"props":769,"children":770},{},[771],{"type":131,"value":772},"表2总结了凭据系统、翻译引擎和全局管理之间的分工。",{"type":18,"tag":223,"props":774,"children":775},{},[776,802],{"type":18,"tag":227,"props":777,"children":778},{},[779],{"type":18,"tag":231,"props":780,"children":781},{},[782,787,792,797],{"type":18,"tag":235,"props":783,"children":784},{},[785],{"type":131,"value":786},"机制",{"type":18,"tag":235,"props":788,"children":789},{},[790],{"type":131,"value":791},"承载组件",{"type":18,"tag":235,"props":793,"children":794},{},[795],{"type":131,"value":796},"职责",{"type":18,"tag":235,"props":798,"children":799},{},[800],{"type":131,"value":801},"典型触发时机",{"type":18,"tag":251,"props":803,"children":804},{},[805,828,851],{"type":18,"tag":231,"props":806,"children":807},{},[808,813,818,823],{"type":18,"tag":258,"props":809,"children":810},{},[811],{"type":131,"value":812},"凭据系统",{"type":18,"tag":258,"props":814,"children":815},{},[816],{"type":131,"value":817},"UBMD + TokenValue",{"type":18,"tag":258,"props":819,"children":820},{},[821],{"type":131,"value":822},"表达访问哪块内存+有无权限",{"type":18,"tag":258,"props":824,"children":825},{},[826],{"type":131,"value":827},"Home注册内存时生成，访问时携带",{"type":18,"tag":231,"props":829,"children":830},{},[831,836,841,846],{"type":18,"tag":258,"props":832,"children":833},{},[834],{"type":131,"value":835},"翻译引擎",{"type":18,"tag":258,"props":837,"children":838},{},[839],{"type":131,"value":840},"UMMU（Home侧）+ UB Decoder（User侧）",{"type":18,"tag":258,"props":842,"children":843},{},[844],{"type":131,"value":845},"地址正反翻译 + 权限校验",{"type":18,"tag":258,"props":847,"children":848},{},[849],{"type":131,"value":850},"每次访问都执行",{"type":18,"tag":231,"props":852,"children":853},{},[854,859,864,869],{"type":18,"tag":258,"props":855,"children":856},{},[857],{"type":131,"value":858},"全局管理",{"type":18,"tag":258,"props":860,"children":861},{},[862],{"type":131,"value":863},"UBFM",{"type":18,"tag":258,"props":865,"children":866},{},[867],{"type":131,"value":868},"网络身份分配、路由下发、资源协调",{"type":18,"tag":258,"props":870,"children":871},{},[872],{"type":131,"value":873},"系统上电 + 拓扑变化时",{"type":18,"tag":164,"props":875,"children":877},{"id":876},"五完整剖析一次跨节点内存共享是如何发生的",[878],{"type":131,"value":879},"五、完整剖析：一次跨节点内存共享是如何发生的",{"type":18,"tag":19,"props":881,"children":882},{},[883],{"type":131,"value":884},"抽象概念需要具体场景来落地。下面用一个完整案例串起所有机制：GPU A借用NPU B的64MB HBM存放训练中的激活值。这个场景刻意选得简单，以便专注于流程本身；更复杂的多节点、多租户场景只是规模上的叠加。",{"type":18,"tag":19,"props":886,"children":887},{},[888],{"type":131,"value":889},"整个建链与访问过程可以划分为七个阶段，时间轴与关键动作如下：",{"type":18,"tag":387,"props":891,"children":892},{"style":389},[893,901],{"type":18,"tag":19,"props":894,"children":895},{},[896],{"type":18,"tag":23,"props":897,"children":900},{"alt":898,"src":899},"图6","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig6-cross-node-memory-sharing.png",[],{"type":18,"tag":19,"props":902,"children":903},{},[904],{"type":18,"tag":403,"props":905,"children":906},{"style":405},[907],{"type":131,"value":908},"图6 跨节点内存共享阶段",{"type":18,"tag":144,"props":910,"children":912},{"id":911},"_51-上电物理基础的建立",[913],{"type":131,"value":914},"5.1 上电：物理基础的建立",{"type":18,"tag":19,"props":916,"children":917},{},[918],{"type":131,"value":919},"故事从系统上电开始。两颗UBPU通过UB Link连接。物理层LMSM状态机完成Lane训练、速率协商、FEC配置，进入Link_Active状态。数据链路层初始化信用流控，双方交换Init Block协商链路参数。",{"type":18,"tag":19,"props":921,"children":922},{},[923],{"type":131,"value":924},"这个阶段两颗芯片完成了物理意义上的握手，线已经通了，但上层一片空白：没有网络地址，没有通信端点，没有任何应用可以跨芯片交流。它们只是两颗知道对方存在的芯片，还不构成一个超节点。",{"type":18,"tag":144,"props":926,"children":928},{"id":927},"_52-ubfm登场从芯片到超节点",[929],{"type":131,"value":930},"5.2 UBFM登场：从芯片到超节点",{"type":18,"tag":19,"props":932,"children":933},{},[934],{"type":131,"value":935},"超节点的成形始于UBFM的登台。系统某个UBPU在启动的时候被确定为UBFM角色，它开始在整个Fabric内部扫描、编目、分配。",{"type":18,"tag":19,"props":937,"children":938},{},[939],{"type":131,"value":940},"首先是拓扑枚举。UBFM从自己出发，向每个直连邻居发送拓扑查询命令（Configure CNA命令CMD=0），邻居返回本节点信息后，UBFM继续向它们的邻居查询，按广度优先遍历扫遍整个超节点。这个过程类似传统网络中的邻居发现协议，但通信基础是UB自己的报文格式。",{"type":18,"tag":19,"props":942,"children":943},{},[944],{"type":131,"value":945},"然后是身份分配。UBFM为每颗UBPU分配Primary CNA（24-bit节点地址），为每个Entity分配EID（128-bit实体标识）。这些值通过Configure CNA与Entity Registration命令下发，写入对应UBPU的CFGO_BASIC寄存器。假设GPU A得到CNA=0x1001，NPU B得到CNA=0x2002（例子使用16-bit CNA模式，对应后续CFG=9的9场景）；两颗芯片各自的业务Entity分别得到EID_A与EID_B。",{"type":18,"tag":19,"props":947,"children":948},{},[949],{"type":131,"value":950},"最后是路由下发。UBFM基于拓扑运行最短路径算法（包含ECMP支持和环路避免约束），计算出每个UB Switch应如何转发到任意目标CNA，把这些路由条目写入各UB Switch的CFG0_ROUTE_TABLE。",{"type":18,"tag":19,"props":952,"children":953},{},[954],{"type":131,"value":955},"这一阶段结束时，整个超节点具备了最基础的网络可达性。GPU A发一个DCNA=0x2002的包，UB Switch能准确送达NPU B。但应用还不能互通，缺少传输层和事务层的通信上下文。",{"type":18,"tag":144,"props":957,"children":959},{"id":958},"_53-npu-b注册内存把本地hbm变成可共享资源",[960],{"type":131,"value":961},"5.3 NPU B注册内存：把本地HBM变成可共享资源",{"type":18,"tag":19,"props":963,"children":964},{},[965],{"type":131,"value":966},"现在轮到NPU B的应用主动出场。它调用一个注册接口：",{"type":18,"tag":583,"props":968,"children":972},{"className":969,"code":970,"language":971,"meta":8,"style":8},"language-c shiki shiki-themes github-light github-dark monokai","urma_register_seg(\nctx,\n.addr = shared_buf,\n.size = 64 * 1024 * 1024,\n.perm = URMA_ACCESS_READ | URMA_ACCESS_WRITE,\n&token_id, &uba_base, &token_value\n);\n","c",[973],{"type":18,"tag":590,"props":974,"children":975},{"__ignoreMap":8},[976,986,995,1004,1012,1021,1030],{"type":18,"tag":403,"props":977,"children":980},{"class":978,"line":979},"line",1,[981],{"type":18,"tag":403,"props":982,"children":983},{},[984],{"type":131,"value":985},"urma_register_seg(\n",{"type":18,"tag":403,"props":987,"children":989},{"class":978,"line":988},2,[990],{"type":18,"tag":403,"props":991,"children":992},{},[993],{"type":131,"value":994},"ctx,\n",{"type":18,"tag":403,"props":996,"children":998},{"class":978,"line":997},3,[999],{"type":18,"tag":403,"props":1000,"children":1001},{},[1002],{"type":131,"value":1003},".addr = shared_buf,\n",{"type":18,"tag":403,"props":1005,"children":1006},{"class":978,"line":28},[1007],{"type":18,"tag":403,"props":1008,"children":1009},{},[1010],{"type":131,"value":1011},".size = 64 * 1024 * 1024,\n",{"type":18,"tag":403,"props":1013,"children":1015},{"class":978,"line":1014},5,[1016],{"type":18,"tag":403,"props":1017,"children":1018},{},[1019],{"type":131,"value":1020},".perm = URMA_ACCESS_READ | URMA_ACCESS_WRITE,\n",{"type":18,"tag":403,"props":1022,"children":1024},{"class":978,"line":1023},6,[1025],{"type":18,"tag":403,"props":1026,"children":1027},{},[1028],{"type":131,"value":1029},"&token_id, &uba_base, &token_value\n",{"type":18,"tag":403,"props":1031,"children":1033},{"class":978,"line":1032},7,[1034],{"type":18,"tag":403,"props":1035,"children":1036},{},[1037],{"type":131,"value":1038},");\n",{"type":18,"tag":19,"props":1040,"children":1041},{},[1042],{"type":131,"value":1043},"这行代码背后发生了相当多的事情。OS驱动首先锁定64 MB物理页（Pin住，防止被操作系统换出），然后向UMMU申请一个空闲的TCT条目，UMMU分配TokenID=0x00042。驱动规划一段UBA虚拟地址区间，比如从0x10_0000_0000到0x10_0400_0000，正好64MB。接着生成TokenValue（用硬件RNG或软件随机数，比如0xCAFE_BABE）。",{"type":18,"tag":19,"props":1045,"children":1046},{},[1047],{"type":131,"value":1048},"然后驱动要填四张UMMU硬件表：TECTE告诉UMMU这个Entity的TCT基址在哪；新分配的TCTE指向该段的MATT与MAPT；MATT建立UBA到物理地址的多级映射；MAPTE填入Permission=RW和主\u002F备TokenValue。",{"type":18,"tag":19,"props":1050,"children":1051},{},[1052],{"type":131,"value":1053},"至此，NPU B的UMMU硬件已经知道这段64 MB内存的存在，并且拥有完整的访问控制策略。但这些映射和权限上下文仍位于NPU B本地，GPU A需要后续凭据分发才能访问。",{"type":18,"tag":144,"props":1055,"children":1057},{"id":1056},"_54-凭据分发带外通道的角色",[1058],{"type":131,"value":1059},"5.4 凭据分发：带外通道的角色",{"type":18,"tag":19,"props":1061,"children":1062},{},[1063],{"type":131,"value":1064},"UBMD与TokenValue组成的四元组，必须从NPU B传递到GPU A，两者才能建立数据面通信。UB规范没有强制规定分发方式，这实际上属于带外通道的职责。",{"type":18,"tag":19,"props":1066,"children":1067},{},[1068],{"type":131,"value":1069},"典型的选择是走TCP\u002FIP管理网络：两侧应用守护进程通过集群协调服务（如etcd\u002FZooKeeper）交换元数据。更高安全性的场景会经UBFM中转，由UBFM基于全局权限策略控制凭据流向。少数实现也会通过UB的公知Jetty 1（事务层信息交换端点）做分发，但这要求基础通信已经建立。",{"type":18,"tag":19,"props":1071,"children":1072},{},[1073],{"type":131,"value":1074},"不论走哪条路，分发的都是同一个四元组：",{"type":18,"tag":583,"props":1076,"children":1079},{"className":1077,"code":1078,"language":131,"meta":8},[586],"{ home_eid, token_id, uba_base, size, token_value, permissions }\n",[1080],{"type":18,"tag":590,"props":1081,"children":1082},{"__ignoreMap":8},[1083],{"type":131,"value":1078},{"type":18,"tag":19,"props":1085,"children":1086},{},[1087],{"type":131,"value":1088},"值得一提的是，TokenValue相当于访问密码，明文传输有泄露风险。UB规范的CIP机制（AES-GCM \u002F SM4-GCM）可以为数据面加密，但带外通道自身的安全性需要管理面另行保障。在可信网络内部可以简化处理，跨安全域传输时必须加密。",{"type":18,"tag":144,"props":1090,"children":1092},{"id":1091},"_55-建链从还不能发到可以发",[1093],{"type":131,"value":1094},"5.5 建链：从还不能发到可以发",{"type":18,"tag":19,"props":1096,"children":1097},{},[1098],{"type":131,"value":1099},"GPU A现在手握凭据，但不同访问路径还需要不同的本地准备工作：URMA路径需要传输层TP Channel和应用层Jetty；LD-ST路径则需要UB Decoder映射和对应的一致性\u002F访问属性配置。",{"type":18,"tag":19,"props":1101,"children":1102},{},[1103],{"type":131,"value":1104},"URMA路径的TP Channel建立由UB Controller硬件与固件协同完成。规范第6.3.1章节明确TP Channel的具体建立流程不在本规范定义范围内，这是UB规范目前的一个留白。但可以将它合理抽象为：两端由系统软件，典型做法是通过公知Jetty 0（传输层信息交换端点）完成协商；双方协商TPN分配、PSN初值、BitMapSize、拥塞算法类型、MTU等关键参数。协商完成后各自建立TP Channel上下文。多条TP Channel通常组成一个TPG（Transport Channel Group），用于后续的多路径负载均衡和带宽聚合。",{"type":18,"tag":19,"props":1106,"children":1107},{},[1108,1110,1115],{"type":131,"value":1109},"Jetty创建也是URMA路径的应用层准备。GPU A调用urma_create_jetty创建一个通信端点，驱动从",{"type":18,"tag":403,"props":1111,"children":1112},{},[1113],{"type":131,"value":1114},"32, 1023",{"type":131,"value":1116},"范围分配Jetty ID，配置Jetty Context Table（JETC）、权限与JFC，为配套的SQ与RQ缓冲区分配内存页。Jetty在UB协议中是URMA编程模型的基本通信单元，可以理解为自带硬件队列的socket。LD-ST路径不依赖Jetty队列，而是依赖UB Decoder页表把本地地址窗口映射到远端UBMD。",{"type":18,"tag":19,"props":1118,"children":1119},{},[1120],{"type":131,"value":1121},"这里需要特别澄清一个容易混淆的点：由于GPU A执行的是Write\u002FRead（内存语义）而非Send（消息语义），NPU B侧不需要创建专门的接收Jetty。UMMU会直接按UBMD定位内存并完成访问，不经过NPU B的任何Jetty。这是内存语义最典型的单边特征：发起方需要完整的访问凭据，接收方只需暴露UMMU表项。相比之下，如果GPU A要发Send消息给NPU B，则NPU B必须有接收Jetty且已经在RQ挂好接收缓冲，发送方还需显式携带目标Jetty标识（MTETAH.TGT_TC_ID），那是另一套路径。",{"type":18,"tag":144,"props":1123,"children":1125},{"id":1124},"_56-真正的访问urma和ld-st两条路径",[1126],{"type":131,"value":1127},"5.6 真正的访问：URMA和LD-ST两条路径",{"type":18,"tag":19,"props":1129,"children":1130},{},[1131],{"type":131,"value":1132},"一切就绪后，GPU A终于可以访问NPU B的内存了。UB提供两条访问路径，覆盖不同的性能需求。",{"type":18,"tag":19,"props":1134,"children":1135},{},[1136],{"type":131,"value":1137},"URMA路径让应用通过API显式发起：",{"type":18,"tag":583,"props":1139,"children":1141},{"className":969,"code":1140,"language":971,"meta":8,"style":8},"urma_post_jetty_send_wr(\njetty_a,\n.opc = URMA_WRITE,\n.local_buf = activation_data,\n.length = 40 * 1024 * 1024,\n.remote = { EID_B, 0x00042, 0x10_0000_0000, 0xCAFE_BABE },\n.wr_id = step_id\n);\n",[1142],{"type":18,"tag":590,"props":1143,"children":1144},{"__ignoreMap":8},[1145,1153,1161,1169,1177,1185,1193,1201],{"type":18,"tag":403,"props":1146,"children":1147},{"class":978,"line":979},[1148],{"type":18,"tag":403,"props":1149,"children":1150},{},[1151],{"type":131,"value":1152},"urma_post_jetty_send_wr(\n",{"type":18,"tag":403,"props":1154,"children":1155},{"class":978,"line":988},[1156],{"type":18,"tag":403,"props":1157,"children":1158},{},[1159],{"type":131,"value":1160},"jetty_a,\n",{"type":18,"tag":403,"props":1162,"children":1163},{"class":978,"line":997},[1164],{"type":18,"tag":403,"props":1165,"children":1166},{},[1167],{"type":131,"value":1168},".opc = URMA_WRITE,\n",{"type":18,"tag":403,"props":1170,"children":1171},{"class":978,"line":28},[1172],{"type":18,"tag":403,"props":1173,"children":1174},{},[1175],{"type":131,"value":1176},".local_buf = activation_data,\n",{"type":18,"tag":403,"props":1178,"children":1179},{"class":978,"line":1014},[1180],{"type":18,"tag":403,"props":1181,"children":1182},{},[1183],{"type":131,"value":1184},".length = 40 * 1024 * 1024,\n",{"type":18,"tag":403,"props":1186,"children":1187},{"class":978,"line":1023},[1188],{"type":18,"tag":403,"props":1189,"children":1190},{},[1191],{"type":131,"value":1192},".remote = { EID_B, 0x00042, 0x10_0000_0000, 0xCAFE_BABE },\n",{"type":18,"tag":403,"props":1194,"children":1195},{"class":978,"line":1032},[1196],{"type":18,"tag":403,"props":1197,"children":1198},{},[1199],{"type":131,"value":1200},".wr_id = step_id\n",{"type":18,"tag":403,"props":1202,"children":1204},{"class":978,"line":1203},8,[1205],{"type":18,"tag":403,"props":1206,"children":1207},{},[1208],{"type":131,"value":1038},{"type":18,"tag":19,"props":1210,"children":1211},{},[1212],{"type":131,"value":1213},"UB Controller读取这条WQE，查Jetty Context找到绑定的TPG，TPG调度选择一条TP Channel，得到SrcTPN和DstTPN，分配一个INI_RC_ID记录SQ Context（用于后续响应匹配），查EID-CNA获得DCNA。40 MB数据按MTU切成若干TP Packet，每个包自动加PSN、计算ICRC。包头里的MAETAH携带UB Address与TokenID，TVETAH携带TokenValue，CFG字段根据访问类型派生为9（16-bit CNA）。这些工作几乎全部由硬件自主完成，应用只提供了WQE里的几个核心字段。",{"type":18,"tag":387,"props":1215,"children":1216},{"style":389},[1217,1225],{"type":18,"tag":19,"props":1218,"children":1219},{},[1220],{"type":18,"tag":23,"props":1221,"children":1224},{"alt":1222,"src":1223},"图7","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig7-urma-write-path.png",[],{"type":18,"tag":19,"props":1226,"children":1227},{},[1228],{"type":18,"tag":403,"props":1229,"children":1230},{"style":405},[1231],{"type":131,"value":1232},"图7 URMA Write包处理路径",{"type":18,"tag":19,"props":1234,"children":1235},{},[1236],{"type":131,"value":1237},"LD-ST路径面向同步细粒度访问，将远端访问映射到本地内存地址范围。配置阶段驱动把UBMD写入UB Decoder的两级页表，建立本地物理地址范围到远端UBMD的映射：",{"type":18,"tag":583,"props":1239,"children":1241},{"className":969,"code":1240,"language":971,"meta":8,"style":8},"ub_decoder_map(\n.local_pa_range = { 0x7F_E000_0000, 0x7F_E400_0000 },\n.remote_ubmd = { EID_B, 0x00042, 0x10_0000_0000, 0xCAFE_BABE }\n);\n",[1242],{"type":18,"tag":590,"props":1243,"children":1244},{"__ignoreMap":8},[1245,1253,1261,1269],{"type":18,"tag":403,"props":1246,"children":1247},{"class":978,"line":979},[1248],{"type":18,"tag":403,"props":1249,"children":1250},{},[1251],{"type":131,"value":1252},"ub_decoder_map(\n",{"type":18,"tag":403,"props":1254,"children":1255},{"class":978,"line":988},[1256],{"type":18,"tag":403,"props":1257,"children":1258},{},[1259],{"type":131,"value":1260},".local_pa_range = { 0x7F_E000_0000, 0x7F_E400_0000 },\n",{"type":18,"tag":403,"props":1262,"children":1263},{"class":978,"line":997},[1264],{"type":18,"tag":403,"props":1265,"children":1266},{},[1267],{"type":131,"value":1268},".remote_ubmd = { EID_B, 0x00042, 0x10_0000_0000, 0xCAFE_BABE }\n",{"type":18,"tag":403,"props":1270,"children":1271},{"class":978,"line":28},[1272],{"type":18,"tag":403,"props":1273,"children":1274},{},[1275],{"type":131,"value":1038},{"type":18,"tag":19,"props":1277,"children":1278},{},[1279],{"type":131,"value":1280},"运行时CPU\u002FNPU直接用本地指针访问（注：如果NPU具备通信卸载能力，LD-ST访问可由NPU自己发起）：",{"type":18,"tag":583,"props":1282,"children":1284},{"className":969,"code":1283,"language":971,"meta":8,"style":8},"int *remote_ptr = (int*)0x7F_E000_1000;\nint value = *remote_ptr;                    \u002F\u002F 读远端HBM\n*remote_ptr = 42;                           \u002F\u002F 写远端HBM\n__sync_fetch_and_add(remote_ptr, 1);         \u002F\u002F 远端原子加\n",[1285],{"type":18,"tag":590,"props":1286,"children":1287},{"__ignoreMap":8},[1288,1296,1304,1317],{"type":18,"tag":403,"props":1289,"children":1290},{"class":978,"line":979},[1291],{"type":18,"tag":403,"props":1292,"children":1293},{},[1294],{"type":131,"value":1295},"int *remote_ptr = (int*)0x7F_E000_1000;\n",{"type":18,"tag":403,"props":1297,"children":1298},{"class":978,"line":988},[1299],{"type":18,"tag":403,"props":1300,"children":1301},{},[1302],{"type":131,"value":1303},"int value = *remote_ptr;                    \u002F\u002F 读远端HBM\n",{"type":18,"tag":403,"props":1305,"children":1306},{"class":978,"line":997},[1307,1312],{"type":18,"tag":403,"props":1308,"children":1309},{},[1310],{"type":131,"value":1311},"*remote_ptr = 42;",{"type":18,"tag":403,"props":1313,"children":1314},{},[1315],{"type":131,"value":1316},"                           \u002F\u002F 写远端HBM\n",{"type":18,"tag":403,"props":1318,"children":1319},{"class":978,"line":28},[1320],{"type":18,"tag":403,"props":1321,"children":1322},{},[1323],{"type":131,"value":1324},"__sync_fetch_and_add(remote_ptr, 1);         \u002F\u002F 远端原子加\n",{"type":18,"tag":19,"props":1326,"children":1327},{},[1328],{"type":131,"value":1329},"CPU\u002FNPU发出mov指令后，本地MMU识别该地址为Memory，请求送到UB Decoder。UB Decoder查本地两级页表，得到{EID, TokenID, UBA_BASE, TokenValue}，把本地物理地址的低位拼到UBA_BASE上形成完整的UBA。随后UB Controller按当前一致性域、地址属性和传输配置封包；在典型LD-ST配置中，可使用一致性访问语义和TP Bypass等低开销路径。CPU\u002FNPU流水线阻塞等待响应，响应到达后数据写入寄存器，流水线解除阻塞。",{"type":18,"tag":19,"props":1331,"children":1332},{},[1333,1335,1341],{"type":131,"value":1334},"对应用而言，",{"type":18,"tag":590,"props":1336,"children":1338},{"className":1337},[],[1339],{"type":131,"value":1340},"int value = remote_ptr;",{"type":131,"value":1342},"这条C语句即可触发一次跨节点内存读。访问粒度可以细到单个Cache Line；实际延迟取决于拓扑距离、拥塞状态、表项命中率、一致性域配置以及具体芯片实现。",{"type":18,"tag":19,"props":1344,"children":1345},{},[1346],{"type":131,"value":1347},"两条路径共享同一套UMMU校验逻辑，但在发起侧走了不同的硬件路径。URMA依赖Jetty的SQ\u002FCQ管理，适合批量和异步场景；LD-ST依赖UB Decoder的地址反向翻译，适合细粒度和同步场景。它们不是替代关系，而是互补关系。AI训练中大多数场景是用URMA传梯度，用LD-ST读远端状态标志这样的混合使用。",{"type":18,"tag":144,"props":1349,"children":1351},{"id":1350},"_57-持续使用与权限回收",[1352],{"type":131,"value":1353},"5.7 持续使用与权限回收",{"type":18,"tag":19,"props":1355,"children":1356},{},[1357],{"type":131,"value":1358},"建立之后的持续访问成本极低。同一条UBMD可以被反复使用，每次访问无需重新建链。URMA只需重复post_send，LD-ST只需继续使用本地指针访问，硬件自动完成所有翻译、封包、校验。",{"type":18,"tag":19,"props":1360,"children":1361},{},[1362],{"type":131,"value":1363},"当协作结束，NPU B可以选择两种方式回收权限：完全撤销（urma_unregister_seg注销Segment，后续所有访问被拒绝）或者精细撤销（修改MAPTE的主\u002F备TokenValue，让特定用户的旧凭据失效而保留其他用户的访问）。精细撤销中主\u002F备TokenValue机制的价值充分显现：换锁芯而不销毁保险柜，无需通知其他用户，无需销毁内存段，完全在UMMU内部完成。",{"type":18,"tag":164,"props":1365,"children":1367},{"id":1366},"六软硬件协作的分工原则",[1368],{"type":131,"value":1369},"六、软硬件协作的分工原则",{"type":18,"tag":19,"props":1371,"children":1372},{},[1373,1375,1380],{"type":131,"value":1374},"回看整个流程，一个规律清晰浮现：",{"type":18,"tag":181,"props":1376,"children":1377},{},[1378],{"type":131,"value":1379},"控制平面软件主导，数据平面硬件主导",{"type":131,"value":1381},"。",{"type":18,"tag":19,"props":1383,"children":1384},{},[1385],{"type":131,"value":1386},"上电、UBFM枚举、CNA\u002FEID分配、路由下发、内存注册、TP Channel建立、Jetty创建、UB Decoder页表配置，这些建链相关动作大部分由软件（UBFM固件、OS驱动、应用库）主导，硬件被动响应（写寄存器、更新上下文表）。建链完成后，数据面的每次访问几乎完全由硬件自主完成：UB Controller封包，UMMU翻译和校验，DMA读写内存，CEG生成CQE。软件只负责提交请求和查询完成。",{"type":18,"tag":19,"props":1388,"children":1389},{},[1390],{"type":131,"value":1391},"这种分工不是偶然，而是基于一个根本的工程考量：建链次数少但逻辑复杂，交给软件更灵活；数据访问次数多但逻辑固定，交给硬件更高效。建链每个会话只做一次，涉及策略决策、资源协调、配置下发，用软件实现成本低、可迭代性强。数据访问每秒可能发生数百万次，延迟和吞吐都是关键指标，必须硬件化才能达到us级响应和TB级带宽。",{"type":18,"tag":19,"props":1393,"children":1394},{},[1395],{"type":131,"value":1396},"以一次典型的URMA Write为例，软件提供的仅仅是WQE里的几个字段：对端EID、TokenID、UBA、TokenValue、数据长度、操作码。其余所有包头字段都由硬件自主填入：SCNA来自寄存器读取，DCNA来自EID-CNA路由查询，SrcTPN\u002FDstTPN来自TPG调度器的选择，PSN来自TP Channel上下文的递增，CFG根据目标地址类型自动派生，LBF由硬件按负载均衡策略生成，ICRC由硬件流水计算。粗略估算，大约70%的包头字段由硬件自主产生，这正是UB能做到零CPU开销的根本原因。",{"type":18,"tag":19,"props":1398,"children":1399},{},[1400],{"type":131,"value":1401},"对LD-ST路径而言，CPU\u002FNPU的参与度更低。发出一条指令后就进入流水线阻塞，其余所有工作（本地物理地址到UBMD的翻译、封包、发送、接收响应、解除阻塞）都在硬件流水中完成。CPU\u002FNPU甚至不知道这是一块远端访问，它以为自己在等一次本地内存访问完成。",{"type":18,"tag":19,"props":1403,"children":1404},{},[1405],{"type":131,"value":1406},"这种分工模式让UB内存池化在应用层呈现两种接口形态：URMA面向异步批量传输，LD-ST面向同步细粒度访问。但底层是同一套硬件、同一套协议栈、同一套权限校验。",{"type":18,"tag":164,"props":1408,"children":1410},{"id":1409},"七两种访问模式的取舍",[1411],{"type":131,"value":1412},"七、两种访问模式的取舍",{"type":18,"tag":19,"props":1414,"children":1415},{},[1416],{"type":131,"value":1417},"URMA和LD-ST并非并列的两套协议，而是同一协议栈的两种使用方式。它们共享TAOpcode编码（Write都是0x03，Read都是0x06），共享UMMU的翻译与校验流程，但在发起侧的触发方式和完成管理上完全不同。",{"type":18,"tag":19,"props":1419,"children":1420},{},[1421],{"type":131,"value":1422},"URMA是异步编程模型，适合批量、大块、吞吐优先的场景。一次post_send可以提交一个GB级的传输请求，内部被切成大量TP Packet并发发送，硬件在后台完成所有传输，应用在合适的时机poll_cq查询结果。它的端到端延迟包含CPU提交、队列处理、网络传输和完成轮询开销，但吞吐更容易贴近链路上限。AI训练中的参数同步、Checkpoint保存、权重拉取、Pipeline激活值传递，都是URMA的典型舞台。",{"type":18,"tag":19,"props":1424,"children":1425},{},[1426],{"type":131,"value":1427},"LD-ST是同步编程模型，适合细粒度、低延迟、控制流场景，尤其适用融合算子这种极致性能优化场景（计算和通信细粒度pipeline）。一条mov或cmpxchg指令可以完成一次Cache Line级别的访问，语义更接近本地内存访问。原子操作可由硬件映射到对应Atomic事务，但具体ISA支持和一致性保证取决于处理器、UB Decoder配置和一致性域。此类访问通常不需要Jetty队列，可使用TP Bypass等低开销路径。分布式锁、远端状态查询、小控制字段更新、跨节点一致性维护，都是LD-ST适用的应用场景。",{"type":18,"tag":19,"props":1429,"children":1430},{},[1431],{"type":131,"value":1432},"在真实系统中两者往往混用。AI训练框架用URMA传梯度，用LD-ST读远端的同步标志位；MoE推理用LD-ST访问远端专家的路由表，用URMA批量回传中间激活值；分布式KV Cache用LD-ST查询元信息，用URMA搬运数据主体。这种混合使用体现了UB的接口分层价值：同一套底层协议和标识符体系，可以按场景选择不同访问路径。",{"type":18,"tag":19,"props":1434,"children":1435},{},[1436],{"type":131,"value":1437},"LD-ST适合细粒度同步访问，URMA则保留了异步模型在大块传输场景下的吞吐优势。LD-ST每次访问都让CPU\u002FNPU流水线阻塞等待RTT，对于传输1 GB数据这样的任务，阻塞上百万个RTT时间并不经济。URMA允许应用一次提交后让CPU\u002FNPU继续处理其他工作，DMA引擎在后台并发传输。两种模式各自覆盖不同访问需求，共同构成完整的访问能力谱系。",{"type":18,"tag":387,"props":1439,"children":1440},{"style":389},[1441,1449],{"type":18,"tag":19,"props":1442,"children":1443},{},[1444],{"type":18,"tag":23,"props":1445,"children":1448},{"alt":1446,"src":1447},"图8","\u002Fcategory\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology\u002Ffig8-urma-ld-st-matrix.png",[],{"type":18,"tag":19,"props":1450,"children":1451},{},[1452],{"type":18,"tag":403,"props":1453,"children":1454},{"style":405},[1455],{"type":131,"value":1456},"图8 URMA与LD-ST选择矩阵",{"type":18,"tag":19,"props":1458,"children":1459},{},[1460],{"type":131,"value":1461},"表3对比了URMA与LD-ST在触发方式、粒度、延迟和场景上的差异。",{"type":18,"tag":223,"props":1463,"children":1464},{},[1465,1486],{"type":18,"tag":227,"props":1466,"children":1467},{},[1468],{"type":18,"tag":231,"props":1469,"children":1470},{},[1471,1476,1481],{"type":18,"tag":235,"props":1472,"children":1473},{},[1474],{"type":131,"value":1475},"维度",{"type":18,"tag":235,"props":1477,"children":1478},{},[1479],{"type":131,"value":1480},"URMA异步模式",{"type":18,"tag":235,"props":1482,"children":1483},{},[1484],{"type":131,"value":1485},"LD-ST同步模式",{"type":18,"tag":251,"props":1487,"children":1488},{},[1489,1507,1525,1543,1561,1579,1597,1615,1633,1651],{"type":18,"tag":231,"props":1490,"children":1491},{},[1492,1497,1502],{"type":18,"tag":258,"props":1493,"children":1494},{},[1495],{"type":131,"value":1496},"触发方式",{"type":18,"tag":258,"props":1498,"children":1499},{},[1500],{"type":131,"value":1501},"API（post_send \u002F poll_cq）",{"type":18,"tag":258,"props":1503,"children":1504},{},[1505],{"type":131,"value":1506},"CPU指令（mov \u002F cmpxchg）",{"type":18,"tag":231,"props":1508,"children":1509},{},[1510,1515,1520],{"type":18,"tag":258,"props":1511,"children":1512},{},[1513],{"type":131,"value":1514},"访问粒度",{"type":18,"tag":258,"props":1516,"children":1517},{},[1518],{"type":131,"value":1519},"KB-GB批量",{"type":18,"tag":258,"props":1521,"children":1522},{},[1523],{"type":131,"value":1524},"Cache Line（64B）级",{"type":18,"tag":231,"props":1526,"children":1527},{},[1528,1533,1538],{"type":18,"tag":258,"props":1529,"children":1530},{},[1531],{"type":131,"value":1532},"访问延迟",{"type":18,"tag":258,"props":1534,"children":1535},{},[1536],{"type":131,"value":1537},"包含提交\u002F轮询开销，通常高于单次同步访问",{"type":18,"tag":258,"props":1539,"children":1540},{},[1541],{"type":131,"value":1542},"取决于拓扑、拥塞、表项命中和一致性域配置",{"type":18,"tag":231,"props":1544,"children":1545},{},[1546,1551,1556],{"type":18,"tag":258,"props":1547,"children":1548},{},[1549],{"type":131,"value":1550},"吞吐能力",{"type":18,"tag":258,"props":1552,"children":1553},{},[1554],{"type":131,"value":1555},"可打满链路带宽",{"type":18,"tag":258,"props":1557,"children":1558},{},[1559],{"type":131,"value":1560},"受单颗RTT限制",{"type":18,"tag":231,"props":1562,"children":1563},{},[1564,1569,1574],{"type":18,"tag":258,"props":1565,"children":1566},{},[1567],{"type":131,"value":1568},"CPU参与度",{"type":18,"tag":258,"props":1570,"children":1571},{},[1572],{"type":131,"value":1573},"post\u002Fpoll需要参与",{"type":18,"tag":258,"props":1575,"children":1576},{},[1577],{"type":131,"value":1578},"仅发指令，硬件阻塞\u002F硬件响应",{"type":18,"tag":231,"props":1580,"children":1581},{},[1582,1587,1592],{"type":18,"tag":258,"props":1583,"children":1584},{},[1585],{"type":131,"value":1586},"缓存一致性",{"type":18,"tag":258,"props":1588,"children":1589},{},[1590],{"type":131,"value":1591},"通常不参与",{"type":18,"tag":258,"props":1593,"children":1594},{},[1595],{"type":131,"value":1596},"可参与，取决于一致性域与地址属性配置",{"type":18,"tag":231,"props":1598,"children":1599},{},[1600,1605,1610],{"type":18,"tag":258,"props":1601,"children":1602},{},[1603],{"type":131,"value":1604},"原子操作",{"type":18,"tag":258,"props":1606,"children":1607},{},[1608],{"type":131,"value":1609},"协议级Atomic事务",{"type":18,"tag":258,"props":1611,"children":1612},{},[1613],{"type":131,"value":1614},"可映射到处理器支持的原子语义",{"type":18,"tag":231,"props":1616,"children":1617},{},[1618,1623,1628],{"type":18,"tag":258,"props":1619,"children":1620},{},[1621],{"type":131,"value":1622},"是否用Jetty",{"type":18,"tag":258,"props":1624,"children":1625},{},[1626],{"type":131,"value":1627},"是",{"type":18,"tag":258,"props":1629,"children":1630},{},[1631],{"type":131,"value":1632},"否",{"type":18,"tag":231,"props":1634,"children":1635},{},[1636,1641,1646],{"type":18,"tag":258,"props":1637,"children":1638},{},[1639],{"type":131,"value":1640},"传输层模式",{"type":18,"tag":258,"props":1642,"children":1643},{},[1644],{"type":131,"value":1645},"RTP \u002F CTP（含PSN重传）",{"type":18,"tag":258,"props":1647,"children":1648},{},[1649],{"type":131,"value":1650},"常用TP Bypass等低开销路径",{"type":18,"tag":231,"props":1652,"children":1653},{},[1654,1659,1664],{"type":18,"tag":258,"props":1655,"children":1656},{},[1657],{"type":131,"value":1658},"适用场景",{"type":18,"tag":258,"props":1660,"children":1661},{},[1662],{"type":131,"value":1663},"梯度同步、Checkpoint、权重拉取",{"type":18,"tag":258,"props":1665,"children":1666},{},[1667],{"type":131,"value":1668},"分布式锁、状态查询、小字段更新",{"type":18,"tag":164,"props":1670,"children":1672},{"id":1671},"八ai负载中的价值显现",[1673],{"type":131,"value":1674},"八、AI负载中的价值显现",{"type":18,"tag":19,"props":1676,"children":1677},{},[1678],{"type":131,"value":1679},"内存池化不是展板上的技术名词，而是解决具体工程问题的手段。几个典型的受益场景可以说明它的实战价值。",{"type":18,"tag":19,"props":1681,"children":1682},{},[1683,1688],{"type":18,"tag":181,"props":1684,"children":1685},{},[1686],{"type":131,"value":1687},"MoE大模型推理中的专家访问。",{"type":131,"value":1689}," DeepSeek V4这类模型有数百个专家，一次token路由可能激活其中若干个。传统方案下专家权重分散在不同节点，每次路由往往需要显式的Dispatch\u002FCombine通信。UB内存池化下，专家权重可以暴露为全局内存段，计算节点有机会通过LD-ST直接读取所需专家权重，从而减少显式通信和调度开销。具体延迟收益取决于专家放置、拓扑距离、访问粒度和缓存命中情况。",{"type":18,"tag":19,"props":1691,"children":1692},{},[1693,1698],{"type":18,"tag":181,"props":1694,"children":1695},{},[1696],{"type":131,"value":1697},"KV Cache的动态池化。",{"type":131,"value":1699}," 百万token上下文下的KV Cache可能占几十GB。不同请求之间的负载极不均衡。传统方案中，单请求超出本卡HBM上限只能拒绝或截断；UB内存池化允许KV Cache分散在整个集群内存池中，让内存紧张的节点按需使用其他节点的空闲HBM。它的价值在于提高可调度空间和削峰能力，实际利用率提升幅度需要结合负载分布、调度策略和远端访问比例评估。",{"type":18,"tag":19,"props":1701,"children":1702},{},[1703,1708],{"type":18,"tag":181,"props":1704,"children":1705},{},[1706],{"type":131,"value":1707},"参数服务器架构的重新评估。",{"type":131,"value":1709}," 经典PS架构在大模型训练场景中因为CPU处理瓶颈逐渐被AllReduce替代（推荐系统等场景仍在使用）。UB内存池化让PS在大模型训练中重新具备讨论空间：PS节点把权重暴露为全局内存段，Worker直接用LD-ST或URMA拉取权重，PS的CPU完全不介入数据面。PS的灵活性（异构Worker、动态调度）和AllReduce的性能（零CPU介入）第一次可以兼得。",{"type":18,"tag":19,"props":1711,"children":1712},{},[1713,1718],{"type":18,"tag":181,"props":1714,"children":1715},{},[1716],{"type":131,"value":1717},"训练中的低干扰Checkpoint。",{"type":131,"value":1719}," Checkpoint曾是训练中CPU与IO的共同瓶颈，每次保存可能占用数秒到数十秒的计算时间。UB内存池化下，Checkpoint可以通过URMA异步写入专用存储节点的共享内存，使计算与存储更充分并行。最终吞吐损失取决于Checkpoint频率、写入带宽、存储节点能力和后台传输调度。",{"type":18,"tag":19,"props":1721,"children":1722},{},[1723],{"type":131,"value":1724},"这些场景的共同点是：它们都不是UB发明的需求，而是AI工程师一直面对的痛点。UB通过提供统一的内存访问基础设施，让这些痛点有了系统性的解决方案，而不是让每个团队各自打补丁。基础设施的价值，往往体现在它把复杂的跨节点协作转化为可复用的系统能力。",{"type":18,"tag":164,"props":1726,"children":1728},{"id":1727},"结语从远程搬运到统一内存访问",[1729],{"type":131,"value":1730},"结语：从远程搬运到统一内存访问",{"type":18,"tag":19,"props":1732,"children":1733},{},[1734],{"type":131,"value":1735},"过去二十年，分布式计算的演进方向一直是让多台机器更好地协作。局部高速互联、跨卡内存扩展和跨机数据传输分别解决了不同层面的问题。面向8192卡尺度的AI集群，内存系统还需要同时具备全局地址组织、硬件级权限校验、低开销访问路径和可扩展管理能力。",{"type":18,"tag":19,"props":1737,"children":1738},{},[1739],{"type":131,"value":1740},"UB内存池化走到了这个交叉点上。它通过UB Controller、UMMU、UB Decoder、UB Switch、UBFM的端到端协同，让超节点规模的所有HBM第一次以统一的地址空间、统一的访问语义呈现给软件。对AI应用开发者而言，这意味着数据在哪里从架构设计一等公民变成运行时绑定部署细节。",{"type":18,"tag":19,"props":1742,"children":1743},{},[1744],{"type":131,"value":1745},"这不只是性能优化，更是编程模型的变化。当一个8192卡集群能够以统一地址和统一访问语义暴露给软件，分布式协作就可以从应用显式编排，逐步转移为基础设施默认提供的能力。",{"type":18,"tag":19,"props":1747,"children":1748},{},[1749],{"type":131,"value":1750},"推理模型把计算从秒级拉到分钟级，Agent把单次任务的状态从MB拉到GB，多模态把显存消耗推向另一个数量级。DeepSeek V4这一代模型对内存系统的要求，早已超出了单卡更大HBM能解决的范围。整个行业需要的是一次从远程数据访问到统一内存访问的范式变化。",{"type":18,"tag":19,"props":1752,"children":1753},{},[1754],{"type":131,"value":1755},"UB内存池化的意义，在于把跨节点内存访问从应用显式搬运转向基础设施级访问语义。这是一种从局部优化到机制重构的变化，也是UB作为下一代互联协议的重要技术价值。",{"type":18,"tag":164,"props":1757,"children":1759},{"id":1758},"参考资料",[1760],{"type":131,"value":1758},{"type":18,"tag":605,"props":1762,"children":1763},{},[1764,1769,1774,1779],{"type":18,"tag":609,"props":1765,"children":1766},{},[1767],{"type":131,"value":1768},"UB Base Specification 2.0.1",{"type":18,"tag":609,"props":1770,"children":1771},{},[1772],{"type":131,"value":1773},"UB Firmware Specification 2.0",{"type":18,"tag":609,"props":1775,"children":1776},{},[1777],{"type":131,"value":1778},"UB Software Reference Design for OS 2.0",{"type":18,"tag":609,"props":1780,"children":1781},{},[1782],{"type":131,"value":1783},"UB SuperPOD Architecture White Paper",{"type":18,"tag":1785,"props":1786,"children":1787},"style",{},[1788],{"type":131,"value":1789},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",{"title":8,"searchDepth":28,"depth":28,"links":1791},[1792,1793,1794,1795,1796,1797,1798,1799,1800,1801,1802,1803,1804,1805],{"id":146,"depth":988,"text":146},{"id":377,"depth":988,"text":380},{"id":426,"depth":988,"text":429},{"id":456,"depth":988,"text":459},{"id":573,"depth":988,"text":576},{"id":661,"depth":988,"text":664},{"id":729,"depth":988,"text":732},{"id":911,"depth":988,"text":914},{"id":927,"depth":988,"text":930},{"id":958,"depth":988,"text":961},{"id":1056,"depth":988,"text":1059},{"id":1091,"depth":988,"text":1094},{"id":1124,"depth":988,"text":1127},{"id":1350,"depth":988,"text":1353},"content:zh:news:large-scale-ai-cluster-memory-access-mechanism-technology.md","zh\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology.md","zh\u002Fnews\u002Flarge-scale-ai-cluster-memory-access-mechanism-technology",{"code":8,"msg":8,"data":1810},{"mail_lists":1811},[1812,1816,1820],{"addr":1813,"name":1814,"desc":1815},"ub-spec@lists.unifiedbus.com","灵衢规范","灵衢规范技术问题讨论，包括灵衢基础规范和固件规范，以及使能操作系统参考设计等，适合硬件架构师、芯片设计工程师、操作系统开发工程师、集群系统开发工程师、集群运维系统开发工程师、标准组织专家等。",{"addr":1817,"name":1818,"desc":1819},"superpod-ref@lists.unifiedbus.com","超节点参考架构","基于灵衢技术的超节点参考架构方面的问题讨论，包括已有超节点参考架构的技术讨论，以及新增超节点参考架构的讨论。适合集群系统设计和开发工程师。",{"addr":1821,"name":1822,"desc":1823},"ub-discuss@lists.unifiedbus.com","灵衢综合讨论","用于灵衢基础规范、固件规范、使能操作系统参考设计以及超节点参考设计以外的讨论，包括但不限于对社区和生态合作方面的咨询、建议、意见等。",[1825],{"title":1826,"summary":1827,"file_name":1828,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":8,"version":1829,"preview":1830,"btnOptions":1831,"zh":1838,"en":1839},"基于灵衢®的超节点参考架构白皮书","定义基于灵衢的超节点参考架构，其拥有总线级互联、协议归一、平等协同、全量池化、大规模组网和高可用性六大特征，帮助您迎接智能化时代算力基础设施挑战","UB-SuperPoD-Architecture-White-Paper-zh.pdf","6.0.0","\u002Fapi-server\u002Fweb\u002Fv1\u002Fwhite-paper\u002Fzh\u002Ffile\u002FUB-SuperPoD-Architecture-White-Paper-zh.pdf\u002F6.0.0",[1832,1835],{"label":1833,"value":1834},"中文","zh",{"label":1836,"value":1837},"英文","en",{"title":1826,"summary":1827,"file_name":1828,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":8,"version":1829,"preview":1830},{"title":1840,"summary":1841,"file_name":1842,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":8,"version":1829,"preview":1843},"UnifiedBus™ (UB) SuperPoD Reference Architecture White Paper","Defines the SuperPoD reference architecture that helps you tackle the compute infrastructure challenges in the AI era. The reference architecture features bus interconnect, unified protocol, peer-to-peer coordination, all-resource pooling, large-scale networking, and high availability.","UB-SuperPoD-Architecture-White-Paper-en.pdf","\u002Fapi-server\u002Fweb\u002Fv1\u002Fwhite-paper\u002Fen\u002Ffile\u002FUB-SuperPoD-Architecture-White-Paper-en.pdf\u002F6.0.0",["Reactive",1845],[1846,1876,1890,1904,1918],{"title":1847,"summary":1848,"file_name":1849,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1851,"version":1852,"marked":1853,"zh":1860,"en":1861,"btnOptions":1864},"灵衢®基础规范","定义灵衢基础规范2.0.1版本，包括灵衢系统组成、协议、以及编程模型等。本文档帮助读者理解符合灵衢基础规范的设备和系统的交互行为、互操作要求、编程模型、资源管理等","UB-Base-Specification-2.0.1-zh-clean.pdf",true,"base-specification","2.0.1",{"title":1847,"summary":1848,"file_name":1854,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":1850,"type_name":1851,"version":1852,"zh":1855,"en":1856},"UB-Base-Specification-2.0.1-zh-marked.pdf",{"title":1847,"summary":1848,"file_name":1854,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":1850,"type_name":1851,"version":1852},{"title":1857,"summary":1858,"file_name":1859,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":1850,"type_name":1851,"version":1852},"UnifiedBus™ (UB) Base Specification","Provides a comprehensive overview of the UB architecture, protocol, and programming models. It helps you understand the interaction, interoperability requirements, programming models, and resource management of devices and systems that conform to the base specification.","UB-Base-Specification-2.0.1-en-marked.pdf",{"title":1847,"summary":1848,"file_name":1849,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1851,"version":1852,"marked":1853},{"title":1857,"summary":1858,"file_name":1862,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1851,"version":1852,"marked":1863},"UB-Base-Specification-2.0.1-en-clean.pdf",{"title":1857,"summary":1858,"file_name":1859,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":1850,"type_name":1851,"version":1852,"zh":1856,"en":-1},[1865,1866,1869,1870,1873],{"label":1833,"value":1834},{"label":1867,"value":1868},"中文（含修订记录）","marked_zh",{"label":1836,"value":1837},{"label":1871,"value":1872},"英文（含修订记录）","marked_en",{"label":1874,"value":1875},"全部版本","all",{"title":1877,"summary":1878,"file_name":1879,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1880,"version":1881,"zh":1882,"en":1883,"btnOptions":1887},"灵衢®固件规范","配套灵衢协议，定义灵衢设备固件的架构设计、交互逻辑、功能及接口，确保固件在全生命周期内满足可靠性、安全性和兼容性要求灵衢固件规范","UB-Firmware-Specification-2.0-zh.pdf","firmware-specification","2.0.0",{"title":1877,"summary":1878,"file_name":1879,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1880,"version":1881},{"title":1884,"summary":1885,"file_name":1886,"need_login":7,"need_agree":1850,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1880,"version":1881},"UnifiedBus™ (UB) Firmware Specification","Defines the architecture design, interaction logic, functions, and interfaces of the UB device firmware, ensuring the firmware reliability, security, and compatibility throughout its lifecycle.","UB-Firmware-Specification-2.0-en.pdf",[1888,1889],{"label":1833,"value":1834},{"label":1836,"value":1837},{"title":1891,"summary":1892,"file_name":1893,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1894,"version":1881,"zh":1895,"en":1896,"software_link":1900,"btnOptions":1901},"灵衢®使能操作系统参考设计","介绍操作系统灵衢组件（UB OS Component）的架构、功能及外部接口，方便应用开发者、驱动开发者以及OS开发者等了解操作系统灵衢组件和基于操作系统灵衢组件进行开发","UB-Software-Reference-Design-for-OS-2.0-zh.pdf","software-reference",{"title":1891,"summary":1892,"file_name":1893,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1894,"version":1881},{"title":1897,"summary":1898,"file_name":1899,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1894,"version":1881},"UnifiedBus™ (UB) Software Reference Design for Operating Systems","Introduces the architecture, functions, and external interfaces of UB components for operating systems. It helps you understand the components and facilitate your development.","UB-Software-Reference-Design-for-OS-2.0-en.pdf","\u002Fsoftware\u002Fub-os-component",[1902,1903],{"label":1833,"value":1834},{"label":1836,"value":1837},{"title":1905,"summary":1906,"file_name":1907,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1908,"version":1881,"zh":1909,"en":1910,"software_link":1914,"btnOptions":1915},"灵衢®系统高阶服务软件架构参考设计","介绍支持面向智算和通算场景灵衢产品的系统高阶服务架构、所需的主要软件功能模块及接口功能。便于软件开发工程师、技术支持、企业技术负责人等使用、开发、管理和维护灵衢产品","UB-Service-Core-SW-Arch-RD-2.0-zh.pdf","service-core",{"title":1905,"summary":1906,"file_name":1907,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1908,"version":1881},{"title":1911,"summary":1912,"file_name":1913,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1908,"version":1881},"UnifiedBus™ (UB) Service Core Software Architecture Reference Design","Describes the UB Service Core architecture, key software modules, and interfaces supporting UB products for both intelligent computing and general-purpose computing. It enables software developers, technical support engineers, enterprise technical leads, and others to effectively use, develop, manage, and maintain the UB products.","UB-Service-Core-SW-Arch-RD-2.0-en.pdf","\u002Fsoftware\u002Fub-service-core",[1916,1917],{"label":1833,"value":1834},{"label":1836,"value":1837},{"title":1919,"summary":1920,"file_name":1921,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1922,"version":1881,"zh":1923,"en":1924,"btnOptions":1928},"灵衢®系统管控运维软件架构与接口参考设计","介绍基于灵衢的超节点智算和通算场景管控运维所使用的软件架构和接口功能参考。方便运维系统开发者、管控系统开发者、运维工程师和系统管理员等使用、开发、管理和维护灵衢产品","UB-Mgmt-OM-SW-Arch-and-IF-RD-2.0-zh.pdf","management-om",{"title":1919,"summary":1920,"file_name":1921,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1922,"version":1881},{"title":1925,"summary":1926,"file_name":1927,"need_login":7,"need_agree":7,"need_watermark":7,"access_by_download":7,"marked_up":7,"type_name":1922,"version":1881},"UnifiedBus™ (UB) Management and O&M Software Architecture and Interface Reference Design","Describes the software architecture and interface functions used for UB-based SuperPoD management and O&M in intelligent and general-purpose computing scenarios. It guides developers of management and O&M systems, O&M engineers, and system administrators in the use, development, management, and maintenance of UB-based products.","UB-Mgmt-OM-SW-Arch-and-IF-RD-2.0-en.pdf",[1929,1930],{"label":1833,"value":1834},{"label":1836,"value":1837},1785413945447]