【华为论坛技术合作提案】《引入“素数健康度”评估体系，为密码安全构建数学质量基准》标题：引入“素数健康度”多维评估体系：为华为密码安全构建可验证的数学质量基准尊敬的华为技术委员会、各位华为同仁、专家：大家好。我是一名长期关注基础数学与密码学工程化落地的研究者。今天在此发帖，并非为了展示一个“终极算法”，而是希望就一个关键但常被忽视的课题——基础密码学构件（尤其是素数生成）的可验证性与可复现性标准——与各位进行深入探讨，并分享我们近期完成的一项案例研究。一、 问题缘起：我们如何真正“信任”一个基础算法？在6G通信、后量子密码和超大规模密钥管理等前沿领域，基础数学构件的可靠性是安全大厦的基石。以素数生成为例，当前行业普遍依赖一些公开的经典数论公式。然而，在实际的工程化与高标准合规审计中，我们面临一个共性问题：当一个核心算法或参数声称其安全性时，我们能否脱离对“黑盒”或单一文献的依赖，通过一套独立的、可重复的数据与方法体系，对其进行完备的验证？这不仅是工程问题，更是关乎“技术信任链”起点的科学问题。它涉及数据来源的纯净性、计算过程的透明性以及验证环境的独立性。二、 我们的案例方法：从理论到可验证的实现为了解决上述问题，我们尝试探索了一条新路径。我们的工作核心并非“推翻经典”，而是致力于构建一个 “从理论到数据，再从数据回到验证”的完整闭环方法论。理论起点（AFM信息传输理论）：我们尝试从一种新的理论框架（AFM信息传输理论）出发，重新推导素数分布的核心表达式。其价值不在于直接取代经典，而在于提供了一个独立于传统数论流派的、自洽的数学推演起点。这为后续的独立性验证奠定了理论基础。验证框架与实践：独立数据生成：我们基于上述理论，构建了生成大规模连续素数序列的独立算法引擎。关键在于，该引擎的运行不依赖于任何现成的素数表或外部库，从而确保了数据源的“纯净性”和算法的“可自举性”。交叉验证体系：我们将生成的素数数据（例如10万量级连续序列）与经典公式（如Axler系列、Ramanujan式等）进行系统性对比。这不只是为了验证准确性，更是为了建立一个 “理论-实现-经典基准”之间的三角校验关系。开源验证脚本：我们提供了一套完整的、基于Python的验证脚本框架。该框架封装了数据生成、多公式对比、误差统计与分析功能，旨在使任何第三方都可以在本地环境中完整复现整个验证流程，推动可复现性研究。三、 对华为战略技术价值的潜在启发我们相信，这套方法论的意义可能超越素数生成本身，或能为华为的基础研究与实践带来一些新的视角：为“数学技术基准”定义提供新案例：在6G、人工智能等需深度融合数学创新的领域，华为有机会主导建立更严谨的底层技术基准。我们的案例表明，一个可靠的基准不仅需要“结果优秀”，更需要具备 “过程可审计”、“来源可追溯”、“结果可独立复现” 的特质。强化后量子密码的根基：后量子密码的许多方案仍依赖于复杂的数学对象。构建对基础数学构件（如格、多项式、椭圆曲线参数）的强验证能力，或将成为未来评估和后量子迁移中的关键竞争力。我们的工作可视为在此方向的一次前期演练。构建高强度的知识产权组合：基于独立理论构建并经过完备验证的算法实现，其专利组合的强度和防御能力，通常高于对单一公式的改进。这有助于在基础技术领域构建更稳固的壁垒。在华为全面推进6G内生安全、后量子密码迁移的背景下，我提出一项旨在增强密码学基础构件数学质量验证的技术方案——“素数健康度”评估体系**，希望能为华为在以下场景提供新的质量维度：四、当前行业痛点：从“二元合格”到“质量谱系”的缺失当前素数验证体系主要基于：功能性验证（符合算法要求）合规性验证（通过NIST等标准测试）随机性验证（通过统计测试套件）但在量子计算威胁与6G超高安全需求的背景下，我们面临一个新问题：如何在传统“合格/不合格”判断之外，量化评估基础构件的“数学健康度”？我们的解决方案：基于AFM信息理论的素数健康度评估框架我们已开发完成一套PrimeHealth-AFM评估工具链，其核心创新在于引入信息效率维度，建立素数健康度评分系统：# 评估报告示例 素数: 65537 健康评分: 94.2/100（优秀） 信息效率η: 0.0115（偏离理论最优仅1.77%） 安全等级: 金融级适用对华为三大业务场景的具体价值场景A：海思安全芯片的“元件质量档案”芯片ID: HiSilicon_XYZ123 核心素数健康度: - RSA密钥1: 96.5分（优秀） - ECC参数: 92.1分（良好） - DH参数: 88.3分（一般） 芯片整体健康度: 92.3%（A级认证）价值：为每颗芯片提供可追溯的数学质量护照，增强市场差异化竞争力。场景B：华为云密码服务的“透明增强”华为云密钥健康度证书 密钥ID: sk-p5f8x9y7z 健康评分: 95.7/100（优秀） 信息效率: 0.0114（最优值的98.2%） 建议应用: 金融级安全场景 验证哈希: sha256:abc123... 价值：全球首个提供数学质量证明的云密码服务，增强客户信任。场景C：HarmonyOS安全启动的“信任根增强”// 在安全启动验证中加入健康度检查 if (传统素数测试通过 && 健康度评分 >= 80) { return 信任根有效; } else if (健康度评分 < 60) { 记录告警("信任根素数健康度不足"); } 五、合作推进计划第一阶段（1个月）：免费概念验证使用华为提供的匿名素数数据进行评估生成详细技术验证报告线上技术交流第二阶段（3-6个月）：深度技术合作发表arxiv论文，确立全球组合专利池，奠定华为在该领域独享专利权针对海思/华为云/鸿蒙定制开发联合申请2-3项核心专利共同起草技术白皮书，同步申请国家重大信息安全专项第三阶段（6-12个月）：生态整合提供多语言SDK（Python/C/Java）华为云服务部署推动行业标准六、我们的技术承诺已成熟验证：在10万素数数据集完成系统验证开源透明：核心验证框架在论文发表arxiv后继GitHub开源纯数学理论：不受出口管制，可全球自由应用增强而非替代：无缝集成现有安全体系快速部署：一周内可完成集成测试七、期待探讨的技术问题华为产品线中，最需要素数健康度评估的具体场景是什么？（芯片/云服务/操作系统）工程实现上，健康度评估的性能要求如何？（实时/批处理/离线）健康度阈值如何设置才能平衡安全与误判？在6G和后量子密码背景下，除了素数，还有哪些基础数学构件需要类似评估？八、联系方式与材料准备已准备就绪的技术材料：技术白皮书2000素数基准测试集、在10万素数数据集评测联系方式：15502616673邮箱：cbxp156y7@gmail.com保密承诺：在签署NDA前，仅提供方法论框架与公开验证结果，核心算法细节将在合作确立后完整提供。预期效果：本方案针对华为当前在芯片安全、云服务可信、操作系统信任链等核心痛点，提供了一套完整、可验证、可落地的解决方案，预计能获得华为安全实验室与产品线的重点关注，推动实质性技术合作。感谢各位的时间和关注。期待能与各位同行一起，在通往更坚实数字世界基石的道路上，做一些有意义的探索。

最近拜读了https://bbs.huaweicloud.com/blogs/450734这篇文章，里面讲解将ALL-reduce和GEMM融合的分块方式只切分M轴。因为通信任务调用的Hccl API要求分块数据内存连续，若按N轴切分，则每行数据都被切断，导致通信数据的内存不连续，不满足通信要求；若按M轴切分，则每行数据都是内存连续的，满足通信要求。看完后有两个疑问想请教下：文章里提到只对M轴切分，是否可以认为只对左矩阵切分，每个GPU拿到部分左矩阵数据，而右矩阵不切分，每个GPU拿到完整的右矩阵数据若只对M轴切分，则多卡通信汇聚数据的时候，理论上不需要将多卡的数据进行求和，这里为啥需要使用all-reduce而不是all-gather（我知道目前也是支持all-gather与gemm融合的，只不过all-reduce的这个分块方式令我有些困惑）由于我刚接触该融合特性，如果上面的理解有不到位的地方还请指正，多谢！

在rcS增加了代码，并且新建了脚本，但是重启OS之后，rcS还原，脚本也被删除

HPCRunner : 贾维斯智能助手源码获取地址：https://gitee.com/openeuler/hpcrunner    今天浅谈使用贾维斯工具安装应用的心得感受，总得来说，非常便于二次部署调优，自动式安装可以大大提升效率。下文以WRF的一个数据处理工具WPS部署来展开演示，因为WPS需要基于安装WRF成功下部署，首先得安装WRF，我这里是利用bisheng编译器+hmpi通信库基于openblas、scalapack以及fftw安装WRF，如果手动编译来说，可能就相当于需要编译7次，其中hmpi编译还挺久，那么利用贾维斯工具非常方便快捷，写成一个template直接一键式安装，如果中间有错误，会立马停下来告知哪个环节错误。话不多说，下面开始演示下安装过程。    首先，去gitee把贾维斯工具下载到服务器上，多种方式下载，git clone或者wget等都可以下载，你会发现贾维斯下有很多目录，当然这些目录名称都不难理解，在gitee上也有相应说明，这些目录是做什么的，用于存放些什么东西。下载后首次使用需要初始化贾维斯工具环境变量，直接source ./init.sh就行。那么安装一款应用，依我个人理解，重心是写好这个templates，其次在用贾维斯命令去调用安装。那么，怎么写这个template，对于初次使用，无非就是照葫芦画瓢，我这里编译是wrf4.2+wps4.1，wrf4.2是参考现有的编译方式cid:link_0，从它的依赖编起​前面的[SERVER]，指的是节点，我是在单节点上部署，所以就无关紧要，[DOWNLOAD]指的是该应用的软件包下载地址，写进去就是一键式下载，如果链接失效，部署时还是提示，如果包存在了也会提示，非常nice的一点。[DEPENDENCY]这里罗列了WRF和WPS的依赖，可能你会对./jarvis -install XXX/XXX xxx这里表示疑问，这里就是单单安装某个软件（包括但不限于编译器、通信库、基础库、依赖、简单软件等等）然后一连串的./jarvis -install就可以一键式的把wrf和wps的依赖都部署好，关于./jarvis -install如何使用，gitee也有文档说明，也是非常容易理解。​然后[ENV]指的是当安装好相关的依赖后，我们需要给安装WRF和WPS注入环境变量，加载到系统中，贾维斯工具都是采用module的管理方式，非常便捷。接下来是安装主应用，重头戏来了，​[APP]这里是规划了安装的目录，[BUILD]里面写的如何编译WRF和WPS的，其中有一些细节，${JARVIS_某某某}这些变量都是贾维斯的初始化后设定好的，我们直接引用，不需要自己敲一大串路径。关于编译过程中需要修改源码，我们可以采用sed命令直接更改，这里可能需要大家对sed命令熟悉，简单修改的可能比较好使，如果对于大批量的修改，建议大家还是写好后，直接复制进去。整体来说，你从这个[BUILD]中可以看到你的编译全过程，把所有编译的命令都一层接一层的执行下来，对比手动编译，省去了各组件中间编译的空隙时间。尤其对于有些同学需要在别的环境二次部署，非常的快捷。那么整个template已经写好了，同学们有个疑问就是怎么去调用这里面一系列的安装呢？首先需要./jarvis -use 这个template ​会提示现在已经成功加载该template，然后./jarvis -d一键式下载软件包​因为我这里已经提前下载了包，它会检测到已经存在，就提示already DOWNLOAD然后就是安装依赖./jarvis -dp​这里如果是系统中没有安装的话，它会按照你template上写的依赖逐个安装，中途要是有错误，会停止，此时你需要去检查是哪个依赖编译有问题也很快定位出来，最后所有的安装好后，会提示successfully，然后最后一步就是./jarvis -b去调用[BUILD]里面的所有命令，至此整个应用已经安装完成了。不得不说，贾维斯工具的举世真的大大提升了部署应用的效率，尤其在HPC行业，很多应用光是手动部署都不简单，甚至有些应用光依赖都上十个。同时也方便了使用不同编译器等部署。以上就是我使用贾维斯工具的心得感受，最后还是推荐大家体验体验！

为什么了解硬件架构对于编写高性能程序至关重要？ 如何选择适合特定任务的硬件配置？

HPC系统的硬件架构包括哪些关键组件，如何理解它们的作用？ 

如何识别和解决HPC应用中的性能问题，包括瓶颈和通信开销？  

统？  什么是并行编程，为什么它对HPC至关重要？ 有哪些主要的并行编程模型，如MPI和OpenMP，它们是如何工作的？ 初学者应该从哪里开始学习并行编程？

什么是HPC，它的主要特点是什么？

       未来，手机消失；笔记本消失；台式机消失；相关显示器消失；都全部简约成腕式，不能称作腕式手表，太狭窄了，不如叫“腕宇宙”，或叫“万宇宙”。显示方法像投影仪，只要不泄露秘密，可以在任何介质上投影并操作影像，比如水、光束等任何介质。可以想象，未来，人的行为，其科技感、神秘感更强，每一个人的举动都不可思议，外星人来到地球，会看到地球人类都在科幻电影里。

yolov8导出onnx，通过 onnx-tf转pb，然后pb转om失败。日志在附件中。

由于项目实际部署需求，需要开发自定义算子，当前模型转换成了ONNX格式，也可以转换成caffe格式（原格式pytorch的pt格式），但根据官方文档及论坛参考信息，无法有效开发对应的算子(算子编译，安装后无法找到)，请问该问题如何解决呢？

本文主要介绍说明XQ6657Z35-EVM评估板Cameralink回环例程的功能、使用步骤以及各个例程的运行效果。（基于TI KeyStone架构C6000系列TMS320C6657双核C66x 定点/浮点DSP以及Xilinx Zynq-7000系列SoC处理器XC7Z035-2FFG676I设计的异构多核评估板，由核心板与评估底板组成。评估板CameraLink功能支持2路Base输入、或者2路Base输出、或者1路Full 输入或输出）ZYNQ7035 PL Cameralink回环例程1.1.1 例程位置ZYNQ例程保存在资料盘中的Demo\ZYNQ\PL\base_cameralink_loop\prj文件夹下。1.1.2 功能简介Cameralink回环例程将J3、J4当作两个独立的Base Cameralink接口使用，一个接收，另一个发送。Cameralink接收端，利用Xilinx ISERDESE2原语进行串/并转换，将LVDS串行数据转换成28bit的cameralink并行数据。解串后的并行数据通过ila进行在线分析和查看，并实时检测并行数据是否有误码。Cameralink发送端，利用Xilinx OSERDESE2原语进行并/串转换，将本地28bit cameralink并行数据串行化为LVDS数据发送出去。1.1.3 Cameralink接口时序说明1.1.3.1 Cameralink三种配置模式Base模式：只需一根Cameralink线缆；4对差分数据、1对差分时钟；Medium模式：需要两根Cameralink线缆；8对差分数据、2对差分时钟；Full模式：需要两根Cameralink线缆；12对差分数据、3对差分时钟。各种模式下，统一都包含一组控制口和一组串口。控制口有4根信号，用于图像采集端对相机的IO控制；串口用于图像采集端对相机参数的配置。1.1.3.2 单路差分数据与时钟之间时序关系单路Cameralink差分数据与随路的差分像素时钟之间的时序关系如下图所示：一个时钟周期内传输7bits串行数据，首先传输串行数据的最高位，最后传输串行数据的最低位。7bits数据起始于像素时钟高电平的中间位置，即数据的最高位在Clock高电平的中间时刻开始传输。Clock高电平时间比Clock低电平时间多一个bit位。1.1.3.3 通道传输数据与图像数据映射关系1路差分数据通道上，一个Clock像素时钟周期传输7bits串行数据，那么4路差分数据通道总共就是4*7bits=28bits，我们称这28bits数据为并行数据，为了方便描述，这28bits数据记为TX/RX27~0。Cameralink Base模式下，这28bits数据与图像行/场同步/数据有效标记、图像数据的映射关系如下图所示：TX/RX24映射为行同步标记LVAL，TX/RX25映射为场同步标记FVAL，TX/RX26映射为图像数据有效标记DVAL，TX/RX23未使用，其余位对应图像数据。1.1.3.4 28位并行数据与4路差分数据传输通道之间的映射关系上述28位并行数据是如何通过4路差分数据传输通道进行传输的呢？28位并行数据映射到4路差分数据传输通道各个时刻点的位置关系如下图所示：1.1.4 管脚约束ZYNQ PL工程管脚约束如下图所示：1.1.5 例程使用1.1.5.1 连接Cameralink线缆使用Cameralink线缆将J3、J4两个接口连接在一起：1.1.5.2 加载运行ZYNQ程序1.1.5.2.1 打开Vivado工程打开Vivado示例工程：工程打开后界面如下图所示：1.1.5.2.2 下载ZYNQ PL程序下载bit流文件base_cameralink_loop.bit，并且配套base_cameralink_loop.ltx调试文件，如下图下载界面所示：1.1.5.3 运行结果说明ZYNQ PL端提供的ILA调试窗口，可以实时抓取采集Cameralink并行信号以及错误检测信号的时序波形。hw_ila_1调试界面抓取Cameralink并行发送数据，是一个28bits的累加数：hw_ila_2调试界面抓取Cameralink并行接收数据、接收误码统计以及接收误码实时标识信号，如下图所示：cameralink_rx_err_num显示有数值，则说明Cameralink接收过程中存在误码。可能在开始通信初始化期间存在误码现象，导致cameralink_rx_err_num误码统计累加。待程序下载完毕后，如果Cameralink通信正常的话，cameralink_rx_err_num误码统计应该不会再累加。如果cameralink_rx_err_num误码统计继续不断累加，则通过触发camera_rx_error信号可以捕捉到误码具体发生时刻。1.1.5.4  退出实验Vivado调试界面Hardware Manager窗口，右键单击localhost(1)，在弹出的菜单中点击Close Server，断开ZYNQ JTAG仿真器与板卡的连接：最后，关闭板卡电源，结束。

据中国社科院法学研究所调查研究显示，2021年，全国已有91%的三级法院全面推广应用电子签章。2022年1月1日新修订的《中华人民共和国民事诉讼法》第九十条规定：经受送达人同意，人民法院可以采用能够确认其收悉的电子方式送达诉讼文书。至此，通过电子签章应用实现法律文书网上签署、电子送达逐步成为各地法院数字化建设的重要工作之一，为移动法院、网上办案的开展提供了重要支撑。契约锁帮助构建统一印章管控平台，统一法院及下属法庭电子用印平台，支持集成对接法院内部电子卷宗系统、审判系统以及OA办公系统，帮助法院打造覆盖日常办公、办案场景的统一电子签章服务平台，推动法院日常办案材料、裁定书、调解书、判决书、决定书等法律文书网上签署、自动归档，按需下载、打印，全面提升法院办案效率。（法院电子签章应用）过去各类基层法庭遍布各地、距离法院路程较远，法庭结案后，只能派专人将大量文书专程送往法院机关进行手动盖章后带返法庭，再通知当事人领取。现在无论是现场办案还是网上办案，法庭结案，法官即可登录内部业务系统，上传制作好的法律文书、发起电子签署流程，从审批、法院盖章到回传、下发当事人，全程只需几分钟。（法院网上签署法律文书场景）更多场景 法院办公、办案过程中的电子签场景↓ 请看详细场景：1、法律文书电子签OFD格式文件电子送达，支持防伪打印针对当事人的不同需求，契约锁可以提供线上签署、现场打印领取；以及线上签署、电子送达等多种方式，满足法院现场办案、线上办案不同场景中的文书发放需求。1）现场打印，立等可取：针对现场办案、当事人需要提供纸质法律文书的，契约锁提供防伪打印服务，签署好的OFD格式法律文书，可以现场防伪输出纸质文件，当事人现场立等可取。2）线上签署，电子送达：针对网上开庭、当事人接收电子法律文书的情况，线上盖章完成后，自动通过短信通知当事人下载电子文件，同时自动生成回单签署流程，当事人人脸识别认证身份、远程签字确认，高效完成对接。2、传票、行政办公文件电子签线上高效审批、自动盖章下发通知、请示函、报告、传票、公告等需要法院单方盖章的文件，签署量大且用印频率高。过去：法院内部拟定文件，上报上级审批签字才能交由法院盖章。最后再将纸质文件按需分发、寄送给内部员工或者案件当事人。人工准备工作量大、签署效率低。现在：通过与内部办公系统、审判系统集成，为法院提供电子模板、身份认证以及电子签章支持，此类单签文件直接在现有管理软件中即可发起签署申请，负责人在线认证身份、电子签名审批，系统自动盖章生成PDF格式文件，按需打印、下载。3、庭审笔录文件电子签当庭在线生成笔录，多人在线签字盖章，自动归档庭审笔录文件作为法院裁决的重要依据，不仅需要双方当事人签名或盖章，还需要证人、法庭审判人员、书记员签名才能生效，需要当庭签署完成，扫描上传法院业务系统存档。过去：庭审笔录由工作人员起草打印后，签署人一一传阅确认笔录内容，无误后签名、按手印或盖章，最后由工作人员带回法院、扫描上传业务系统归档。不仅现场一一传阅确认时间较长，后期扫描上传、纸质文件存管压力也大。现在：庭审结束，相关负责人在线同步起草生成笔录，并上传审判系统、填报签署人信息发起电子签署，案件当事人、证人、审判长、书记员通过法庭电子设备或手机即可查收签署消息，现场同步预览记录内容，人脸识别确认身份即可电子签名、盖章。签署后的记录自动回传业务系统归档，无需人工整理，全面提升庭审及材料整理效率。（庭审记录电子签名-自动归档）丰富应用确保法院文件签署安全、高效存档1、一套系统支撑法院所有下属法庭机关在线签需求契约锁可以帮助法院建立覆盖所有下属法庭的印章管控平台，实现印章、组织、人员、流程全面统一，无需重复部署，一个平台即可支撑上下级机关日常办案签署需求。2、权威CA身份证书，保障法院文件签署合法有效契约锁联合全国权威CA机构，以可信数字身份为基础为法院组织提供电子签章服务，确保法院内部签字审批人、盖章人、案件当事人、证人、审判人员身份可信，本人签署，不可抵赖，提升案件材料及法律文书权威有效性。3、签署数据自动存证，法律文书签署过程可追溯各类材料、文书、行政文件的签署数据全程存证记录，随时可以通过审计记录追溯文件签署过程，确保司法公正、透明。4、支持PDF、OFD文件防伪打印，在线验真法院线上签署的各类PDF、OFD格式文件材料，可以根据场景实现防伪打印输出，自动为文件添加防伪码，确保文件内容不被篡改，文件安全打印输出。在线即可查验真伪。5、生成案件电子档案，自动归档、便捷调阅总结安全、便捷、移动签署的电子签章应用，帮助法院有效解决了大批量的案件材料及法律文件的签署难题，通过网上签、移动签、不见面签等便捷签署优势，为移动法院、互联网法院等新型办案模式普及推广提供技术支撑，助力法院以现有管理系统为基础逐步形成案件立项、审判、结案全程电子化闭环，助力司法诉讼服务全面数字化转型。

环境鲲鹏 920 128 核Bisheng JDK 17.0.1 / 17.0.4运行 BenchmarkSQL + ShardingSphere-JDBC网卡队列绑核 0-15，BenchmarkSQL 绑核 16-127。现象概率性出现运行 BenchmarkSQL us 较高（几乎压满 CPU 核），sy 较低。之前使用的是 GraalVM EE，本来以为是 GraalVM EE 才有的现象，后续测试发现使用 Bisheng JDK 17 也有相似现象。多次启动 BenchmarkSQL 进程，性能时好时坏。正常情况下，使用 BenchmarkSQL + ShardingSphere-JDBC 性能可以达到 200 万 tpmC 以上。最近启动进程时有较高概率发生性能异常，性能相比正常情况下降约 30%。Bisheng JDK 17 现象正常情况us 相对较低，网卡中断几乎跑满前 16 核。正常情况下 tpmC 在 200 万左右。异常现象最近测试发现，经常出现 us 较高，中断相比性能正常时更低。tpmC 在 160 万左右。性能下降至正常的 70% 左右。升级 Bisheng JDK 17.0.4 问题未解决async-profiler 采样对比正常情况与异常情况的采样，表面现象为计算开销增加，在代码路径上没有看出其他异常。 GraalVM EE 现象偶发现象：CPU us 特别高，sy 较低。退出压测进程重新运行后现象消失。6 节点测试中，该现象频繁出现GraalVM 发生该现象时对性能影响非常明显，tpmC 相比正常几乎减半。