昇腾960超节点首发NPO这消息出来的时候我第一反应不是去看单卡算力冲到了多少而是先琢磨了NPO三个字母。干这行久了你会明白一件事AI算力集群的瓶颈早就从芯片能算多快转移到了芯片之间能传多快。当你把几百张AI加速卡塞进一个超节点要同时喂饱所有芯片的梯度同步和激活交换传统互联方案已经撑不住这个场面。这篇内容想跟你聊聊为什么超节点必须往光互联走NPO在中间扮演什么角色以及以后评估一个算力集群你该盯哪些硬指标。1. 为什么超节点架构成了算力竞争的头号战场1.1 大模型训练的通信墙算得再快也怕传得慢我经常跟团队说一句话大模型训练不是一道纯计算题更像一道交通运输题。你用一万张卡去训练一个万亿参数模型每一轮迭代每个芯片都要把自己的梯度广播给其他芯片同时从别人那里拿回聚合后的梯度。这个动作在分布式系统里叫AllReduce几乎是每步训练都在做。模型越大、卡越多这堵通信墙就越明显。做个粗略估算你就知道问题有多严重。假设一个千亿参数模型100B按数据并行训练。每个参数按4字节的梯度来算一轮迭代产生的梯度总量就是100B×4B400GB。这些数据要在这轮迭代的计算结束之前在所有芯片之间同步完成。如果域内互联的有效带宽只有50GB/s光同步梯度就要8秒。而同样一个模型在单卡上前向计算一轮也就几秒到几十秒。通信耗时的占比一旦超过30%整卡利用率就会肉眼可见地往下掉。我见过不少团队买了几百张卡纸面算力非常漂亮结果训练吞吐只有宣传值的六成问题大多出在互联上。通信占比的计算并不复杂每轮通信量除以有效带宽就是通信耗时通信耗时再除以单轮总耗时就是占比。要想把通信占比压下来一是提升互联带宽二是用好并行策略——数据并行、张量并行、流水线并行、专家并行怎么配比本质上就是一个资源配置建模问题。在算力约束下把通信和计算的配比调到最优才是系统设计者真正要干的活。1.2 超节点到底是个什么东西从一堆机器到一台巨无霸计算机为了缓解通信墙行业给出的答案高度一致把更多芯片放进一个高带宽的物理域里。过去一个集群是网络把一堆服务器连起来现在则演进成先把几十张、几百张卡通过超高带宽、低时延的域内互联焊成一台逻辑上的巨无霸计算机再用网络把若干台巨无霸连成集群。这个被焊起来的大单元就是超节点。这个概念不是某一家凭空造出来的。英伟达的NVL72就是把72张GPU通过域内互联做成一个机柜级的超大单元华为此前发布的CloudMatrix 384超节点也明确提出过把384张昇腾芯片当一个整体资源来调度的思路。昇腾960超节点首发NPO正是这条路线上的最新落子。超节点把原来跑到机外、跑到交换机上的通信流量尽量收拢在机内完成路径更短、时延更低、可靠性更高。一台超节点在调度器看来就是一台超大型号的算力设备反而简化了作业调度和故障域划分。超节点的出现还带来一个直接影响AI算力集群的架构分层变了。以前是计算服务器网络交换机存储三层各管各的现在最吃紧的是计算和网络之间的互联层。这一层用什么技术决定了整个超节点的带宽天花板、功耗上限和可维护性。这也是为什么NPO会抢到首发这么重要的位置。AI算力集群的基本构成已经从一堆加速卡变成了一个互联域谁把互联域做大做强谁就在集群架构上抢占了先手。2. 昇腾960超节点首发NPO光互联为什么这么重要2.1 NPO是什么光电共封装路线在超节点上的落地先说明一点NPO的全称在不同资料里不完全一致行业里普遍把它理解为近封装光学或下一代光电集成方向的具体演进形态。但不管名字怎么叫核心思想非常朴素让光引擎尽量贴近计算芯片和交换芯片。传统方案里光模块是一个可插拔的小盒子插在服务器面板上。信号要从芯片出发经过PCB上的铜走线一路跑到面板的光模块再转成光信号传出。芯片速率越高、信号频率越快这段铜走线就越吃力损耗大、发热高、信号容易失真。可插拔光模块的厂商们都在想办法把电信号调制做得更好但这套路子在功耗和密度上已经逼近物理极限。CPOCo-Packaged Optics共封装光学要解决的就是这个问题把光引擎直接封装到芯片的基板上让光信号生成单元和交换芯片做邻居电信号只走很短的路程就变成光功耗大幅下降。昇腾960超节点首发的NPO可以看作CPO思路在超节点场景的进一步推进把光互联从机箱面板挪到了芯片附近甚至是在两颗芯片之间直接建立光通路。这种技术路线在超大带宽、超低时延、超高密度三个维度上都明显优于传统可插拔光模块。当然具体到昇腾960超节点里NPO的实现形态——是片间光互联还是与交换芯片的共封装还是光电混合背板——最终要以官方发布的架构技术细节为准。但从行业公开资料和超节点自身的带宽需求来推断NPO的价值一定是落在用光把芯片之间连接做得更快、更省电、更密集上。把光做到离芯片越近信号的传输效率和集成密度就越高这是整个高速互联产业都在沿着走的方向。2.2 首发NPO解决了什么问题带宽、功耗、时延三本账超节点要同时喂饱几十甚至几百张卡的通信需求互联方案要过的关有三道带宽密度、功耗、时延。我逐个展开说。先说带宽密度。可插拔光模块受限于面板尺寸和散热空间一个机箱前面能插的模块数量是有限的而NPO把光引擎嵌入基板附近单位面积能承载的光通道数量大幅提升。同样一个机柜空间NPO方案能提供的聚合带宽可能是传统方案的数倍。这意味着在超节点里设计高维度、高带宽的互联拓扑时物理上有了更多余量不必为了省面板空间而牺牲拓扑的可靠性。再说功耗。光模块是数据中心里出了名的电老虎单个高速可插拔光模块的功耗往往在十几瓦到二十几瓦量级成百上千个模块堆下来功耗非常可观。光电共封装的一大卖点是通过缩短电信号路径、减少信号调理电路把每比特传输功耗压下来。对动不动就上万千卡、一个集群耗电几兆瓦的数据中心来说互联功耗每降低一瓦折算成散热和电费都是实打实的成本。我在帮客户算数据中心TCO总拥有成本的时候互联这部分经常被忽略但它恰恰是最能隐形省钱的环节。最后是时延。超节点内部跑的是AllReduce、All-to-All这类集合通信通信次数极其频繁单次通信时延哪怕降低几十纳秒乘上每天的迭代次数和全年运行时长累积下来的训练加速非常可观。光引擎贴近芯片之后信号传输的物理距离变短中继和重定时环节变少时延自然往下走。这三本账算下来昇腾960超节点把NPO放在首发位置等于在新架构发布的第一天就把互联底层的代际差拉开了。2.3 互联底层技术路线之争铜、可插拔光、CPO/NPO现在业界做高速互联有几种并行路线理解这个格局你才能明白首发NPO为什么被称作改写赛道。铜缆直连包括ACC/AEC有源电缆适合中短距离、低成本的场景但带宽提升空间有限频率越高铜缆传输距离越短。可插拔光模块是目前最成熟、生态最完整的路线部署灵活、单点可替换但功耗密度压力越来越大。LPO线性驱动可插拔光模块是一个中间过渡路线去掉模块里的DSP省功耗但牺牲了部分信号处理能力。CPO/NPO则是终局感最强的路线光电融合最彻底功耗密度最优化但制造工艺、良率、可维护性的挑战也最大。这几条路线不是一个简单的谁取代谁的关系它们会长期共存。可插拔光模块在未来几年仍是绝对主流毕竟生态成熟、维护方便。但超节点这类高带宽密度、高集成场景恰恰是CPO/NPO最容易率先落地的理想靶场机柜内空间高度受限又需要极端带宽和功耗表现传统插拔方案的劣势被放大到不可忽视。昇腾960超节点首发NPO相当于直接在这个靶场里投下了第一枚重弹。从产业格局看谁先把这个从实验室到量产的路走通谁就掌握了下一代算力集群互联标准的定义权。这就是改写赛道的真实含义——它改写的不是某一款芯片的跑分而是整条技术路线的优先级。当整个供应链、软件栈、数据中心物理设施都围绕NPO重构的时候追赶者要复制的不只是一项技术而是背后一整条产业链。3. 怎么看懂超节点互联的硬指标带宽、时延和能效比3.1 一个实用公式评估算力集群之前先算通信账我在这行踩过不少坑总结出一个原则先算通信账再决定买什么。你评估一个算力集群能不能跑起你的模型第一步不是看FP16峰值算力而是拿你的模型参数规模、训练并行方案去估算每轮迭代的通信量。简化模型一轮训练迭代的总耗时约等于计算耗时加上通信耗时。计算耗时取决于单卡算力和模型算量通信耗时取决于每轮通信总量和有效带宽。每轮通信总量可以这样粗估数据并行下梯度同步量约等于参数量乘以梯度字节数张量并行下激活交换量则与序列长度、层数、隐藏维度强相关。拿千亿参数模型来说梯度同步就是我们前面算过的400GB量级。如果有效带宽只有100GB/s那一轮通信就要4秒。所以判断一个集群够不够用就用你的模型规模套这个式子看算出来的通信时间是否明显小于单轮计算时间。通信时间占比超过20%这个集群的互联就跟不上你的模型。这种资源配置建模的思路比盯着厂商参数表上的峰值算力靠谱得多。在算力约束下通过调整并行度、模型切分、梯度压缩等手段把通信占比压到最低才是大规模训练调优的真正核心。3.2 精度选择如何影响算力和互联需求FP64/FP32/FP16/FP8/INT8很多人评估芯片性能时分不清各种精度之间的关系这里把常见精度的账捋一遍。芯片的算力指标必须绑定精度来看同一颗芯片的FP16算力往往是FP32的两倍INT8算力又可能是FP16的两倍以上。不同精度的数据位宽不同单位数据在显存里占的字节数不同对显存容量和互联带宽的需求也随之变化。精度位宽典型场景对显存/互联带宽的压力FP6464位科学计算、高精度仿真极高FP3232位传统AI训练、数值稳定性敏感场景高TF3219位矩阵运算的精度与速度折中方案中高FP16/BF1616位大模型训练主流精度中FP88位新一代大模型训练与推理加速低INT88位推理量化主流精度低这里有个容易忽视的逻辑同样的模型用FP16训练和用INT8推理对算力和互联的需求完全不是一个量级。所以选型时不要只看单精度多少TFLOPs要针对自己的实际负载来选择精度路线。大模型训练现在普遍用BF16和FP16推理用FP8/INT8量化这套组合拳下来带宽、显存、算力三者需要重新平衡。昇腾960超节点这类系统支持多精度是基本能力关键是精度切换之后互联带宽和显存能不能扛住实际负载这才是实测里要重点验证的东西。3.3 一个评价框架拿什么标准衡量昇腾960超节点这类系统给你一个我平时用的评价框架三个层面单卡能力、域内互联、系统调度。单卡能力看算力密度、显存容量和带宽、能效比。域内互联看单卡互联带宽、时延、拓扑结构以及是否支持高速聚合寻址能力昇腾平台有自研的高速互联协议配合CANN软件栈做类似NVLink域的那种整体内存寻址。系统调度看的是超节点能否作为一个整体被调度故障时是整节点隔离还是精细隔离软件栈对集合通信的支持程度如何。很多厂商发布会喜欢把聚合带宽吹到几百TB/s但你要盯的是单卡有效带宽×非阻塞拓扑覆盖率。所谓非阻塞拓扑就是任何两张卡之间通信都不经过降速中继如果用的是收敛比过高的网络聚合数字再好看跑到多卡AllReduce就直接露馅。昇腾960超节点首发NPO从架构上就把互联密度拉高等于在单卡带宽这个核心指标上先声夺人。当然最终表现要看实测但至少它选择了一条正确的主赛道。4. 实操视角算力集群选型和评估的避坑指南4.1 别只盯峰值算力互联带宽和显存容量同样决定成败我接过不少企业算力规划的项目发现一个通病大家谈算力就只谈FLOPS忽略互联、显存和软件栈。实际训练大规模模型的时候显存容量决定你能不能放下模型和优化器状态互联带宽决定多卡协同效率软件栈决定你是否能把硬件潜力榨干。这三项任何一项掉链子FLOPS再高也都只能躺在参数表里好看。举个实际例子。有些云算力平台能让你很快租到单张高配加速卡像AutoDL这类平台单卡很便宜随开随用。但真当你要做分布式训练需要的是一个互联成整体的集群而不是一堆散卡拼在一起。散卡之间的通信走常规以太网带宽低、时延高跑点小模型还能凑合跑百亿参数模型就原形毕露。这也是为什么现在互联集群和超节点租赁成了一种新需求。选型的时候一定要问清楚三个问题这批卡的单卡互联带宽是多少跨节点网络收敛比是多少调度层能不能把一批卡当成一个整体资源来分配这三个问题答不清楚集群大概率中看不中用。4.2 私有互联协议与开放生态的取舍互联不止是硬件还牵涉协议栈。英伟达用NVLinkNVSwitch做域内互联配套自己的集合通信库昇腾也有自研的高速互联协议和对应的通信库配上CANN软件栈。私有协议的好处是软硬件协同性能最优坏处是生态相对封闭迁移成本高。开放生态比如以太网加RDMA兼容性强但性能和功耗通常拼不过私有方案。对企业来说这不是非黑即白的选择。如果你要走昇腾路线要考虑的不是协议好不好而是你的团队有没有能力基于CANN做二次开发把你的模型框架、训练脚本迁移过来。昇腾生态这几年的进步很明显主流大模型框架基本都做了适配但真要跑大规模分布式训练还是需要熟悉昇腾通信库的工程师来调优。这也是异构算力调度平台越来越受关注的原因数据中心里既有英伟达卡也有昇腾卡还有一些边缘推理芯片用一套调度平台把异构资源统一管起来才能让算力利用率最大化。这类平台不是简单的任务排队工具它要理解不同芯片的互联拓扑把通信密集的作业尽量调度到同一个超节点内。4.3 给算力需求方的四个可落地的评估建议第一先测算通信占比。用你的模型参数量、批量大小、并行方案套前面那个公式算出通信耗时和计算耗时的比例给自己设定一个阈值比如20%。如果超了优先考虑提升域内互联带宽而不是增加单卡算力。第二看精度与带宽的匹配。如果你的训练以BF16为主峰值算力和互联带宽就按BF16的实际流量来估如果推理以INT8为主要求会低一些。用精度、批量、模型大小综合反推带宽需求不要被FP64多少TFLOPs这种数字带偏方向。第三做一次真实的小规模并行测试。租不到超节点时哪怕先租8张同型号卡组成一个小集群跑一个中小规模模型记录通信占比和卡利用率再线性外推到大规模。这比任何纸面参数都有说服力。第四把运维和功耗成本算进总账。NPO这类光电共封装设备集成度高单点故障可能对应更大范围的硬件替换运维模型和可插拔光模块时代不一样。你要评估自己的机房有没有能力维护这类高密度互联设备散热和供电规划是否匹配别等买到手了才发现电费和散热改造比硬件本身还贵。5. 常见问题速查关于NPO和超节点的几个高频疑问5.1 NPO与CPO有什么区别和传统光模块是什么关系这个问题几乎在我每场分享里都会被问到直接整理成一张速查表方便你有需要的时候翻出来对照。疑问快速答案NPO和CPO是一回事吗属于同一技术方向上的两步演进CPO是光引擎与交换芯片共封装NPO更强调贴近计算芯片的片间或近封装光互联具体技术定义以官方发布为准NPO出现之后还需要光模块吗需要。超节点内部会越来越多用近封装光但机柜间、跨节点的互联仍会大量使用可插拔光模块两者长期共存NPO光引擎坏了怎么办集成度越高越难做单点维护通常要按整板或整节点隔离替换运维模型需要提前设计铜缆会被淘汰吗短距离、低成本场景还会长期存在但高带宽密度的超节点内部会越来越多转向光互联我的模型很小需要关心互联吗需要。哪怕只有8卡通信拓扑不合理也会明显拖慢训练先算通信占比再决定配置5.2 从互联底层看算力产业的一个真实趋势东拉西扯聊了不少其实我真正想说的判断只有一个未来两三年的算力产业最大的变量不在芯片单点算力而在互联。芯片制程逼近物理极限单卡算力每年的提升幅度在放缓但互联技术还远没到天花板。谁能在互联底层把带宽密度、功耗、时延这三个指标同时做好谁就能让一堆卡真正变成一台计算机。昇腾960超节点首发NPO正是这个趋势下的一个重要节点。它把光电融合的路线从实验室拉进了超节点量产架构让芯片离光更近一步从口号变成了产品选择。这种变化会传导到整个产业链数据中心设计要改网络运维模式要改软件栈的通信优化要改甚至芯片封装工艺也要改。这就是改写赛道的完整含义——它改的是整个链条的技术起点而不只是某一款产品的参数。我在做集群评估时有个习惯拿到任何一套新算力系统先问两个问题——卡和卡之间是怎么连的以及配套的通信库能不能充分用好这套连接。这两个问题问明白了系统的真实价值基本就能判断个八九不离十。昇腾960超节点在NPO这点上的选择至少把第一个问题回答得很漂亮。第二个问题需要时间去验证也需要我们这些做系统的人在实际集群里一遍遍跑测试来确认。毕竟算力这种事儿纸面说得再好都不如自己的训练作业在上面多跑几个来回来得踏实。
企业数字化 ERP 产品动态
相关推荐
PostgreSQL Schema管理与优化实战指南 1. PostgreSQL Schema基础概念解析 在PostgreSQL数据库体系中,schema(模式)是一个至关重要的逻辑容器概念。简单来说,它就像是数据库里的文件夹系统,允许我们将表、视图、函数等数据库对象进行分组管理。每个PostgreSQ… · 2026/11/4 8:54:30
Agent静默截断排查:源端50条数据为何模型只看到20条 做 Agent 的同学应该都有过这种经历:你明明在源端准备好了 50 条候选数据,模型回答里却只体现出了 20 条的信息。它不报错、不警告、不告诉你少了一半,就静悄悄地用剩下那部分内容给你交差。我第一次遇到这个问题是在调一个检索增强型 Agent … · 2026/11/4 8:54:30
LEF/DEF 5.8 格式规范详解:物理设计中避坑与DRC通关的核心依据 简介:本资源是Cadence官方发布的《LEF/DEF 5.8 语言参考》PDF手册,面向集成电路物理设计工程师、EDA工具使用者及VLSI课程学习者,系统解决LEF/DEF格式在工艺建模、单元库定义、布局布线描述与跨工具数据交换中的核心语法与规范理解问题。文件… · 2026/11/4 8:54:30
Superpowers 技能包体系:给 AI 编程助手装上工程方法论外挂 1. 从“superpowers”这个标题说起:它到底是什么 第一次看到“superpowers”这个词,很多人脑子里蹦出来的可能是超级英雄、超能力这类画面。但在技术圈子里,尤其是最近一段时间,这个词被反复提起,语境完全不一样。它指… · 2026/11/4 10:53:29
无刷电机AX BY CZ磁轴详解:从120°轴系到FOC坐标变换 搞无刷电机控制的,基本绕不开“轴”这个字。前阵子有个朋友拿着驱动器调试记录跑过来问我:“AX、BY、CZ 是不是按垂直轴线划分的?我一直以为是三根互相垂直的轴,可对着电机看了半天也没找到。”我当时就笑了,这个问题几… · 2026/11/4 10:53:29
MySQL+Java学生选课系统:事务控制与业务约束实战 简介:这是一套面向高校数据库与Java课程设计实践的完整CS架构学生选课信息管理系统,适用于计算机相关专业本科生开展数据库建模、JDBC编程与多角色权限管理综合实训。系统严格遵循三层用户逻辑:学生可完成选课退课、成绩查询与成绩单打印&… · 2026/11/4 10:53:29
单片机嵌入式面试120题:硬件与C语言核心考点解析 单片机嵌入式岗位的面试有个很现实的特点:范围看着不大,实际问起来能从寄存器位操作一路聊到电源纹波,从volatile的语义扯到中断服务函数里该不该调用printf。很多人复习的时候抱着厚厚一本教材从头翻,翻到定时器那一章就困了&… · 2026/11/4 10:53:29
Model-Optimizer:大模型推理的硬件-运行时-模型协同优化方法论 1. 什么是Model-Optimizer:不是“一键加速器”,而是模型推理效能的系统性重构工程 你搜“Model-Optimizer”,十有八九会撞上一堆TensorRT、vLLM、NVIDIA驱动安装失败的报错截图,还有人问“vLLM部署DeepSeek卡在scheduler初始化”—… · 2026/11/4 10:53:29
Superpowers技能框架:让AI编程助手稳定输出工程级代码 1. 从“superpowers”说起:这套技能框架到底在解决什么问题第一次看到“superpowers”这个词,很多人会以为是某个超级英雄题材的游戏或者插件合集。但如果你最近在折腾 Claude Code、Codex CLI 这类终端里的 AI 编程助手,大概率已经在各种社区… · 2026/11/4 10:52:28
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 3:16:49
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 6:59:29
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 7:02:38
AI辅助技术栈评估:提升研发决策效率60% 1. 项目背景与核心价值技术决策一直是研发团队面临的重大挑战。随着技术生态的快速演进,技术栈的选择、维护和迭代变得愈发复杂。我们团队在过去两年里,先后经历了三次重大技术栈迁移,每次都需要投入大量人力进行技术评估和风险分析。直到去年… · 2026/11/4 0:00:17
从生成Token到直接决策:Jev如何重塑AI Agent工程实践 1. 从"生成文字"到"拍板决策":Jev 到底在解决什么问题大多数人第一次接触大模型,脑子里建立的模型是"输入问题、输出文字"。你问它今天天气怎么样,它给你一段描述;你让它写个周报,它给你… · 2026/11/4 0:00:17
32G统一内存跑大模型:内存账、TPS实测与端云分流 想在一台 32G 统一内存的小主机上把大模型跑成"日常可用",这件事我前后折腾了小半年。标题里说的这台 Mac mini M6,是我们这次讨论的目标平台,具体到手规格以实物为准;但下面这套推算方法和实测思路,对任何统… · 2026/11/4 0:00:17
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 3:16:49
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 6:59:29
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 7:02:38