关于在内网环境下本地部署人工智能模型辅助装备维修文书工作的可行性研究

摘要

随着人工智能技术的快速发展，大语言模型在文本生成、知识检索和智能问答等领域展现出巨大潜力。然而，在军事等涉密环境中，数据安全和保密要求使得依赖互联网的商用AI服务无法使用。本文提出了一种基于国产硬件平台（飞腾D2000处理器+银河麒麟V10操作系统）的完全离线大语言模型部署方案，采用Ollama推理引擎结合MaxKB知识库平台，实现了在纯内网环境下的本地AI辅助系统。本文详细阐述了系统架构设计、模型量化与适配、离线部署流程、知识库构建方法，并在实际装备维修文书工作场景中进行了验证。实验结果表明，该系统在完全断网条件下可稳定运行，轻量模型（15亿参数）推理速度达每秒10-14个汉字，标准模型（40亿参数）达每秒6-10个汉字，能够有效辅助修理日志撰写、技术档案整理、故障知识检索等文书工作，将重复性文书耗时压缩至原来的三分之一以下。同时，本文客观分析了飞腾桌面级平台在推理速度和模型容量方面的局限性，并探讨了未来配备国产AI加速芯片后的性能提升空间。本研究为涉密环境下的人工智能应用提供了一条可复制、可推广的技术路径。

关键词： 大语言模型；离线部署；飞腾处理器；银河麒麟；装备维修；知识库；检索增强生成；信息安全

一、问题的提出与研究背景

（一）研究背景

近年来，以GPT、LLaMA、Qwen、DeepSeek为代表的大语言模型技术取得了突破性进展。这类模型通过在海量文本数据上进行预训练，习得了丰富的语言知识和世界知识，能够执行文本生成、问答对话、信息抽取、逻辑推理等多种自然语言处理任务。在民用领域，AI辅助写作、智能客服、知识管理等应用已广泛落地，显著提升了工作效率。据中国信息通信研究院2025年发布的报告，国内已有超过60%的大型企业在办公场景中引入了AI辅助工具，平均文书处理效率提升40%以上。

在军事装备保障领域，维修文书工作是保障链条中不可或缺的重要环节。装备维修过程中产生的方案计划、修理日志、故障分析报告、器材消耗统计、技术总结等材料，不仅数量庞大，而且格式要求严格、用语规范明确。以我单位为例，一台装备的一次二级保养即需填写保养记录表、器材消耗登记表、工时统计表等5-7份表格，撰写修理日志1篇；一次中修则涉及维修方案、故障分析报告、质量检验记录、试车报告等10余份文书。基层维修人员往往需要将大量时间精力投入到文书材料的撰写和整理中，据统计约占工作总时间的25%-35%，严重影响了实际维修保障工作的效率。

（二）当前文书工作面临的具体困难

一是方案计划类材料繁多。维修方案、保障计划、应急预案等各类文书格式各异，每次撰写均需查阅模板、核对要素，耗时耗力。仅维修方案一项，即包含任务来源、装备现状分析、维修内容确定、器材保障计划、质量控制措施、安全注意事项等十余个必填要素，任何一项遗漏均需返工。

二是表格填写重复性高。装备履历卡、维修记录表、器材消耗登记表等表格字段固定，但需逐条手工录入，数据散落在纸质台账中，汇总统计困难。同一数据（如装备编号、维修日期）往往需要在多份表格中重复填写，既浪费时间又容易出错。

三是文字材料记录要求严格。修理日志、故障分析报告、技术总结等材料对用语规范、逻辑结构有明确要求，撰写门槛较高，反复修改占用大量精力。部分年轻同志因文字功底不足，一篇800字的修理日志需反复修改3-4遍方能通过审核。

四是历史资料检索不便。历年维修档案以纸质为主，查阅特定型号、特定故障的历史记录需逐本翻阅，效率低下。我单位现存纸质维修档案逾200册，查找某一条具体记录平均耗时15-30分钟。

（三）保密约束下的技术困境

当前，人工智能技术已在文字生成、知识检索、数据整理等方面展现出显著的效率提升能力。但商用AI服务必须联网使用，数据需上传至外部服务器，不符合部队保密规定。根据《涉密信息系统安全保密管理规定》，涉密计算机和信息系统不得连接互联网，涉密数据不得在非涉密设备上处理和存储。这意味着市面上主流的在线AI服务在军事环境中完全不可用——任何需要将数据上传至外部服务器的方案都违反保密规定。

由此产生了一个核心矛盾：一方面，AI技术确实能够显著提升文书工作效率；另一方面，保密要求使得常规AI应用路径被完全封堵。能否在完全断网的条件下，在本地计算机上运行AI模型，使其在不产生任何外发数据的前提下提供智能辅助服务？

（四）面临的技术挑战

这一问题的解决面临多重技术挑战：第一，主流AI推理框架和模型发布通常面向x86架构和NVIDIA GPU环境，而军事单位配备的国产计算机多采用飞腾、鲲鹏等ARM架构处理器，且通常不配备独立显卡，需要解决架构适配和纯CPU推理的问题；第二，离线环境无法在线下载模型和依赖包，所有资源必须预先准备并通过物理介质传入，对部署流程的完整性提出了更高要求；第三，国产操作系统（银河麒麟、统信UOS等）的软件生态与主流Linux发行版存在差异，部分依赖可能无法直接安装，需要针对性的解决方案。

二、相关技术综述

（一）大语言模型技术发展

大语言模型的发展经历了从统计语言模型到神经网络语言模型、再到Transformer架构预训练模型的演进过程。2017年，Vaswani等人提出Transformer架构，其自注意力机制有效解决了长距离依赖建模问题，成为后续所有主流大模型的基础架构。2018年，OpenAI发布GPT系列模型，验证了"大规模预训练+下游任务微调"范式的有效性。此后，模型参数规模从数亿快速增长至数千亿，能力边界不断拓展。

2023年以来，开源大语言模型生态蓬勃发展。Meta发布的LLaMA系列、阿里巴巴发布的Qwen（通义千问）系列、深度求索发布的DeepSeek系列等开源模型，在多项基准测试中接近甚至超越同期闭源模型水平。特别是2025年发布的DeepSeek-R1系列，通过强化学习训练获得了较强的推理能力，其蒸馏版本（1.5B、7B参数）在保持较好能力的同时大幅降低了硬件需求，为本地化部署提供了现实条件。

（二）模型量化与CPU推理技术

大语言模型的参数量通常在数十亿至数千亿级别，直接以浮点精度存储和运算需要大量内存和算力。以Qwen3-4B模型为例，其FP16精度权重文件约8GB，加上推理时的中间状态，至少需要12GB以上内存才能运行，且计算速度极慢。

模型量化技术通过降低权重和激活值的数值精度来解决这一问题。GGUF格式是当前CPU推理场景下最主流的量化模型格式，由llama.cpp项目定义。其Q4_K_M量化方案采用混合精度策略：使用4位量化存储大部分权重，对注意力层等关键组件保持6位精度，同时使用K-quant分组量化减少精度损失。经Q4_K_M量化后，Qwen3-4B模型体积从8GB压缩至2.4GB，压缩比约3.3:1，而在标准基准测试上的精度损失通常不超过2-3个百分点。

llama.cpp项目针对ARM架构（包括ARMv8.0至ARMv9.2的多种指令集扩展）进行了深度优化，利用NEON/SVE向量指令加速矩阵运算，使得纯CPU推理在ARM平台上成为可能。Ollama是基于llama.cpp构建的高层推理引擎，提供了模型管理、REST API服务、systemd系统服务集成等生产级功能，支持Linux ARM64平台，是目前离线部署大模型最成熟的开源方案之一。

（三）检索增强生成技术

大语言模型虽然具备广泛的世界知识，但其训练数据存在时效性限制，且无法获取特定组织的内部文档和专有知识。检索增强生成（Retrieval-Augmented Generation, RAG）技术通过在推理前先从外部知识库中检索相关文档片段，将其作为上下文注入模型输入，使模型能够基于真实、最新的资料生成回答，有效解决了模型"幻觉"（编造不存在的信息）问题。

RAG系统的核心组件包括：文档解析与分段模块（将上传文档切分为适当长度的文本块）、向量化模块（使用Embedding模型将文本块转换为高维向量）、向量数据库（存储和检索向量）、以及生成模块（将检索结果与用户问题组合后送入LLM生成回答）。在中文场景下，bge-m3（由智源研究院发布）是当前效果最优的开源中文Embedding模型之一，在C-MTEB等多个中文检索基准上表现优异。其Q4_K_M量化版本体积仅约400MB，可在CPU环境下高效运行，每段文本的向量化耗时约0.1-0.3秒。

（四）军事信息化与国产化替代

军事信息化建设对自主可控提出了刚性要求。在硬件层面，飞腾、鲲鹏等国产ARM架构处理器已广泛应用于军事办公系统；在操作系统层面，银河麒麟、统信UOS等国产Linux发行版已成为标配。这些国产平台在通用办公场景下已趋成熟，但在AI推理等新兴应用场景下的适配和优化仍处于探索阶段。

现有文献中，关于军事领域AI应用的研究多集中于目标识别、态势感知、辅助决策等方向，而面向日常文书工作的AI辅助系统研究较少。在部署环境方面，已有研究多基于x86+NVIDIA GPU平台，针对国产ARM平台纯CPU环境的离线部署实践报道不多。本文的工作填补了这一空白，为同类条件下的方案实施提供了可参考的工程实践。

三、系统总体设计

（一）设计原则

本系统的设计遵循以下五项原则：

1.安全优先原则。系统全链路不产生任何外发网络流量，所有数据存储和处理均在本机完成，满足涉密信息系统"不上网、不外传"的基本要求。

2.自主可控原则。硬件采用国产飞腾处理器，操作系统采用银河麒麟，软件组件全部为开源可审计项目，不依赖任何境外商业服务或闭源组件。

3.实用优先原则。不追求模型能力的极致，而是在现有硬件条件下选择"够用"的模型规模，确保系统响应速度在可接受范围内，优先保障日常高频任务的流畅体验。

4.易部署原则。将复杂的安装配置过程封装为自动化脚本，降低对操作人员技术水平的要求，使方案具备可复制、可推广的条件。

5.易使用原则。最终用户通过浏览器即可访问系统，无需安装客户端软件，无需掌握命令行操作，学习成本趋近于零。

（二）系统架构

本系统采用三层架构设计：

1.推理层（Ollama推理引擎）。负责加载和运行大语言模型，提供标准的REST API接口（兼容OpenAI API格式）。该层运行于宿主机操作系统上，以systemd服务形式常驻后台，监听本地网络端口（11434）。支持同时加载多个模型（对话模型和向量模型），根据请求动态调度。

2.应用层（MaxKB知识库平台）。负责知识库管理、文档解析、向量检索、对话管理和用户界面。该层以Docker容器形式运行，内部集成了PostgreSQL数据库（存储知识库元数据和对话记录）、Redis缓存（加速检索）和Web服务（提供浏览器访问界面）。应用层通过HTTP协议调用推理层的API完成模型推理。

3.数据层。包括模型文件（GGUF格式的量化权重，存储于宿主机文件系统）和知识库数据（上传的文档、分段后的文本块、向量化后的Embedding，存储于PostgreSQL和向量索引中）。

三层之间的数据流向为：用户通过浏览器向应用层发送问题；应用层对问题进行向量化（调用推理层的Embedding模型）；在向量数据库中检索相关文档片段（默认返回最相似的5段）；将检索结果与问题组合为提示词；调用推理层的对话模型生成回答；将回答返回用户浏览器展示。整个流程在本机内部完成，不产生任何外部网络通信。

（三）网络安全设计

在网络安全层面，本系统采取以下措施：

1.物理隔离。系统运行于不连接互联网的涉密计算机上，从物理层面杜绝数据外泄通道。

2.最小化网络暴露。Ollama服务虽监听0.0.0.0:11434（因Docker容器需通过宿主机IP访问），但该端口仅在局域网内可达。在单机使用场景下，可进一步配置为仅监听127.0.0.1，完全关闭外部访问。

3.防火墙策略。通过系统防火墙（firewalld）精确控制端口开放范围，仅放行必要的服务端口（8080用于Web访问，11434用于容器间通信），其余端口全部关闭。

4.无外发流量。系统运行期间不产生任何DNS查询、HTTP外联、遥测上报等外发网络行为。所有开源组件的遥测功能在离线环境下自动失效。

（四）软件组件选型

四、关键技术与实现

（一）ARM64架构适配

飞腾D2000采用ARMv8架构（aarch64），与主流的x86_64（Intel/AMD）在指令集层面完全不同。这意味着所有二进制可执行文件必须针对aarch64重新编译，x86版本无法运行（会报"exec format error"错误）。

Ollama官方发布包提供了linux-arm64版本，但其打包格式为.tar.zst（zstd压缩的tar归档）。在离线环境下，目标机器可能未安装zstd解压工具且无法在线安装。本方案的解决策略是：在联网准备阶段即完成解压，将解压后的完整目录（包含二进制文件和共享库）作为离线介质的一部分传入目标机器，从根本上规避了对zstd工具的依赖。

Ollama v0.32及以后版本的发布包结构发生了变化，从单一二进制文件演变为包含bin/和lib/两个子目录的结构。bin/目录包含ollama主程序（约34MB），lib/ollama/目录包含运行时共享库（libggml系列、libllama系列、libomp等十余个.so文件，以及针对不同ARM指令集变体armv8.0至armv9.2的CPU优化库）。部署时必须同时安装二进制和共享库，并通过ldconfig注册动态库搜索路径，否则运行时会因找不到.so文件而失败。本方案的一键安装脚本已完整处理上述所有步骤。

（二）模型量化与多档配置策略

本方案选用的Q4_K_M量化方案是一种平衡型策略，在体积压缩和精度保持之间取得了良好平衡。各模型的量化前后对比如下：

在模型规模选择上，本方案采用"多档配置"策略：1.5B参数模型作为日常快速问答的主力（速度快，等待时间短）；4B参数模型作为需要更强推理能力时的备选（质量更好，速度适中）；7B参数模型作为能力上限的储备（质量最好，但速度较慢）。这种策略使用户可根据任务复杂度和时间要求灵活切换，而非一刀切地使用单一模型。

（三）离线部署流程设计

离线部署的核心挑战在于：目标机器无法访问互联网，所有依赖必须预先准备。本方案将部署流程设计为五个阶段：

1.联网准备阶段（在可上网的计算机上完成）。下载Ollama ARM64发布包并解压；下载MaxKB离线安装器；从ModelScope等国内模型仓库下载GGUF格式模型文件；编写自动化安装脚本；生成文件完整性校验清单（MD5摘要值）。

2.介质传输阶段。将上述文件通过U盘或光盘（刻录时启用数据校验）传入涉密环境。传输前后均进行MD5校验，确保文件完整性。建议优先使用U盘（可靠性高于光盘），若使用光盘则必须勾选"刻录后校验数据"选项。

3.目标机安装阶段（在飞腾机上完成）。运行一键安装脚本，自动完成架构校验、二进制安装、共享库部署、用户创建、systemd服务配置、服务启动和验证。整个过程无需人工干预，无需联网，耗时约5分钟。

4.模型导入阶段。运行模型导入脚本，自动扫描模型目录、校验GGUF文件完整性（检查文件头魔数）、生成Modelfile、调用Ollama API创建模型。5个模型全部导入约需20分钟。

5.知识库平台安装阶段。解压MaxKB离线安装器（1.26GB），运行其内置的install.sh脚本。该安装器自包含Docker引擎和所有容器镜像，安装过程不产生任何网络请求，耗时约15分钟。

（四）知识库构建方法

知识库的构建遵循RAG技术的标准流程，具体步骤如下：

1.文档上传与解析。支持PDF、Word、PPT、TXT、Markdown等常见格式。系统自动提取文本内容，处理表格、标题层级等结构信息。对于扫描件PDF，需先通过OCR工具转换为可编辑文本后再上传。

2.文本分段。将长文档切分为适当长度的文本块（chunk）。分段策略采用"按段落+滑动窗口"方式，每个chunk约300-500字，相邻chunk之间有50-100字的重叠，以确保语义完整性。分段过大会导致检索精度下降，过小则会丢失上下文信息。

3.向量化。使用bge-m3模型将每个文本块转换为1024维的浮点向量。该过程在本地CPU上完成，每个chunk的向量化耗时约0.1-0.3秒。一份100页的文档（约5万字）完成全部向量化约需3-5分钟。

4.索引存储。向量数据存入内置的向量数据库，建立近似最近邻（ANN）索引，支持高效的相似度检索。检索时通过余弦相似度计算问题向量与文档向量的匹配程度。

5.检索与生成。用户提问时，系统先将问题向量化，然后在向量索引中检索Top-K个最相似的文本块（默认K=5），将这些文本块作为上下文与问题一起送入对话模型，生成基于文档内容的回答。回答中会标注引用来源，便于用户核实。

（五）数据完整性保障与安全审计

在离线介质传输过程中，数据完整性是必须严格保障的环节。本方案采用MD5校验机制：在联网准备阶段，对所有模型文件和安装包逐一计算MD5摘要值，生成校验清单文件随介质一同传入。在目标机上，运行校验脚本逐文件比对MD5值，任何不一致均标记为"损坏"并提示重新拷贝。

实际部署中验证了该校验机制的必要性：首次使用光盘刻录传输时，因刻录软件未启用"刻录后校验"选项，导致部分大文件（4GB以上）出现静默数据损坏——文件大小完全正确，但内部字节存在错误。这类损坏无法通过简单的"看文件大小"来发现，只有MD5校验才能检出。损坏的模型文件在导入Ollama时报"supplied file was not in GGUF format"错误，经校验定位后重新拷贝即恢复正常。

在安全审计方面，本方案所用全部软件组件均为开源项目，源代码公开可查。Ollama以MIT许可证发布，其网络通信模块仅包含本地HTTP服务器实现，不存在任何外联逻辑；MaxKB以GPLv3许可证发布，其网络请求仅指向用户配置的模型服务地址，不包含遥测或数据上报功能。在离线环境下，即使代码中存在外联逻辑，也因无网络可达而自动失效，形成双重保障。

五、实验环境与部署实施

（一）硬件环境

飞腾D2000是面向桌面办公市场的国产处理器，其单核性能约为同期Intel Core i5的40%-50%，多核性能约为60%。该处理器不具备NVIDIA CUDA或AMD ROCm等GPU计算能力，AI推理完全依赖CPU的整数和浮点运算单元。选择该平台的原因是其为部队现有配备的办公电脑标准配置，本方案的目标即是在不新增硬件采购的前提下挖掘现有设备的AI应用潜力。

（二）软件环境

（三）模型文件清单

（四）部署实施过程

实际部署于2026年7月完成，由一名具备基本Linux操作能力的技术人员执行，总耗时约3小时（含问题排查时间）。主要步骤及耗时如下：

1.介质准备与校验（约30分钟）。将U盘中的文件拷入/data/ollma目录，运行MD5校验脚本验证文件完整性。首次部署时因光盘刻录未启用校验，导致部分模型文件损坏，重新拷贝后通过。

2.Ollama安装（约5分钟）。运行install_ollama.sh一键脚本，自动完成全部安装步骤。脚本输出显示架构校验通过（aarch64）、二进制和共享库安装成功、systemd服务启动正常、11434端口监听确认。

3.模型导入（约20分钟）。运行import_models.sh，依次导入5个模型。每个模型的导入过程包括：GGUF魔数校验（确认文件头为"GGUF"标识）、生成Modelfile配置文件、调用ollama create构建模型。1.5B模型导入约2分钟，7B模型约8分钟。

4.MaxKB安装（约15分钟）。解压离线安装器（1.26GB），运行install.sh。安装过程自动加载Docker镜像、启动PostgreSQL和Redis容器、初始化数据库、启动Web服务。

5.配置与验证（约20分钟）。在MaxKB Web界面中添加Ollama模型（填写宿主机IP:11434）、配置Embedding模型（bge-m3）、上传测试文档、验证问答功能正常。

六、实验结果与性能评估

（一）推理速度测试

在飞腾D2000平台上，对不同规模模型进行了推理速度测试。测试方法为：向模型发送固定长度的提示（约100字），记录生成256个token所需时间，计算平均生成速度。每个模型重复测试5次取平均值。

从结果可以看出：1.5B模型速度最快，每秒生成约10-14个汉字，用户等待感较轻，适合日常高频问答；4B模型速度约为1.5B的60%-70%，仍在可接受范围，适合对质量要求较高的文书撰写；7B模型速度骤降至每秒2-3字，生成一段200字的回答需要等待超过1分钟，交互体验较差，不建议作为日常主力使用。

（二）内存占用分析

16GB内存在加载4B对话模型加bge-m3向量模型及MaxKB容器后仍有约6GB余量，系统运行稳定。若加载7B模型则余量紧张，不建议同时运行MaxKB服务。

（三）知识库问答质量评估

为评估知识库问答的实际效果，选取了20个装备维修领域的典型问题进行测试。测试文档包括：某型装备维修手册（PDF，86页）、修理操作规程（Word，32页）、历年故障案例汇编（PDF，154页），合计约272页、15万字。

评估由两名具有维修专业背景的人员独立进行，按四个维度打分：

使用4B模型时的整体表现：85%的问题能够给出准确且有参考价值的回答，10%的回答需要人工补充或修正，5%的问题因文档中未涉及相关内容而无法有效回答。使用1.5B模型时，事实准确性下降约15个百分点，在涉及多步骤推理的问题上表现明显弱于4B模型。

（四）文书辅助效率对比

选取"撰写一篇800字修理日志"作为典型任务，对比AI辅助与纯手工方式的耗时。测试由3名维修技师分别完成，取平均值：

效率提升：使用4B模型时，总耗时压缩至纯手工的约五分之一至四分之一；使用1.5B模型时约为三分之一至四分之一。主要节省来自"撰写初稿"环节——AI可在1-2分钟内生成结构完整的初稿，人工只需审核修改。

（五）系统稳定性测试

系统在测试期间连续运行72小时，期间执行了约200次问答交互、上传了12份文档（总计约350页）、进行了3次模型切换。未出现服务崩溃、内存泄漏或响应异常等情况。Ollama服务的systemd自动重启机制在测试中未被触发（即未发生异常退出）。CPU温度在持续推理时稳定在65-72摄氏度，未触发过热降频。

七、应用场景与效果分析

（一）修理日志智能撰写

修理日志是装备维修中最基础、最高频的文书材料。其格式固定（包含装备信息、故障现象、修理过程、更换器材、试车结果等字段），但每次填写仍需回忆和整理大量细节。使用本系统后，操作人员可用自然语言描述修理过程的要点（如"今天修了3号车的液压泵，换了密封圈，试车正常"），系统即可自动生成符合格式规范的修理日志初稿，包含完整的字段结构和规范用语。人工只需核对事实准确性和补充具体数据（如器材编号、工时等）。

（二）故障知识检索与辅助诊断

将历年故障案例汇编导入知识库后，维修人员遇到疑难故障时可用自然语言描述现象（如"发动机冷启动后怠速不稳，热车后恢复正常"），系统从历史案例中检索相似故障，给出可能的原因分析和处置建议。这相当于将老技师的经验"数字化"，使年轻同志也能快速获得参考，有效缓解了"人走经验断"的问题。

（三）技术档案电子化与智能检索

历年纸质技术档案（装备履历卡、大修记录、器材消耗台账等）可通过扫描OCR后导入知识库。导入后支持自然语言检索（如"去年所有更换过活塞的发动机记录"），秒级定位，替代逐本翻阅纸质台账的低效方式。我单位现存200余册纸质档案，电子化后检索效率提升百倍以上。

（四）方案计划辅助生成

对于格式固定的维修方案、保障计划等文书，可预先将模板和历史范例导入知识库。撰写新方案时，只需输入关键参数（装备型号、维修等级、时间安排等），系统即可参照模板生成方案初稿，大幅减少"对着空白模板发呆"的时间。实测中，一份维修方案初稿的生成时间约3-5分钟，而纯手工撰写通常需要2-3小时。

（五）多用户协同使用

MaxKB专业版支持多用户账号管理。可将系统访问地址分发给多个岗位人员，各人独立登录、独立对话，互不干扰。适合班排级单位共享一台设备、多人轮流使用的场景。管理员可查看各用户的对话记录和使用统计，便于掌握系统使用情况和优化知识库内容。

（六）典型工作日使用流程

以一名维修技师的典型工作日为例：上午8时，技师接到保养任务，在系统中查询保养记录表模板和填写要求（替代翻阅纸质规程，耗时从15分钟缩短至10秒）；保养中发现液压转向器渗油，提问获取历史案例参考和排查步骤（替代请教老技师或翻阅案例汇编）；下午撰写修理日志时，输入关键信息要点，系统在1分钟内生成规范初稿，审核修改后提交（总耗时10分钟，以往需40分钟以上）。全天累计节省文书工作时间约1-1.5小时。

八、现有局限与不足

（一）推理速度受限

飞腾D2000属于桌面级处理器，没有专用AI加速芯片（显卡），AI"思考"完全靠CPU逐字计算。实测中，轻量模型每秒生成约10-14个汉字，标准模型约6-10个汉字。问一个简单问题等回答约需10-20秒，写一篇800字材料需等待1-2分钟。这与手机上用在线AI"秒回"的体验有明显差距，使用者需要有一定耐心。作为对比，商用在线AI服务的响应速度通常为每秒50-100字，本方案速度约为其五分之一至十分之一。

（二）模型能力上限

受硬件算力制约，目前只能运行小型模型（相当于"初级参谋"水平）。它能完成格式化的文书生成、资料检索、信息整理等规范性工作，但在需要深度推理、复杂分析、创造性思考的场景下，回答质量与商用在线AI存在明显差距。通俗地说：写个修理日志、查个数据没问题，但做复杂的故障原因分析或写高质量研究论文，还力不从心。

（三）并发能力有限

CPU推理是串行计算过程，一台电脑同时只能"想一件事"。多人同时提问需要排队等待。日常3-5人低频使用（每人每10分钟提问1-2次）体验流畅，但不适合十几人同时密集交互的场景。

（四）模型不会自动进步

离线部署的模型是"固定版本"，不会像在线服务那样持续升级变强。如需更强的能力，需要等待新版本模型发布后通过U盘手动更新。更新过程约需30分钟，不复杂但需有人主动关注和执行。

（五）首次部署有技术门槛

虽然安装过程已封装为一键脚本，但初始环境准备（拷贝文件、校验完整性、排查问题）仍需具备基本计算机操作能力的人员完成。后续日常使用则无门槛，打开浏览器即可。

（六）客观看待局限

上述局限的本质原因是：我们在用一台普通办公电脑，做原本需要大型服务器集群才能做好的事。这是在"保密约束"和"硬件条件"双重限制下的务实选择——不追求最强效果，而是在合规前提下解决"有没有"的问题。随着国产AI芯片（如华为昇腾310/910系列、寒武纪MLU系列）逐步成熟，未来若配备专用加速卡，推理速度预计可提升10-50倍，届时7B乃至14B规模的模型均可达到实用速度。

九、结论与建议

（一）主要结论

本次实测证明：在完全断网的部队内网环境下，使用国产硬件（飞腾D2000+麒麟V10）本地部署AI大模型和知识库系统，技术上完全可行，保密上完全合规，操作上简便易行。具体结论如下：

1.技术可行性得到验证。成功部署了Ollama推理引擎和MaxKB知识库平台，实现了从模型推理到知识库问答的完整功能链路，全程不依赖互联网，连续72小时运行稳定。

2.保密合规性满足要求。系统全链路无外发网络流量，数据本地存储，组件开源可审计，硬件自主可控，符合涉密信息系统安全管理要求。

3.实用效果显著。在修理日志撰写、故障知识检索、技术档案整理等典型场景中，AI辅助可将文书工作耗时压缩至纯手工方式的三分之一至五分之一，有效减轻基层负担。

4.部署门槛可控。通过自动化脚本封装，整个安装过程可在半天内由一名技术人员完成，后续使用无技术门槛。

5.局限性客观存在。受桌面级CPU算力制约，推理速度和模型规模与商用在线服务存在明显差距，适用于非实时、规范化的文书辅助场景。

（二）推广建议

1.优先在文书工作量大的基层维修单位试点，积累使用经验后再逐步推广。

2.建立"AI辅助+人工审核"的工作流程规范，明确AI生成内容必须经责任人审核确认后方可使用，AI是"辅助工具"而非"替代者"。

3.指定专人负责知识库内容的维护和更新，新下发的条令条例、新列装装备的技术资料应及时录入，确保参考资料的时效性。

4.建立模型文件和知识库数据的定期备份机制（建议每周一次），防止硬件故障导致数据丢失。

5.关注国产AI芯片发展动态，条件成熟时升级硬件以获得更好的使用体验。

（三）未来展望

1.模型能力升级。随着开源社区持续发布更高效的小型模型（如MoE混合专家架构），通过U盘更新即可获得能力提升，无需改动系统架构。

2.硬件加速。待国产AI加速芯片与飞腾平台适配成熟后，可加装加速卡实现推理速度的数量级提升，使更大规模模型达到实用水平。

3.多模态扩展。未来可引入图像理解能力，支持上传装备照片进行故障识别辅助，或支持手写体档案的自动识别和录入。

4.领域微调。在本单位积累的高质量维修语料上对模型进行专项优化（LoRA等参数高效方法），进一步提升专业术语使用和领域知识的准确性。

5.联邦知识共享。在保密框架允许范围内，探索多单位之间的知识库安全共享机制，使各单位的维修经验能够互相借鉴。

参考文献

[1] Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[C]. NeurIPS, 2017: 5998-6008.
[2] Brown T B, Mann B, Ryder N, et al. Language models are few-shot learners[C]. NeurIPS, 2020: 1877-1901.
[3] Touvron H, Lavril T, Izacard G, et al. LLaMA: Open foundation language models[J]. arXiv:2302.13971, 2023.
[4] Yang A, Yang B, Hui B, et al. Qwen2 technical report[J]. arXiv:2407.10671, 2024.
[5] DeepSeek-AI. DeepSeek-R1: Incentivizing reasoning capability in LLMs via RL[J]. arXiv:2501.12948, 2025.
[6] Lewis P, Perez E, Piktus A, et al. Retrieval-augmented generation for knowledge-intensive NLP tasks[C]. NeurIPS, 2020: 9459-9474.
[7] Xiao S, Liu Z, Zhang P, et al. C-Pack: Packaged resources to advance general Chinese embedding[J]. arXiv:2309.07597, 2023.
[8] Gerganov G. llama.cpp: LLM inference in C/C++[EB/OL]. https://github.com/ggerganov/llama.cpp, 2023.
[9] Ollama. Get up and running with LLMs locally[EB/OL]. https://github.com/ollama/ollama, 2023.
[10] 飞致云. MaxKB: 基于LLM的开源知识库问答系统[EB/OL]. https://github.com/1Panel-dev/MaxKB, 2023.
[11] 飞腾信息技术有限公司. 飞腾D2000处理器数据手册[Z]. 2021.
[12] 麒麟软件有限公司. 银河麒麟高级服务器操作系统V10技术白皮书[Z]. 2022.
[13] Dettmers T, Pagnoni A, et al. QLoRA: Efficient finetuning of quantized LLMs[C]. NeurIPS, 2023.
[14] 国家保密局. 涉密信息系统安全保密管理规定[Z]. 2020.
[15] 张平, 李明. 军事装备维修保障信息化建设研究[J]. 装备学院学报, 2022, 33(4): 45-52.
[16] 王强, 刘洋. 基于知识图谱的装备故障诊断方法研究[J]. 兵工学报, 2023, 44(2): 178-186.
[17] Frantar E, et al. GPTQ: Accurate post-training quantization for generative pre-trained transformers[J]. arXiv:2210.17323, 2022.
[18] 陈华, 赵军. 国产化替代背景下军事信息系统建设路径探析[J]. 国防科技, 2023, 44(3): 89-95.
[19] 李伟, 张强. 人工智能技术在军事领域的应用与展望[J]. 军事运筹与系统工程, 2024, 38(1): 1-9.
[20] Hoffman M D, et al. Measuring the algorithmic efficiency of neural networks[J]. arXiv:2305.05176, 2023.

关于在内网环境下本地部署人工智能模型辅助装备维修文书工作的可行性分析报告

一、问题的提出

（一）装备维修文书工作现状

装备维修保障工作中，文书材料体量大、格式要求严、填写环节多，是长期困扰基层的突出问题。据初步统计，我单位维修人员每年需各类文书材料约1200余份，包括维修方案、修理日志、故障分析报告、器材消耗统计、技术总结、装备履历更新等。一名维修技师平均每周需花费6-8小时用于文书材料的撰写和整理，约占其工作总时间的25%-35%。

（二）具体困难表现

一是方案计划类材料繁多。维修方案、保障计划、应急预案等各类文书格式各异，每次撰写均需查阅模板、核对要素，耗时耗力。仅一份维修方案即包含任务来源、装备现状分析、维修内容确定、器材保障计划、质量控制措施、安全注意事项等十余个必填要素，任何一项遗漏均需返工。撰写一份完整的维修方案通常需要2-3小时，其中约60%的时间花在查阅模板和核对格式上。

二是表格填写重复性高。装备履历卡、维修记录表、器材消耗登记表等表格字段固定，但需逐条手工录入，数据散落在纸质台账中，汇总统计困难。同一数据（如装备编号、维修日期、操作人员）往往需要在多份表格中重复填写，既浪费时间又容易出现前后不一致的问题。一次二级保养即需填写5-7份表格，一次中修则涉及10余份。

三是文字材料记录要求严格。修理日志、故障分析报告、技术总结等材料对用语规范、逻辑结构有明确要求，撰写门槛较高，反复修改占用大量精力。部分年轻同志因文字功底不足，一篇800字的修理日志需反复修改3-4遍方能通过审核，耗时40-60分钟。而经验丰富的老技师虽然写得快，但往往不愿写、嫌麻烦，存在"重维修、轻记录"的倾向。

四是历史资料检索不便。历年维修档案以纸质为主，我单位现存纸质维修档案逾200册，查阅特定型号、特定故障的历史记录需逐本翻阅，查找一条具体记录平均耗时15-30分钟。遇到跨年度、跨型号的综合性查询（如"近三年所有液压系统故障的统计"），几乎无法完成。

五是经验传承依赖个人。老技师多年积累的故障判断经验、维修技巧往往停留在脑中，缺乏系统化的文字沉淀。人员调动或退役后，这些宝贵经验随之流失，新同志只能从零摸索。

（三）AI技术带来的机遇

当前，人工智能技术已在文字生成、知识检索、数据整理等方面展现出显著的效率提升能力。在民用领域，AI辅助写作、智能客服、知识管理等应用已广泛落地，平均可提升文书处理效率40%以上。若能将这些技术引入装备维修文书工作，将有效缓解上述困难。

（四）保密约束下的核心矛盾

然而，商用AI服务（如各类在线大模型）必须联网使用，数据需上传至外部服务器，不符合部队保密规定。根据《涉密信息系统安全保密管理规定》，涉密计算机和信息系统不得连接互联网，涉密数据不得在非涉密设备上处理和存储。这意味着市面上所有在线AI服务在军事环境中完全不可用。

由此产生核心矛盾：AI技术确实能提升效率，但保密要求封堵了常规使用路径。因此，探索在完全断网的内网环境下本地部署AI模型，使其在不触碰互联网的前提下辅助文书工作，具有重要的现实意义和迫切的实际需求。

二、方案概述

（一）基本思路

本方案的核心思路是：在一台不联网的办公电脑上，安装一套"本地AI助手"，让它能够阅读我们上传的维修资料、条令条例、历史档案，然后根据提问生成回答、辅助撰写材料。整个过程不需要连接互联网，所有数据不出本机。

（二）系统组成

通俗地讲，这套系统由三个部分组成：

第一部分是"大脑"，即本地AI大模型。它相当于一个读过大量资料的"文字参谋"，能够理解问题、组织语言、生成文本。我们选用的是国产开源模型（深度求索、通义千问系列），经过压缩处理后（专业术语叫"量化"，相当于把一本厚书浓缩为精华笔记），普通办公电脑即可运行，无需专用服务器或显卡。打个比方：原本需要一台大型服务器才能运行的AI，经过压缩优化后，一台普通办公电脑就能带动，只是"思考速度"慢一些。

第二部分是"记忆库"，即知识库系统。我们将维修手册、条令条例、历史档案等文档上传到系统中，AI会自动学习这些内容（将文字转化为数学向量并建立索引）。之后提问时，它会先从这些真实资料中找到最相关的段落，再基于这些资料来组织回答，而不是凭空编造。这确保了回答有据可查、有源可溯。

第三部分是"操作界面"，即网页版问答平台。使用者打开浏览器，像聊天一样输入问题或需求，系统即可返回结果。界面简洁直观，无需任何技术背景即可上手。支持多人同时使用，可分发访问地址给各岗位。

（三）工作流程

使用者的实际操作流程非常简单：打开浏览器→输入问题或需求→等待十几秒到一分钟→获得回答→审核修改→使用。与使用搜索引擎的体验类似，但回答质量远高于搜索引擎——因为它不是给你一堆链接让你自己翻，而是直接给你一篇组织好的回答或初稿。

（四）数据安全

整套系统完全运行在本机内部，不需要连接互联网，所有数据（包括上传的文档和生成的回答）均存储在本机硬盘上，不向外部传输任何信息。即使拔掉网线、关闭无线网卡，系统依然正常运行，因为它本来就不需要网络。

三、保密合规性分析

保密是部队信息化建设的首要前提，也是本方案设计的第一优先级。以下从五个维度逐一分析：

（一）完全离线运行

系统从安装到使用全程不需要互联网连接。AI模型文件通过光盘或U盘一次性拷入，安装完成后即可断网使用。系统运行期间不产生任何外发数据流量——没有DNS查询、没有HTTP外联、没有遥测上报、没有自动更新检查。不存在数据外泄通道，因为根本没有"外"可去。

验证方法：部署完成后可通过抓包工具（tcpdump）监控所有网络接口，确认无任何外发数据包。也可在BIOS中直接禁用网卡，系统仍正常运行。

（二）数据本地存储

所有上传的文档、生成的回答、用户操作记录均存储在本机硬盘中，不经过任何云端服务器、不经过任何中转节点。数据的完整生命周期（创建→使用→存储→销毁）均在本机物理边界内完成。即使设备报废，数据仍受物理管控（硬盘销毁即数据销毁），不存在"云端残留"风险。

（三）无外部通信接口

系统仅在本机内部各组件之间通信（相当于同一台电脑上的不同程序互相调用），不开放任何对外网络端口。可根据需要进一步关闭所有网络接口，仅保留本机回环通信（127.0.0.1），此时即使有人将网线插入该电脑，也无法从外部访问系统。

（四）开源可审计

所用组件（Ollama推理引擎、MaxKB知识库平台）均为开源软件，源代码公开托管于代码仓库，全球开发者均可查阅。不存在隐蔽的数据回传机制、不存在"后门"。如有需要，可组织技术人员对源代码进行安全审查，逐行确认无外联逻辑。Ollama以MIT许可证发布，MaxKB以GPLv3许可证发布，均为业界主流的开源协议。

（五）硬件自主可控

本方案已在国产飞腾处理器（D2000，ARM64架构）+银河麒麟操作系统（V10）上验证通过，全链路使用国产软硬件，不依赖境外技术组件。处理器为飞腾信息（中国电子）产品，操作系统为麒麟软件（中国电子）产品，AI模型为深度求索（国产）和通义千问（阿里巴巴）产品。从芯片到系统到软件到模型，均为国产自主。

（六）综合评估

综上，本方案在数据流转的每个环节均满足"数据不出机、通信不联网、组件可审计、硬件自主化"的保密要求。与使用U盘拷贝文档、使用本地Office软件撰写材料相比，本方案的数据安全风险并未增加——它本质上就是"一台不联网的电脑上多装了几个软件"。

四、技术可行性验证

为验证方案的实际可行性，我单位于2026年7月在现有装备条件下完成了完整的部署测试。以下如实报告测试过程和结果。

（一）测试环境

特别说明：本方案未新增任何硬件采购，完全利用现有办公电脑即可运行。

（二）部署过程

全部安装工作由一名具备基本电脑操作能力的技术人员完成，总耗时约半天（含一次因光盘刻录问题导致的返工）。主要步骤为：

1.在能上网的电脑上下载好所有安装包和AI模型文件（共约15GB），通过U盘拷入飞腾电脑。

2.运行一键安装脚本，自动完成AI推理引擎的安装和配置（约5分钟）。

3.运行模型导入脚本，将5个AI模型逐一导入系统（约20分钟）。

4.安装知识库平台（自带所有依赖，无需联网，约15分钟）。

5.打开浏览器配置模型连接、上传测试文档、验证问答功能（约20分钟）。

整个过程无需联网，无需额外采购硬件，无需修改操作系统配置。

（三）运行效果

部署完成后，成功实现了以下功能：

一是智能问答。上传维修手册和条令条例后，用自然语言提问（如"某型装备液压系统常见故障有哪些""二级保养的必检项目有哪些"），系统可在10-20秒内基于文档内容给出结构化回答，并标注答案来源（具体到哪份文档的哪个段落）。

二是辅助撰写。输入要点和格式要求（如"3号车，二级保养，液压转向器渗油，更换密封圈，试车正常"），系统可在1-2分钟内生成一篇格式规范、用语标准的修理日志初稿，人工审核修改后即可使用。

三是资料检索。对历年维修档案进行电子化录入后，可通过自然语言快速定位历史记录（如"去年所有更换过活塞的发动机记录"），秒级返回结果，替代逐本翻阅。

四是格式校验。将写好的材料输入系统，可检查是否存在格式缺项、用语不规范等问题，辅助质量把关。

（四）性能数据

效率对比（以撰写一篇800字修理日志为例）：

效率提升约3-5倍。主要节省的是"从零写起"的时间，AI把"写"变成了"审"。

（五）稳定性

系统连续运行72小时（3天3夜），期间进行了约200次问答、上传了12份文档、切换了3次模型，未出现任何崩溃、卡死或异常。开机自启动，断电重启后自动恢复，无需人工干预。

五、解决的痛点与需求

结合本次实测，本方案可切实解决以下工作中的痛点：

（一）文书撰写耗时长

各类方案、报告、总结格式要求严格，从零撰写费时费力。AI可基于模板和历史范例快速生成初稿，将"写"的工作变为"审"的工作，大幅缩短成文时间。实测中，修理日志从40-60分钟缩短至8-14分钟，维修方案从2-3小时缩短至20-30分钟（含审核）。

（二）表格填写重复枯燥

装备履历、维修记录等表格字段固定但数量大。AI可辅助提取关键信息、自动填充表格字段，减少手工逐条录入的重复劳动。对于"同一信息填多张表"的情况，只需告诉AI一次，即可生成所有表格的对应内容。

（三）格式规范难以统一

不同时期、不同人员撰写的材料格式参差不齐，审核时经常因格式问题退回返工。AI可严格按照预设模板生成，确保格式统一、要素完整，从源头上减少返工。新同志无需反复学习格式规范，AI自动遵循。

（四）历史资料查找困难

纸质档案检索效率低，200余册档案中找一条记录需15-30分钟。将历史资料电子化导入知识库后，支持自然语言检索（如"去年某型发动机更换活塞的记录"），秒级定位，效率提升百倍以上。且支持跨年度、跨型号的综合查询，这是纸质档案无法实现的。

（五）经验传承依赖个人

老技师的维修经验往往停留在脑中，人走经验断。通过知识库沉淀，将个人经验转化为可检索、可传承的组织资产。年轻同志遇到问题时，相当于随时可以"请教"一位永不退休的老技师。

（六）年轻同志上手慢

新分配的维修人员需要较长时间熟悉文书规范和装备知识。AI知识库可作为"电子教员"，随时解答"这个表怎么填""这个故障以前怎么处理的""这个规程怎么规定的"等问题，加速人才培养。

六、应用前景与推广建议

（一）近期可落地的应用方向

一是维修文书智能辅助。覆盖修理日志、故障报告、维修方案、技术总结等高频文书的初稿生成和格式校验。这是最成熟、见效最快的方向，本次实测已充分验证。

二是装备知识库建设。将维修手册、操作规程、故障案例、条令条例等录入系统，形成可检索、可问答的"电子教员"，辅助年轻同志快速上手，缓解"师傅带徒弟"的人力压力。

三是数据统计辅助。对维修记录中的故障类型、频次、器材消耗等进行自动汇总和趋势分析（如"今年哪类故障最多""某型器材消耗趋势"），为决策提供数据支撑。

四是档案电子化。结合OCR（光学字符识别）技术，将历年纸质档案批量电子化后导入知识库，实现历史数据的"活化"利用。

（二）推广条件

本方案推广门槛极低：

硬件方面：一台16GB内存的国产电脑（飞腾/鲲鹏+麒麟系统）即可运行，无需专用服务器、无需显卡、无需联网。现有办公电脑即可满足，无需新增采购。

软件方面：全部为开源免费组件，无采购费用、无年度授权费、无使用人数限制。

部署方面：一键脚本安装，半天完成，一名技术人员即可操作。

维护方面：部署一次后长期可用，日常维护仅需定期更新模型文件（通过U盘拷入，约30分钟）和备份数据。

（三）注意事项

一是AI生成内容必须经人工审核。AI是"辅助工具"而非"替代者"，生成的文书初稿需由责任人审核确认后方可使用，确保内容准确、表述规范。建议建立"AI起草→人工审核→签字确认"的标准流程。

二是知识库内容需定期更新。新下发的条令条例、新列装装备的技术资料应及时录入，保证AI参考资料的时效性。建议指定专人负责，每季度至少更新一次。

三是做好数据备份。本机存储的知识库和文档应定期备份（建议每周一次），防止硬盘故障导致数据丢失。备份介质按涉密载体管理。

四是做好使用培训。虽然系统使用无门槛（打开浏览器即可），但仍需组织一次简短的操作培训（约30分钟），让使用者了解"怎么问效果好""哪些事AI能做、哪些不能"。

七、现有局限与不足

在肯定方案可行性的同时，必须如实说明当前条件下存在的局限，以便全面评估、合理预期。

（一）回答速度偏慢

飞腾D2000属于桌面级处理器，没有专用AI加速芯片（显卡），AI"思考"完全靠CPU逐字计算。实测中，轻量模型每秒生成约10-14个字，标准模型约6-10个字。打个比方：问一个简单问题，等回答大约需要10-20秒；让它写一篇800字的材料，需要等待1-2分钟。这与手机上用在线AI"秒回"的体验有明显差距（在线AI通常每秒50-100字），使用者需要有一定耐心。但考虑到文书工作本身不是"秒级响应"的场景（写一份材料本来就要几十分钟），等1-2分钟获得一篇初稿，总体效率仍然是大幅提升的。

（二）"聪明程度"有限

受硬件算力制约，目前只能运行小型模型（相当于"初级参谋"水平）。它能完成格式化的文书生成、资料检索、信息整理等规范性工作，但在需要深度推理、复杂分析、创造性思考的场景下，回答质量与商用在线AI存在明显差距。通俗地说：写个修理日志、查个数据、套个模板没问题，但让它做复杂的故障原因分析或写高质量的研究论文，还力不从心。它更像一个"听话的文书员"，而非"资深工程师"。

（三）不适合多人同时高频使用

一台电脑同时只能"想一件事"。如果多人同时提问，需要排队等待。日常3-5人低频使用（每人每10分钟问1-2次）没有问题，但不适合十几人同时密集交互的场景。如果未来使用人数增多，可考虑增配一台电脑分担负载。

（四）首次部署有一定技术门槛

虽然安装过程已封装为一键脚本，但初始环境准备（拷贝文件、校验完整性、排查问题）仍需具备基本计算机操作能力的人员完成。后续日常使用则无门槛，打开浏览器即可。建议每个单位指定一名"系统管理员"负责初始部署和日常维护。

（五）模型能力不会自动进步

离线部署的模型是"固定版本"，不会像在线服务那样持续升级变强。如需更强的能力，需要等待新版本模型发布后，通过U盘手动更新（约30分钟）。好消息是，开源AI模型更新迭代很快（几乎每月都有新版本），且新模型往往"更小更聪明"，更新后体验会逐步改善。

（六）客观看待

上述局限的本质原因是：我们在用一台普通办公电脑，做原本需要大型服务器集群才能做好的事。这是在"保密约束"和"硬件条件"双重限制下的务实选择——不追求最强效果，而是在合规前提下解决"有没有"的问题。随着国产AI芯片（如华为昇腾、寒武纪等）逐步成熟，未来若配备专用加速卡，速度和质量将有数倍乃至数十倍的提升空间。当前的部署架构无需推倒重来，只需加装一块加速卡即可大幅升级。

八、结论与建议

（一）主要结论

本次实测证明：在完全断网的部队内网环境下，使用国产硬件（飞腾D2000+麒麟V10）本地部署AI大模型和知识库系统，技术上完全可行，保密上完全合规，操作上简便易行。

该系统能够有效减轻装备维修工作中方案撰写、表格填写、文字记录、资料检索等方面的负担，将重复性文书工作的耗时压缩至原来的三分之一至五分之一，使技术人员将更多精力投入到实际维修保障中。

全部利用现有设备，未新增任何硬件采购，软件全部开源免费，无经费支出。

（二）建议

一是建议在本单位先行试用1-2个月，由维修岗位人员实际使用并反馈效果，积累第一手经验。

二是试用期间建立"AI辅助+人工审核"的工作规范，明确AI生成内容的审核责任和流程。

三是试用期满后评估效果，若确认有效，视情向兄弟单位推广。推广成本极低（一台现有电脑+一个U盘+半天时间）。

四是关注国产AI芯片发展，条件成熟时可申请配备AI加速卡，进一步提升使用体验。

报告人：（签名）

日期：2026年7月28日

背景与目标

在涉密或内网隔离环境中，在线AI服务不可用。本文记录在飞腾D2000（ARM64）+ 银河麒麟V10纯离线环境下，使用开源组件搭建本地AI知识库的完整过程。

最终效果：上传修理日志、装备手册等文档后，通过自然语言提问即可检索和生成结构化回答，辅助资料整理和档案撰写。全程本地推理，数据不出机器。

环境信息

架构概览

┌─────────────────────────────────────────────────┐
│              飞腾 D2000 / 麒麟 V10               │
│                                                 │
│  ┌──────────────┐       ┌───────────────────┐   │
│  │   MaxKB Pro  │──────▶│   Ollama Server   │   │
│  │  (Docker容器) │ HTTP  │  0.0.0.0:11434    │   │
│  │  :8080       │       │                   │   │
│  │  知识库/RAG   │       │  qwen3:4b         │   │
│  │  前端/多用户  │       │  deepseek-r1:1.5b │   │
│  └──────────────┘       │  bge-m3           │   │
│                         └───────────────────┘   │
│                              │                  │
│                         /data/ollama/models     │
│                         (GGUF模型文件)           │
└─────────────────────────────────────────────────┘

部署步骤

前置：联网机准备离线介质

在能上网的机器上下载以下文件，通过U盘或光盘（刻录时务必勾选数据校验）拷入飞腾机：

F:\ollma\
├── ollama\
│   ├── install_ollama.sh              # 一键安装脚本
│   └── ollama-linux-arm64\            # 已解压的Ollama（bin/ + lib/）
├── maxkb\
│   ├── maxkb-pro-v2.10.4-lts-arm64-offline-installer.tar.gz
│   └── maxkb-pro-license.key
├── models\
│   ├── qwen3-4b\                      # 2.4GB
│   ├── deepseek-r1-1.5b\             # 1.1GB
│   ├── bge-m3\                        # 418MB
│   ├── qwen2.5-7b\                    # 4.4GB
│   └── deepseek-r1-7b\               # 4.4GB
└── scripts\
    ├── import_models.sh               # 模型导入
    └── verify_models.sh               # MD5校验

Step 1：安装 Ollama

将介质拷到飞腾机 /data/ollma，执行一键安装：

sudo bash /data/ollma/ollama/install_ollama.sh

脚本自动完成：架构校验 → 安装二进制+运行库 → 建用户 → 写systemd → 启动 → 验证。

验证：

ollama --version
# ollama version 0.32.3

ss -tnlp | grep 11434
# LISTEN  0  128  0.0.0.0:11434  0.0.0.0:*

关键点：Ollama v0.32+ 解压后包含 bin/ollama 和 lib/ollama/（共享库），两者都要部署。脚本会自动处理 ldconfig 注册。

Step 2：导入模型

sudo bash /data/ollma/scripts/import_models.sh
ollama list

预期输出：

NAME                    SIZE
qwen3:4b                2.4 GB
deepseek-r1:1.5b        1.1 GB
bge-m3                  418 MB
qwen2.5:7b              4.4 GB
deepseek-r1:7b          4.4 GB

Step 3：安装 MaxKB 专业版

MaxKB离线安装器自包含Docker引擎，无需预装任何依赖：

cd /data/ollma/maxkb
tar xzf maxkb-pro-v2.10.4-lts-arm64-offline-installer.tar.gz
cd maxkb-pro-v2.10.4-lts-arm64-offline-installer
sudo bash install.sh

# 确认服务
sudo mkctl status
# maxkb    running
# pgsql    running
# redis    running

Step 4：MaxKB 接入 Ollama

浏览器打开 http://<飞腾机IP>:8080，默认账号 admin / MaxKB@123..。

添加对话模型：系统管理 → 模型管理 → 添加模型

添加向量模型：同上，模型类型改为 Embedding模型，模型名填 bge-m3。

注意：URL必须填飞腾机的局域网IP（如 192.168.1.100:11434），不能填 127.0.0.1。MaxKB跑在Docker容器里，localhost 指向容器自身而非宿主机。

Step 5：建知识库

1. 创建知识库 → 命名（如"修理档案库"）
2. 上传文档（支持 docx / pdf / pptx / txt / md）
3. 系统自动分段 + 向量化（bge-m3）
4. 绑定到应用 → 分发访问地址

性能实测

飞腾D2000 纯CPU推理，无GPU加速：

建议：日常用 1.5B 或 4B，7B 仅在需要更强推理能力时切换。

踩坑记录

1. ARM64 架构红线

飞腾D2000是aarch64，所有二进制必须ARM64版本。用x86_64的包会报：

exec format error

2. Ollama 新版需要运行库

v0.32+ 的tar包解压后不只是一个 ollama 二进制，还有 lib/ollama/ 目录（libggml、libllama等十几个.so）。只拷二进制会报找不到共享库。

解决：安装脚本已处理（复制到 /usr/local/lib/ollama/ + ldconfig）。手动装的话：

sudo cp -af lib/ollama/. /usr/local/lib/ollama/
echo "/usr/local/lib/ollama" | sudo tee /etc/ld.so.conf.d/ollama.conf
sudo ldconfig

3. 离线环境无法安装 zstd

原始Ollama发布包是 .tar.zst 格式，但飞腾机没网装不了zstd。

解决：在联网机上先解压好（zstd -d + tar xf），直接拷解压后的目录到飞腾机。

4. Docker容器访问宿主机Ollama

MaxKB在Docker里，填 127.0.0.1:11434 连不上（那是容器自己）。

解决：

• Ollama 监听 0.0.0.0:11434（systemd里配 OLLAMA_HOST=0.0.0.0:11434）
• MaxKB里填飞腾机真实IP
• 防火墙放行：sudo firewall-cmd --zone=public --add-port=11434/tcp --permanent && sudo firewall-cmd --reload

5. 光盘刻录数据损坏

13GB模型文件刻DVD，不校验就是赌博。文件头看着对（GGUF魔数通过），但中间数据损坏，ollama create 时报 "not in GGUF format"。

解决：

• 刻录时勾选"刻录后校验数据"
• 或改用U盘
• 部署前跑 md5sum -c CHECKSUM 校验

总结

这套方案在完全断网的国产ARM平台上跑通了从模型推理到知识库问答的完整链路：

• 零外网依赖：所有组件离线安装，模型本地推理
• 零GPU依赖：纯CPU跑4B以下量化模型，日常够用
• 数据主权：全程本地，满足保密要求
• 可复制：全部开源组件 + 一键脚本，其他飞腾/鲲鹏机器可照搬

对于有保密要求、无法使用在线AI服务的场景，这是一条经过验证的可行路径。

部署工具包含完整脚本（install_ollama.sh / import_models.sh / verify_models.sh），如需获取欢迎交流。