同样在大模型出来之后，相对于大模型之前◆■★■，如果把它称之为传统或者常规AI模型★■■◆，这些蓝色的点它的限制需求，它的算力跟现在大模型的需求又是非常大的区别，做大模型的优化是解决显存还有算力方面的挑战。优化是一件非常困难的事情，因为在优化领域◆◆，也类似于其他各行各业里面也存在一个不可能三角★◆◆，即成本、性能、效果◆◆■★，从成本角度★■，希望部署的AI应用能够用更少的资源，以更低的成本部署，在性能角度■★■◆，希望AI应用能够有更好的响应速度◆■、更快的生成速度以及更好的系统吞吐■◆，在效果角度◆■◆◆★■，无论做什么优化◆★，都不能够影响到模型本身的表达能力。因此在模型表现和模型机会方面，也不能退让◆■■★◆◆。

　　阿里云服务器计算型实例怎么选择？计算型c7、c8y ★■■★■★、c8i性能评测与选择参考

　　这是从柜级的工程能力来说■◆★◆，需要这么大的供电◆★■★，随之而来还有散热问题，散热不太可能在AI的时代用风冷继续解决，到了这个时候◆◆，一定会进入到液冷◆★■◆◆，画的三个图都是新一代的AI infra2.0，在开场的暖场视频，包括主会场都有机柜的展出。第一个是冷板式业冷，选择的整个方案是一加一的erect CDU, 来做1+1备份■■■◆◆★，好处是可以使故障域爆炸半径变成了节点器■★★◆◆◆，如果出现问题出现故障■◆★◆，仅仅是一个板卡下线，不至于影响到整个柜★◆■★■◆，再一个问题在于这样大的供电能力下，传统的低压供电也不太够★★◆，所以这时候既需要高压供电，也需要集中供电◆◆★■★★，选择HVDC的高压供电，而且是集中的80SPA。第三是对高速的挑战，不管是112，甚至是224★■，越来越多的已经不太可能在PCB上能解决★■，所以一定要走到cable背板■★◆，cable背板最自然的选择◆■■，大家都会选择的路线★■◆★，走cable cartridge，用cable cartridge把交换节点和AI的节点互联起来，这些都是在柜机上面需要考虑和解决的问题。

　　第二个compression是根据大模型权重数值的分布特点，设计一套压缩和数据存储格式来达到压缩显存的效果。

　　考虑下一代AI整个架构的时候，硬件上会遇到一些工程能力的挑战，首先■◆◆■★★，需要AI芯片快速进入到更大更高性能更强的性能阶段，第一是更高性能◆★◆■，更强劲的性能■■，会带来大封装，大封装又会带来一些分层形变的挑战，包括芯片的CTE和PCB的CTE，甚至芯片内衬板上的CTE跟自带的CTE不匹配，都会引起芯片在翘取开列，这些东西在整机上面，要有一系列除了芯片内要做这方面的加工保障，在整机上，包括生产制造上，从结构从工艺上都有一系列的优化要去做★◆◆■■，这是大封装尺寸带来的板级工程的第一个挑战。

　　前面讲了很多AIinfra里面的硬件架构的引进，整个AI基础设施里边离不开软硬件的协同，分享面向AI infra2★◆◆■■.0服务器软件结合创新的探索。主要是分为三部分★◆◆，第一是演进的趋势，做一个小总结，第二部分A1infra软硬一体具体的一些挑战◆◆★★。第三是震旦大模型磁法解耦的架构探索。

　　Jupyter MCP服务器部署实战★■■：AI模型与Python环境无缝集成教程

　　AI大语言模型虽强大，但其原生能力仅限于文本对话，难以直接与外部世界交互◆■■★★。MCP（Model Context Protocol）服务器技术作为桥梁◆★◆，赋予AI实质性环境交互能力，如浏览网页、分析数据等◆■★。本文基于实际经验，精选五种开源MCP服务器实现◆★★◆：Stagehand用于网络内容提取；Jupyter适用于数据分析；Opik提供AI行为监控；GitHub集成代码仓库管理；FastAPI-MCP支持自定义API集成。这些工具免费且可定制，为构建实用AI系统奠定基础。文章还提供了配置指南和应用场景剖析，助读者快速上手◆★■◆。

　　同整个物理核心数据的快速增加★■，带来了一些对业务上的挑战。从性能的维度来看。从最近十年左右的演进，从最早四代五代的服务器还是以10g的网络速率为主，到现在当前公有云的计算，网络速度已经到了100g，大概有10倍左右的网络带宽的提升，但是CPU单核的性能，它并不是像网络一样达到这么大性能的提升，整体来看◆◆◆■■★，每一代CPU的提升是有限的，经过四代叠加，CPU单核的性能大概是4倍左右的提升，整体看起来CPU的性能和网络带宽它会形成一个演进的不匹配，变成网络带宽可能IO超过了CPU的发展速度，导致了CIPU变成资源浪费。

　　很早的时候发现一个问题◆◆★■：解耦以后★◆◆■，GPU除了本身NV的GPU以后，还有很多国产化其他新兴的AI加速器，所以要解耦，首先有一种统一的抽象的XPU定义，定义是做了一层软的磁化的解耦■■★。CPU可以跟任意XPU进行任意配比，也是在集团中大规模的应用■■◆★■，到大模式的阶段，NV的GPU卡，好的卡很难买得到★◆★■◆，但很多小的种卡是不缺的，怎么用小卡来虚拟成大卡，这里有一种分布式解耦，让小的卡虚拟成大的卡，支持大模型的方式。现在已经到了更优化，把单一模型的计算特征进行分离◆★◆★■■，即PD的分离，支持异构的XPU磁化。池化解耦有几个关键的一些技术挑战◆◆◆■，为了达到高效率以及高性能，不是为了解耦而解耦■■★◆，解耦的最终的目的是要让大模型的高效运行，让整体的资源的利用率提升★◆■■■◆，在基础设施的硬件层面◆◆■★，希望在XPU层面有统一的编制，它统一的编制的好处相当于让多个XPU之间进行ScaleUp，呼应前面的Alink。

　　AI尝鲜：使用DeepSeek-R1-0528 + bolt.diy一句话生成公司或个人网站

　　再进一步看一下每一项优化的手段能够带来什么样的效果■■■◆。主要还是从offloading开始，卸载★◆★，offloading针对大语言模型的计算特征，还有执行的过程设计这样一个过程自适应，将部分权重细到CPU，达到辅助协同的效果■◆■■◆◆。同时选择对象和schedule过程也是全自动的■◆，可以减少人工的尝试以及嵌入局部最优的情况，同时，值得一提的是这边也会在卸载的时候也会感知到不同的权重★■■◆，它的数据精度，不同的优化方法之间是可以叠加协同产生一个1+12的效果，会感知到卸载到底是IP16还是巴比特INT8 ip8还是是四比特等等。右上角大概是一个流程演示，因为不同的卸载对象不同的schedule会导致不同的结果，有很多不同的candidate★★◆★，策略会在其中找到最佳的candidate来实现最好的优化◆★★■◆■。右下角则是跟现在offloading业界最好的SOTA deepSpeed zero, 是专门做offloading模块的◆◆■★★，开源框架跟它的对比，通过右下角的表来看一下，offloading性能是非常明显的超过了现在offloading SOTA，举了四个情景的数据■◆，前三个情景都可以看到最终的性能上的优势。

　　从硬件发展的脉络之后这是一个结果◆★■■。根本的原因在于现在用的是冯诺一曼架构■■★，存储和计算是分离的，左边的图讲了最近几年大模型的发展，除了算力是指数级的增长■★■■■■，内存的需求也在指数级的往上长★★■，这样的一个矛盾在存算分离的冯诺一曼架构下的矛盾，NV的GPU从volta一直进步的Blackwell◆★，它的算力增长了20倍，但是它的内存只增长了6倍★◆，存储和计算的差距，GAP越来越大，GAP要如何弥补，在单卡上面是不可解决，要解决必须要想办法ScaleUp把它聚合成一个更大的卡来获得更大的内存，有了这样的前提，右面的图把现有的大家进行互联来解决内存墙的问题做了分类，基本上用私有协议或者是开放协议★◆，用带SW交换和不带SW交换这样的维度，可以把现有的技术路线大概分成几个象限，带SW私有协议的，NV是一个领头羊，这是目前业界行业的标杆。

　　分享是内容是面向大模型高效推理的显存优化和量化压缩技术★★■★★，这一系列的技术是存在SinianLITE优化工具之中，Sinian是震旦的英文名，也是跟刚才分享的是一个统一的软件站■★。阿里云是AI驱动的云，AI带来了变革◆◆★◆◆，带来了生产力，但是也带来了非常大的挑战。从模型部署的角度，AI的大模型给带来了什么样的挑战。在大家能想到的众多挑战中，首当其冲的两个是显存和算力的挑战，下面两张图◆★■◆，左边的是算力部分的一些数据，右边是内存和显存部分的一些数据■◆★■，可以看到非常明显的趋势，红色点构成了这些红色的线，代表的是transformer模型结构大模型出来之后◆◆，各个模型的数据，无论是在算力的角度还是在显存的角度，红色线的增长趋势和增长的幅度跟左侧熟悉的灰色线摩尔定律★■◆■■，右侧绿色线现在AI硬件的显存容量◆★■■★◆，跟这两个线的趋势都是不可同日而语的区别◆■。

　　第三weight Quantization是现在在大模型部署领域用了越来越多的权重的量化◆■◆。

　　第二方面是权重压缩方面★★■★★。右上角这两个图★◆◆◆■，在大模型里边■■◆，它有不同的模型，它的权重，把它指数位还有尾数位分开来看它的分布规律◆■，如果拿值这样拉平来看它的分布，会有一个非常明显的分布的特征，根据这样不同的分布特做了定制的优化，通过定制的数据格式达到压缩效果，设计了两个level的压缩模式，右下角的图是type 1type2两个压缩的模式★■■★■，这两个压缩模式都能够达到在压缩之后，相对于IP16的原始模型没有精度损失的效果◆★■■◆，其中type 1是严格上的数据无损■◆◆★◆★，type2不是数据上严格无损■★■■◆◆，但从整体表现看观察不到损失的。

　　第五optimization manager◆◆★■◆★，则会综合各种优化的方法★◆★，以及具体使用什么硬件，模型的选型是什么，以及优化目标来得到一个综合协同的优化效果。这是大概的概览。进一步来看具体各个方法都是怎么做的■■。

　　为什么要做混合精度量化◆◆■★，它是为了改善现在业界比较通用的■■◆★◆，比较熟悉的可能有INT8的量化，有IN4的量化◆★，但这些都是单一精度的，或者uniformprecision，但单一精度它是显然没有考虑到模型不同层的适应度以及它的重要程度，因此可能会引入一些额外的对模型表达影响★★■，混合精度的策略可以也非常好的解决问题◆■■★，同时能够达到优化的效果。右下角是KV cache的量化，同样也是把刚才权重量化的技术又更进一步的针对KV cache展开，同时后边也会有一个图，KV cache的数据分布也是有非常典型的不同特征，所以会根据k cache和v cache的数据特征去匹配最佳的数据精度，达到平衡的效果，最终是中间optimization manager， 会综合各种各样的优化的手段去根据hardware configs◆■， 根据具体的硬件★◆◆、具体模型的选型和原数据◆◆★，以及中间的的优化的目标、精度目标，还有成本优化的目标，得到一个在当前模型以及选用硬件上最佳的优化策略，优化方案，这是现在的大致的架构。

　　这部分主要介绍阿里云在基础架构设施里服务器领域新一代的通用计算服务器设计。

　　2018年BERT又开始扛起了大模型的大旗，随着BERT把大模型推入高潮★■，前两年大家耳熟能详的chatGPT又把它点上了最高的热度的封顶◆★◆■■。逐渐发现是需求已经进入到需要更大的model size ■◆◆★★★, 一张卡放不下，需要把它切分，多卡并行，在互联的时候◆◆■■◆，ScaleUp逐渐进入到了NVlink直连。2024年，GTC上进入了Super pod, 也是sScaleUp super pod的结构，它是进用了更大规模的NVlink来互联成一个更大的集群。从整个发展历史★■■◆◆★，串下来发现一个问题，芯片在这段演进的过程中★◆■■★★，它的核心变化是从传统的KuDAL演进到了pen SQL, 硬件的基本架构出现了从无到有的ScaleUp网络，而且网络越发展越强，最终把更大规模的一堆卡聚合在一起，这是硬件发展的一个脉络◆◆■★◆。

　　在AI infra里面软硬件的挑战，总结AI infra里面在架构上面的挑战，是硬件的不均衡★★，不均衡体现在首先的AI服务器的不均衡◆◆★◆◆■，AI服务器演进到现在是从单卡到8卡，现在已经出现了32卡★■★■■，出现了CPU和GPU配比的不均衡◆★◆■，如何把这些不均衡的应用在不同的应用下，能够达到一致的体验。第二是AI芯片的兴起★★★◆■◆，AI芯片的兴起它有两种的影响，第一是计算形态的影响◆★◆★◆，每个芯片它的计算在目前在AI芯片上它是没有标准，所以加速单元包括增加的指令，都是不通用的。

　　阿里云服务器ECS计算型c7和通用算力型u1在适用场景、计算性能★★■★★、网络与存储性能等方面的对比

　　第四个情景，举了一个比较极端的case，当模型的大小远超于硬件提供的显存的时候，不管怎么救，它的瓶颈都是在PC带宽，所以在情景下，大家都卡的地方没有什么区别◆■■★★。这也从另外一个角度说明一定要谨慎选择卸载的对象■★，还有卸载的schedule◆■★■。

　　第一offloading比较好理解，可以利用CPU的内存弥补GPU显存不足的部分，辅助GPU做大模型推理。

　　第二是互联的带宽，互联的方式的影响，互联除了带宽■■★◆★，还有语义的定义，语义的定义对于编程的模式◆■■，是有一些变化的，传统的编程模式在单机类可以通过内存的语义，很简单可以ScaleUp, 一旦超过了互联的单机的带宽■◆◆■，一定要通过NVlink卡或者网络的编程方式去做，第三是整机的形态，是单机的8卡还是16卡，影响扩展性，在大规模的集权里做软件优化的时候，有一个ScaleUp的率，多卡扩展的域一般能做到90%或者80%已经算是很高。第四是集群的容量影响到了整体的可靠性。

　　分享从我们的角度怎么看AI基础设施服务器，如何进行架构演进，背后的逻辑是什么。

　　AI部署架构：A100、H100、A800、H800、H20的差异以及如何选型？开发◆★■◆◆、测试、生产环境如何进行AI大模型部署架构？

　　比如今天跟大家分享如果没有PPT，只能口头跟大家说★★◆■◆，可能说完了大家也不知道在说什么，但是一旦有了图有了视频，很多在文字上不能表现的东西，很多在文字里面丢失的信息又被还原了。如果目标不仅仅追求一个聊天，而是要追求通用的人工智能，一定会走入多模态。一旦走入多模态，需要的数据量又会暴增，需要的计算量也会暴增。所以从这个角度来判断，scaling law会持续演进，ScaleUp域也会持续往下迭代发展。类比一下，多媒体出现之后，需要的带宽也在指数级的往上涨，以前用一个猫几十K可以上网，但是现在没有几百兆的宽带都不好意思跟大家打招呼■★■。

　　阿里云ECS服务器u1和c7实例在适用场景、性能■■■、处理器特性等方面存在显著差异。u1为通用算力型，性价比高，适合中小企业及对性能要求不高的场景◆★★★；c7为企业级计算型◆■◆，采用最新Intel处理器，性能稳定且强大，适用于高性能计算需求。u1支持多种CPU内存配比★★◆，但性能一致性可能受底层平台影响；c7固定调度模式，确保高性能与稳定性■■★。选择时可根据预算与性能需求决定。

　　随着scaling law持续往下涨，物理拓普包括互联拓普，以前是走的胖树的结构，这是最常见的路，下一跳很有可能大家为了解决更短的网络半径，可能拓普会往DRYGEN FLY演进■◆★■★，同时，现在能看到像Google和特斯拉3的tourras或mash的结构也在持续的迭代，这种流式的架构◆■，也得到了很多初创startup青睐，这两种架构仍然会在一段的时间内继续并行，大家互相在争鸣。第三举一个简单的类比■■★，从当前人的大脑★■◆■◆■，神经长度大概是有800km，以NVR72为例★◆■，互联的整个cable大概只有5000米，所以从这个角度上来，ScaleUp互联能力不是做的太强，而是比人脑差的太远◆★◆，所以相信在ScaleUp整个过程中★■★■，仍然有极大的发展潜力。

　　第二是互联，互联的兴起，至少现在有三种形态的互联■◆★■，有PCE、NVlink■◆■◆、还有各种私有的协议。这些影响导致了软件一体化优化的挑战。除了硬件上带来的一些不均衡，从计算的特征上面来看，它也有各种不均衡的这种挑战★★◆。第一是硬件上CPU到GPU的不均衡，不同的模型，从大模型以后★■◆★★■，还有很多小模型，大模型从视觉类到文本类到多模态★★★，模型不一样它对于CPU跟GPU的计算量它是不一样的，怎么保证不同的模型能放到合适的硬件上面，这里的挑战是比较大的。第二是多XPU的互联，因为不同的模型■★◆，不同的计算方式，因为大模型必须要把模型拆分成offer，拆分的时候可以通过PP◆★■■◆、DP的方式■◆★，不同的拆分方式对于互联的带宽是有影响的，不同的互联的方式决定了要怎么去XPU模型★■★，这里面也带来很多软件上面的挑战■■◆★◆，第三是大模型最常见的有Prefill-DeCode，这两种计算特征不一样■■★★◆◆，计算特征有的是计算密集◆★，有的是显存密集，要做这方面均衡的考量，在大模型后还具有一种投机采样的方式去提升它的吞吐与效率，投机采样它有一个明显的特征是通过大小模型，大小模型与组合它又是不均衡的，这些不均衡的计算挑战，应该怎么处理。

　　阿里云服务器内存型实例怎么选？r7/r8y/r8i实例性能■■★■◆、适用场景与选择参考

　　最后简单介绍整个震旦硬件异构的软硬件结合的全站★◆◆◆★，目的第一是让硬件的基础设施它能够蓬勃的发展，能够支持多样的XPU的芯片■◆，以及磐久服务器★★★■■，第二是除了硬件◆★■■◆◆，还要有软件硬点协同★◆★◆，分为三个方面，第一是要把芯片使存起来，让AI的站能够迁移，第二是云原生★◆★，云原生有K8S的协同，能够把多样的规模化的集群快速的部署起来■★，管理高效率可靠性的运行，最终目的是希望整个AI基础设施更快更优，达到更省◆★◆★■，让AI的计算成本降低◆★■◆■，更简单化◆◆◆◆。

　　上面分享的是当前的一些技术挑战，从下一跳会面临一些什么样的逻辑架构上的变化。第一个问题是很多人经常会聊起来◆■，scaling law是否会持续往下走，现在做的ScaleUp域会不会继续往大的涨■★★◆◆■。上面的图也是比较典型，是Epoch AI,发布的数据■◆★★■，基本上是在未来的两三年之内，现有的互联网人类产生的所有文本都会被训练耗尽■■，文本耗尽了，碰上了数据墙，scaling law是否失效了，是不是AI的ScaleUp不再需要了■◆？可以从几个方面理解★◆◆。因为文字能承载的信息，永远是对信息的高度抽象◆■，在高度抽象的同时也损失掉了大量的细节信息。

　　A1 infra 2.0软硬件一体的挑战，决定了软硬件优化整体的硬件集群的方式的演进到底是走向ScaleUp还是Scale Out，没有统一的法★◆■◆■，至少从目前来看，这两个要兼而有之，为什么要选择ScaleUp和Scale Out■★，ScaleUp的方式对于所有的软件应用很简单■◆◆★，因为它可以统一编制★★■■，可以单一的设备，在单一的应用之下，可以很简单的把模型变得很大◆■，Scale Out的方式，它会涉及到能力要扩展，要懂分布式的编程■★◆◆◆■，知道网络通讯的方式，还要做跨级的通讯◆★★，它会带来很多很多的复杂性◆■■■★★。对于整体的AI infra本身模型很大◆■◆■，要做AI nfra工程化，它也是很复杂的。

　　第二是ScaleUp再继续往大的涨★■，会出现一个更大的ScaleUp域，在更大的ScaleUp域下面可能会有一些新的变化■★，现在硬件上所能操作维护的是一个OS域，为了不至于引起PC1热插拔之类的问题，硬件上进行操作维护的都是一个OS域★★，OS域大小对ScaleUp域没有什么意义，如果再向后去推演，可能会出现一个情况，是现在的8卡甚至是4卡的大节点■◆■◆，有可能会逐渐弱化成单卡的小节点■★★◆★。举下面一个图，从故障替换，如果故障域替换一开始是8卡节点、4卡节点，有一个卡故障了■★■◆■，要替换的时候是拿4卡去替换4卡，有3个好卡跟着陪跑■◆◆★★■，但如果是单卡节点，在一个大的ScaleUp域里◆◆■，替换的时候是精确的好卡替故障卡，不会引起连带的反应。

　　第二因为是统一的资源池，解耦以后，任意模型任务可以运行到任意的XPU资源上★◆★★◆，所以在异构XPU上应该要统一的API◆■★★★◆。第三是在面向大模型，模型算力的增长■◆■，模型的形态的增长，现在面向硬件的编程，有很多的约束，像迁移，今天换了一张卡跑不动，希望XPU以统一的算力方式进行抽象，不管是解耦，还是多形态，都能够很好的运行各种模型。所以在震旦3.0★★★■■，有一个池化解耦的形态。这些不仅是一个计算芯片的扩展★■■，大模型它意味着计算量的增长★★◆★◆◆，还面对显存的诉求，计算跟存储有一个明显的趋势是融合，因为在大模型以后，单个的Query长度◆■■★。它是不断增长的，除了模型本身静态的缓存诉求★■，它对于动态的缓存的需求也是比较强的，在推理上面，除了计算量跟计算能力的缓存的诉求以外，还有一个东西，因为在推理上★★，对时延是比较敏感的■★◆★。在打对话的时候★◆，打了一条对话◆◆★◆，半天没有反应，大家的体验是很差的，除了在计算资源之外，还有对于计算以及缓存的调度，提出面向SLO的算力的画像以及调度来解决池化它软硬件协同的优化的问题。

　　其他还有一些直连■◆, 包括了Google TPU VS★■■、Tesia Dojo 这样的系统是在走一些无SW互联的路线，行业还有一些开放联盟，以国外联盟为例◆■★◆◆，包括UA link、UEC走的是开放协议■◆★，带SW的结果。业界还有一些startup走的更激进，它既是开放协议走一些网络，同时又不带SW，既走标准网络，同时又拿标准网络来非SW的Mash的互联，Tenstorrent最新发布的Blackhole,是这样的架构◆◆■■■，如果把眼光再往远看，对内存的解决方案★■■◆■■，也不是只有ScaleUp这样一条路，ScaleUp是把HBM聚成一个更大的规模。业界还有一些非HBM的解决路线■★■■★，包括Cerebrass ■■■◆，用了海量的SRA，还有Groq，甚至还有内存计算★■★◆，像PiM/Aim这样的一些路线。从这里可以看到，整个AI在解决内存强的问题上★■◆■，进入了百家争鸣百花齐放的阶段。

　　AI部署架构：A100、H100、A800★★■、H800、H20的差异以及如何选型？开发、测试、生产环境如何进行AI大模型部署架构？

　　本文详细介绍了阿里云应用服务器如何助力传统J2EE应用实现智能化升级★★◆。文章分为三部分◆★■★◆：第一部分阐述了传统J2EE应用在智能化转型中的痛点，如协议鸿沟、资源冲突和观测失明■■◆；第二部分展示了阿里云应用服务器的解决方案，包括兼容传统EJB容器与微服务架构、支持大模型即插即用及全景可观测性★◆◆★■；第三部分则通过具体步骤说明如何基于EDAS开启J2EE应用的智能化进程，确保十年代码无需重写，轻松实现智能化跃迁。

　　阿里云与华五教学协同中心、超星集团联合发布高校AI实践通识课丨云工开物

　　第三是从高速的角度■◆★，信号速率如果要加大ScaleUp的互联，系统信号速率112已经是一个必配，业界的NV已经走到224，从112~224■■◆★，不仅仅是信号速率的提升，同时也会带来对板材的一系列要求◆★◆◆■★，板材至少要上到M8，到了M8以后，如果全上M8又会带来成本问题，为了降低成本，又会引发一系列的比如PCB不同板材的混压，这些混压技术又是一些新的课题和新的挑战★◆★◆◆■，所以从板级工程上■◆，新的AI的基础设施◆■，新的AI的服务器设计，也带来了一系列的新的内容和目标■◆■■。

　　破茧成蝶：阿里云应用服务器让传统 J2EE 应用无缝升级 AI 原生时代

　　从2019年阿里开始做方升架构★◆★■◆■，阿里云的方升硬件架构的自研开始，从1.0最终从原来的后出线，做了一个风液冷兼容的设计，同时开始探索，CPU的物理核心数已经在快速增加，做了一个探索做到CIPU支持Multi-Host双节点，到3.0当前阶段继续做了优化，CIPU和节点的灵活配比，同时做到IO资源的弹性■■，节点的热插拔，经过迭代演进，未来会进一步优化的方升架构，在5.0的时代，希望能做到硬件资源的进一步解耦，进一步去收敛L6形态◆■■◆◆，把更多的硬件资源跟CPU资源做一次分离解耦，做到整个硬件资源的灵活配比，同时，在下一代可以看到也面临诸多的工程上的挑战，包含CPU现在已经到600甚至到650瓦，以后的散热如何处理，还有是SI的挑战，比如的PC6◆★★.0、7★■◆■.0的慢慢的演进，还有DDR速率的提升等等，这些新的技术可能会对整个服务器的硬件的设计的工程挑战带来了比较大的挑战，以后在整个的发生5.0的迭代演进中◆■◆◆★■，也会跟供应链的同事，跟业界的专家一起讨论下一代服务器硬件设计到底如何进行。

　　第二是从整个性能上■◆★■◆◆，更强劲的性能需要一个更强劲的供电，以前对于几百瓦的处理器，电流都是几百安■★，但是现在面向AI的芯片，电流动辄是超过1000安，甚至是更高■■★◆★，在这样的方式下，传统的VR布局◆★■◆★，横向的水平的VR供电的布局■★，挑战越来越大，新的方案一定要想办法在更小的面积上★■■★◆★，尽量布更多的VR的像数，来提高整个供电的效率，同时要解决PI和SI之间的干扰■★◆★◆，从横向供电进入到横向加垂直的系统供电的变化，也是板级工程必须考虑的点。

　　Jupyter MCP服务器基于模型上下文协议（MCP）■★★■★■，实现大型语言模型与Jupyter环境的无缝集成。它通过标准化接口★◆★◆■◆，让AI模型安全访问和操作Jupyter核心组件★◆■◆◆★，如内核■★★★■、文件系统和终端★■◆★■。本文深入解析其技术架构、功能特性及部署方法。MCP服务器解决了传统AI模型缺乏实时上下文感知的问题，支持代码执行、变量状态获取◆■、文件管理等功能◆■◆，提升编程效率★★■。同时，严格的权限控制确保了安全性。作为智能化交互工具，Jupyter MCP为动态计算环境与AI模型之间搭建了高效桥梁。

　　所以针对这些是技术上的发展带来的对业务方的挑战★★★，还带来性能挑战■★，同时★■，服务器的演进，物理机还有一些自己工程实现上的挑战★◆◆★★■，这些挑战在于左边的饼图上有一个初步的划分★■◆★，公有云的业务有很大一部分的比例★◆，它是售卖服务器核心的，所以它LEVEL6的形态相对是简单的，而且它相对是简单且好部署。但是其他的一些零星的业务，比如存储型的业务■★◆，异构型的业务，这些业务在当前的服务器架构下，还是以单独LEVEL6物理机来满足这些业务的需求。

　　在新的服务器设计中还做了一些模块化的尝试，首先可以快速看到物理机的形态是2U的标准形态，2U是支持两个node，这两个node代表两个CPU的节点，在2U2N这种设计下◆★■■■，1U支持单路服务器，单路服务器做了一些散热的优化，可以最高支持到600瓦的TDP散热■■★★■，纯风冷的散热。同时■■★◆■，还继续维持以往的方生架构服务器设计的优势，继续兼容多平台的服务器设计，业界主流的CPU主流的处理器平台都可以在LEVEL6的统一形态下落地。同时，还做了几个相对以往的优化，第一个服务器的LEVEL6形态比较多样，根据不同的配置◆■◆■★，可能需要出货不同的物理机◆◆■■■★，有存储的，有异构的机型，在这一代的服务器设计里★■■■★，想尽量规划LEVEL6的设计，所以在部件上做到可插拔的维护，比如CIPU模块■◆，包含存储的SCD的模块，本身支持插拔◆◆，还有物理的网卡或者显卡的模块◆◆，都可以做到支持在线的改配，减少LEVEL6的形态，相当于已经部署了一些比如在不同的领域部署了主售的机型■■★，不需要这些部件，但是主售的机型部署在不同的机房的时候，如果客户有快速的灵活的需求时■◆◆■，只需要在供应链备一些部件在仓库可以，根据客户的需求，不同的调整的备件的数量，现场插拔这些部件，来达到物理的LEVEL6的形态的收敛，能快速的响应客户的需求。

　　另外一个好处★★，现在的AI的硬件◆★◆★，拿GPU为例，这边列的不同AI硬件对不同数据类型的理论算力也是不一样的◆■★，通常更低的数据精度能够有更高的理论算力，将数据量化为更低精度的时候，会有更好的速度方面的提升，混合精度则是用来解决单一精度弊端的方式，它能够解决单一精度下模型精度下降过多的问题，来达到模型的精度和优化收益的平衡■■◆■★★。右下角图可以看到在不同的模型上，混合精度的效果能够达到比单一精度更好的效果◆★■◆。KV cache,可以重点关注一下这个图，是对现在的大语言模型■★◆■★，它的k cache和v cache各自有不同的分布的特点，左右两列对比★★★◆■■，可以看到K cache 和V cache分布是非常不同的◆◆★，如果用统一的数据类型表示显然是不科学的，规律在不同的模型间都有这样的体现，可以通过不同的数据类型表示K cache V cache，像右边这张图是不同的数据精度组合下■★，它的显存压缩的收益，下面这张图则是不同的数据精度组合下◆◆■◆■★，整体模型端到端的表现，accuracy的收益，是越低越好的，可以看到不同的精度会有不同的压缩和精度效果，混合精度方法可以得到效果还有精度的收益平衡。能够降低大模型在执行过程中动态显存的需求，即KV cache上面占有的显存。最终优化的manager则是有两个定位◆◆★◆，第一个定位是它可以用来挖掘不同优化方法的协同效果，实现叠加的效果★■■★◆■，1+12的效果，像下面列的一些典型的场景，都会有不同的典型应用★■■。另外一个定位，是manager可以根据硬件的特性◆■◆，使用什么样的大语言模型以及具体的优化目标自动构建出最佳的优化方案。最终看一下整体的优化效果，SinianLITE特是针对大模型的推理优化，它能够达到效果，从大面上是提升系统效率以及降低AI部署的成本。右边的表格里面列了几个典型的场景baseline◆■■★★，以小见大，baseline以8卡100为基础◆■◆，第二行相当于使用相同的硬件★★★■◆，可以达到什么样的规划。最后一个costs efficiency是成本的收益，第三行是用相同的硬件，但是更少的数量，能够达到什么样的更好的cost efficiency, 更好的成本收益◆★◆，以及最后一行则是用相同的数量硬件，但是用一些更弱更低的硬件★◆，同样能够达到非常好的成本收益，通过这样的方式能够帮助在云上提供服务的时候，以更高的效率，更好的性价比为云客户来提供服务。

　　阿里云服务器通用型实例怎么选？g7/g8y/g8i适用场景、性能对比与选择参考

　　5月24日，华五教学协同中心◆■★■、阿里云与超星集团联合发布《高校AI实践通识课》。该课程融合理论与实践，由复旦大学等高校名师打造理论部分，阿里云提供AI实训平台支持实践环节，助力学生提升AI应用能力。课程预计秋季学期免费开放，推动AI时代人才培养。阿里云副总裁刘湘雯表示，这是AI与教育深度融合的创新实践；超星集团总裁史超强调，合作模式助力人才适应未来社会发展◆★◆★。此外，阿里云“云工开物”计划持续为高校提供技术支持与免费算力，助力AI教育发展。

　　从业务方来看◆★◆，业务方最直观的感受是爆炸半径的影响★◆★■★，从本身做公有云的计算算力的售卖，从算力来看，如果是单个CPU的核心数增加◆◆■★，代表着单个物理机的核心数增加★◆◆★，单个物理机的核心增加必然会带来了整个影响的VM数量和用户总的数量急剧的增加，如果单台服务器它的稳定性表现不好，或者它还维持以前的稳定性，它的影响爆炸范围相对以往它的核心数会有指数线性的增加，同时，第二部分也增加了运维的复杂度。

　　本文旨在从 MCP 的技术原理、降低 MCP Server 构建复杂度、提升 Server 运行稳定性等方面出发，分享我们的一些实践心得◆★★■。

　　做了大概的估算，从目前的pluggable可插拔的光网模块功耗和成本相对于deck线缆都有明显的劣势，但如果把可用的时间放在三年左右，可以看到随着CPU甚至2◆◆◆★■.5D optics这样下一代的光互联的技术◆★◆。在功耗和成本这两个最核心的指标都能取得相当长足的进步，所以未来的下一跳一定是从铜互联像光互联再继续往下走。

　　最早的方式是单机多卡，它受限于PCE域，PCE域是不能跨多机的，它只能在单机内，所以可以看到传统的服务器基本上都是单机8卡，最新出现的可能有32卡、16卡★■◆◆，但市面上最多见的是8卡★★★，第二通过以特网scale ou★■◆◆■，以特网是通过多机互联的方式，通过IDMA◆★■、ID★■◆★◆★，通过以特网scale out，scale out的方式是有一些缺陷的，第一个是它的时延跟带宽是有限的■■◆★★★，第二对于编程的复杂度有一些挑战，通常是通过计算的单机的编程，要扩展到面向网络通信的编程，所以在最新NVlink代表是ScaleUp的网络★★■，NVlink system可以认为ScaleUp的连法，为什么叫ScaleUp，是因为可以在单系统或者单进程内，可以看到多张卡■★■，不是8张卡★◆★，像NV最新可以看到72张卡◆◆★◆★■，为什么要做软硬协同，因为软件跟硬件是一个相互促进的事情，硬件的发展跟软件的协同★■★，它的关系首先是单芯片的能力决定了的模型的大小◆■，从传统的模式，芯片的显存多大，模型能做到多大。

　　本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作，开启AIGC盲盒。

　　回顾整个AI的发展路线，最开始AI服务器是一堆stand alone的GPU卡，当时面临的主要的核心问题是机器学习，这是一个小样本的训练过程，并不需要太复杂的交互，也没有太大的计算量◆★■■◆。2012年左右，Kington教授门下开始把AlexNet CV领域崭露头角的模型打出了名气，所以从AlexNet之后，CV领域的深度学习引领了整个AI应用的主流，之后服务器架构也随之产生了变化，随着深度学习CV类不断的进行■★■◆，需要大量的dataset反复进行训练，这时候有了数据并行的需求★■◆★，有了数据并行的需求也带来了GPU卡和GPU卡之间频繁Allreduce交互，传统的单卡架构已经不合适，进入了多卡阶段◆★◆◆，多卡阶段最开始是用PCIe来做ScaleUp◆■■★■，用PCIe的通道来进行数据的相互交互，随着深度学习数据并行不断的演进。

　　这些不下架的运维也带来了另外一个优势是运维时间的减少，PCIE网卡或者PCIE卡的形态■★■★，一般都是在服务器里以endincard的形态在插拔维护，如果出现了物理的损伤或者一些故障，需要下架把开盖、线缆拔出来，再把卡换掉，经过了最新的优化之后，这些部件都可以做到不下架的插拔设计，不需要再服务器把它拿掉，同时节点也可以做到插拔的维护，在同一个CIPU下，比如支持两个物理节点■◆，单个物理节点的失效不影响整个机器的运行，另外一个物理节点还可以继续运行，如果根据实际SSO时间，可以另外备件一个节点◆◆◆，把它重新再插拔回去■◆■，快速的恢复业务，降低整体的运维时间。左侧可以整个前后视图，前面最左侧是CIPU节点的位置，中间是的SCD存储的位置★■■◆，最右侧是PCIE标卡的扩展位置■◆★，相对于比较简单，后面是两个节点做到可插拔的维护的位置，还有两个CRPS的标准电源◆◆。这是今天发布的最新一代磐久F系列的通讯计算服务器。

　　从物理架构看，基本上进到Blackwell以后，现在的芯片的功率梯度已经达到了75W/cm2，整个散热能力基本上要进入全液冷时代，风冷已经不太可能退回去。如果现在开个玩笑AI时代最牛的工程师是热设计的工程师，因为他随手一解决是千亿个万亿个太阳的功率密度。这样的前提下，解决千亿万亿个太阳功率密度的芯片★◆◆★■，散热能力一定会往液冷甚至可能是多项液冷这样的方式走。这是一个大的往前演进的发展趋势，从具体的功率上面◆★，如果做设计，NV现在是1200瓦◆◆，但在设计上面一定得往2000瓦、3000瓦芯片的功率预留，整柜一定突破到200kW，甚至整个IDC也得按照百兆瓦的水平和量级去规划和部署，再一个变化是从SI的角度，因为左边的大图，从趋肤效应的角度，已经走到了极限，基本上在当前的224一米的互联距离已经不太可能再持续往上涨了，如果再往上涨进到448，一定得走到光★■。

　　本文深入探讨AI服务器在技术落地中的核心瓶颈问题，结合实战经验解析从模型训练到端侧部署的算力优化策略。内容涵盖三大典型场景的算力需求差异、GPU服务器选型的五大反直觉真相★◆■、实战优化方法（如混合精度训练与硬件资源监控）★■★◆★■，以及边缘AI部署挑战和解决方案★■◆★★★。同时提供算力弹性扩展策略■◆◆■★、模型生命周期管理及合规性建议◆★■，帮助读者构建可持续发展的算力体系。文末附有获取更多资源的指引■■★★■。

　　利用GPU本身的这段时间和CPU到GPU的传输时间做一个最好的overlapping。左上角是刚才提到的weight compression，通过对大模型中各权重值的分布研究■★，后面会有一些具体的分布图，它的值的分布根据它的尾数，还有根据指数不同会有很明显的特征■★■■★◆，根据特点设计了一些不同的压缩方式以及数据存储格式，也可以很大程度上减少它的潜能占用★◆◆◆■。右上角是权重的量化◆◆★■，突出强调的混合精度的cross layer的量化■◆◆，本来的权重大模型通常是IP16的数据格式■★，会根据这些权重的重要程度★◆◆★★★，敏感程度以及量化到更低精度之后的执行速度等信息得到最量身定制的优化的混合精度方案，得到类似于右边这样的效果◆■★◆★。

　　第二部分，CPU本身的核数会增加非常快，已经超过100物理核数，所以在新一代的服务器设计中，抛弃了或者放弃了传统的两路的服务器设计，把服务器已经全部归一化到单路的服务器设计，会减少单个节点物理的爆炸半径★★◆，减少单个物理机的物理的核数★◆★■★◆，如果在单路的设计里，单物理机的物理核数跟以往双路的物理机核数基本保持持平★◆◆◆★，所以整个售卖比，整个的爆炸半径的水位跟以往基本上保持一致。

　　大模型前两年主要训练对于算力的诉求很多◆◆◆★，到今年推理规模化的应用◆◆，算力在推理上成本是第一个诉求■◆★◆■◆，从大模型算力的增长，不仅仅是计算力的增长★★，对于显存是同步增长的，大模型为什么叫大★★■★，因为单个模型在计算的时候◆★■，单卡跟单机根本放不下◆★■★■◆，一定要通过AI集群的方式去做★■◆■■，计算量和计算力它增长的趋势是完全不匹配★■◆■■◆，计算量一个模型的参数以及它越来越大★◆◆，意味着它的计算量同步的会增长，一般的增长都是指数级的■■，CPU跟GPU为主要的计算资源，GPU每年可以看到它还可以增长到3~4倍◆★。

　　新一代的F系列磐久通用计算的服务器相对相对以往主要有几个方向的改变◆■★★，第一是CIPU节点比例的灵活配比实际的CPU的性能的增长与网络带宽的增长是不匹配的，会形成了一些网络带宽的浪费◆■◆★★，在新一代磐久服务器的设计中■◆★■，把CIPU的网络IO和CPU节点的数量，物理机的节点数量做了灵活的处理★◆■，可以根据不同的需求可以做到单CIPU支持两个节点，也可以做到对一些个网络带宽需求比较高的领域，做到一个CIP带一个节点，同时有一些更高带宽的网络需求的时候◆■★■■，可以做到两个CIPU对应一个节点，这样把网络带宽的IO和实际的CPU或者实际的服务器节点的配比做了灵活的处理。

　　与其称之为不可能三角◆★◆★，更倾向于把它称作为困难三角，因为在优化领域，可以通过精尖的技术★◆◆★■◆、优秀的工程实现以及软硬协同的方式来达到三者的平衡◆◆■◆◆★，得到一个兼具效果的优化成果。具体看一下是如何做的★★★■，这一页是SinianLITE其中几个技术特征的概览，1-4是其中几个比较典型的优化的方法。

　　从服务器本身的核心技术发展的维度到服务器在实际部署中遇到的一些实际的问题，针对这些问题做新一代的磐久F系列的通用计算服务器的设计。在云栖展会上★◆◆★■■，推出最新一代F系列通用计算服务器，通用计算的服务器在2号展厅的主展台有实际的物理机展现，会议结束可以到主展台现场参观实际的物理机形态◆◆★★■■。

　　第三方面是大家熟知的权重的量化，权重量化的目的是降低大语言模型推理过程中的静态部分，模型定了静态部分就定了，典型的精度像32位◆■■◆★、16位、8位◆★、4位等以及两种典型的模式■★◆■，weight-only的只压缩位置◆■，以及weight-and-activation◆◆★。量化带来两个好处，从更高的数据比特数降低到更低数据的数据时，它对显存的压力降低了，它对带宽的压力也降低了■★。

　　首先提到通用计算的服务器，最核心的部分是处理器芯片，处理器芯片从整个趋势来看★■■■◆，从最早期摩尔定律的制成还在继续演进，还有各种封装的技术使能多样化，提升了单位socket封装下的核心数◆★★◆，整体来看，通用计算服务器领域■◆■■◆，它的处理器的核心数还在不断增加◆◆■◆■◆，从2022年突破了50个核心之外★◆◆，到2024年业界的通用的主流服务器的核心数◆◆◆■★，已经超过了100核心以上，甚至已经达到160核心■◆◆◆，可能在未来下一代可能会到256核心以上，处理器核心数的快速增长，也给业务和服务器自己的硬件研发带来了一些挑战。

　　但本身的这些物理机它的占比又是相对比较少的，如果有一些突发的业务需求，或者有突发的客户需求★■◆，会带来碎片化，经营的成本比较高，同时★◆◆■■，客户的响应还比较慢，因为有一些不同的客户有一些不同地方的响应的时候★◆◆■★★，整个供应链的响应，它有一个刚性的时间，并不是客户有了需求之后，马上把物理机运到IDC机房，有生产的时间、交付的时间，还有装机的时间之类，时间是刚性的不可调整的■★■，所以这一部分如果物理机的形态过多■■，客户需求比较灵活的情况下，会导致客户响应比较慢，整个体感是比较差的。

　　单机的VM和用户数量的增加，同时也带来了维修成本的增加，第三部分是物理部分刚性的东西，服务器silicon本身物理核数增加★◆◆★，势必也会带来故障率的增加，因为silicon本身它的失效率相对是稳定的，所以物理核心数的增加，带来整个silicon成本故障率的增加■◆★★◆，同时，因为单物理机的核心数增加，单物理机的售卖客户群体的增加也会带来如因为不属于一台物理机■■，并非可以快速的把它们全部能卖出去，它总会带来一些水位上的增加，同时★■◆◆■■，带来整个售卖率的降低■★★，售卖率降低会导致整个TCO收益降低，对整个云业务整体TCO带来了比较大的挑战。

　　阿里云在新一代通用计算服务器设计中，针对处理器核心数迅速增长（2024年超100核）、超多核心带来的业务和硬件挑战、网络IO与CPU性能增速不匹配◆■◆◆、服务器物理机型复杂等问题■◆◆◆★，推出了磐久F系列通用计算服务器★■。该系列服务器采用单路设计减少爆炸半径，优化散热支持600瓦TDP◆★，并实现CIPU节点比例灵活配比及部件模块化可插拔设计，提升运维效率和客户响应速度。此外，还介绍了面向AI的服务器架构挑战与软硬件结合创新，包括内存墙问题、板级工程能力挑战以及AI Infra 2■■★◆◆.0服务器的开放架构特点★★。最后◆★，探讨了大模型高效推理中的显存优化和量化压缩技术，旨在降低部署成本并提高系统效率。

　　AI的主会场场馆进门的地方AI Infra2.0服务器■◆★，核心主打开放的架构，高能效、高可用和高性能★◆■★◆，详细的指标不一一列举■★■■。今天也有很多个专家学者，都是行业的资深人士★◆■■★，再一个是推Alink的系统，希望凝聚产业界的合力★◆，共同来打造一个开放的强力的ScaleUp的互联。

　　面向这些挑战提出大模型池化解耦架构探索，池化解耦，解耦不是割裂，它更好的让软硬件能够协同起来★★★◆◆，因为底下硬件是多样的◆◆★，上面计算的方式也是多样的，解耦以后可以用到更多新的硬件，也能在硬件上面支持更多的计算的特征，在历程中，从大模型之前★■，一直在探索这种解耦，因为从云上面售卖的资源面临各种各样的计算的特征★■◆◆，解耦一直是在基础设施上面追求的方式，最早是CPU、GPU的解耦◆◆，相当于CPU跟GPU之间分离开◆★★，可以灵活的逐成不同的配置方式。

　　首先图中间部分◆■◆，是一个大模型结构的示意◆★◆。中间长方体基本上代表了大模型的主体部分即权重★◆★■，每一个块可以理解成一个transformer的decoder，也可以理解成更细力度的0计算，各种算子，下面是在生成过程中的KV cache. 从Offloading讲起，即卸载，Offloading比较容易理解■◆，GPU显示不够用的时候■★◆◆，拿CPU的内存辅助，但是Offloading有一个非常大需要注意的点◆◆◆，因为它是CPU跟GPU之间的传输，它会非常受限于PCIE带宽的速率◆■◆，因此决定Offloading策略的时候要非常小心★◆，非常的关注到底Offload的哪些层■★■★■，以及offload的schedule，调度是什么样的◆★◆，去保证在引入Offloading过程中不会对整体模型的性能带来一些overhead。

　　但CPU增长百分比的增长趋势，所以GAP会越来越大，面向这些GAP◆■◆★◆■，会衍生一些AI infra集群的多样性■■★★★◆，面向传统的小模型时，它的部署包括应用是单维的，是在单卡上面能把一个模型放下◆■◆，在单卡上面能放下，部署跟应用在软件上很简单，如果像大模型发展以后，通常一个大模型比如到100B的时候，基本上单机甚至单模型要支持多机的部署，部署的维度是越来越复杂的■◆★◆★◆，模型的发展有一个趋势★◆◆◆，模型是数据强的趋势，芯片也有芯片工艺■★★■◆，它也有芯片墙■★，从单个芯片的维度去解决算力的资源，它是有限的★★★★，但是通过集群Scale的方式去扩展算力资源，它是可以无限的■◆■◆■★，scale的方式有有几种，传统是单卡解决不了的问题■★■◆■■，一定要通过多卡，多卡的解决的方式有几种形态，第一个多卡是单机的，单机最传统可以看到多卡的互联，最主要的是三种方式。

　　第四KV cache是大模型在推理的过程中非常典型，有普遍的一个特征，它会保存生成过程中的一系列contact上面的K和V的值用来辅助后面的生成，它也是占用显存的大头★■。