信息通信业2023：算力调度与网络软化的工程实践

1. 从一场行业论坛标题里，我读出了什么

拿到“2023中国信息通信业发展论坛”这个标题的时候，我第一反应不是去看议程表，而是先拆词。信息通信业，这五个字覆盖的范围其实非常宽——从底层的传输网络、数据中心，到中间的云平台、算力调度，再到上层的各类数字化应用，全都装得进去。而“发展论坛”这四个字，意味着它不是一个纯技术评审会，而是一个把技术趋势、产业格局、政策风向揉在一起讲的场合。至于后面挂着的“国研政情·经济信息研究智库”，则进一步说明了这场论坛的定位：它带有研究机构的视角，关注的是信息通信业在整个经济信息大盘子里的位置和作用。

我之所以对这个标题感兴趣，是因为过去几年我一直在做企业数字化基础设施相关的项目，跟通信运营商、设备商、云服务商都打过交道。这个圈子里的人有一个共同特点：技术细节聊得很深，但一旦上升到“产业往哪走”“钱往哪投”“哪些能力是未来三年的刚需”这类问题，很多人就说不清楚了。而这类论坛，恰恰是补齐这块认知短板的好地方。它把做技术的人、做规划的人、做投资的人放在同一个房间里，逼着大家用同一种语言讨论问题。

所以这篇博文，我想做的事情很具体：把这个标题背后涉及的几个核心议题拆开，讲清楚信息通信业在2023年前后到底在关注什么、为什么关注这些、以及一个从业者能从中学到什么可以直接用到自己项目里的东西。不管你是做网络运维的、做云平台的、做行业解决方案的，还是单纯想了解这个行业在往哪个方向走，下面这些内容应该都能给你一些参考。我不会去复述某场演讲的具体内容，而是基于这个标题所指向的领域，结合我自己的项目经验，把里面最值得琢磨的几个点讲透。

2. 信息通信业的核心议题拆解

2.1 为什么“算力”成了绕不开的关键词

2023年这个时间节点很特殊。在此之前，信息通信业的讨论重心更多集中在“连接”上——5G覆盖了多少、带宽提升了多少、时延降到了多少。但到了2023年，你会发现几乎所有跟这个行业沾边的论坛，话题都往“算力”上偏。这不是跟风，而是有实实在在的产业逻辑在背后。

我自己的理解是，连接的价值正在从“通道”变成“底座”。以前大家觉得网络就是把数据从A搬到B，搬得快、搬得稳就行。但现在大量的业务场景——比如工业质检的视觉推理、城市交通的实时调度、甚至是一些内容生成类的应用——它们对计算资源的需求是爆发式的，而且这些计算不能全都放在远端的数据中心里做，必须有一部分下沉到离业务更近的地方。这就带来了一个很现实的问题：算力怎么分布、怎么调度、怎么让需要它的业务真正用得上。

我在一个制造业客户的现场就遇到过这个问题的典型版本。他们工厂里部署了几十路高清摄像头做产品表面缺陷检测，一开始的方案是把视频流全部回传到总部的机房做推理，结果网络带宽吃紧不说，推理结果的回传延迟也让产线节拍对不上。后来改成在厂区本地部署边缘计算节点，只把告警和统计结果上传，带宽压力降了七成以上，响应时间也从秒级压到了百毫秒以内。这个案例让我特别深刻地体会到，算力这件事不是单纯堆服务器，而是要在“云、边、端”之间做合理的分配。

论坛上讨论算力，本质上讨论的就是这种分配的艺术。哪些计算适合集中做，哪些必须分散做，中间的调度层怎么设计，不同厂商的设备怎么互通，这些都是实打实的技术问题。而且这里面还牵扯到一个容易被忽略的点：算力的“计量”和“交易”。当算力变成一种可以像水电一样被调度和计费的资源时，它的度量标准、结算机制、服务质量保障就都成了需要解决的问题。这也是为什么这类论坛上，除了技术专家，还会有研究机构和产业规划方面的人参与——因为这不只是技术问题，还涉及到整个产业怎么协同。

2.2 网络架构的“软化”到底走到了哪一步

信息通信业另一个持续被讨论的话题是网络架构的演进。传统通信网络的特点是“硬”——专用设备、专用协议、专用管理界面，一套设备干一件事，稳定但不够灵活。这些年行业一直在推的方向是“软化”，也就是把网络功能从专用硬件上解耦出来，用通用服务器加软件的方式来实现。

这个趋势在2023年的语境下已经有了不少落地案例，但离全面普及还有距离。我在几个省级的城域网改造项目里看到的情况是，核心层的软化推进得相对顺利，因为核心层设备数量少、可控性强，软件化之后带来的弹性扩容和快速迭代优势很明显。但到了接入层和边缘层，问题就复杂了——设备数量多、部署环境差异大、运维力量参差不齐，软化的成本收益比就没那么好看。

这里面的核心矛盾在于：软化带来的灵活性，需要一套强大的编排管理系统来支撑，否则就是一堆散落的软件模块，运维复杂度反而更高。我见过一个项目，把某个网络功能做了软件化改造，结果因为编排层没跟上，每次业务开通还是要人工登录到不同节点上敲命令，效率比原来用专用设备还低。这个教训说明，网络软化不是把硬件换成软件就完事了，编排和管理能力的配套才是决定成败的关键。

论坛上讨论这个话题的价值在于，它把不同厂商、不同运营主体在实践中遇到的问题摆到了一起。你会发现，凡是软化做得比较顺的项目，都是在编排系统上下了大功夫的；而那些推进困难的，往往是把注意力全放在了单个网元的功能实现上，忽略了整体协同。这个经验对于任何做基础设施改造的团队都适用：不要只盯着单点技术指标，要看整个系统的协同效率。

2.3 行业应用从“样板间”到“商品房”的距离

信息通信业这些年一直在讲“赋能千行百业”，各类论坛上也从来不缺漂亮的案例展示。但我在实际项目中的感受是，从演示环境到规模化落地，中间隔着的距离比很多人想象的要大。

演示环境的特点是：需求明确、边界清晰、资源充足、容错率高。而真实的生产环境恰恰相反：需求模糊且多变、系统边界交错、资源预算有限、一次故障就可能造成实际损失。我在一个港口做智能调度项目的时候就深有体会。演示阶段，我们用一个标准化的堆场模型跑得很顺，但到了实际现场，发现堆场的作业规则有大量“例外情况”——有些箱区因为历史原因有特殊的堆放限制，有些作业流程因为人员习惯形成了不成文的规定。这些细节在演示环境里根本不存在，但在真实环境里，它们决定了系统能不能被现场人员接受。

所以论坛上讨论行业应用，真正有价值的部分不是那些光鲜的案例展示，而是关于“落地方法论”的交流。比如怎么做需求调研才能挖出那些没说出口的约束条件，怎么设计系统架构才能在不推翻重来的前提下适应需求变化，怎么跟现场人员协作才能让新系统真正被用起来。这些经验往往不会写在产品手册里，但却是决定项目成败的关键。

我自己的做法是，在任何行业应用项目启动之前，先花足够的时间做“现场沉浸”——不是坐在会议室里听汇报，而是跟着一线人员上工、观察他们的实际操作、记录他们遇到的麻烦。这个过程中获得的认知，比任何需求文档都更接近真实。论坛上如果有关于这方面的方法论分享，那才是真正值得听的部分。

3. 从论坛议题到落地实践的关键环节

3.1 算力调度方案的选型逻辑

如果你所在的项目需要做算力资源的调度和分配，2023年前后的技术选型空间已经比前几年宽了很多。但选择多了，选错的代价也大了。我梳理一下自己在几个项目里积累的判断逻辑，供你参考。

首先要区分的是“调度粒度”。如果你的业务是相对粗粒度的——比如一批虚拟机或容器需要分配到不同的物理节点上——那用成熟的容器编排平台或者云管平台就足够了，没必要自己造轮子。但如果你需要做的是细粒度的算力调度，比如把一个大模型推理任务拆成多个子任务分配到不同的加速卡上，那就需要更底层的调度框架，甚至要考虑任务之间的数据依赖和通信开销。

其次要考虑的是“调度范围”。是只在单个数据中心内部调度，还是要跨数据中心、跨云环境调度？前者相对简单，后者就涉及到网络带宽、数据一致性、安全边界等一系列额外问题。我在一个跨区域的项目里就吃过亏：一开始只考虑了计算资源的调度算法，忽略了跨区域数据传输的延迟和成本，结果调度策略在纸面上很优，实际跑起来因为数据搬运的开销太大，整体效率反而不如就近处理。

还有一个容易被忽略的维度是“调度目标”。是为了最大化资源利用率，还是为了最小化任务完成时间，还是为了满足某些服务质量约束？不同的目标会导致完全不同的调度策略。我在实际项目中的经验是，大多数场景下不需要追求单一指标的极致优化，而是要找到一个平衡点。比如在保证关键业务响应时间的前提下，尽量提升整体利用率，这个思路比单纯追求利用率最大化要稳妥得多。

下面这张表是我在选型时常用的一个对照框架，把几种常见方案的特点列出来，方便快速定位：

选型的时候，我建议先把业务的调度需求写成几条明确的约束条件，然后拿这些条件去套上面的框架，看哪个方案能满足大部分约束、剩下的部分是否可以通过二次开发补上。不要一上来就追求“最先进”的方案，适合自己业务节奏的才是好方案。

3.2 网络软化改造的实操路径

网络软化这件事，我在不同规模的项目里做过几轮，总结下来一个比较稳妥的推进路径是“先外围后核心、先管理面后数据面”。

先外围后核心的意思是，不要一上来就动核心网元，而是从相对边缘、影响面小的部分开始。比如先把网络的管理和监控功能做软件化，这部分即使出问题，影响的是运维效率而不是业务连续性，风险可控。等团队对软件化环境的运维流程熟悉了，再逐步推进到业务面。

先管理面后数据面也是类似的逻辑。管理面的软化主要涉及配置下发、状态采集、告警处理这些功能，对实时性要求相对低，技术栈也比较通用。数据面的软化对性能要求高得多，需要处理高速数据包的转发，对软件优化和硬件加速的依赖都很强。先把管理面做扎实，积累经验，再攻数据面，成功的概率会高很多。

具体到技术实现上，有几个点是我踩过坑之后特别想提醒的。第一是性能测试一定要做足，而且要在接近真实的流量模型下测。我见过一个项目，实验室里用固定包长的流量测出来性能达标，上线后遇到真实业务那种大小包混合、突发流量频繁的场景，性能直接掉了一半。第二是回退方案必须提前准备好，软件化改造涉及的面比较广，一旦某个环节出问题，要能快速切回原来的方案，不能把业务晾在那里。第三是运维团队的能力建设要同步跟上，软件化之后，运维人员需要理解的不再是单一设备的操作界面，而是整个软件栈的协作关系，这个转变需要时间和培训投入。

3.3 行业应用落地的需求挖掘方法

前面提到行业应用从演示到落地有距离，那怎么缩短这个距离？我的核心方法是“三层需求挖掘”。

第一层是“说出来的需求”。这是客户在需求文档里明确写出来的，比如“系统要能支持多少路视频接入”“告警要在多少秒内推送”。这些需求重要，但远远不够。

第二层是“做出来的需求”。这需要你到现场去观察，看一线人员实际是怎么操作的。很多时候，他们嘴上说的流程和实际做的流程并不一致，而实际流程里藏着大量系统设计需要适配的细节。我在一个仓储项目里发现，系统设计的拣货路径和工人实际走的路径差别很大，原因是工人会根据货架的实时拥堵情况临时调整路线，这个信息在需求文档里完全没有体现。

第三层是“说不出来的需求”。这是最难挖的，因为它涉及到用户的习惯、心理和组织的隐性规则。比如现场人员可能对某个操作界面有强烈的偏好，原因仅仅是“用惯了”，这种偏好如果不被尊重，再先进的系统也会被抵触。挖掘这一层需求，靠的是长时间的相处和信任建立，没有捷径。

这三层需求挖下来，你会发现真正需要写进系统设计的东西，比最初的需求文档要多出好几倍。但正是这些多出来的部分，决定了系统上线后是被真正使用还是被搁置。我在项目中的做法是，把三层需求的挖掘结果整理成一份“落地约束清单”，在每次设计评审的时候拿出来对照，确保没有遗漏关键约束。

4. 实操中容易踩的坑与排查思路

4.1 算力资源利用率上不去的排查路径

算力资源利用率低是很多项目上线后的常见问题。表面上看是资源没被充分使用，但根因可能分布在好几个层面。我一般按下面的顺序排查。

先看调度层。调度策略是不是过于保守？比如为了保证服务质量，给每个任务都预留了大量资源，导致实际使用率很低。这种情况需要重新评估服务质量约束的合理性，看能不能用更精细的资源隔离手段来替代粗放的预留。

再看应用层。应用本身的资源使用模式是不是和调度假设不匹配？比如调度系统假设任务是短时突发型的，但实际应用是长时稳定型的，那调度策略就需要调整。我在一个项目里发现，某个批处理应用的资源申请量是实际使用量的三倍，原因是开发人员为了“保险”把申请值调高了，这种问题只能通过实际监控数据来发现和纠正。

最后看基础设施层。是不是存在资源碎片化的问题？比如物理机上剩余的资源总量够，但分散在不同的节点上，无法满足单个任务的资源需求。这种情况需要考虑资源池的整合或者调度粒度的调整。

排查的时候，监控数据的粒度很关键。如果只看到集群级别的平均利用率，很多问题会被掩盖。我建议至少做到节点级别的资源使用监控，有条件的话做到任务级别的资源使用追踪，这样才能定位到具体的浪费点。

4.2 网络软化后性能不达预期的常见原因

网络功能软件化之后性能不达预期，我遇到过好几次，原因大致可以归为几类。

最常见的是数据面优化不足。通用服务器处理网络数据包，如果没有做针对性的优化——比如使用高性能的数据面开发套件、合理配置大页内存、优化中断处理方式——性能会差很多。这个问题的排查方法是做逐层压测，从最简单的转发场景开始，逐步增加功能复杂度，看性能在哪一层出现明显下降。

第二常见的是虚拟化开销。如果软件化后的网络功能跑在虚拟化环境里，虚拟交换机的开销可能成为瓶颈。这时候需要考虑是否使用硬件辅助虚拟化技术，或者调整虚拟交换机的配置参数。

第三是配置参数不匹配。软件化的网络功能通常有大量可调参数，默认值往往是为了通用性而设置的，不一定适合你的具体场景。比如队列深度、缓冲区大小、轮询模式这些参数，需要根据实际流量特征来调整。我在一个项目里把某个转发模块的批处理参数从默认值调整到适合当前流量模型的值之后，吞吐量提升了将近四成。

排查这类问题，我的经验是不要一上来就怀疑架构设计，先把配置层面的问题排除掉。很多时候性能问题就出在几个关键参数的设置上，调整之后就能解决大部分问题。

4.3 行业应用推广受阻的应对策略

系统上线了但用不起来，这是行业应用最让人头疼的问题。我遇到过几次，总结下来应对策略分三步。

第一步是找到“关键少数”。任何组织里都有那么几个人，他们对新事物接受度高、在同事中有影响力。先把这些人争取过来，让他们成为系统的早期使用者和传播者，比自上而下地推要有效得多。我在一个项目中，先说服了班组里最资深的一位老师傅试用新系统，他发现系统确实能减少他的重复劳动之后，主动帮我们向其他工友解释，推广阻力一下子就小了很多。

第二步是设计“最小可用路径”。不要指望用户一上来就用全部功能，而是设计一条最短的、能解决他们最痛问题的使用路径，让他们在几分钟内就能感受到价值。比如一个巡检系统，最痛的点可能是“不用再手写巡检记录了”，那就把这个功能做到极致简单，其他功能慢慢引导。

第三步是建立反馈闭环。用户提出的问题要能被快速响应和解决，哪怕只是告诉他们“这个问题我们记下了，下个版本会改”。这种响应本身就是在建立信任。我见过一些项目，系统功能其实不错，但因为用户反馈石沉大海，最后没人愿意再用。技术问题可以慢慢解，信任问题一旦丢了就很难挽回。

4.4 常见问题速查表

下面这张表是我在实际项目中整理的高频问题对照，方便快速定位方向：

这张表不是万能的，但它能帮你快速缩小排查范围。实际项目中，问题的根因往往是多个因素叠加的，需要结合具体场景做判断。

5. 我个人的几点实操体会

做信息通信相关的项目这些年，有一个体会越来越深：技术方案的优劣，很多时候不取决于技术本身有多先进，而取决于它和实际场景的匹配程度。一个在实验室里跑分很高的方案，到了现场可能因为一个不起眼的约束条件就完全失效。所以我现在做任何方案设计，都会先问自己一个问题：这个方案在最不理想的现场条件下，还能不能跑起来？如果答案是否定的，那就需要准备降级方案。

另一个体会是关于“标准”和“现实”的差距。信息通信业是一个标准化程度很高的行业，各种接口规范、协议标准非常完善。但在实际项目中，你总会遇到设备厂商对标准的理解有偏差、实现有差异的情况。这时候不能指望标准来解决问题，而是要在工程层面做兼容性设计。我的做法是在系统架构里预留适配层，把可能变化的接口封装起来，这样即使某个厂商的实现有出入，也只需要调整适配层，不影响整体架构。

还有一个是关于团队能力建设的。信息通信业的技术栈更新很快，今天熟悉的工具明天可能就被新的替代了。但有些能力是相对稳定的，比如对网络协议的理解、对系统性能的分析方法、对需求本质的把握能力。我在带团队的时候，会有意识地把这些稳定能力和具体工具的使用分开，让团队成员在掌握具体工具的同时，也建立起不依赖特定工具的底层认知。这样即使技术栈变了，团队的核心能力还在。

最后说一个很小的点，但我觉得挺重要：文档和记录的习惯。信息通信项目涉及的系统多、环节多，很多问题的排查依赖于对历史状态的了解。我在每个项目里都会坚持做两件事：一是把关键决策的背景和理由记录下来，二是把每次故障排查的过程和结论整理成可检索的条目。这两件事在当下看起来费时间，但在后续的维护和交接中能省下大量沟通成本。我见过太多项目因为关键人员变动导致知识断层，最后不得不从头摸索。这个坑，能避就避。