★ FEATURED ARTICLE 智算无限 全栈智能聊聊AI服务器新品背后的真实行业逻辑算力这东西前两年大家还在纠结“买几张卡跑实验”现在直接进化到“一个机柜能塞多少张卡、怎么把几千张卡管起来”的阶段了。我最近一直在关注各家厂商在 AI 基础设施上的动作因为这一波大模型带动的算力需求已经不是单纯堆显卡那么简单的事。看到联想问天两款 AI 服务器新品亮相标题里“智算无限、全栈智能”这八个字放在当下的产业语境里还挺有嚼头——它背后其实代表着一整条关于 AI 基础设施的思考路径单机性能怎么榨干、多卡互联怎么打通、软件调度怎么跟上硬件速度、最后落到实际业务里怎么不翻车。这篇文章不打算给你念发布会PPT而是以一个长期折腾 AI 服务器、给客户搭过训练集群、也踩过无数硬件坑的从业者视角拆解一下这类 AI 服务器新品到底在解决什么问题、核心技术在哪儿、选型时该盯哪些参数以及真正部署的时候会遇到哪些让人头大的细节。无论你是刚接触 AI 基础设施的运维新人还是正在给团队规划算力采购的技术负责人这篇内容应该都能让你少走点弯路。1. 从“卖整机”到“卖智算系统”AI服务器为什么越来越强调全栈1.1 单卡性能到集群性能的跨越先说个行业里每天都在发生的现象。很多团队第一次上手大模型训练时习惯把目光锁定在GPU型号上觉得只要买到了高端卡训练速度就一定快。但真正把机器拿到手、开始组网跑任务才会发现瓶颈无处不在CPU 跟不跟得上数据喂送、内存通道够不够宽、多卡之间的通信效率高不高、存储的 IO 能不能扛住 checkpoint 频繁写入。任何一个环节掉链子高端 GPU 也会被拖成“高端摆设”。这就是为什么现在厂商发布 AI 服务器时不再只强调“我用了什么芯片”而是把整台机器的CPU、内存、存储、网络、散热、甚至管理运维软件打包成一套方案来讲。联想问天这次的定位就是这种思路——不是一个孤立的硬件盒子而是一个面向 AI 计算场景的子系统。它强调“全栈智能”本质上是在说从底层硬件到上层调度再到业务场景的适配都帮你考虑了。1.2 两款新品背后的场景分工从行业惯例看AI服务器新品一般会走两条差异化路线一条是极致性能路线面向大规模训练集群追求单机算力密度和扩展能力另一条是灵活均衡路线面向推理、中小规模微调、数据预处理这类场景强调单位算力成本、部署效率和场景适配性。“两款新品”的组合大概率就是对应这两类截然不同的需求。我之前给客户做算力规划时最常遇到的困境不是“买不起高端卡”而是“买了一堆高端机器实际业务根本吃不满”或者反过来“想做推理服务却发现买来的训练服务器功耗、噪音、占地全都不适合机房现状”。厂商把产品线拆成两条本质上是为了让你按需买单而不是为用不上的性能支付溢价。1.3 为什么“智算无限”不是空话算力需求这东西确实是永无止境的。模型参数从百亿到千亿训练数据从 TB 到 PB如果你只盯着单台机器的峰值算力很快就会发现不够用。真正的“无限”感来自横向扩展能力——当你需要更多算力时新机器能不能平滑融入现有集群网络能不能支撑更大规模的集合通信调度系统能不能把异构资源统一纳管。这也是我看这类新品时最关注的一个维度它是不是为规模化部署设计的。具体来说就是机器之间的网络互联能力比如是否支持高速 RDMA 组网、供电和散热的余量能不能支持高密度部署、以及管理接口的标准化程度能不能被现有云平台或调度系统识别、纳管。这些地方做得好“智算无限”才是一个可实现的目标否则就是发布会上一句漂亮话。2. 拆解核心硬件技术AI服务器拼的不只是GPU2.1 计算平台与CPU选型逻辑GPU 是 AI 服务器的主角但配角选不好主角一样演砸。CPU 在整台机器里的角色是负责数据搬运、任务调度、以及那些还没被卸载到 GPU 上的预处理逻辑。训练大模型时CPU 一旦成为瓶颈GPU 就会经常处于“等数据”的状态GPU 利用率哗哗往下掉。所以在选 CPU 时我一般会关注这么几个点核心数能不能满足多路并发数据加载、PCIe 通道数够不够支撑多张 GPU 和高速网卡的带宽需求、内存通道数量是否匹配高带宽内存配置。高端 AI 服务器通常会采用双路甚至多路 CPU 设计目的就是为了保证并行数据通路足够宽让每张 GPU 都能吃饱数据。联想问天这类新品在 CPU 配置上应该采用的是主流服务器级平台支持最新一代的处理器同时内存容量上会给到比较大的扩展空间——这对于动辄需要几百GB甚至上TB内存来装载模型参数和中间激活值的训练任务来说是硬性要求。2.2 GPU互联与显存扩展的工程问题多 GPU 服务器最核心的工程挑战不是“插上四张卡通电能用”而是“四张卡之间的通信带宽够不够快”。大模型训练里的张量并行、流水线并行都极度依赖 GPU 之间的数据交换速度。如果卡间走的是普通 PCIe 通道那多卡并行带来的通信开销可能会抵消掉大部分算力增益甚至出现“越多越慢”的怪现象。业界主流做法是引入高速卡间互联技术让多张 GPU 构成一个高带宽域。联想的 AI 服务器产品线在高端型号里通常会支持这种互联拓扑实际操作中这意味着你跑分布式训练框架时可以放心地开启张量并行而不必担心通信成为瓶颈。对于显存扩展这块大模型推理时的 KV Cache 非常吃显存支持大容量显存版本的 GPU 能显著减少需要跨卡访问的情况提升单机吞吐能力。2.3 内存带宽与容量的平衡艺术很多人买服务器时只盯着 CPU 和 GPU却忽略了内存规格这是个特别容易犯的错。AI 负载对内存带宽的要求极其变态尤其是训练场景下数据加载、embedding 查询、样本 shuffle 都需要高频访问内存。如果内存带宽跟不上GPU 就会频繁 stall空转等待数据。我见过一个真实案例某公司在自建机房跑推荐模型训练GPU 利用率始终上不去排查了很久才发现是内存配置问题他们的服务器内存频率偏低且没有做满通道配置导致数据供应速度远远跟不上 GPU 的消费速度。后来换了高频高带宽的内存方案同样的 GPU训练时间直接缩短了将近一半。所以看到 AI 服务器新品时我会特别留意它们的内存规格和通道配置这往往决定了实际表现和理论峰值之间的差距有多大。存储层面同样不能忽视。大模型训练过程中checkpoint 定期保存会产生大量数据写入如果存储是本地 NVMe SSDIO 延迟低保存过程对训练的影响就比较小如果走的是网络存储那还要看网络带宽和存储系统的吞吐能力。联想问天的新品在这个层面通常会提供灵活的存储配置支持高性能本地盘也能对接外部分布式存储这套组合拳对实际生产环境来说很有意义。2.4 散热与功耗容易被低估的隐形门槛如果说 GPU、CPU 这些是台面上的性能指标那散热和功耗就是藏在台面底下的隐形门槛。两三千瓦的单机功耗不是闹着玩的风冷方案在高负载下会产生巨大的噪音和热量机房里如果散热设计不到位机器分分钟过热降频性能暴跌。这也是为什么越来越多 AI 服务器开始推出液冷版本。液冷的好处是导热效率高、噪音低、还能支持更高密度的机柜部署。对新建机房来说液冷可能意味着前期的管路改造投入但对已有风冷机房来说选择风冷版还是液冷版得结合机房实际情况来权衡。我看到联想问天的产品发布里也提到了散热方案的优化这对于跑大规模训练的用户来说是个需要认真对待的选型维度。3. 全栈智能的核心从硬件到软件的最后一公里3.1 驱动、固件与底层软件的协同问题硬件只是基础真正让 AI 服务器发挥性能的是满载驱动、固件、加速库的软件栈。过去很多团队遇到的问题是硬件买回来很先进但驱动和加速库版本不配套导致框架跑不起来或者固件版本太老影响 GPU 性能稳定发挥。所谓“全栈智能”落到实际操作层面就是厂商把这些底层软件的适配和验证工作提前做完了。用户拿到机器后不需要自己费劲去匹配各种依赖版本直接就能进入业务调试阶段。这个价值在规模化部署时尤其突出——几十上百台机器如果每台都要人工处理驱动兼容性问题运维成本会让人崩溃。3.2 容器化与GPU资源池化现代 AI 基础设施的另一个关键点是资源管理和调度。裸机跑 AI 任务的时代已经过去了现在主流做法是把 GPU 资源池化通过容器平台统一调度。无论是开发环境的快速创建、训练任务的资源分配还是推理服务的弹性伸缩都离不开一个稳定的容器化底座。这就对服务器的底层设计提出了要求虚拟化支持好不好、设备直通能力行不行、能不能和主流的容器调度平台无缝对接。我在帮客户搭训练平台时最怕的就是硬件厂商只给了裸机对上层调度生态一问三不知。真正的智能基础设施必须原生于云化环境联想问天这类产品强调“全栈”说明他们已经在这块做了不少适配工作这对于想快速搭建 AI 平台的技术团队会是实打实的减负。3.3 多卡并行与分布式框架的适配还有一个容易被低估的“软实力”就是服务器对分布式训练框架的适配程度。同样是 8 卡机器跑同样的模型有的机器只需要简单配置就能获得接近线性的加速比有的机器却会因为拓扑差异、驱动设置问题出现严重的性能衰减。这个问题的根源在于服务器设计时是否充分考虑了并行计算的需求。比如GPU 的拓扑排列是否合理、NUMA 亲缘性是否优化过、卡间通信是否走了专用高速通道这些都会影响分布式框架的最终表现。对不走运的用户来说可能买回来的高端机器实际性能只有理论值的六七成。所以我会建议评估 AI 服务器时别只看单卡跑分一定要看多卡并行实测数据和分布式框架的兼容性报告。4. 不同AI业务场景下怎么选才不踩坑4.1 大模型训练场景的关键考量如果你是做千亿级大模型预训练那算力密度的优先级极高。单机 8 卡甚至更多 GPU 的配置、高速卡间互联、大容量高带宽内存、以及支持高速网络扩展的能力一个都不能少。这种场景下单位机柜能提供的总算力越高越好因为训练集群的规模往往受限于机房空间和电力配额你需要在有限的空间里塞进最多的有效算力。同时也得考虑 checkpoint 保存和加载的效率。大模型训练动辄跑几周甚至几个月中途如果节点故障恢复速度直接取决于存储和网络的配合效率。高端服务器通常会配备高速本地盘就是为了在节点故障时能快速恢复状态减少训练时间损失。4.2 推理场景的不同偏好推理负载和训练负载的需求完全不同推理更看重延迟、吞吐和单位请求成本。如果你主要做在线推理服务比如聊天机器人、AI 助手那单张卡的推理吞吐量是关键显存容量也要能容纳模型的 KV Cache 需求。服务器不一定要追求最高的 GPU 算力但一定要有良好的功耗控制因为推理服务是 7x24 小时常年运行的电费账单上的差异会非常可观。联想问天两款新品如果其中一款定位推理优化那它大概率会在功耗、机架密度、以及推理加速组件适配上有针对性设计。我通常会建议做推理服务的团队认真做压测而不是直接照搬训练服务器的选型方案。4.3 中小规模微调与数据预处理还有一个很常见的场景被很多人忽略中小规模微调、数据清洗、特征工程、模型评估这类轻量级但数量庞大的任务。这类任务的特点是并发不高但种类繁杂对算力的要求不极致但对资源调度的灵活性要求很高。一台均衡型服务器搭配池化管理平台可以同时跑多个任务充分利用空闲算力。对于这种情况我反倒不太建议买顶配旗舰机性价比非常低。买一两台性能均衡、扩展性好、管理方便的服务器反而能更快地支撑起业务的多样化需求。这也是为什么厂商推双产品线是有现实逻辑的——不同用户、不同场景、不同预算都应该能找到合适的配置。4.4 典型选型对比参考需求场景优先级指标推荐思路可能踩的坑大模型预训练算力密度、卡间互联、网络扩展高配旗舰机关注多卡并行性能忽略散热和电源容量性能发挥受限在线推理服务吞吐、延迟、功耗推理优化型注重单位请求成本买成训练机功耗高且性能过剩微调和数据预处理灵活性、稳定性、性价比均衡型配置配合资源池化管理资源碎片化缺乏统一调度科研与教学实验易用性、兼容性标准化整机驱动生态成熟依赖特定框架版本兼容不好5. 部署实操心法从开箱到稳定运行的完整路线5.1 开箱检查与固件更新别急着上电先说一个很多人忽视的环节服务器到手后的开箱检查。AI 服务器因为功耗大、组件多运输过程中的振动可能导致 GPU 或网卡松动内存条也可能因为颠簸出现接触不良。我拿到新机器后的标准流程是先拆开侧板检查所有 GPU 是否插紧、供电线是否连接牢固、内存是否完全卡到位然后再上电。上电后第一件事不是装系统而是进 BMC 管理界面查看硬件健康状态、传感器读数、以及固件版本信息。如果厂商提供了固件更新包我建议在上生产环境之前统一升级一遍避免在后续使用中被一些已经修复的硬件 bug 坑到。这一步听起来简单但能省掉后面大量的排查时间。5.2 驱动安装与配置版本匹配是第一要务驱动安装是另一个极易出问题的环节。AI 服务器对 GPU 驱动、CUDA 版本、加速库版本之间的匹配关系非常敏感版本不匹配可能出现驱动加载失败、GPU 无法识别、CUDA 初始化报错等一系列让人崩溃的问题。我的建议是严格按照厂商提供的兼容性列表来安装不要用最新版强迫症。最新未必最稳稳定才是生产环境的第一需求。安装完成后用命令行工具确认所有 GPU 都被正确识别然后跑一次简单的矩阵运算验证 CUDA 环境可用。这个验证步骤不会超过五分钟但能帮你避免在正式训练时才发现环境问题的尴尬。5.3 网络与分布式配置组网是集群的灵魂如果你要搭多机集群那网络配置的优先级就直接拉满。AI 训练集群的组网模式通常需要支持高速 RDMA配置时涉及 IP 分配、路由设置、子网划分、拥塞控制参数调优等一系列操作。这里最常踩的坑是交换机配置没有开启对应的流控和拥塞控制导致多机通信性能远低于预期。我之前帮一个客户排查性能问题单机 8 卡训练速度正常但扩展到 4 台机器后加速比只有理论值的二分之一。排查到最后发现问题出在交换机的缓冲区设置上没有针对 AI 训练的流量模型做调优。这类问题单看服务器本身是看不出来的必须对整个网络链路做整体优化。所以在规划集群时别只盯着服务器配置网络设备的选型和参数配置同样重要。5.4 稳定性测试清单怎么确认机器真的能打正式上线之前建议做一轮完整的稳定性测试。我的常规测试清单包括以下几个项目GPU 计算压力测试跑一段时间的高负载矩阵运算观察 GPU 温度、频率和利用率是否稳定有没有掉卡或者降频现象。内存压力测试验证内存稳定性排除内存条接触不良或者配置错误导致的隐性故障。卡间通信带宽测试实测多卡通信带宽是否达到标称值这个指标直接影响分布式训练表现。磁盘 IO 测试验证本地 NVMe 盘的读写性能确保 checkpoint 保存和加载不会成为瓶颈。整机长时间满载测试模拟真实训练负载运行数小时观察整机功耗、温度和稳定性。这套测试流程走下来如果机器能稳定通过那基本上可以放心上生产。如果中途有哪一项不过关最好在业务上线前解决否则后面出问题都是加倍的成本。6. 运维中的常见问题与排查技巧实录6.1 GPU 掉卡与降频问题排查GPU 掉卡是 AI 服务器运维里最经典的问题之一。现象是训练跑到一半某张卡的利用率突然归零或者系统直接报设备丢失。这类问题的成因很多排查的时候要按顺序来先查物理连接GPU 是否松动、供电线是否接触良好。再看散热是否存在过热导致保护性降频或离线。然后查驱动日志看看有没有报设备超时、总线错误之类的信息。最后考虑电源问题电源余量不足或供电波动会导致多卡高负载时个别卡掉线。这类问题有时候是偶发的极难复现我的经验是一旦遇到立刻去翻系统日志和 BMC 传感器记录看有没有温度、功耗的异常突变可以把排查范围大幅缩小。6.2 显存不足OOM的软性解法显存不足是训练和推理场景的常见报错但很多人不知道的是不一定每次 OOM 都需要买新卡。在代码层面可以做很多优化减小 batch size、开启梯度累积、使用混合精度训练、优化模型的内存占用、清理不再需要的中间变量、设置合理的 KV Cache 缓存策略。硬件层面也可以做一些事情确认是否开启了显存的全部可用容量、检查是否有其他进程占用了显存、调整容器平台的资源限制策略。把这些软性手段用尽之后如果显存依然不够再考虑换更大显存的 GPU 或者增加多卡并行这样能最大化现有资源的利用率避免过早陷入硬件采购循环。6.3 网络性能异常的定位思路多机训练时如果出现“机器越多反而越慢”的诡异现象大概率是网络通信出了问题。定位思路一般是先在单机内跑多卡训练确认单机性能正常再扩展到两机、四机逐级排查用网络性能测试工具测一下实际的点对点通信带宽和延迟确认是否达到预期值检查 TCP/RDMA 连接数和丢包率看有没有拥塞或配置不当。网络问题往往牵涉服务器网卡、交换机配置、防火墙策略等多个层面排查时要一层层剥。我的建议是从一开始组网就做好网络配置的标准化文档后续扩展时直接按文档执行能避免大量重复性踩坑。7. 我个人长期用下来的几条实在建议7.1 别迷信峰值性能跑一次真实负载再说不管厂商宣传的规格有多漂亮最终决定你实际体验的一定是真实负载下的表现。我见过太多用户被宣传的材料参数吸引买回来后才发现实际性能远达不到预期。最靠谱的办法是在采购前拿到样机跑一遍自己的真实业务负载看 GPU 利用率、训练吞吐、推理延迟这些指标到底怎么样。花几天时间做测试远比买错机器后几个月的心塞划算。7.2 留足扩展余量算力规划要有前瞻性做算力规划时大多数人容易犯的错误是“刚刚好主义”——今天就按今天的业务规模买设备完全没有预留明天的发展空间。AI 业务的发展速度往往超出预期模型参数越来越大、数据越来越多、并发请求越来越高当你要扩容时如果现有服务器的电源、网络、散热都没有预留余量那就只能整机替换成本非常高。所以我建议选型时宁可稍微多花一点钱选择电源余量更大、扩展槽位更多、散热设计更强的机型。多付出的那部分成本本质上是为未来的灵活性买的保险。7.3 算力设备的附加价值在服务与生态最后再说一点可能很多人忽略的算力设备的真正价值不只是硬件本身更是背后的服务与生态。驱动兼容性验证、固件更新支持、故障诊断服务、与主流AI框架的适配程度这些“看不见的部分”决定了你实际使用时的顺畅程度。两个品牌硬件规格差不多但因为底层的适配和服务能力不同实际运维体验可能天差地别。选择成熟的、有完整生态支持的 AI 服务器产品线本质上是在选择降低自身运维复杂度的可能性。对于大多数团队来说把精力花在业务创新上永远比花在纠结底层配置上更有价值。联想问天这两款 AI 服务器新品的亮相背后折射的是整个 AI 基础设施行业从“拼硬件参数”转向“拼全栈体验”的大趋势。我个人的体会是一家厂商如果能把硬件、软件、生态、服务这条链路都跑通那它所定义的就不仅仅是一台服务器的性能数字而是一整套可以用最低复杂度支撑起智能业务的基础设施能力。对于正在做算力规划的团队来说与其焦虑“该买什么卡”不如认真想清楚自己的业务场景需要什么样的整套方案再去做产品选型这样更容易找到真正适合自己的答案。
阅读完成 · 觉得有帮助？
