095 目录 黄大年茶思屋“难题揭榜” 第 95 期 -- 云核心网领域第三期 完整技术难题逐条整理

难题 1：面向网络流量的预训练大模型技术

一、技术背景

1. 5G 覆盖 eMBB、URLLC、mMTC 三大场景，5G 核心网作为移动网络控制中枢，需提升智能化水平适配人车物差异化连接需求。

2. 5G 核心网智能化催生网络 AI 技术（应用识别、体验评估、质差分析等），现有 AI 模型存在开发难度大、成本高、泛化差问题：依赖高质量标注数据，数据量不足、分布不均会大幅削弱模型泛化能力。

3. 预训练模型依托自监督学习，从无标注样本学习可迁移参数，微调适配下游任务，已在 NLP、计算机视觉广泛落地。

4. 目标：构建面向网络流量的预训练网络大模型，统一整合各类网络 AI 任务，依托海量流量训练数据，提升多任务性能与泛化能力。

二、技术挑战

1. 统一序列表达：设计适配网络流量的 Tokenizer 与 Embedding 方案；网络流量层级结构复杂，包含用户、流、突发、报文、协议字段多层关联关系。

2. 高效模型架构：适配网络流量的基础模型、多任务模型结构选型与设计。

3. 高效优化目标：设计面向流量样本的预训练、微调任务；模型充分挖掘流量样本信息，实现快速、低成本学习。

三、当前结果

1. 应用感知小模型：TOP300 应用识别、8 大类应用独立同分布场景效果优，识别准确率＞90%；流量变化场景准确率平均下降 20%，最差下降 80%，重度依赖标注拨测数据，泛化能力弱。

2. 体验评估小模型：准确率受网络、应用行为影响大；正常网络下直播 / 点播 / 短视频 3 大类 13 个 APP 清晰度、卡顿指标准确率＞90%；弱网、拥塞场景准确率下降 20%；不同应用传输协议、流量模式差异大，需逐场景定制模型。

3. 面向网络流量预训练大模型：暂未落地成熟方案。

四、技术诉求

1. 能力要求：设计适配流量数据的序列化表达、模型架构、预训练任务；微调支撑 3 类下游任务（TOP300 应用识别、8 大类识别、3 大类 13 个 APP 清晰度 / 卡顿评估），华为自研数据集准确率≥95%。

2. 泛化性：预训练模型可快速适配流量、网络状态变化；对比随机森林、MLP 等传统模型，同等准确率下标注数据需求降低至原 10%。

参考文献

[1] ET-BERT: A Contextualized Datagram Representation with Pre-training Transformers for Encrypted Traffic Classification. In WWW 2022 [2] NetGPT: Generative Pretrained Transformer for Network Traffic. In arxiv 2023

难题 2：高性能、适用于 NPU 硬件的 Training-free 大模型剪枝算法

一、技术背景

1. 大模型参数量持续膨胀，推理算力需求激增；云核场景要求低成本、高性能，需在端侧有限算力部署百亿参数大模型，小型化剪枝是降推理成本、实现端侧部署、提升推理性能的核心突破方向。

2. 传统剪枝两大缺陷：剪枝后重训练周期长达数周、成本高；大模型受离群值影响精度损失显著，压缩比例越高精度衰减越严重。

3. 业界方案 SparseGPT 在 GPU 效果良好，但非结构化 / 2:4 半结构化剪枝思路无法在 NPU 实现推理加速；310P 算力仅 70TFLOPS，为 910B 的 1/4，无硬件加速则无法满足云核心网极致推理诉求。

4. 剪枝后稀疏模型微调周期长、调优成本高。

二、技术挑战

研发可商用 NPU 侧大模型无训练剪枝算法，支撑云核心网场景大模型 NPU 离线剪枝，可对 Llama-2-70B 实现 30%/50% 剪枝，满足两类指标：

1. 剪枝 30% 参数量，无需重训练，多测评集平均推理精度劣化＜2%；

2. 剪枝 50% 参数量，剪枝后小时级重训练，多测评集平均推理精度劣化＜2%。

3. 实现 30% 以上推理速度增益，匹配云业务极致性能需求。

三、当前结果

现有 SparseGPT 剪枝方案存在两处短板：

1. NPU 原生不支持该算法，迁移需改造 MindSpore、CANN 适配；

2. 半结构化剪枝架构在达芬奇硬件无计算加速收益。

四、技术诉求

1. 验证链路：算法 / 算子方案→开源数据集（MMLU、GSM8K、HumanEval、Math-500）验证→华为自有数据集验证→全量数据集落地，达成全部指标： （1）精度约束：剪枝率 30% 无重训练，全场景推理精度劣化＜0.5%；剪枝率 50%，推理指标劣化＜1%。 （2）性能约束：剪枝后充分利用 NPU 硬件加速，降低显存占用，计算速度提升 30% 以上。

难题 3：低时延无障碍原声传译技术

一、技术背景

1. 5G 核心网升级后，通话网络拓展超清、AI、交互能力；网侧引入 AI 无需终端升级，即可提供创新业务，无障碍通话为核心能力：通话中 AIGC 生成对端语言音频，实时传译同时保留原说话人语气、情绪、停顿、音色，兼顾语义准确与自然度。

2. 整体技术链路分为三阶段：原声 Encoder 网络预训练、T2A 音频生成网络预训练、A2A 原声传译微调。

二、技术挑战

1. 时延约束：传统分段转写 + 翻译链路时延极高，无法实时传译；需流式输出，大幅压低端到端时延同时保障语义准确。

2. 数据约束：A2A 原声传译数据质量标准极高，大规模采集难度大，仅少量样本可微调；无法直接搭建端到端网络，需分段构建；T2A/A2T 数据依赖翻译、ASR 工具合成，合成数据清洗校准难度大。

三、当前结果

1. T2A 特征注入：仅完成音色克隆可行性验证，语气、情绪、停顿维度未验证；

2. 数据储备：拥有海量无标注音频数据；

3. 现有能力：翻译中心具备 ASR + 翻译能力，但仅适配同声传译场景，基线时延 1.6s、中英 BLEU23.8；无障碍原声传译在时延、语音自然度存在明显短板，需深度升级。

四、技术诉求

1. 基础指标：语义 BLEU＞25；语音自然度 SMOS＞4.0；端到端时延＜1s；仅支持中英互译。

2. 挑战指标：语义 BLEU＞35；语音自然度 SMOS＞4.5；端到端时延＜300ms；语句语义分割精度≥98%；音色 / 风格 / 韵律相似度余弦相似度＞0.8；支持中英日韩等 20 + 语种。

参考文献

[1] https://arxiv.org/pdf/2305.17547.pdf [2] [2106.07447] HuBERT: Self-Supervised Speech Representation Learning by Masked Prediction of Hidden Units [3] https://aclanthology.org/2020.acl-main.58.pdf [4] [2006.04558] FastSpeech 2: Fast and High-Quality End-to-End Text to Speech [5] https://github.com/keonlee9420/STYLER

难题 4：电信网络异构 (多模态) 语料关联编码技术

一、技术背景

1. 运维领域包含 KPI、信令、配置等多源数据，支撑故障定位；现有核心网知识、运维数据无统一编码方案，无法识别数据内在关联，不能联动分析，故障边界无法精准界定。

2. 整体技术架构：多类原始数据独立预处理后输入多模态多任务大模型，结合业务知识库 Prompt 指导数据分析，输出多类故障分析任务结果。

3. 数据类型覆盖：时序指标 Perf、告警序列 Alarm、运行日志 Debuglog、半结构化信令 MML、信令序列 CHR、产品文档、3GPP 协议文档、网络流量时序数据，分别适配运维 / 网络大模型。

二、技术挑战

1. 多模态数据种类繁杂，预处理难度高；网络拓扑、设备配置、VoNR/VoLTE 业务知识等非结构化语料缺少统一编码技术。

2. 多模态数据强关联、存在因果依赖，需要融合知识与数据混合编码，实现知识、数据精准关联对齐。

三、当前结果

仅信令数据实现流程 - 消息 - 信元三层编码；MML、KPI 等其余单模态数据无成熟编码方案，无法开展多源运维数据联动分析、异常识别。

四、技术诉求

研发异构多模态数据关联编码技术，实现多模态数据语义对齐、复杂故障边界判定；基于华为自有数据集，异常识别准确率≥99%，覆盖两类异常：

1. 数据表征异常：指标零值、突增突降；

2. 关联关系异常：会话数远小于用户数等链路异常。

难题 5：三方 CaaS 下 CloudOS 存储 Bypass 关键技术

一、技术背景

1. 存储 Bypass 定义：后端存储故障时，虚拟机及业务可稳定运行一段周期（平台层最长 24h，网元层最长 4h）；实时检测存储状态，故障时业务、最小维护通道与存储解耦持续运行。

2. 原生 CloudOS 缺陷：虚拟机场景强依赖远端存储，底层存储故障会导致上层容器卡死、业务中断；现有定制化内存启动方案可实现存储解耦，但存在侵入式修改 CloudOS 的缺陷。

3. 架构说明：虚拟机分为华为自有业务容器、第三方平台容器；底层依赖 HOSTOS、OpenStack、Qemu/KVM，数据持久化依托远端 SAN / 分布式存储，本地磁盘仅做辅助。

二、技术挑战

1. 原生三方 CaaS CloudOS（容器 OS+K8s Agents + 容器引擎）存储耦合度高，原生不具备故障 Bypass 能力。

2. 云原生三层解耦发布架构，虚拟机 CloudOS 由第三方提供，不支持侵入式底层修改。

三、当前结果

1. 远端存储故障场景，虚拟机 CloudOS 存在卡死现象，上层容器重启复位，业务无法平稳运行；主流 CaaS 平台无存储 Bypass 能力，仅华为电信云平台具备该能力。

2. 存储故障恢复后，容器访问远端存储权限异常（只读无法切换读写），业务无法恢复。

3. 现有可行方案：将 CloudOS 关键配置文件内存化；长期方案推动开源社区原生支持内存化。

四、技术诉求

虚拟机场景非侵入式上层插件技术，解除运行时存储依赖；存储故障时，CloudOS 全组件（容器 OS、K8s Agents、容器引擎）稳定运行，规避上层容器复位，指标约束：

1. 组件兼容：适配 RHCOS、Photon OS、SUSE 等通用 CloudOS；

2. 性能损耗：整体虚拟机性能劣化不超过 5%；

3. 故障约束：存储故障场景，K8s Agents、容器引擎惯性运行，上层容器无复位；存储故障恢复后容器不重启，持续读写访问。

整体补充说明

1. 全 5 道难题覆盖云核心网 AI 大模型、NPU 硬件加速、实时语音 AIGC、电信运维多模态编码、云平台存储高可用五大技术方向；

2. 每条完整保留：技术背景、核心挑战、当前落地瓶颈、量化技术指标、参考文献（如有），剔除全部对接专家、出题组织、联系方式、浏览互动数据、页面 UI 信息；

3. 所有量化精度、时延、算力、性能、时长、准确率指标完整保留无删减。