ITPub博客

近日，中科曙光与中国气象局地球系统数值预报中心联合宣布：基于曙光8000全国产十万卡AI超集群，国产下一代天气气候一体化模式MCV成功实现全球5公里分辨率预报业务化计算时效达标，并首次完成全球3公里模拟。

导语 过去很长时间里，封装在芯片产业链中扮演的是“后勤”角色：芯片设计完成、晶圆制造下线，最后交给封测厂装进壳子里，能焊到 PCB 上就算完成任务。但在企业级计算场景中，这个认知正在被推翻。当单颗芯片的晶体管数量逼近光罩极限、当 HBM 需要与逻辑 die 靠得足够近、当 Chiplet 成为大芯片的主流架构，封装不再只是“把芯片包起来”，而是直接决定性能上限、功耗表现和成本结构的关键环节。 本文围绕封装类型、基板、硅中介层、TSV、Chiplet 集成等方向，梳理从 FCBGA 到 2.5D/3D 的技术演进逻辑，并讨论先进封装对企业级芯片竞争力与封测供应链格局的影响。 一、封装为什么突然变得重要 要理解封装的地位变化，先要理解企业级芯片面临的三个硬约束。 第一是 面积约束 。光刻机的单次曝光视场有限，芯片

当技术更迭的周期从十年压缩到三年，企业 IT 基础设施的每一次投资决策，都像是在为未来下注。存储、计算、网络、芯片、数据中心——哪些是过渡方案，哪些是长期趋势？本文尝试给出一份基于技术演进逻辑的判断框架。 导语：基础设施的“时间差”困境 企业 IT 基础设施正处在一个罕见的“多周期叠加”阶段。一边是传统架构仍在支撑核心业务，一边是云原生、AI 算力、高速互联等新技术加速渗透。更棘手的是，不同技术的生命周期并不一致：有些技术看似火热，实则只是过渡方案；有些技术低调演进，却可能成为未来十年的底座。 对于企业 CTO 和基础设施负责人而言，真正的挑战不是“要不要用新技术”，而是“在什么时间窗口、以什么节奏、投入多少资源”。选早了，可能成为先烈；选晚了，可能被锁定在过时架构上。本文从存储、计算、网络、芯片、数据中心五个

导语 当人们谈论数据中心和储能系统时，话题往往集中在算力规模、GPU 集群、PUE 指标和电池能量密度上。相比之下，消防与安全系统长期处于“隐形”状态——它不产出算力，不直接贡献营收，却决定了当一场热失控或电气火灾发生时，整个设施是局部受损还是全面瘫痪。随着高密度机柜和锂电储能的大规模部署，这套“隐形系统”正面临前所未有的新挑战。 一、为什么消防在数据中心里总是“被忽视的细节” 在传统数据中心的设计逻辑中，消防系统属于典型的“合规驱动型”投入。它必须满足消防验收、行业规范和保险要求，但在日常运营中几乎不产生可见价值。于是，它常常被压缩预算、延后升级，甚至在扩容改造中被当作“够用就行”的附属项。 然而，数据中心的风险结构正在发生变化。过去，机房火灾的主要诱因是电气线路故障和传统设备过热；如今，两个新变量正在重塑风

导语 在企业 IT 基础设施的生命周期中，存储替换与上云迁移几乎是绕不开的课题。硬件老化、容量瓶颈、数据中心搬迁、混合云战略落地，任何一个理由都可能触发一次大规模数据迁移。然而，与计算资源可以快速重建不同，存储承载的是企业最核心的资产——数据本身。一旦迁移过程中出现不可逆的数据损坏或丢失，后果往往不是“重启一下”就能解决的。 这也是为什么在企业级项目中，数据迁移常被视为“高风险动作”：它同时牵涉数据一致性、业务连续性、停机窗口、回滚能力和跨团队协作，任何一个环节的疏忽都可能在迁移当天被放大成生产事故。 一、迁移场景的复杂性，决定了风险不是单一维度的 企业级存储迁移很少是“把数据从 A 拷到 B”这么简单。常见场景包括： 同构存储替换 ：旧型号退役，新型号接替，协议与语义相对接近，但性能特征、快照机制、精简配置行

导语 过去，数据中心里最受关注的“表”是电表。今天，越来越多的团队开始关心另一种“表”——算力账单。随着 GPU、AI 训练和推理负载进入生产系统，数据中心内部的成本归属、能效分摊和对外服务计费，正在从粗放的“按机柜估算”走向更细颗粒度的“按用量结算”。这背后是一条从电力计量到算力计量的完整链路，也是 FinOps 在基础设施层面真正落地的过程。 一、为什么“计量”突然变得重要 在传统托管和自建数据中心时代，成本核算相对简单：机柜按月租用，电力按合同容量或实际用电结算。业务团队对“用了多少电、花了多少钱”的感知是模糊的，因为账单通常停留在设施层，而不是业务层。 变化来自三个方向： 单机柜功率密度上升 。高密度计算设备让“一个机柜”不再是均质单元，同一排机柜的功耗可能相差数倍，按机柜平均分摊会严重失真。 算力成为

导语 在企业级存储体系里，“多路径”常被当作一个配置项：装好驱动、认到盘、把路径聚合起来，似乎就完成了高可用。但真正进入生产环境后，路径状态、控制器归属、故障切换策略、操作系统与阵列的语义差异，都会决定一次链路抖动是“无感切换”还是“业务挂起”。多路径不是简单的冗余线缆，而是一套跨越主机、SAN/NVMe-oF 网络与存储阵列的可用性契约。 一、多路径 IO 到底解决什么问题 在多路径 IO（MPIO）出现之前，主机通过 HBA 看到存储 LUN 时，往往会把同一块物理盘识别成多个设备。原因很直接：主机到存储之间通常存在两条甚至更多物理链路，每条链路都会暴露同一个 LUN。如果没有多路径层，操作系统会把这些路径当成不同磁盘，既造成管理混乱，也容易引发数据一致性问题。 多路径层的核心职责可以概括为三件事： 聚合

当千卡、万卡集群成为大模型训练的常态，硬件故障不再是“意外”，而是“日常”。真正决定训练效率的，往往不是峰值算力，而是中断之后能不能快速、无损地接着跑。 在大模型训练的世界里，有一个略显反直觉的事实：集群规模越大，单次训练任务连续无故障运行的时间反而越短。当成千上万张 GPU 被绑在同一个训练任务上时，任何一张卡、一条链路、一个电源模块的异常，都可能让整个任务戛然而止。于是，“训练中断了怎么办”从一个运维细节，升级为 AI 基础设施的核心命题。 本文围绕 checkpoint 策略、故障检测、任务重启、弹性训练与容错框架，梳理大规模训练中故障的常态，以及恢复效率优化的主要思路。 一、故障是常态，不是例外 理解故障恢复，首先要接受一个前提：在大规模训练中，故障是统计意义上的必然。 从硬件层面看，GPU、显存、NV

导语：在服务器采购清单里，CPU 型号往往是最受关注的一行，而内存那一栏常常被简化成“512GB”或“1TB”这样的数字。但在企业级场景中，内存的通道数、DIMM 插法、容量与带宽的平衡、NUMA 拓扑，以及镜像与备用等可靠性策略，往往才是决定这台机器能否跑出预期性能的关键。配置不当，轻则性能打折，重则采购预算花在了看不见的瓶颈上。 一、内存不是“插满就行” 很多企业采购服务器时的默认逻辑是：容量越大越好，插槽插满最省心。这个逻辑在消费级主板上或许问题不大，但在企业级平台上，内存子系统的行为要复杂得多。 现代服务器 CPU 的内存控制器通常支持多个通道，每个通道下又可能挂载多个 DIMM 插槽。内存带宽并不是所有插槽共享一条总线，而是由通道数量、每通道的 DIMM 数量、内存代数与频率共同决定。换句话说，同样容

在数据中心能效话题中，人们习惯把注意力放在芯片制程、液冷方案、供电架构这些“硬核”环节上，而空气怎么走、从哪里进、从哪里出，往往被视为机房运维的细枝末节。但恰恰是这些看不见的气流路径，决定了一台服务器是稳定运行还是频繁告警，也决定了一个机房的 PUE 是停留在纸面还是真正落地。 一、被忽视的“空气基础设施” 如果把数据中心比作一套精密运转的工业系统，供电是血液，网络是神经，而气流组织更像是呼吸。呼吸不畅，再强的心脏也会出问题。 然而在实际项目中，气流组织常常排在预算和关注度的末位。原因并不复杂：它不像一台新服务器那样有明确的采购清单，也不像液冷那样自带技术光环。冷热通道是否隔离、机柜是否装了盲板、地板送风口开度是否合理，这些细节分散在施工、运维、IT 多个环节之间，缺少一个明确的“责任人”。 结果是，很多机房在

导语 在企业 IT 基础设施中，“存储”往往是最容易被低估、却最容易在关键时刻暴露短板的一层。应用团队关心的是数据库响应、虚拟机启动速度、容器持久卷的挂载时间；而支撑这些体验的，是底层一套关于“磁盘如何组织、容量如何分配、数据如何保护”的机制。RAID、LVM、存储池、精简配置、快照与克隆，这些名词经常被混用，甚至被当成同一层级的技术来比较。实际上，它们处在不同的抽象层，解决的是不同的问题。 本文尝试从媒体视角梳理这条技术脉络：RAID 级别如何演进，LVM 在传统卷管理中扮演什么角色，存储池与精简配置改变了什么，快照和克隆又依赖哪些底层能力。最后回到企业选型，讨论传统卷管理与分布式存储池之间的边界，以及容量与性能之间的权衡。 一、RAID：从“磁盘冗余”到“性能与可靠性的组合” RAID 的初衷很朴素：用多块

近日，中科曙光联合西安交通大学科研团队，依托全国产十万卡AI超集群曙光8000，完成超大规模多喷口超声速射流高精度数值模拟，创下国际已知最大规模的同类仿真纪录。双方向我们生动讲述了如何用国产算力攻克可重复使用火箭研发中最棘手的难题。

导语 过去十余年，企业 IT 基础设施的演进逻辑正在发生一次深层转向：从“每家厂商各自定义一套软硬件栈”，走向“由开放社区定义接口与规范，厂商在规范之上做差异化”。OCP（Open Compute Project）、OpenBMC、SONiC、OpenRAN 是这一转向中最具代表性的几个名字。它们分别覆盖服务器与数据中心硬件、带外管理固件、网络操作系统和无线接入网，看似分散，实则共享同一套方法论——把过去封闭在专有体系里的关键层抽象出来，用开放规范、开源实现和多方协作来替代单一供应商锁定。 对企业而言，这不只是技术选型问题，而是采购逻辑、运维模式与供应链韧性的系统性变化。本文尝试从媒体视角梳理这条脉络：开放化到底开放了什么，标准化带来了哪些真实收益，又设置了哪些门槛。 一、从“专有盒子”到“开放规范”：这条路线

导语 数据中心正在变得越来越像一座“无人化工厂”：服务器密度持续上升，单机柜功率不断抬高，运维窗口被压缩到分钟级，而熟练的现场工程师却越来越难招、越来越贵。在这样的背景下，“用机器人替代部分人力”从概念演示逐渐走向真实机房。但如果把镜头拉近，会发现这条路径远没有宣传片里那样顺滑——巡检、搬运、自动化运维、数字孪生，各自处在完全不同的成熟阶段。 一、先厘清：数据中心里的“机器人”其实是四类东西 讨论“运维机器人走到哪一步”，首先要避免把不同技术混为一谈。依据行业公开的普遍分类，数据中心场景中的“机器人化”大致可以分为四条线： 巡检机器人 ：沿通道移动，采集温湿度、噪音、指示灯状态、局部热成像等数据，替代人工“抄表式”巡检。 搬运机器人 ：在仓储与机房之间运输服务器、硬盘、备件、电池等重物，替代人工搬运和部分物流调

导语 在企业存储的讨论中，“文件系统”常常被当成一个底层到不值得讨论的细节。但真正做过存储选型的人都知道，文件系统决定了数据如何落盘、如何校验、如何快照、如何扩容，也决定了故障发生时你手里还剩多少牌。XFS、ZFS、Btrfs 以及各类分布式文件系统，并不是同一层面的竞品，把它们放在一张选型表里比较，本身就是一种误读。本文尝试从媒体视角梳理这几类技术的分工逻辑，以及不同业务场景下的选型思路。 先厘清一个前提：它们不在同一层 XFS、ZFS、Btrfs 属于本地文件系统，运行在单机或单节点之上，直接管理块设备。分布式文件系统则工作在更高一层，通常把多台机器的本地存储聚合成一个逻辑命名空间，向上提供共享访问能力。 这意味着一个常见的架构事实：分布式存储的底层节点，往往仍然跑着某种本地文件系统。也就是说，这两类技术不

当企业把越来越多的核心业务、敏感数据和关键算法托付给芯片时，“这颗芯片安全吗”正在从工程问题变成采购问题。安全启动、可信执行环境、侧信道防护、硬件木马与供应链安全，共同构成了企业级芯片的安全底座。 导语：芯片安全，正在从“技术细节”变成“采购门槛” 过去，企业采购服务器、终端或边缘设备时，关注点大多集中在性能、功耗、生态和价格。芯片安全往往被归入“技术团队后续再评估”的范畴。 但随着数据合规要求提升、关键业务上云、AI 模型成为核心资产，芯片作为所有计算行为的物理起点，其安全性开始直接影响企业的风险敞口。一颗芯片是否具备可信的启动链路、是否支持隔离的执行环境、是否在设计阶段考虑了侧信道攻击，正在成为企业采购决策中不可回避的问题。 依据现有素材判断，企业级芯片安全可以从五个层面理解：安全启动、可信执行环境、侧信道

导语：在数据中心内部，铜缆与光缆的边界正在被重新划定。一边是 800G、1.6T 光模块加速上量，CPO（共封装光学）被反复讨论；另一边是有源铜缆（AEC）在机柜间和短距互联场景中重新获得关注。所谓“光进铜退”，并不是一条单向直线，而是一场由距离、速率、功耗和成本共同决定的动态博弈。 一、“光进铜退”不是一个开关，而是一条边界 讨论数据中心互联时，最容易出现的误区，是把“光”和“铜”当成非此即彼的两代技术。实际上，二者长期共存，只是分工不同。 传统上，机柜内部、服务器到交换机之间的极短距离连接，大量依赖铜缆和背板走线；机柜之间、列之间以及更远距离的连接，则更多由光模块加光纤承担。原因并不复杂：铜缆在短距、低成本、低功耗场景下仍有优势，而光缆在带宽距离积、抗电磁干扰和长距传输上更胜一筹。 因此，“光进铜退”更准确

在多数人的直觉里，存储扩容无非是“加盘、加柜、加节点”。但真正在企业生产环境里做过扩容的工程师都知道，这是一场牵动容量、性能、数据分布、业务连续性和预算的综合博弈。本文从纵向与横向两条路径出发，梳理数据重平衡、性能衰减、停机窗口与容量规划等关键问题，并对比分布式与集中式存储在扩容上的差异与风险。 一、扩容不是“加容量”，而是“改结构” 企业级存储的扩容，表面上是容量数字的变化，实质上是系统内部结构的调整。 当一套存储系统从“够用”走向“不够用”，管理员面对的从来不是简单的加法题。新增的磁盘、节点或存储柜，需要被纳入原有的数据分布体系、元数据管理体系和数据保护体系。数据要重新分布，副本要重新对齐，校验要重新计算，缓存与索引要重新适配。任何一个环节处理不当，扩容带来的可能不是性能提升，而是新的瓶颈。 这也是为什么很

当算力成为显性指标，数据准备仍是训练流水线上最容易被低估的隐性成本。 在大模型训练动辄调用成千上万张 GPU 的今天，行业讨论的焦点往往集中在算力规模、集群互联和训练框架上。但真正参与过模型训练一线的工程师大多有一个共识： 训练任务真正卡住的地方，常常不是 GPU 不够快，而是数据没准备好。 从原始数据采集到最终喂给模型的张量，中间横亘着采集、清洗、标注、格式转换、加载与预处理等一长串环节。这条链路看似“脏活累活”，却直接决定了 GPU 的有效利用率。 一、被低估的“数据准备”链路 在典型的 LLM 或多模态训练流程中，数据准备通常包含以下几个阶段： 数据采集 ：从网页、书籍、代码仓库、日志、传感器、业务系统等来源获取原始数据。 数据清洗 ：去重、去噪、过滤低质量内容、剔除有害或违规样本、统一编码。 数据标注

导语 过去几年，企业级服务器的算力构成正在发生结构性变化。以 CPU 为唯一核心的传统架构，逐渐让位于 CPU 与 GPU、FPGA、DPU 等多种计算单元并存的异构形态。这一趋势在 AI 训练与推理、实时数据分析、网络与存储卸载等场景中表现得尤为明显。然而，从“能买到异构服务器”到“能把异构算力真正用起来”，企业之间仍横亘着一道不小的鸿沟。本文尝试从协同、编程模型、调度与资源管理、软件栈碎片化以及实际采纳节奏几个维度，梳理异构计算在企业落地过程中遇到的现实难题。 一、异构协同：四种计算单元的定位与边界 在讨论落地难题之前，有必要先厘清 CPU、GPU、FPGA、DPU 在企业级服务器中各自承担的角色。 CPU 依然是系统的控制中枢，负责通用逻辑、操作系统调度、I/O 协调以及大量分支密集型任务。它的优势在于通