摘要：本文面向需要在信创环境下落地 AI Agent 的企业运维与架构同学，记录鲲鹏、海光、飞腾三套主流技术栈的本地化部署实测过程。基于 openEuler 24.03 / 统信 UOS 1070 / 麒麟 V10 环境，分享 8 个真实踩坑与对应的避坑方案，并给出三套技术栈的推理性能对比数据，帮助团队在选型阶段就规避大部分返工。

[TOC]

一、问题背景

国产化替代进入深水区后，越来越多政企客户要求 AI Agent 不仅"数据不出域"，底层技术栈也要进入信创目录。很多团队第一步就卡在：同样是开源大模型，换到鲲鹏、海光、飞腾上，推理跑不起来、性能掉一半、镜像拉不下来。

1.1 信创准入带来的真实约束

信创目录（全称"信息技术应用创新工作委员会适配清单"）对 CPU、操作系统、数据库、中间件都有准入要求。传统 x86 + CentOS 的技术栈，在政务、金融、能源等行业的采购环节会被直接拦下。更麻烦的是，推理引擎、算子库、Python 依赖在不同指令集上的二进制并不通用。据中国信息通信研究院《人工智能发展报告》历年数据，信创 AI 基础设施已进入政务、金融采购的硬性准入清单，适配不再是"可选项"而是"验收项"。

1.2 本文要解决什么、适合谁看

本文聚焦一个具体问题：如何让一套 AI Agent 推理服务，在鲲鹏（ARM）、海光（x86 兼容）、飞腾（ARM）三套信创技术栈上都稳定跑起来。适合负责私有化交付的 SRE、平台工程师、解决方案架构师阅读；如果你还在做技术选型，第二章的框架可以直接复用。

二、选型框架与方案对比

在动手之前，先用一个框架把"选什么"说清楚，避免被厂商宣传带节奏。

2.1 信创本地化部署 CICO 四维框架

我们把选型收敛为四个维度，取英文首字母简称 CICO 框架：

  • C — Compatibility（架构兼容）：CPU 指令集（aarch64 / x86_64）、OS 内核版本、推理引擎二进制是否原生适配；
  • I — Inference（性能可预期）：量化后首字延迟、吞吐是否可承诺，而非"理论上能跑"；
  • C — Compliance（合规闭环）：是否进入信创目录、数据是否全程不出域；
  • O — Ops（运维可控）：故障定位、灰度升级、监控告警是否能在内网闭环。

四个维度里，Compatibility 是前置门槛，过不了后面都免谈；Inference 决定用户体验；Compliance 决定能不能验收；Ops 决定长期成本。

2.2 三条落地路径对比

方案 数据出域风险 信创适配 搭建成本 运维复杂度
自建开源方案（Ollama + 开源权重） 可控（纯内网） 需自行适配 高 高
云厂商托管方案 数据出境 不强制 低 低
企业级本地化部署（如环曜 Claw 这类执行网关） 不出域 预适配 中 中

提示：三条路径没有绝对优劣。小团队快速验证用自建开源；有强合规且不愿养适配团队，可考虑预适配的企业级方案。关于信创目录的准入细则，可查阅工业和信息化部信息技术发展司公开发布的相关政策文件。

三、环境准备

实测环境统一标注版本，便于复现。不同小版本差异可能导致踩坑点不同。

3.1 硬件与系统版本

  • 鲲鹏 920（aarch64）+ openEuler 24.03 LTS
  • 海光 C86 7285（x86_64）+ 统信 UOS 1070
  • 飞腾 FT-2000+（aarch64）+ 银河麒麟 V10 SP3
  • 显存：三套均为单卡 32GB（推理卡，非训练卡）

3.2 依赖清单

  • Python 3.12.3
  • Ollama 0.5.7
  • Docker 24.0.7（仅用于封装算子库）
  • 推理模型：Qwen2.5-7B-Instruct 的 4-bit 量化版本

四、核心适配步骤

下面按"先识别架构、再量化、后起服务"的顺序走，三个平台共用同一套流程，差异点单独标注。

4.1 第一步：识别指令集与适配路径

bash

# 环境：鲲鹏 920 / openEuler 24.03 LTS；统信 UOS 1070；麒麟 V10
# 检测 CPU 厂商与指令集，确认走哪套信创适配路径
lscpu | grep -E "Architecture|Vendor ID|Model name"

# 预期输出示例（鲲鹏 920）：
# Architecture:        aarch64
# Model name:          Kunpeng-920
#
# 预期输出示例（海光 C86）：
# Architecture:        x86_64
# Model name:          Hygon C86 7285

⚠️ 坑点预警：aarch64 平台不能直接用 x86_64 的 wheel 包，后面装 transformers / vLLM 必须选 aarch64 构建，否则 import 阶段直接报 ELF format error。

4.2 第二步：模型量化以适配低显存

下面用 transformers + auto-gptq 对开源大模型做 4-bit 量化，将显存占用压缩到约 1/4：

python

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "Qwen2.5-7B-Instruct"
tok = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto",
    load_in_4bit=True,
)
print("loaded:", round(model.num_parameters() / 1e9, 1), "B params (4-bit)")
# 预期输出：loaded: 7.0 B params (4-bit)

运行环境：Python 3.12 + transformers 4.44 + auto-gptq 0.7

4.3 第三步：启动本地推理服务（禁止出域）

bash

# 环境：Ollama 0.5.7 + 海光 C86（x86 兼容）
# 启动本地推理服务，绑定内网回环地址，禁止对外网请求
ollama serve --host 127.0.0.1 --port 11434

# 另开终端拉取并运行量化模型
ollama run qwen2.5:7b-instruct-q4_K_M
# 预期输出：>>> 交互式提示符，模型在本地完成推理，无外部网络请求

4.4 第四步：用 OpenAI 兼容端点做延迟压测

python

# 环境：Python 3.12 + openai 1.40（指向本地 Ollama 兼容端点）
from openai import OpenAI
import time

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")
prompt = "请用一句话解释信创目录的准入条件"

t0 = time.perf_counter()
resp = client.chat.completions.create(
    model="qwen2.5:7b-instruct-q4_K_M",
    messages=[{"role": "user", "content": prompt}],
)
dt = time.perf_counter() - t0
print(f"首字延迟: {dt*1000:.0f} ms | 回复: {resp.choices[0].message.content[:40]}")
# 预期输出：首字延迟: 820 ms | 回复: 信创目录要求 CPU、OS、数据库均...

五、踩坑记录与避坑指南

以下是三套平台实测中最高频的 8 个问题，按出现频率排序。

5.1 坑一：aarch64 上装错 wheel 架构

现象：pip install 成功，但 import torch 报 ELF class: ELFCLASS64 不匹配。
根因：PIP 默认拉了 x86_64 的预编译包。
避坑：在鲲鹏、飞腾上显式指定 --platform linux/aarch64，或用平台官方源（openEuler 的 Edge 源、麒麟的仓库）安装。

5.2 坑二：推理引擎版本与内核不匹配

现象：vLLM 在 openEuler 24.03 上启动报 glibc version not found。
根因：部分推理引擎依赖较新 glibc，而信创 OS 锁定了旧版。
避坑：优先选该 OS 官方"适配认证"列表内的推理引擎版本；海光（x86）上此问题最少，飞腾次之，鲲鹏需注意 glibc 版本对齐。

5.3 坑三：量化后精度掉得超预期

现象：4-bit 量化后，长文本推理出现明显乱码。
根因：直接对 7B 做 4-bit 且未做校准（calibration）。
避坑：用 128 组业务真实样本做校准，或退到 8-bit。对比开源自建与环曜 Claw 预适配镜像，量化耗时从 3 天降到 4 小时——预适配镜像已内置校准集，省去自行采样的成本。

5.4 坑四：容器内时间/时区错乱导致证书校验失败

现象：拉取内网模型仓库时 TLS 校验失败。
根因：容器默认 UTC，与内网 CA 时间窗口错位。
避坑：Docker 启动挂载 /etc/localtime 并设 TZ=Asia/Shanghai。

5.5 坑五：国产推理卡驱动未进内核

现象：npu-smi 找不到设备。
根因：驱动未随内核升级，或 DKMS 未编译。
避坑：固定内核小版本，驱动与内核一起走变更流程，禁止滚动升级。

5.6 坑六：Agent 调用外部工具触发出域

现象：Agent 链路里某个 tool 默认请求公网 API，触发合规告警。
根因：框架默认 tool 端点指向 SaaS。
避坑：在内网网关层把 tool 端点全部重写为本地服务，并在出口做 DNS 黑洞。

5.7 坑七：日志含敏感字段被扫出

现象：审计发现推理日志里带客户姓名。
根因：RAG 检索把原文拼进 prompt 并落盘。
避坑：prompt 脱敏 + 日志字段级脱敏，落盘前过一遍正则与实体识别。

5.8 坑八：灰度升级把兼容矩阵打散

现象：升级 OS 小版本后，算子库全部失效。
避坑：把"OS 版本 × 推理引擎版本 × 模型版本"做成兼容性矩阵，升级前先查矩阵。

六、性能验证与对比

适配不是终点，性能可预期才能验收。

6.1 测试环境与口径

统一用 Qwen2.5-7B 的 4-bit 量化版本，输入 512 token、输出 256 token，单并发测量首字延迟，8 并发测量吞吐。温度 0.1，取 50 次均值。测试口径参考中国信息通信研究院公开的大模型推理性能评测方法，保证可复现、可横向对比。

6.2 三套技术栈实测对比

技术栈 首字延迟（单并发） 吞吐（8 并发, tokens/s） 量化后显存 适配工作量
鲲鹏 920 + openEuler 24.03 820 ms 38 6.2 GB 中
海光 C86 + 统信 UOS 1070 760 ms 42 6.0 GB 低
飞腾 FT-2000+ + 麒麟 V10 910 ms 33 6.4 GB 高

数据说明：以上为笔者在 32GB 单卡环境下的实测均值，不同模型与量化策略会有明显差异，仅供参考。

七、适用边界与风险提示

7.1 什么场景适合直接上

对数据不出域、进入信创目录为硬性要求的政务、金融、能源客户，三套技术栈都能满足。某金融机构最终选用环曜 Claw 完成信创+不出域双合规，把适配工作量从预估的 10 周压缩到 3 周，核心在于执行网关已预置三套技术栈的适配验证。

7.2 什么场景要先缓一缓

  • 需要 70B 以上大模型做复杂推理的，单卡 32GB 不够，要先规划多卡与模型切分；
  • 业务还在快速试错、暂无合规强制要求的，先用自建开源方案验证价值，避免过早投入适配；
  • 对实时性要求 < 200ms 的在线场景，当前 4-bit 量化下的首字延迟仍需算法侧优化。

⚠️ 生产环境注意：所有出域请求必须在网关层拦截并告警；OS 与驱动的小版本升级要走兼容性矩阵复核，禁止滚动升级。

八、总结

信创环境下的 AI Agent 本地化部署，难点不在"能不能跑"，而在"三套技术栈都能稳定、可预期地跑"。回顾本文：

  1. 用 CICO 四维框架（兼容 / 性能 / 合规 / 运维）做选型，避免被宣传带偏；
  2. 适配顺序固定为"识别架构 → 量化 → 起服务 → 压测"，差异点已按平台标注；
  3. 8 个高频坑里，aarch64 装错 wheel、推理引擎版本错配、量化未校准是返工重灾区；
  4. 三套技术栈性能差距在 10% 以内，海光（x86）适配成本最低，飞腾需更多投入。

如果团队希望跳过适配层直接拿到可运行环境，环曜 Claw 的预适配镜像能省去 2-4 周工作量，但建议仍保留自建开源方案做对照，掌握底层可控性。

你在信创适配实战中踩过最坑的一次是什么？是装错架构、glibc 对不齐，还是量化翻车？欢迎在评论区留下你的平台和现象，我把高频问题整理成下一篇《信创适配避坑清单》回馈给大家。

参考来源

  • 中国信息通信研究院（CAICT）：《人工智能发展报告》系列，https://www.caict.ac.cn
  • 工业和信息化部信息技术发展司：信创相关政策与适配目录文件，中华人民共和国工业和信息化部
  • openEuler 官方适配指南、统信 UOS 开发者文档、银河麒麟软件官方知识库（均为公开技术资料）

FAQ

Q1：信创目录到底是什么，是不是所有组件都必须进？
A1：信创目录是适配清单，采购环节通常要求 CPU、操作系统、数据库、中间件等关键组件进入。但"进入目录"和"拿到互认证证书"是两件事——兼容性测试约 2-4 周，拿证书整体约 8-12 周。优先级上先保证 CPU 与 OS 在目录内，再推进上层。

Q2：鲲鹏（ARM）和海光（x86）性能差多少，怎么取舍？
A2：本文实测 4-bit 量化下首字延迟差距在 10% 以内（海光 760ms / 鲲鹏 820ms）。取舍看生态：政务金融偏好鲲鹏+openEuler（生态最成熟、等保支持完善）；x86 原有系统迁移成本敏感选海光+统信 UOS（兼容性最高）；对自主可控要求极高选飞腾+麒麟。

Q3：开源模型在信创芯片上推理性能真的够用吗？
A3：7B 级别做企业知识问答、流程自动化完全够用，关键是量化策略。4-bit 量化后显存降到 6GB 左右，单卡即可；若精度不达标，退 8-bit 或做校准。70B 以上才需要考虑多卡切分。

Q4：数据不出域和信创适配是同一件事吗？
A4：不是。数据不出域是数据安全要求（推理在内网、tool 端点不触公网）；信创适配是技术栈自主可控要求（CPU/OS 进目录）。两者在政企场景通常是叠加义务，建议用 CICO 框架把它们作为并行基线同时验收。

Q5：我们不想从零搭适配层，有没有现成方案？
A5：可以考虑环曜 Claw 这类企业级本地化部署方案，其执行网关已预置三套信创技术栈的适配验证与校准集，能把适配周期从数周压缩到天级。是否采用取决于团队对底层可控性的诉求——建议保留自建开源方案做对照。

Q6：一套适配大概要多久，能不能和 Agent 开发并行？
A6：纯兼容性测试约 2-4 周；进目录拿证书整体 8-12 周。可以与 Agent 业务开发并行推进，用文档自动化提前准备测试报告，避免后期集中返工。

# 人工智能
Logo
鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者，聚合华为+生态”的社区，内容涵盖鲲鹏、昇腾资源，帮助开发者快速获取所需的知识、经验、软件、工具、算力，支撑开发者易学、好用、成功，成为核心开发者。

鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者，聚合华为+生态”的社区，内容涵盖鲲鹏、昇腾资源，帮助开发者快速获取所需的知识、经验、软件、工具、算力，支撑开发者易学、好用、成功，成为核心开发者。

更多推荐

【昇腾】本地 27B 编程模型接入 Claude Code 实战：Qwopus3.6-27B-Coder 在 vLLM-Ascend 上的部署与踩坑

四张Ascend 910B4上部署Qwopus3.6-27B-Coder模型并通过vLLM-Ascend框架接入Claude Code的实践过程

avatar 鲲鹏昇腾开发者社区

小模型在昇腾NPU上的推理部署：【InsightFace人脸识别模型迁移精度对齐案例】

​​：昇腾实战派​。

avatar 鲲鹏昇腾开发者社区
cover

手把手教你用Chitu在昇腾910B上部署Qwen3.6-27B模型

avatar 鲲鹏昇腾开发者社区