企业官网建设流程全解析

1. 为什么我盯上了这台吃灰的 Oracle Cloud 免费机器

手里有一台 Oracle Cloud 永久免费套餐的 ARM 实例，这事儿在圈子里不算新鲜。4 核 Ampere A1、24GB 内存、200GB 存储，跑分比不少付费小鸡还猛，但很多人领完就扔在那儿吃灰——要么不知道怎么用，要么怕哪天被回收。我当初也是这个心态，直到某天深夜刷到 Hermes 这个 AI 助手项目，脑子里突然冒出一个念头：与其让这台机器空转，不如把它改造成一个 7×24 小时在线的私人 AI 助手。

这个想法的核心诉求其实很朴素。市面上的云端 AI 助手要么按 token 计费，要么有会话时长限制，要么数据全在别人服务器上。而 Hermes 这类可自托管的 AI 代理框架，恰好能解决三个痛点：数据留在自己手里、没有调用次数焦虑、可以挂载本地模型或对接外部 API。把它部署到一台常年在线的服务器上，你就相当于拥有了一个随叫随到、不会掉线的智能体。

Oracle Cloud 免费套餐的 ARM 实例在这里有几个天然优势。第一是永久免费，只要你不主动删实例、不违反使用条款，理论上可以一直跑下去；第二是ARM 架构的能效比，Ampere A1 跑轻量级 AI 代理服务绰绰有余，功耗和资源占用都很友好；第三是公网 IP 固定，配合域名和证书就能对外提供服务，不用折腾内网穿透。当然，它也有坑——比如 ARM 镜像兼容性、免费实例被回收的传闻、以及默认安全组策略比较严格，这些后面会逐个拆解。

需要先说明的是，Hermes 在这里指的是一类可自托管的 AI 代理助手框架，不同版本和分支的实现细节有差异。我下面讲的是基于常见部署实践总结的通用路径，具体命令和配置需要根据你拿到的实际版本来调整。如果你用的是桌面版或智能体形态的 Hermes，思路是相通的，只是安装方式从命令行变成了图形化引导。

提示：Oracle Cloud 免费实例的可用性受区域和库存影响，注册时如果提示无资源，可以换区域或错峰尝试。实例创建后建议先跑一周观察稳定性，再决定是否投入精力部署正式服务。

2. 部署前必须想清楚的几件事：架构、模型与网络

很多人一上来就急着敲安装命令，结果卡在依赖冲突或者模型加载失败上。我在第一次部署时就吃过这个亏，后来总结出一条经验：先把架构想明白，再动手。这一节就把部署前需要决策的关键点摊开讲。

2.1 本地模型还是外部 API：算力账要提前算

Hermes 作为 AI 代理助手，核心能力来自背后的大语言模型。你有两条路可选：一是在服务器上跑本地模型，二是对接外部 API。这两条路的资源消耗和体验差异很大，必须提前算账。

先说本地模型。Oracle Cloud 免费 ARM 实例有 24GB 内存，听起来不少，但 ARM 架构下可用的推理框架和量化模型选择有限。跑一个 7B 参数、4-bit 量化的模型，内存占用大约在 5-8GB，CPU 推理速度大概每秒几个 token，日常对话勉强够用，但复杂任务会明显卡顿。如果你打算跑更大的模型，比如 13B 以上，免费实例基本扛不住，会频繁触发 OOM。

再说外部 API。对接外部模型服务的好处是推理速度快、模型能力强，代价是按量计费。对于个人助手场景，如果每天调用量不大，成本其实可控。我的建议是：先用外部 API 跑通全流程，确认 Hermes 的功能符合预期后，再考虑是否迁移到本地模型。这样能避免在环境配置上浪费大量时间，最后发现产品形态不是自己想要的。

2.2 ARM 架构的兼容性陷阱

Oracle Cloud 免费实例默认是 ARM64 架构，这是第一个大坑。很多 AI 相关的 Python 包、推理框架、甚至 Docker 镜像，默认只提供 x86_64 版本。你在 ARM 上直接pip install或者docker pull，很可能遇到 "no matching distribution" 或者镜像拉下来跑不起来的情况。

我的应对策略是：优先选择官方支持 ARM64 的组件。比如 Python 生态里，大部分纯 Python 包没问题，但涉及底层编译的包（如某些推理加速库）需要确认是否有 aarch64 wheel。Docker 镜像则要看维护者是否构建了 multi-arch 版本，没有的话就得自己写 Dockerfile 从源码编译，这个过程可能很耗时。

另一个思路是用 x86 实例替代。Oracle Cloud 免费套餐里也有 x86 的 AMD 实例，虽然配置低一些（通常是 1 核 1GB），但兼容性好得多。如果你只是跑一个轻量级代理服务，x86 实例反而更省心。不过 1GB 内存跑本地模型就别想了，只能走外部 API 路线。

2.3 网络与安全组：别让服务裸奔

Oracle Cloud 的网络策略是出了名的严格。默认情况下，除了 SSH 端口，其他入站流量全部被安全组和实例内的防火墙双重拦截。你部署完 Hermes，发现本地能访问、外网打不开，八成是这两层没配好。

第一层是VCN 安全列表（Security List）或网络安全组（NSG）。你需要在 Oracle Cloud 控制台里，为实例所在的子网添加入站规则，放行 Hermes 服务监听的端口。第二层是实例内部的防火墙，Oracle 的官方镜像默认用 iptables，而且规则是持久化的，重启不会丢。很多人改了安全组却忘了改 iptables，结果还是连不上。

注意：放行端口时尽量遵循最小权限原则，只开放必要的端口。如果 Hermes 提供 Web 界面，建议配合反向代理和 HTTPS 证书使用，不要直接把服务端口暴露在公网上。

3. 从零到跑通：Hermes 在 ARM 实例上的完整落地过程

这一节是实操核心。我会按照真实部署顺序，把每一步的命令、意图和可能遇到的问题都讲清楚。你跟着走一遍，基本能跑通一个可用的 Hermes 服务。

3.1 系统初始化与基础依赖安装

实例创建好之后，第一件事是更新系统并安装基础工具。Oracle 的 Ubuntu 镜像默认软件源有时候比较慢，可以先换成国内镜像源加速（如果你在海外区域，这步可以跳过）。

sudo apt update && sudo apt upgrade -y sudo apt install -y python3 python3-pip python3-venv git curl wget build-essential

这里有几个细节值得说。python3-venv 一定要装，因为 Hermes 这类项目通常建议在虚拟环境里运行，避免污染系统 Python。build-essential是为了编译那些没有预编译 wheel 的 Python 包，在 ARM 上这个概率不低。如果你打算用 Docker 部署，还要额外安装 Docker Engine，注意用官方脚本安装 ARM64 版本。

curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER

执行完usermod后需要重新登录 SSH 会话，用户组变更才会生效。这一步经常被忽略，导致后面执行 docker 命令提示权限不足。

3.2 获取 Hermes 并配置运行环境

Hermes 的获取方式取决于你拿到的版本。如果是开源仓库，直接 clone；如果是打包好的安装包，按官方文档走。假设是 Git 仓库形式：

git clone <hermes-repo-url> hermes cd hermes python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt

在 ARM 上执行pip install时，要特别留意输出里有没有 "Building wheel for xxx" 的字样。如果有，说明这个包正在从源码编译，耗时可能较长，而且可能因为缺少系统依赖而失败。遇到编译失败，先看错误信息里缺哪个头文件或库，用apt install补上再重试。

配置文件是另一个关键点。Hermes 通常会有一个配置模板，你需要复制成实际配置并填入模型 API 地址、密钥、监听端口等信息。密钥不要硬编码在代码里，用环境变量或独立的配置文件管理，并且确保配置文件权限是 600，避免被其他用户读取。

cp config.example.yaml config.yaml chmod 600 config.yaml

3.3 模型接入：本地推理与外部 API 的配置差异

如果你走外部 API 路线，配置相对简单：在 config.yaml 里填入 API 端点、密钥和模型名称即可。注意有些服务商对请求频率有限制，Hermes 如果并发调用，可能触发限流。可以在配置里加上重试和退避策略。

如果你坚持在 ARM 实例上跑本地模型，推荐用 llama.cpp 这类对 ARM 友好的推理框架。它的优势是纯 C++ 实现，编译后直接跑量化模型，不依赖庞大的 Python 生态。编译过程大概需要十几分钟，之后下载一个 4-bit 量化的 GGUF 模型文件，用命令行启动推理服务，再把 Hermes 的模型地址指向本地端口。

# 以 llama.cpp 为例的编译示意 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j4 ./server -m models/your-model.gguf -c 2048 --host 127.0.0.1 --port 8080

这里-c 2048是上下文长度，免费实例内存有限，不要设太大，否则容易 OOM。--host 127.0.0.1表示只监听本地，Hermes 和推理服务在同一台机器上，不需要对外暴露。

3.4 服务常驻与开机自启

部署跑通只是第一步，让服务 7×24 小时稳定运行才是目标。最省事的方案是用 systemd 管理 Hermes 进程。写一个 service 文件，配置好工作目录、启动命令、重启策略，然后 enable 它。

[Unit] Description=Hermes AI Assistant After=network.target [Service] Type=simple User=youruser WorkingDirectory=/home/youruser/hermes ExecStart=/home/youruser/hermes/venv/bin/python main.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

Restart=always是关键，进程崩溃后 systemd 会自动拉起。RestartSec=10避免频繁重启导致资源耗尽。配置好后执行systemctl daemon-reload && systemctl enable --now hermes，服务就会在后台常驻，服务器重启也会自动启动。

4. 踩过的坑与排查链路：这些报错我都遇到过

部署过程中我踩了不少坑，有些是 Oracle Cloud 特有的，有些是 ARM 架构带来的。这一节把典型问题和排查过程完整还原，你遇到类似报错时可以对照着查。

4.1 服务本地能访问、外网连不上

这是最高频的问题。排查顺序应该是：先确认服务本身在监听，用ss -tlnp | grep 端口号看进程有没有绑定到 0.0.0.0。如果只绑定了 127.0.0.1，那外网肯定访问不了，需要改配置让服务监听所有网卡。

如果服务监听正常，再查实例内部防火墙。Oracle 的 Ubuntu 镜像默认 iptables 规则里，除了 SSH 其他都拒绝。你需要插入一条放行规则，并且保存到持久化配置里，否则重启后失效。

sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 你的端口 -j ACCEPT sudo netfilter-persistent save

最后查 Oracle Cloud 控制台的安全列表。在实例详情页找到子网，进入安全列表，添加入站规则，源 CIDR 填 0.0.0.0/0（如果只给自己用，可以填你的固定 IP），目标端口填服务端口。这三层都通了，外网才能访问。

4.2 pip 安装时编译失败

在 ARM 上装 Python 包，最常见的报错是缺少编译依赖。比如装某个涉及加密的包时提示找不到openssl/ssl.h，解决办法是sudo apt install libssl-dev。装涉及图像处理的包提示找不到jpeglib.h，就装libjpeg-dev。这类问题的通用排查方法是：看报错信息里提到的头文件或库名，用 apt 搜索对应的 dev 包安装。

还有一种情况是包本身不支持 ARM64，源码编译也过不去。这时候要么找替代包，要么用 Docker 跑 x86 镜像（需要开启 binfmt 支持，性能有损耗）。我的建议是优先找 ARM 原生方案，实在没有再考虑模拟。

4.3 内存不足导致进程被 kill

免费实例内存虽然标称 24GB，但系统和后台服务会占用一部分，实际可用大概 20GB 左右。如果你同时跑了本地模型和其他服务，内存可能吃紧。表现是进程突然消失，dmesg里能看到 OOM killer 的记录。

解决办法有两个：一是减少并发和上下文长度，把模型推理的-c参数调小；二是加 swap。在 ARM 实例上创建 swap 文件很简单，但要注意 swap 在 SSD 上频繁读写会影响寿命，只建议作为应急缓冲，不要长期依赖。

sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

4.4 免费实例被回收的应对

社区里一直有 Oracle Cloud 免费实例被回收的讨论。虽然官方条款说永久免费，但实际中如果实例长期低负载或者违反使用政策，确实有被回收的案例。我的应对策略是：把 Hermes 的配置和数据定期备份到对象存储或本地，这样即使实例没了，换一台机器也能快速恢复。另外，保持实例有一定的资源使用率，不要让它看起来像完全闲置。

5. 让助手真正好用：性能调优与日常维护心得

服务跑起来只是及格线，要让它真正成为顺手的助手，还需要做一些调优和维护。这一节分享几个我在实际使用中总结的技巧。

5.1 响应速度优化：从模型到网络

响应速度取决于三个环节：模型推理、网络传输、Hermes 自身处理。如果走外部 API，网络传输是主要瓶颈，可以选择离服务器区域近的 API 端点。如果跑本地模型，推理速度是瓶颈，可以通过减小量化位数、缩短上下文、限制并发来优化。

Hermes 自身也有一些可调参数，比如请求超时时间、重试次数、缓存策略。对于重复性高的查询，开启缓存能显著减少模型调用。我在配置里把常见问题的回答缓存了 1 小时，命中率大概有三成，省了不少推理开销。

5.2 日志与监控：出问题能快速定位

systemd 管理的服务，日志默认进 journal。用journalctl -u hermes -f可以实时看日志。建议把日志级别调到 INFO，既能看清流程，又不会太啰嗦。如果 Hermes 支持输出结构化日志，可以配合简单的日志分析脚本，统计每天的调用次数、错误率、平均响应时间。

资源监控方面，htop看 CPU 和内存，nethogs看网络流量，df -h看磁盘。免费实例磁盘 200GB，日志和模型文件占大头，定期清理旧日志和不需要的模型能避免磁盘写满。

5.3 安全加固：别让助手变成别人的入口

自托管服务最大的风险是安全。几个基本措施必须做：SSH 禁用密码登录，只用密钥；Hermes 的 Web 界面加认证，不要裸奔；定期更新系统和依赖，修补已知漏洞；限制 API 密钥权限，只给必要的 scope。

如果 Hermes 提供对外接口，建议在前面加一层反向代理（如 Nginx），配置 HTTPS 证书和访问频率限制。证书可以用 Let's Encrypt 免费申请，配合自动续期脚本，基本不用操心。

5.4 备份与迁移：随时能换机器

最后强调备份。Hermes 的配置文件、对话历史、自定义技能（skill）都是宝贵数据。我设置了一个定时任务，每天把配置和数据目录打包，同步到对象存储。这样即使实例出问题，换一台机器重新部署，把备份恢复回去，半小时内就能继续用。

迁移时注意 ARM 和 x86 的差异，如果新机器架构不同，Python 虚拟环境和编译产物需要重建，但配置和数据是通用的。这也是为什么我一直建议把配置和数据与代码分离，迁移时会省很多事。

6. 这套方案适合谁，以及我后续的折腾方向

回过头看，把 Hermes 部署到 Oracle Cloud 免费实例这件事，最适合三类人：一是想拥有私人 AI 助手但不想持续付费的开发者；二是对数据隐私有要求、希望服务跑在自己可控环境里的用户；三是想练手云服务器运维和 AI 服务部署的技术爱好者。如果你属于这三类，这套方案值得一试。

不太适合的情况也要说清楚：如果你需要高并发、低延迟的生产级服务，免费实例的性能和稳定性都不够；如果你完全不想碰命令行，那桌面版 Hermes 或者现成的云端服务可能更合适。部署自托管服务本质上是在用时间换成本和隐私，这个 trade-off 要想明白。

后续我打算在这台机器上继续折腾几个方向。一是接入更多本地技能，比如让助手能查本地文件、执行定时任务、对接智能家居接口。二是优化模型推理，试试更新的 ARM 优化推理框架，看能不能在免费实例上跑出更流畅的体验。三是做多实例负载均衡，如果哪天一台机器不够用，可以再开一台免费实例，用反向代理做分流。

这台吃灰的 Oracle Cloud 实例，现在成了我日常用得最多的服务之一。每天早上它会推送我关注的资讯摘要，工作时帮我整理笔记和草稿，晚上还能跑一些定时任务。免费资源用到位，体验不比付费服务差多少。如果你手里也有闲置的云实例，不妨试试把它变成你的专属 AI 助手。