在会议室里，AI会议助手看起来做的事情并不复杂：有人发言，系统实时转成文字；多人讨论时自动区分不同说话人；会议结束后再根据录音和转写内容生成结构化纪要。

但如果把条件进一步收紧——要求整个过程不能调用公网服务、会议数据不能离开本地网络，同时底层计算平台、操作系统、数据库也需要适配国产软硬件环境——事情就会复杂得多。

这时候，AI会议助手已经不只是一个安装在电脑上的应用，而是一套从硬件算力、操作系统、数据库，到语音识别、声纹识别、大模型，再到最终会议应用完整协同的技术体系。

熙瑾会悟信创AI会议一体机采用的，正是这种思路：不是单独提供一台用于运行大模型的服务器，而是围绕“会议”这一具体业务，把拾音、转写、分人、声纹、大模型纪要和文件输出整合到一套本地化信创环境中。

一、从一次会议开始：AI到底需要处理哪些事情？

先不讨论CPU、GPU和操作系统，单看一场普通会议。

会议开始后，360°全向麦克风首先负责采集会议室中的声音。随着多人轮流发言，系统需要持续完成几项工作。

第一项是实时语音识别。

系统需要把连续音频转换成文本，而且不能等会议结束后统一处理。对于一场持续一两个小时的会议来说，实时性意味着音频数据会不断进入识别模型，模型持续输出文字结果。

第二项是区分发言人。

普通语音转写只解决了“说了什么”，但会议记录还需要知道“谁说的”。

多人讨论过程中，系统需要根据声音特征判断不同语音片段是否来自同一个人。如果提前进行了声纹预录入和人员建档，还可以进一步把声音与实际参会人员关联起来。

最终会议记录不再只是：

发言人1：项目什么时候上线？

而可以对应到具体会议成员。

第三项则是会议内容理解。

一份几十页的逐字稿通常不能直接替代会议纪要。系统还需要进一步识别议题、结论、待办事项、负责人和时间节点，再按照不同会议类型生成结构化内容。

例如项目评审会、周例会和经营分析会需要的纪要结构显然不同，因此模板定制也是会议AI真正落地时非常实际的一项能力。

最终，会议内容可以一键整理并导出为Word或PDF，用于归档、流转或进一步编辑。

从表面看，这是一条“麦克风—文字—纪要”的简单链路；从底层来看，背后实际上同时运行着语音识别、说话人识别、数据库读写、大模型推理和会议应用等多个模块。

二、为什么“数据不出本地”比想象中更难？

现在很多软件都可以做到录音转文字，也有越来越多产品能够利用大模型自动生成会议摘要。

但对于政企、研发、制造、能源、金融等场景，问题往往不只是“AI能力够不够强”，而是：

这些数据到底在哪里处理？

如果语音识别需要调用云端接口，那么会议原始音频需要离开本地网络。

如果声纹识别依赖云服务，那么人员声音特征也可能需要上传。

如果会议摘要调用公网大模型API，那么完整的转写文本仍然需要发送到外部服务。

因此，单纯把客户端安装在内网电脑上，并不能等同于完整的本地化部署。

真正的数据不出本地，需要把整条会议处理链路都留在本地环境：

本地拾音 → 本地语音识别 → 本地说话人区分 → 本地声纹匹配 → 本地大模型处理 → 本地数据存储 → 本地文件输出。

这也是信创AI会议一体机与普通会议软件最大的区别之一。

熙瑾会悟信创AI会议一体机支持单机离线运行，会议过程中的音频、转写结果、声纹信息以及纪要内容均可以在本地环境中完成处理，整个会议业务链路无需依赖公网。

这时候，真正决定系统能否运行起来的，就不仅是上层会议软件了。

三、硬件层：国产GPU为什么会成为关键的一环？

实时语音识别、声纹分析和大模型推理都有一个共同特点：需要持续进行大量矩阵运算。

尤其是会议进行过程中，系统面对的是连续音频流。

假设多名参会者持续讨论，语音识别模型需要不断推理；与此同时，说话人识别还需要分析声音特征；会议结束后，大模型还需要对整场会议文本进行理解、总结和结构化处理。

因此，本地部署AI会议系统首先需要解决算力问题。

熙瑾会悟信创AI会议一体机底层采用摩尔线程GPU提供AI计算能力，并可根据不同项目环境，搭配飞腾、鲲鹏、龙芯、海光、兆芯、申威等国产CPU平台进行配置。

这种架构的重点并不是简单地把国外CPU或GPU换成国产硬件，而是要让上层AI模型能够真正运行在这套环境里。

因为对于AI软件而言，“硬件能够启动”只是第一步。

驱动、计算库、模型推理框架、算子支持、显存管理以及不同模型之间的资源调度，都可能影响最终运行效果。

尤其是实时会议场景，它和离线跑一次大模型测试并不完全一样。

会议系统需要连续运行，并且同时处理音频、转写、声纹和大模型任务，因此稳定性和持续推理能力往往比某一个单独模型的峰值跑分更加重要。

四、软件层：国产OS和数据库不是简单“装上就行”

硬件之上，是整个信创软件环境。

熙瑾会悟信创AI会议一体机可适配银河麒麟、统信UOS、openEuler等国产操作系统，同时支持达梦、人大金仓、Easysearch等数据存储方案。

这一层看起来离普通用户很远，但实际上直接决定了上层会议系统能否稳定运行。

以一个完整AI会议系统为例，操作系统需要同时承载：

• GPU驱动与AI计算环境；
• ASR语音识别服务；
• 声纹识别和说话人区分服务；
• 大模型推理服务；
• 数据库和检索服务；
• Web服务；
• 客户端通信；
• 文件导出与数据管理。

其中任何一个环节存在依赖冲突，都可能导致整个系统无法稳定工作。

数据库同样如此。

AI会议助手保存的并不只是最终生成的一份纪要，还可能包括会议基本信息、参会人员、说话人关系、声纹档案、转写结果、会议模板以及历史记录等数据。

因此，国产化环境真正困难的地方并不是列出一串“支持名单”，而是让这些软硬件组件组成一个能够长期运行的完整系统。

对于最终用户来说，这些复杂度最好是不可见的。

用户进入会议室之后，仍然只需要打开客户端或者浏览器开始会议，而不需要理解下面究竟运行着什么数据库、驱动和推理框架。

五、大模型本地化之后，会议数据才真正形成闭环

近两年AI会议助手最大的变化之一，就是会议纪要正在从简单的关键词提取，逐渐转向大模型理解。

传统算法可能更擅长从文本中提取高频词或关键句，但面对一场长时间、多议题、多角色的会议时，要真正理解“最后决定了什么”，难度会明显提高。

大模型可以进一步完成：

• 会议内容摘要；
• 核心观点提取；
• 决议事项整理；
• 待办任务识别；
• 负责人和时间节点提取；
• 不同格式的纪要生成。

但大模型也带来了新的数据安全问题。

如果前面的录音和语音识别都已经完成本地化，最后却把完整转写内容发送到公网大模型，那么整条私有化链路实际上仍然存在一个出口。

因此，熙瑾会悟信创AI会议一体机将通义千问部署在本地端侧环境中，让会议转写结果能够直接进入本地大模型进行处理。

从数据流角度看，整个过程可以简化成：

360°麦克风 → 本地语音识别 → 发言人区分/声纹匹配 → 本地数据存储 → 通义千问本地推理 → 会议纪要 → Word/PDF。

会议数据从进入系统开始，到最终形成文档，可以始终留在本地私有网络内部。

这也是“信创”和“AI会议”真正产生交集的地方。

信创不是单纯替换几项底层软硬件，而是为了让原本高度依赖云端算力和互联网服务的AI能力，也能够在独立的本地环境中完整运行。

六、最终呈现给用户的，仍然应该是一款会议工具

技术架构越复杂，产品层反而越应该简单。

对于会议参与者来说，并不需要知道后台使用了什么GPU，也没有必要在每次会议前配置模型参数。

熙瑾会悟信创AI会议一体机最终提供的是PC客户端和Web浏览器两种访问方式。

会议开始后，通过360°全向麦克风完成现场拾音，系统实时进行语音转写和发言人区分；对于已经提前完成声纹录入的成员，可以建立对应人员档案；会议结束后，再按照预设模板生成纪要，并一键导出Word或PDF。

换句话说，底层虽然是一整套国产算力、操作系统、数据库和AI模型组成的技术栈，但用户真正接触到的仍然是一套完整的AI会议系统。

这点非常重要。

因为信创项目最终的目标，并不是让用户感受到“国产化适配有多复杂”，而是在满足数据安全、国产化环境和本地部署要求的同时，依然保持原有的软件使用体验。

七、AI会议进入信创环境，真正需要解决的是“整条链路”

如果只看其中任何一个模块，今天已经有很多成熟方案。

国产CPU已经形成多种技术路线，国产GPU正在逐步完善AI计算生态，国产操作系统和数据库也已经进入大量实际业务环境，大模型则正在快速向端侧和私有化部署发展。

真正困难的是把这些能力组合起来，并且让它们围绕一个具体业务稳定运行。

对于AI会议来说，这个业务链路非常清晰：

从麦克风收音开始，到语音被转成文字；从判断不同发言人，到识别具体人员；从保存会议记录，到利用大模型理解会议内容；最终再形成一份能够直接使用的会议纪要。

熙瑾会悟信创AI会议一体机所做的，本质上就是把这条链路完整放进国产软硬件和私有网络环境中。

所以，与其把它理解为一台“能够运行大模型的信创服务器”，不如把它看成一套已经围绕真实会议场景完成整合的本地AI系统。

底层的CPU、GPU、操作系统、数据库和大模型是基础设施。

而实时转写、发言人区分、声纹建档、纪要生成和文档输出，才是这套基础设施最终需要服务的事情。

对很多需要本地化和信创环境的会议场景而言，真正有价值的也并不是“服务器里装了多少国产组件”，而是拔掉公网之后，一场会议从开始记录到最终生成纪要，是否依然能够完整地跑下来。