龙架构双周会第42期于2026年8月2日举行。这个系列例会主要围绕LoongArch生态的技术协同展开，讨论范围通常覆盖内核适配、编译器工具链、运行时、桌面应用、云原生和AI加速等方向。对于想在龙架构设备上落地业务的开发者来说，这类会议的真正价值不是看厂商发布了什么宣传材料，而是判断当前软件适配到底走到了哪一步：哪些组件已经进主线，哪些还要依赖发行版维护，哪些只能靠实验分支跑通。
需要先说清楚：本文不替会议写纪要，也没有办法还原第42期的每一个具体议题，真实会议议程请以官方渠道为准。这篇文章更想做的事，是从工程落地角度把LoongArch生态中已经相对稳定的能力梳理出来，给出一套可以照做的本地部署和验证流程。如果你正准备在龙架构设备上运行服务，或者要评估存量系统能否迁移到LoongArch，可以直接按文章里的步骤过一遍，先确认架构、再配环境、再跑服务、最后看性能，整个闭环走完，心里基本就有底了。
1. LoongArch 核心能力速览
先把最关键的规格放在前面。以下信息以公开技术资料和常见发行版适配情况为基础，具体版本支持范围必须结合你手上设备的操作系统和软件源确认。
| 能力项 | 说明 |
|---|---|
| 指令集架构 | LoongArch 32/64 位指令集，由龙芯主导设计 |
| 典型处理器 | 龙芯 3A5000、3A6000 等系列芯片 |
| 操作系统支持 | 统信 UOS、麒麟、Loongnix 等；社区发行版包括 Debian loong64 移植、Arch Linux loongarch64 等 |
| 内核支持 | Linux 内核主线已合入 LoongArch 支持，具体启用功能取决于内核版本 |
| 编译器工具链 | GCC、LLVM/Clang 等主流工具链已提供 LoongArch 后端 |
| 语言运行时 | JDK、Python、Node.js、Go 等运行时对 loongarch64 的支持需要按版本逐项验证 |
| 容器支持 | Docker 等 OCI 运行时可用于 loongarch64 架构镜像 |
| 二进制翻译 | 部分龙芯平台提供 x86 兼容执行能力，适合老应用迁移，性能损耗以实测为准 |
| 启动方式 | 设备固件引导操作系统，常规服务通过 systemd 管理 |
| 适合场景 | 信创办公、Web 服务、数据库、消息中间件、边缘计算、CI 编译节点 |
这张表没有写死每个软件包的版本，原因是 LoongArch 生态更新节奏非常快，不同发行版仓库里的包版本差异很大。最可靠的判断方式是在目标机器上执行两条命令，看到真实答案以后再决定安装策略。
uname -m cat /etc/os-release如果输出loongarch64，说明当前系统是 64 位 LoongArch；如果输出的是x86_64，说明设备运行在 x86 兼容模式下，后面排查问题时要格外注意平台差异。
2. 双周会关注方向与 LoongArch 生态进展
结合龙架构双周会这类生态例会通常会展开的技术方向，以及公开可以观察到的适配进度，当前值得关注的生态维度主要集中在这五个方面。
2.1 内核与基础软件
LoongArch 与 Linux 内核的合入是生态建设的第一步。现在主流通用内核已经具备 LoongArch 支持，发行版内核也会默认开启相应架构选项。基础 C 库、动态链接器、启动引导等组件完成了对齐，普通用户态程序在源码级重新编译后，通常不需要做复杂修改就能运行。实际部署中，最需要留意的反而是厂商定制内核和第三方驱动，它们不一定跟随上游更新，可能导致容器、虚拟化、安全模块等特性缺失。
2.2 编译工具链与语言运行时
GCC 和 LLVM 对 LoongArch 的支持已经进入可用的实用阶段，C/C++ 项目的编译选项里有loongarch64目标，配置--host=loongarch64-linux-gnu可以完成交叉编译。Java、Go、Python、Node.js 等运行时也已经出现 loongarch64 版本，但不同版本的 JDK 和 Node.js 对 LoongArch 的优化程度不一致，个别语言包可能依赖尚未适配的原生扩展模块。判断标准很简单：在一个干净环境里安装依赖并运行官方示例，能通过就算适配成功。
2.3 云原生与容器生态
容器技术让架构差异变得更容易被掩盖。只要基础镜像和程序二进制都是 loongarch64，Docker Compose 部署方式与 x86 环境没有太大区别。Kubernetes 这类编排系统对多架构集群的支持已经比较成熟，LoongArch 节点可以作为独立节点加入集群。需要注意的是，很多镜像仓库里的热门镜像只有 amd64 和 arm64 版本，没有 loongarch64 版本，直接 pull 会失败，这时需要重新构建镜像或改用源码部署。
2.4 桌面办公与业务系统迁移
桌面办公是 LoongArch 设备最常见的落地场景。浏览器、办公套件、输入法、即时通讯、视频会议这类高频软件，在主流国产操作系统中已经有对应版本。业务系统迁移方面，典型路径是把同一套源码在 loongarch64 上重新编译，而不是依赖 x86 二进制。对于无法获得源码的存量商业软件，部分龙芯平台提供了 x86 兼容执行能力，但这类方案应该视为过渡手段，不适合作为长期生产环境核心依赖。
2.5 AI 与异构计算
这是 LoongArch 生态中还需要重点观察的领域。与 x86 平台常见的 CUDA 生态不同，LoongArch 设备上的 AI 推理通常依赖 CPU 指令集优化和厂商提供的异构计算方案。ONNX Runtime、PaddlePaddle 等框架在资源充足的前提下，可以完成 CPU 推理任务，但训练大模型或高并发 GPU 推理场景暂时不要指望与成熟 x86 + NVIDIA 环境同等效率。选型时要把 AI 工作负载拆开，明确哪些环节可以在 LoongArch 上跑，哪些环节必须保留异构算力。
3. 适用场景与使用边界
3.1 适合什么场景
从目前公开案例和工程实践看，LoongArch 比较适合以下几类负载：
- 标准 Web 服务：Nginx、Tomcat、Spring Boot、Node.js 服务。
- 数据库与存储：MySQL、PostgreSQL、SQLite 等主流数据库的 loongarch64 版本可运行。
- 消息与缓存：Redis、RabbitMQ、Kafka 在源码编译后可以部署。
- 企业内部系统：OA、ERP、CRM 等基于 Java/Python 的业务系统迁移成本较低。
- 边缘计算与专用设备：嵌入式网关、边缘服务器、信创终端。
3.2 不适合什么场景
- 严重依赖 x86 专用指令优化的程序，需要重新编译才能发挥正常性能。
- 闭源商业软件没有提供 LoongArch 版本且授权条款不允许兼容运行，不建议强行迁移。
- GPU 视频渲染、CUDA 深度训练、专业图形工作站在 LoongArch 上的支持有限。
- 对内核实时性、虚拟化特性有严格要求的场景，需要先验证系统版本和内核配置。
3.3 合规与安全边界
架构迁移会涉及软件授权、数据安全和隐私保护问题。使用二进制翻译运行旧软件时，要确认软件许可是否允许跨架构兼容；部署业务系统时，应使用测试数据完成全流程验证；涉及公民个人信息、金融交易、医疗健康等敏感数据时，需要遵循业务所在领域的合规要求，不能因为换了一个 CPU 架构就降低安全基线。整体原则是：先在隔离环境验证，再谈生产接入。
4. 环境准备：先确认设备是什么架构
4.1 硬件检查
拿到一台龙架构设备后，先不要急着装软件，先做三个基础检查。
# 查看CPU架构 uname -m # 查看操作系统发行版信息 cat /etc/os-release # 查看CPU详细信息 lscpu | head -20重点关注四类信息：架构标志、CPU 核数、内存大小、系统版本。如果机器是虚拟机，还要确认虚拟化平台是否把 LoongArch 指令集完整透传给了客户机；部分云平台提供的“国产 CPU 实例”在底层可能是模拟执行，性能数字不具备参考意义。
4.2 磁盘与分区
建议预留至少 50GB 磁盘空间给系统，再单独划分一个数据盘用于存放应用、日志和数据库文件。分区时给/var/lib/docker留出足够空间，因为容器镜像和容器日志会快速占用磁盘。查看磁盘使用情况的命令如下：
df -h lsblk4.3 网络与软件源
LoongArch 设备需要能访问操作系统的软件源。如果是内网环境，必须提前准备离线安装包或内网镜像源。建议先把软件源切换为连通性最好的镜像站点，减少后续安装依赖失败的可能。
# 以 Debian/统信UOS系发行版为例，配置文件位置是： # /etc/apt/sources.list 或 /etc/apt/sources.list.d/ sudo apt update如果更新时报 404 或 403，大概率是软件源里没有匹配当前系统版本的 loongarch64 软件包，需要换用该发行版官方提供的龙架构源。
5. 安装部署：从操作系统到应用服务
5.1 系统安装
系统安装步骤取决于你选择哪个发行版。基础流程是：制作启动盘、引导进入安装器、选择手动分区、设置用户名密码、完成安装后重启。安装完成后，第一件事是确认系统能正常更新，以及内核版本与设备固件匹配。
5.2 安装基础工具包
以 Debian 系发行版为例，安装常用开发工具和运行环境：
sudo apt update sudo apt install -y build-essential git curl wget tar \ python3 python3-pip python3-venv \ openjdk-17-jdk nginx docker.io docker-compose安装完成后，检查 Docker 服务是否正常运行：
sudo systemctl enable --now docker sudo docker run --rm hello-world如果 hello-world 镜像拉取失败，先确认镜像仓库是否有 loongarch64 架构的镜像。某些第三方镜像仓库没有这个平台标识，直接拉取会报no matching manifest，解决问题的方法是使用官方支持源或自己构造 loongarch64 基础镜像。
5.3 启动一个 Nginx 服务
安装 Nginx 后，启动服务的动作在 LoongArch 上与 x86 完全一致：
sudo systemctl start nginx sudo systemctl enable nginx curl http://127.0.0.1/curl 返回 Nginx 默认页说明部署成功。如果 curl 提示连接拒绝，先看服务状态和防火墙：
sudo systemctl status nginx sudo ss -lntp | grep 805.4 编译安装必要的原生扩展
部分 Python 或 Node.js 扩展包没有提供 loongarch64 预编译 wheel，安装时会走源码编译。此时系统必须装好python3-dev和编译工具链，否则会出现gcc: command not found或缺少头文件的报错。建议先建立虚拟环境，再安装依赖：
python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install fastapi uvicorn执行完这一步，就能确认当前 Python 工具链在 LoongArch 上是否完整可用。
6. 功能测试与效果验证
部署完成后，不要急着上生产，按下面的维度完成验证。
6.1 CPU 基准验证
用一段简单的 Python 循环测试 CPU 和 Python 运行时的基础性能：
python3 - <<'PY' import time, math start = time.time() total = 0.0 for i in range(1, 2000000): total += math.sqrt(i) * 0.0001 print("elapsed:", round(time.time() - start, 3), "s") print("result:", round(total, 3)) PY这个测试的意义不是横向对比 x86，而是确认 Python 运行时在 LoongArch 上能正常完成浮点运算。如果运行时间异常长，或者出现illegal instruction，说明 Python 版本和当前处理器的指令集扩展不匹配。
6.2 C 语言编译测试
用源码编译验证工具链完整性：
#include <stdio.h> int main(void) { printf("Hello LoongArch\n"); return 0; }gcc -O2 -o hello hello.c file hello ./hellofile hello输出中应包含loongarch64或类似架构标记，./hello正常打印字符串，说明编译工具链和加载器都没有问题。
6.3 Web 服务功能测试
在龙架构上部署一个典型 Web 应用，验证从启动到外部访问的完整链路。以 FastAPI 为例，创建app.py：
from fastapi import FastAPI import platform import os app = FastAPI() @app.get("/") def home(): return {"message": "loongarch64 service ok"} @app.get("/api/sysinfo") def sysinfo(): return { "platform": platform.platform(), "machine": platform.machine(), "cores": os.cpu_count() }启动服务：
uvicorn app:app --host 0.0.0.0 --port 8000使用 curl 验证：
curl http://127.0.0.1:8000/api/sysinfo预期返回 JSON 中machine字段为loongarch64。如果服务能正常返回，说明网卡、端口监听、Python Web 框架、系统调用链全部通路正常。
6.4 判断成功的标准
- 系统命令执行无
Segmentation fault。 - 软件包安装依赖解析成功。
- Web 服务可访问且 JSON 返回正确。
- 数据库读写测试通过。
- 日志中没有架构相关报错。
6.5 常见失败动作
pip install阶段失败，通常是没有 loongarch64 的 wheel，需要在编译前安装对应依赖；Docker pull 失败，通常是镜像平台不匹配；Nginx 启动失败，通常是端口被占用或配置文件里写死了模块路径。这些问题都可以通过查看日志定位，不要盲目重装系统。
7. 接口 API 与批量任务示例
7.1 部署业务接口
LoongArch 服务器与 x86 服务器在 API 服务上并没有本质区别。上面 FastAPI 服务启动后，其他机器可以通过网络调用接口。外部调用示例：
curl -X POST http://<服务器IP>:8000/api/sysinfo \ -H "Content-Type: application/json" \ -d '{"check": true}'在 LoongArch 设备上部署 API 服务时，重点要验证的不是框架本身，而是框架依赖的底层库是否都完成了架构适配。建议写一个小的健康检查接口，定时轮询，避免依赖方在服务异常时无法感知。
7.2 批量任务处理
LoongArch 设备很适合做批量计算和离线任务。给一批文件做转码、压缩或数据清洗时，可以用 shell 脚本并行执行：
#!/bin/bash # 批量处理 tasks 目录下的文件 mkdir -p output find ./tasks -type f | while read -r file; do filename=$(basename "$file") python3 process.py "$file" > "output/${filename}.log" 2>&1 & if (( $(jobs -r | wc -l) >= 4 )); then wait -n fi done wait echo "batch task done"这里的wait -n表示任意一个后台任务完成后继续调度，适合多核龙架构设备。批量任务建议把每个任务的结果单独写日志，崩溃时不至于丢失所有现场。
7.3 与 CI 集成
LoongArch 可以作为 CI 平台的编译执行节点，完成交叉编译或镜像构建。在 Jenkins 或 GitLab CI 中注册节点时，注意保证构建环境和运行环境一致，不要用 x86 写脚本、再到 LoongArch 上运行二进制。
# .gitlab-ci.yml 中指定 runner 标签 build_loongarch: tags: - loongarch64 script: - uname -m - gcc -O2 -o app main.c - ./app这一步能帮助团队在代码提交阶段就发现架构兼容问题，避免上线时措手不及。
8. 资源占用与性能观察
8.1 观察方法
LoongArch 设备上，资源占用观察方法和通用 Linux 完全一致。推荐使用组合命令：
# 实时查看CPU和内存 top -d 2 # 查看内存详情 free -h # 查看磁盘IO iostat -x 2 # 查看具体进程的资源占用 pidstat -p $(pgrep -f uvicorn) 2重点观察三块：CPU 使用率是否被打满、内存交换是否频繁、磁盘 IO 是否成为瓶颈。如果free -h显示 swap 持续增长，说明物理内存不够用，需要降低并发数或增加内存条。
8.2 性能影响因素
- CPU 核数与主频：决定并行任务上限。
- 编译优化等级：
-O2与-O0的性能差距在 LoongArch 上同样明显。 - 内存带宽：数据库类应用对内存带宽敏感。
- 磁盘类型：SSD 和 HDD 在批量 IO 任务上差距很大。
- 程序是否走二进制翻译：翻译执行的程序性能通常比原生编译程序差。
8.3 降低资源占用的做法
- Web 服务调整 worker 数，避免进程数远超 CPU 核数。
- 数据库类型应用关闭不必要的日志同步策略，改为异步提交。
- 容器运行时设置内存限制，防止单个容器拖垮宿主机。
- Python 服务使用多进程时，合理设置批量任务并发数。
8.4 压力测试
对 Web 服务做简单压测，并同时观察资源变化：
ab -n 10000 -c 50 http://127.0.0.1:8000/api/sysinfo压测结果只能代表当前环境的数据，不要直接拿来和 x86 机器对比。更有效的做法是：保持同一套代码，在同一台 LoongArch 设备上分别测试不同并发数，找出当前配置的拐点，再根据业务容量决定是否扩容。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 系统无法引导 | 固件启动项或启动盘制作错误 | 检查固件启动菜单，验证镜像校验值 | 重新制作启动盘，选择正确启动项 |
| apt/yum 更新报 404 | 软件源没有当前版本的 loongarch64 软件包 | 查看 sources 配置，curl 测试源地址 | 切换为官方龙架构软件源或内网镜像 |
| pip 安装包失败 | 缺少 loongarch64 wheel，触发源码编译 | 查看完整日志，检查 gcc 和 python3-dev | 安装编译依赖，或更换包版本 |
| Docker pull 失败 | 镜像没有 loongarch64 平台版本 | 使用 docker manifest inspect 查看平台 | 构建 loongarch64 镜像，或改用源码部署 |
| 运行程序报 illegal instruction | 程序使用了当前 CPU 不支持的指令 | 查看程序编译参数和 CPU 特性 | 重新编译，使用兼容的 -march 参数 |
| Web 服务端口无法访问 | 防火墙或服务未启动 | ss -lntp 和 systemctl status | 开放端口，启动服务 |
| 批量任务卡住 | 并发数过高或日志文件过大 | 查看进程状态和磁盘空间 | 限制并发，拆分日志 |
| 桌面系统渲染卡顿 | 缺少图形驱动或使用软渲染 | 查看 dmesg 和驱动模块 | 使用系统自带的稳定驱动，关闭特效 |
排查时坚持一个原则：先看日志，再改配置。不要上来就卸载软件。LoongArch 平台上日志里的告警措辞和 x86 平台可能不同，看到关键报错后先搜索架构关键字，往往能找到适配补丁或替代方案。
10. 最佳实践与使用建议
10.1 优先使用发行版软件源
能在软件源里装包就不要再源码编译一遍。源代码编译可以解决“没有包”的问题，但也会带来版本冻结、依赖难维护的后续成本。同一台设备上源码安装的软件多了以后，很难保证库之间不发生冲突。
10.2 建立可复现的部署配置
用容器和脚本把环境固定下来。至少做到：操作系统版本、内核版本、软件包清单、部署目录、端口配置、环境变量都能通过脚本重放。建议在项目仓库里保存一份部署配置样例：
ARCH=loongarch64 OS_VERSION=2026 APP_PORT=8000 DATA_DIR=/data/app LOG_DIR=/var/log/app CONCURRENCY=4这套配置既能用于新设备初始化，也能用于排查环境漂移问题。
10.3 区分“支持”与“已验证”
LoongArch 生态中，很多组件处于“能够运行”的状态，但还没有经过大规模生产验证。在技术选型前，把每个核心依赖明确标记成三个状态：官方支持、社区适配、未验证。官方支持可以直接上线；社区适配要跑一轮完整测试；未验证的组件要评估替代方案。
10.4 注意二进制翻译的使用边界
二进制翻译是解决历史遗留软件问题的应急手段，不是长期依赖。翻译执行的程序在性能、稳定性和行为一致性上都存在不确定性。迁移项目时，应优先推动源码级适配；短期内无法解决的闭源软件，要单独部署并做好降级预案，同时遵守软件授权条款。
10.5 合规与数据安全
在龙架构设备上处理真实业务数据前，确认系统补丁和软件版本及时更新。涉及用户隐私信息、金融交易等敏感数据时，要遵循数据安全规定，敏感业务建议先在测试环境中跑通全部流程。批量任务涉及抓取或处理他人内容时，务必确认内容授权和处理边界，避免侵权风险。
11. 总结：先跑通最小闭环，再扩大适配范围
龙架构双周会第42期这类例会提供了一个持续观察生态进度的窗口，但决定项目能不能落地的，永远是本地环境里的真实测试结果。拿到 LoongArch 设备后，建议先用最小闭环验证能力：确认架构、更新软件源、部署一个 Web 服务、跑一次批量任务，再看资源占用和性能表现。这一步走通之后，再逐步替换数据库、消息队列、容器编排甚至 Kubernetes 节点，整个迁移过程就会可控很多。
最容易踩的坑集中在三个地方：软件源不匹配、镜像平台不兼容、第三方原生扩展没有 loongarch64 版本。这三个问题都能通过日志快速定位，关键是养成“先确认架构标志、再安装依赖、后启动服务”的习惯。如果真的想让 LoongArch 体系在自己团队里发挥作用，可以从一个边缘业务服务开始试运行，积累一套经过验证的部署经验和性能基线，随后再向核心业务扩展。
