1. 为什么我盯上了这台吃灰的 Oracle Cloud 免费机器手里有台 Oracle Cloud 永久免费套餐的 ARM 实例这事儿本身就挺有意思。很多人注册完、开完机、跑个测试脚本然后就把它扔在那儿吃灰了——毕竟 4 核 24G 的 ARM 配置放在免费额度里确实香但真要用起来总得有个说得过去的理由。我的理由很直接我想要一个 7×24 小时在线、随时能响应我问题的 AI 助手而不是每次都得打开浏览器、登录某个网页、等它加载完再开始对话。Hermes 这个项目正好戳中了这个需求。它本质上是一个可以自托管的 AI 代理助手框架支持接入本地模型或者远程 API能跑在一个相对轻量的环境里。你把它部署到服务器上之后它就变成了一个常驻的智能体——你可以通过接口、命令行或者它自带的前端去调用它让它帮你处理一些重复性的问答、信息整理、甚至简单的自动化任务。关键词里提到的“AI 代理助手加本地模型”“hermes agent”“hermes skill”这些说的都是同一件事Hermes 不只是一个聊天窗口它更像是一个可以扩展能力的代理框架。那为什么非得是 Oracle Cloud Free因为免费。说得再直白一点我不想为了一个“可能用得上”的助手每个月掏几十块钱的服务器费用。Oracle 的永久免费 ARM 实例给了 4 个 OCPU 和 24GB 内存这个配置跑一个 Hermes 加上一个中等规模的本地模型比如 7B 级别的量化模型是完全够用的。而且它是真正的 7×24 在线不像我本地电脑合上盖子就断了。但这里有个前提你得先把这台机器从“能 SSH 登录”的状态变成一个“能稳定跑服务”的状态。这中间涉及系统选择、网络配置、依赖安装、模型接入、进程守护、资源监控等一连串事情。我踩过的坑不算少所以这篇文章就把整个部署过程拆开来讲重点放在那些文档里不会写、但实际部署时一定会遇到的问题上。提示Oracle Cloud 的免费 ARM 实例在某些区域库存紧张开机时如果提示容量不足可以尝试换可用域或者换个时间段再试。这不是技术问题纯粹是资源调度问题。2. Hermes 到底是个什么东西以及它不适合谁在动手之前得先把 Hermes 的定位搞清楚。网上关于它的信息比较散有人叫它“AI 代理助手”有人叫“hermes agent”还有人把它和“deepseek hermes”混在一起谈。我实际用下来的理解是Hermes 是一个自托管的 AI 助手运行框架它的核心能力是把你选择的模型本地或远程包装成一个可以持续交互的代理服务并且支持通过 skill 机制扩展功能。2.1 它解决的核心问题让模型从“一次性问答”变成“常驻服务”大多数人用 AI 模型的方式是打开一个网页或者客户端输入问题得到回答关掉。下次再问上下文没了模型也不记得你之前说过什么。Hermes 改变的是这个模式——它把模型跑在一个常驻进程里你随时可以连上去它随时在。你可以给它配置不同的 skill让它能查资料、整理文件、执行一些预定义的操作。关键词里提到的“hermes skill”和“hermes 智能体”说的就是这个扩展能力。我自己的用法比较朴素把它当成一个随时在线的技术问答助手。遇到不熟悉的命令、需要快速查一个参数、想让它帮我整理一段日志直接通过接口发过去几秒钟就有回复。因为模型是跑在我自己的服务器上响应速度比走公网 API 稳定得多也不受某些服务商的速率限制影响。2.2 它不适合的场景别指望它替代完整的生产级应用有一点必须说清楚Hermes 不是那种开箱即用的企业级 AI 平台。它的部署过程需要你手动处理依赖、配置模型路径、设置进程守护。如果你想要的是一个“点一下按钮就能用”的托管服务那 Hermes 不适合你。但如果你愿意花一两个小时把环境搭好后面就能一直用而且完全掌控在自己手里。另外它对硬件是有要求的。虽然官方说可以跑在比较轻量的环境里但如果你要接本地模型内存和 CPU 的消耗是实打实的。Oracle Cloud 的 4 核 24G ARM 实例跑一个 7B 的量化模型比如 Q4 量化版本大概占用 5-6GB 内存CPU 在推理时会有明显波动但日常问答完全够用。如果你打算跑更大的模型那就得考虑升级配置或者用远程 API 来分担推理压力。对比项Hermes 自托管方案网页版 AI 服务在线时间7×24 小时取决于服务器依赖服务商可用性数据隐私数据留在自己服务器数据经过第三方响应速度局域网/内网调用极快受公网延迟影响扩展能力可通过 skill 自由扩展受平台功能限制维护成本需要自己维护服务器零维护费用服务器费用免费套餐可覆盖订阅或按量付费2.3 为什么选 Oracle Cloud Free 而不是其他方案关键词里出现了“本地部署大语言模型”“ollama 本地部署”这些词说明很多人也在考虑本地跑模型。本地跑的好处是延迟低、数据不出门但坏处也很明显你的电脑不可能一直开着而且本地跑模型会占用大量资源影响你正常干活。Oracle Cloud 的免费实例正好补上了这个缺口——它是一台远程的、一直在线的、配置还不错的机器而且不要钱。我对比过几种方案树莓派性能不够跑 7B 模型很吃力家里的旧电脑功耗高、噪音大而且公网访问需要额外配置其他云服务商的免费额度要么时间有限要么配置太低。Oracle Cloud 的永久免费 ARM 实例在这个场景下几乎是最优解。3. 从裸机到可用环境系统层面的准备工作拿到一台全新的 Oracle Cloud 实例之后别急着装 Hermes。先把系统层面的东西理顺后面会省很多事。这一步的核心目标是让这台机器能稳定地跑长时间运行的服务并且你能方便地管理它。3.1 系统选择与基础更新Oracle Cloud 创建实例时可以选择 Ubuntu、Oracle Linux 等镜像。我选的是 Ubuntu 22.04 LTS原因是社区支持好、包管理方便、遇到问题容易搜到解决方案。ARM 架构的 Ubuntu 镜像在 Oracle 上是可用的创建时注意选择 aarch64 架构的镜像。创建完成后第一件事是更新系统sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim htop net-tools这几条命令看起来简单但有一个细节值得注意Oracle Cloud 的默认镜像有时候会自带一些不必要的服务比如 snapd 的自动更新可能会在你不注意的时候占用带宽和 CPU。如果你对资源比较敏感可以考虑禁用 snapd 自动更新或者至少知道它在后台干什么。3.2 网络与防火墙两层防护都要过Oracle Cloud 的网络配置是两层防火墙一层是云平台的安全列表Security List或者网络安全组NSG另一层是实例内部的 iptables。很多人只改了其中一层然后发现端口还是不通就开始怀疑人生。我的做法是先在 Oracle Cloud 控制台的网络配置里放行你需要的端口。Hermes 默认可能用某个端口比如 8080 或者自定义端口你需要把这个端口的入站规则加到安全列表里。然后登录到实例内部检查 iptables 规则sudo iptables -L -n --line-numbers如果发现默认规则是 DROP 或者 REJECT你需要手动添加放行规则。Ubuntu 上通常用 ufw 来管理但 Oracle Cloud 的镜像有时候 ufw 是关闭的iptables 规则是直接生效的。我建议统一用 iptables 来管理避免 ufw 和 iptables 规则冲突。注意Oracle Cloud 的实例默认可能只开放了 SSH 端口22。如果你要通过浏览器访问 Hermes 的 Web 界面需要额外放行对应的 HTTP 端口。放行之后最好用curl在本地测试一下端口是否真的通了别等到配置完 Hermes 才发现访问不了。3.3 创建专用用户与目录结构我不建议直接用 root 跑 Hermes。创建一个专用用户把 Hermes 和相关文件都放在这个用户的家目录下权限清晰出问题也好排查。sudo useradd -m -s /bin/bash hermes sudo passwd hermes sudo usermod -aG sudo hermes然后切换到 hermes 用户创建目录结构su - hermes mkdir -p ~/hermes/{app,models,logs,data}这个目录结构是我自己用的app放 Hermes 的程序文件models放本地模型文件logs放日志data放运行时的数据。分开的好处是备份和迁移的时候目标明确不会把模型文件和日志混在一起。4. 安装 Hermes依赖、模型与首次启动环境准备好之后就可以开始装 Hermes 了。这一步是整个部署过程中最容易出问题的环节因为涉及 Python 依赖、模型下载、配置文件的编写。我会把每个步骤的意图和可能遇到的问题都讲清楚。4.1 Python 环境与依赖安装Hermes 大概率是基于 Python 的项目从关键词里的“flask 部署”“ollama 本地部署”可以推断它可能涉及 Python Web 框架和模型运行时。在 Ubuntu 22.04 上系统自带的 Python 版本是 3.10基本够用。但我建议用虚拟环境来隔离依赖避免污染系统 Python。sudo apt install -y python3-pip python3-venv cd ~/hermes/app python3 -m venv venv source venv/bin/activate虚拟环境激活后安装依赖。如果 Hermes 提供了requirements.txt直接pip install -r requirements.txt如果没有就需要根据它的文档手动安装。这里有一个 ARM 架构特有的坑某些 Python 包在 aarch64 上的预编译轮子wheel可能不存在pip 会尝试从源码编译而编译又需要额外的系统依赖。比如numpy、scipy这些科学计算包在 ARM 上通常有轮子但一些冷门的包可能没有。遇到编译失败时先看错误信息里缺什么头文件然后用apt安装对应的-dev包。4.2 模型的选择与下载本地模型 vs 远程 APIHermes 支持两种模型接入方式本地模型和远程 API。我的建议是两者结合——日常问答用本地模型复杂任务或者本地模型搞不定的问题走远程 API。这样既能保证基本可用性又能在需要的时候获得更强的推理能力。本地模型方面我选的是 7B 级别的量化模型Q4 量化后文件大小在 4GB 左右加载到内存后占用 5-6GB。下载模型文件时注意存储空间——Oracle Cloud 免费实例的默认磁盘是 47GB 左右放一个 7B 模型加上系统和其他文件空间是够的但如果你要放多个模型就得注意清理。cd ~/hermes/models # 假设模型文件已经下载好放到这个目录 ls -lh如果你用的是 Ollama 来管理本地模型安装过程会简单很多curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2:7bOllama 在 ARM 上的支持还不错安装后会注册为系统服务开机自启。但要注意Ollama 默认监听的是127.0.0.1:11434如果你想让 Hermes 通过它来调用模型需要确保 Hermes 能访问到这个地址。如果 Hermes 跑在同一个机器上直接用 localhost 就行。4.3 配置文件的关键字段与首次启动Hermes 的配置文件通常是一个 YAML 或者 JSON 文件里面定义了模型路径、监听端口、API 密钥如果走远程 API、skill 配置等。我建议先把最小配置跑通再逐步加功能。一个典型的最小配置大概长这样具体字段名以实际项目为准server: host: 0.0.0.0 port: 8080 model: provider: ollama base_url: http://127.0.0.1:11434 model_name: qwen2:7b skills: - name: basic_qa enabled: true首次启动时用前台模式运行方便看日志cd ~/hermes/app source venv/bin/activate python main.py如果看到服务启动成功的日志并且没有报错就可以用curl测试一下curl http://127.0.0.1:8080/health返回正常的话说明 Hermes 已经跑起来了。这时候你可以通过浏览器访问http://你的服务器IP:8080看看 Web 界面是否正常。如果访问不了回到第 3.2 节检查防火墙规则。提示首次启动时模型加载可能需要一些时间尤其是从磁盘读取大文件的时候。如果日志显示正在加载模型耐心等一会儿别急着以为卡死了。5. 让它真正 7×24 小时在线进程守护与资源管理服务能跑起来只是第一步让它稳定地一直跑下去才是关键。我见过太多人把服务启动起来就不管了结果 SSH 一断开服务也跟着挂了。或者跑了几天之后内存泄漏把机器拖垮。这一节讲的就是怎么避免这些问题。5.1 用 systemd 管理 Hermes 服务最省心的方式是写一个 systemd unit 文件让系统来管理 Hermes 的启动、停止和重启。这样即使服务器重启Hermes 也会自动拉起来。[Unit] DescriptionHermes AI Assistant Afternetwork.target ollama.service [Service] Typesimple Userhermes WorkingDirectory/home/hermes/hermes/app EnvironmentPATH/home/hermes/hermes/app/venv/bin:/usr/local/bin:/usr/bin:/bin ExecStart/home/hermes/hermes/app/venv/bin/python main.py Restartalways RestartSec10 StandardOutputappend:/home/hermes/hermes/logs/hermes.log StandardErrorappend:/home/hermes/hermes/logs/hermes.err [Install] WantedBymulti-user.target把这个文件保存为/etc/systemd/system/hermes.service然后sudo systemctl daemon-reload sudo systemctl enable hermes sudo systemctl start hermes sudo systemctl status hermesRestartalways是关键它保证服务意外退出时会自动重启。RestartSec10表示重启前等 10 秒避免频繁重启导致资源浪费。5.2 内存与 CPU 的监控和限制Oracle Cloud 免费实例虽然有 24GB 内存但如果你同时跑 Ollama 和 Hermes再加上系统本身的开销内存占用会比较高。我建议给 Hermes 和 Ollama 分别设置内存限制避免其中一个把内存吃光导致系统 OOM。systemd 支持MemoryMax和CPUQuota参数[Service] MemoryMax8G CPUQuota300%MemoryMax8G表示这个服务最多用 8GB 内存超过会被限制。CPUQuota300%表示最多用 3 个核心的算力4 核机器上留一个核心给系统和其他服务。这些限制不是必须的但在资源有限的免费实例上加上它们能显著提升稳定性。监控方面我习惯用htop快速看一眼但长期监控还是得靠日志。Hermes 自己的日志加上 systemd 的 journal基本能覆盖大部分排查需求journalctl -u hermes -f tail -f ~/hermes/logs/hermes.log5.3 自动重启与健康检查的配合systemd 的Restartalways解决的是进程崩溃的问题但如果进程还在、只是卡死了systemd 是不会重启它的。这时候需要一个健康检查机制。最简单的做法是写一个定时任务定期请求 Hermes 的健康检查接口如果连续失败就重启服务。#!/bin/bash # /home/hermes/health_check.sh if ! curl -sf http://127.0.0.1:8080/health /dev/null; then echo $(date): Health check failed, restarting hermes /home/hermes/hermes/logs/health.log sudo systemctl restart hermes fi然后用 crontab 每 5 分钟跑一次crontab -e # 添加一行 */5 * * * * /home/hermes/health_check.sh这个脚本很简单但实际用下来很有效。我有一次遇到 Hermes 因为模型加载异常导致接口无响应进程还在但就是不返回结果健康检查脚本在 5 分钟内就把它重启了。6. 踩过的坑与排查实录部署过程中遇到的问题不少我挑几个有代表性的讲一下重点是排查思路因为具体问题可能因人而异但排查方法是可以复用的。6.1 端口不通两层防火墙的排查链路最开始配置的时候我在 Hermes 里设置了监听 8080 端口本地curl是通的但从外部访问就是不行。排查过程如下第一步确认 Hermes 确实在监听 8080ss -tlnp | grep 8080输出显示0.0.0.0:8080说明监听没问题。第二步检查实例内部的 iptablessudo iptables -L INPUT -n --line-numbers发现默认策略是 DROP而且没有放行 8080 的规则。添加规则sudo iptables -I INPUT 6 -p tcp --dport 8080 -j ACCEPT第三步回到 Oracle Cloud 控制台检查安全列表。发现入站规则里确实没有 8080。添加一条入站规则源 CIDR 设置为0.0.0.0/0如果你知道自己的 IP可以限制得更严格协议 TCP目标端口 8080。三步走完外部访问就通了。这个排查链路的关键是先确认服务本身没问题再查内部防火墙最后查云平台的安全列表。顺序反过来的话容易在云控制台里瞎找半天。6.2 模型加载失败ARM 架构下的依赖问题有一次我尝试换一个模型结果 Hermes 启动时报错说某个 Python 包导入失败。看错误信息是一个用于模型推理的库在 aarch64 上没有预编译轮子pip 尝试从源码编译但失败了。解决办法是安装编译所需的系统依赖sudo apt install -y build-essential cmake libopenblas-dev然后重新安装那个 Python 包。如果还是不行就找这个包的 ARM 兼容版本或者换一个不需要这个依赖的模型。这件事给我的教训是在 ARM 架构上部署 AI 相关项目一定要提前确认关键依赖是否有 ARM 支持。x86 上很成熟的东西ARM 上不一定有现成的轮子。6.3 内存不足导致服务被系统杀掉跑了一段时间之后我发现 Hermes 偶尔会莫名其妙地重启。查 journal 日志journalctl -u hermes | grep -i killed\|oom发现系统 OOM killer 把 Hermes 进程杀掉了。原因是 Ollama 加载模型后占用了大量内存加上 Hermes 本身的开销超过了可用内存。解决办法有两个一是给 Ollama 设置内存限制二是换一个更小的模型。我最后是把模型从 7B 换成了更小的量化版本同时给 Ollama 加了MemoryMax12G的限制。调整之后OOM 问题就没再出现过。问题现象可能原因排查命令解决方案外部无法访问防火墙未放行iptables -L放行端口 云安全列表启动报错ARM 依赖缺失查看错误日志安装编译依赖或换包服务自动重启内存不足 OOMjournalctl -u hermes限制内存或换小模型接口无响应模型加载卡死curl /health健康检查 自动重启7. 日常使用中的几个实用技巧部署完成之后日常使用中还有一些小技巧能让体验更好。这些不是必须的但用上了会省心不少。7.1 用别名简化常用命令我习惯在.bashrc里加几个别名减少重复输入alias hstatussudo systemctl status hermes alias hlogjournalctl -u hermes -f alias hrestartsudo systemctl restart hermes alias ollogjournalctl -u ollama -f这样查看状态、看日志、重启服务都是一条短命令的事。7.2 日志轮转避免磁盘写满Hermes 和 Ollama 的日志如果一直往一个文件里写时间长了会把磁盘占满。用 logrotate 来管理sudo vim /etc/logrotate.d/hermes内容/home/hermes/hermes/logs/*.log { daily rotate 7 compress missingok notifempty }这样日志每天轮转一次保留 7 天自动压缩。磁盘空间就不会被日志吃光了。7.3 定期备份配置文件和数据Hermes 的配置文件、skill 配置、以及data目录里的数据建议定期备份。我用的方法很简单写一个脚本打包这些文件放到另一个目录或者同步到对象存储#!/bin/bash BACKUP_DIR/home/hermes/backups mkdir -p $BACKUP_DIR tar czf $BACKUP_DIR/hermes-config-$(date %Y%m%d).tar.gz \ /home/hermes/hermes/app/config.yaml \ /home/hermes/hermes/data \ /etc/systemd/system/hermes.service # 只保留最近 7 天的备份 find $BACKUP_DIR -name hermes-config-*.tar.gz -mtime 7 -delete这个脚本可以加到 crontab 里每天跑一次。备份文件不大但关键时刻能省去重新配置的麻烦。7.4 根据使用情况调整模型和参数用了一段时间之后你会对自己的使用模式有更清楚的了解。如果主要是短问答小模型完全够用响应还更快如果需要处理长文本或者复杂推理可以考虑在需要的时候临时切换到远程 API。Hermes 的配置支持多模型切换的话可以配置一个本地模型作为默认一个远程 API 作为备选在 skill 或者请求参数里指定用哪个。我在实际使用中的体会是不要追求“一步到位”配置一个完美方案而是先跑起来用起来然后根据实际遇到的问题逐步调整。最开始我花了很多时间纠结选哪个模型、参数怎么调后来发现先把基础服务跑通用起来之后再优化效率高得多。8. 这套方案后续还能怎么扩展Hermes 跑起来之后它就是一个常驻的 AI 代理服务你可以围绕它做很多扩展。比如接入更多的 skill 让它能处理特定领域的任务或者把它和其他的自动化工具串联起来形成一个简单的自动化工作流。关键词里提到的“hermes skill”和“hermes 智能体”指向的就是这个方向——Hermes 本身是一个框架真正的价值在于你往里面加什么。另一个扩展方向是监控和告警。你可以让 Hermes 定期检查某些指标发现异常时通过它支持的渠道发通知。或者反过来把 Hermes 的日志接入到现有的监控系统里统一管理。最后再分享一个小技巧如果你有多台服务器可以把 Hermes 的配置和模型文件放在共享存储上这样换机器或者扩容的时候直接挂载共享存储就能用不用重新下载模型和配置环境。这个做法在需要快速迁移或者做冗余的时候特别有用。踩过几次坑之后我最大的感受是免费服务器跑 AI 助手这件事技术门槛没有想象中那么高但细节特别多。把系统层、网络层、服务层这三层都理顺了后面就是享受 7×24 小时在线的便利了。 
长河君 · 2026/10/7 7:33:24 · 阅读 1.2k Oracle Cloud免费ARM实例部署Hermes AI代理助手：7×24小时在线自托管实践
1. 为什么我盯上了这台吃灰的 Oracle Cloud 免费机器手里有台 Oracle Cloud 永久免费套餐的 ARM 实例这事儿本身就挺有意思。很多人注册完、开完机、跑个测试脚本然后就把它扔在那儿吃灰了——毕竟 4 核 24G 的 ARM 配置放在免费额度里确实香但真要用起来总得有个说得过去的理由。我的理由很直接我想要一个 7×24 小时在线、随时能响应我问题的 AI 助手而不是每次都得打开浏览器、登录某个网页、等它加载完再开始对话。Hermes 这个项目正好戳中了这个需求。它本质上是一个可以自托管的 AI 代理助手框架支持接入本地模型或者远程 API能跑在一个相对轻量的环境里。你把它部署到服务器上之后它就变成了一个常驻的智能体——你可以通过接口、命令行或者它自带的前端去调用它让它帮你处理一些重复性的问答、信息整理、甚至简单的自动化任务。关键词里提到的“AI 代理助手加本地模型”“hermes agent”“hermes skill”这些说的都是同一件事Hermes 不只是一个聊天窗口它更像是一个可以扩展能力的代理框架。那为什么非得是 Oracle Cloud Free因为免费。说得再直白一点我不想为了一个“可能用得上”的助手每个月掏几十块钱的服务器费用。Oracle 的永久免费 ARM 实例给了 4 个 OCPU 和 24GB 内存这个配置跑一个 Hermes 加上一个中等规模的本地模型比如 7B 级别的量化模型是完全够用的。而且它是真正的 7×24 在线不像我本地电脑合上盖子就断了。但这里有个前提你得先把这台机器从“能 SSH 登录”的状态变成一个“能稳定跑服务”的状态。这中间涉及系统选择、网络配置、依赖安装、模型接入、进程守护、资源监控等一连串事情。我踩过的坑不算少所以这篇文章就把整个部署过程拆开来讲重点放在那些文档里不会写、但实际部署时一定会遇到的问题上。提示Oracle Cloud 的免费 ARM 实例在某些区域库存紧张开机时如果提示容量不足可以尝试换可用域或者换个时间段再试。这不是技术问题纯粹是资源调度问题。2. Hermes 到底是个什么东西以及它不适合谁在动手之前得先把 Hermes 的定位搞清楚。网上关于它的信息比较散有人叫它“AI 代理助手”有人叫“hermes agent”还有人把它和“deepseek hermes”混在一起谈。我实际用下来的理解是Hermes 是一个自托管的 AI 助手运行框架它的核心能力是把你选择的模型本地或远程包装成一个可以持续交互的代理服务并且支持通过 skill 机制扩展功能。2.1 它解决的核心问题让模型从“一次性问答”变成“常驻服务”大多数人用 AI 模型的方式是打开一个网页或者客户端输入问题得到回答关掉。下次再问上下文没了模型也不记得你之前说过什么。Hermes 改变的是这个模式——它把模型跑在一个常驻进程里你随时可以连上去它随时在。你可以给它配置不同的 skill让它能查资料、整理文件、执行一些预定义的操作。关键词里提到的“hermes skill”和“hermes 智能体”说的就是这个扩展能力。我自己的用法比较朴素把它当成一个随时在线的技术问答助手。遇到不熟悉的命令、需要快速查一个参数、想让它帮我整理一段日志直接通过接口发过去几秒钟就有回复。因为模型是跑在我自己的服务器上响应速度比走公网 API 稳定得多也不受某些服务商的速率限制影响。2.2 它不适合的场景别指望它替代完整的生产级应用有一点必须说清楚Hermes 不是那种开箱即用的企业级 AI 平台。它的部署过程需要你手动处理依赖、配置模型路径、设置进程守护。如果你想要的是一个“点一下按钮就能用”的托管服务那 Hermes 不适合你。但如果你愿意花一两个小时把环境搭好后面就能一直用而且完全掌控在自己手里。另外它对硬件是有要求的。虽然官方说可以跑在比较轻量的环境里但如果你要接本地模型内存和 CPU 的消耗是实打实的。Oracle Cloud 的 4 核 24G ARM 实例跑一个 7B 的量化模型比如 Q4 量化版本大概占用 5-6GB 内存CPU 在推理时会有明显波动但日常问答完全够用。如果你打算跑更大的模型那就得考虑升级配置或者用远程 API 来分担推理压力。对比项Hermes 自托管方案网页版 AI 服务在线时间7×24 小时取决于服务器依赖服务商可用性数据隐私数据留在自己服务器数据经过第三方响应速度局域网/内网调用极快受公网延迟影响扩展能力可通过 skill 自由扩展受平台功能限制维护成本需要自己维护服务器零维护费用服务器费用免费套餐可覆盖订阅或按量付费2.3 为什么选 Oracle Cloud Free 而不是其他方案关键词里出现了“本地部署大语言模型”“ollama 本地部署”这些词说明很多人也在考虑本地跑模型。本地跑的好处是延迟低、数据不出门但坏处也很明显你的电脑不可能一直开着而且本地跑模型会占用大量资源影响你正常干活。Oracle Cloud 的免费实例正好补上了这个缺口——它是一台远程的、一直在线的、配置还不错的机器而且不要钱。我对比过几种方案树莓派性能不够跑 7B 模型很吃力家里的旧电脑功耗高、噪音大而且公网访问需要额外配置其他云服务商的免费额度要么时间有限要么配置太低。Oracle Cloud 的永久免费 ARM 实例在这个场景下几乎是最优解。3. 从裸机到可用环境系统层面的准备工作拿到一台全新的 Oracle Cloud 实例之后别急着装 Hermes。先把系统层面的东西理顺后面会省很多事。这一步的核心目标是让这台机器能稳定地跑长时间运行的服务并且你能方便地管理它。3.1 系统选择与基础更新Oracle Cloud 创建实例时可以选择 Ubuntu、Oracle Linux 等镜像。我选的是 Ubuntu 22.04 LTS原因是社区支持好、包管理方便、遇到问题容易搜到解决方案。ARM 架构的 Ubuntu 镜像在 Oracle 上是可用的创建时注意选择 aarch64 架构的镜像。创建完成后第一件事是更新系统sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim htop net-tools这几条命令看起来简单但有一个细节值得注意Oracle Cloud 的默认镜像有时候会自带一些不必要的服务比如 snapd 的自动更新可能会在你不注意的时候占用带宽和 CPU。如果你对资源比较敏感可以考虑禁用 snapd 自动更新或者至少知道它在后台干什么。3.2 网络与防火墙两层防护都要过Oracle Cloud 的网络配置是两层防火墙一层是云平台的安全列表Security List或者网络安全组NSG另一层是实例内部的 iptables。很多人只改了其中一层然后发现端口还是不通就开始怀疑人生。我的做法是先在 Oracle Cloud 控制台的网络配置里放行你需要的端口。Hermes 默认可能用某个端口比如 8080 或者自定义端口你需要把这个端口的入站规则加到安全列表里。然后登录到实例内部检查 iptables 规则sudo iptables -L -n --line-numbers如果发现默认规则是 DROP 或者 REJECT你需要手动添加放行规则。Ubuntu 上通常用 ufw 来管理但 Oracle Cloud 的镜像有时候 ufw 是关闭的iptables 规则是直接生效的。我建议统一用 iptables 来管理避免 ufw 和 iptables 规则冲突。注意Oracle Cloud 的实例默认可能只开放了 SSH 端口22。如果你要通过浏览器访问 Hermes 的 Web 界面需要额外放行对应的 HTTP 端口。放行之后最好用curl在本地测试一下端口是否真的通了别等到配置完 Hermes 才发现访问不了。3.3 创建专用用户与目录结构我不建议直接用 root 跑 Hermes。创建一个专用用户把 Hermes 和相关文件都放在这个用户的家目录下权限清晰出问题也好排查。sudo useradd -m -s /bin/bash hermes sudo passwd hermes sudo usermod -aG sudo hermes然后切换到 hermes 用户创建目录结构su - hermes mkdir -p ~/hermes/{app,models,logs,data}这个目录结构是我自己用的app放 Hermes 的程序文件models放本地模型文件logs放日志data放运行时的数据。分开的好处是备份和迁移的时候目标明确不会把模型文件和日志混在一起。4. 安装 Hermes依赖、模型与首次启动环境准备好之后就可以开始装 Hermes 了。这一步是整个部署过程中最容易出问题的环节因为涉及 Python 依赖、模型下载、配置文件的编写。我会把每个步骤的意图和可能遇到的问题都讲清楚。4.1 Python 环境与依赖安装Hermes 大概率是基于 Python 的项目从关键词里的“flask 部署”“ollama 本地部署”可以推断它可能涉及 Python Web 框架和模型运行时。在 Ubuntu 22.04 上系统自带的 Python 版本是 3.10基本够用。但我建议用虚拟环境来隔离依赖避免污染系统 Python。sudo apt install -y python3-pip python3-venv cd ~/hermes/app python3 -m venv venv source venv/bin/activate虚拟环境激活后安装依赖。如果 Hermes 提供了requirements.txt直接pip install -r requirements.txt如果没有就需要根据它的文档手动安装。这里有一个 ARM 架构特有的坑某些 Python 包在 aarch64 上的预编译轮子wheel可能不存在pip 会尝试从源码编译而编译又需要额外的系统依赖。比如numpy、scipy这些科学计算包在 ARM 上通常有轮子但一些冷门的包可能没有。遇到编译失败时先看错误信息里缺什么头文件然后用apt安装对应的-dev包。4.2 模型的选择与下载本地模型 vs 远程 APIHermes 支持两种模型接入方式本地模型和远程 API。我的建议是两者结合——日常问答用本地模型复杂任务或者本地模型搞不定的问题走远程 API。这样既能保证基本可用性又能在需要的时候获得更强的推理能力。本地模型方面我选的是 7B 级别的量化模型Q4 量化后文件大小在 4GB 左右加载到内存后占用 5-6GB。下载模型文件时注意存储空间——Oracle Cloud 免费实例的默认磁盘是 47GB 左右放一个 7B 模型加上系统和其他文件空间是够的但如果你要放多个模型就得注意清理。cd ~/hermes/models # 假设模型文件已经下载好放到这个目录 ls -lh如果你用的是 Ollama 来管理本地模型安装过程会简单很多curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2:7bOllama 在 ARM 上的支持还不错安装后会注册为系统服务开机自启。但要注意Ollama 默认监听的是127.0.0.1:11434如果你想让 Hermes 通过它来调用模型需要确保 Hermes 能访问到这个地址。如果 Hermes 跑在同一个机器上直接用 localhost 就行。4.3 配置文件的关键字段与首次启动Hermes 的配置文件通常是一个 YAML 或者 JSON 文件里面定义了模型路径、监听端口、API 密钥如果走远程 API、skill 配置等。我建议先把最小配置跑通再逐步加功能。一个典型的最小配置大概长这样具体字段名以实际项目为准server: host: 0.0.0.0 port: 8080 model: provider: ollama base_url: http://127.0.0.1:11434 model_name: qwen2:7b skills: - name: basic_qa enabled: true首次启动时用前台模式运行方便看日志cd ~/hermes/app source venv/bin/activate python main.py如果看到服务启动成功的日志并且没有报错就可以用curl测试一下curl http://127.0.0.1:8080/health返回正常的话说明 Hermes 已经跑起来了。这时候你可以通过浏览器访问http://你的服务器IP:8080看看 Web 界面是否正常。如果访问不了回到第 3.2 节检查防火墙规则。提示首次启动时模型加载可能需要一些时间尤其是从磁盘读取大文件的时候。如果日志显示正在加载模型耐心等一会儿别急着以为卡死了。5. 让它真正 7×24 小时在线进程守护与资源管理服务能跑起来只是第一步让它稳定地一直跑下去才是关键。我见过太多人把服务启动起来就不管了结果 SSH 一断开服务也跟着挂了。或者跑了几天之后内存泄漏把机器拖垮。这一节讲的就是怎么避免这些问题。5.1 用 systemd 管理 Hermes 服务最省心的方式是写一个 systemd unit 文件让系统来管理 Hermes 的启动、停止和重启。这样即使服务器重启Hermes 也会自动拉起来。[Unit] DescriptionHermes AI Assistant Afternetwork.target ollama.service [Service] Typesimple Userhermes WorkingDirectory/home/hermes/hermes/app EnvironmentPATH/home/hermes/hermes/app/venv/bin:/usr/local/bin:/usr/bin:/bin ExecStart/home/hermes/hermes/app/venv/bin/python main.py Restartalways RestartSec10 StandardOutputappend:/home/hermes/hermes/logs/hermes.log StandardErrorappend:/home/hermes/hermes/logs/hermes.err [Install] WantedBymulti-user.target把这个文件保存为/etc/systemd/system/hermes.service然后sudo systemctl daemon-reload sudo systemctl enable hermes sudo systemctl start hermes sudo systemctl status hermesRestartalways是关键它保证服务意外退出时会自动重启。RestartSec10表示重启前等 10 秒避免频繁重启导致资源浪费。5.2 内存与 CPU 的监控和限制Oracle Cloud 免费实例虽然有 24GB 内存但如果你同时跑 Ollama 和 Hermes再加上系统本身的开销内存占用会比较高。我建议给 Hermes 和 Ollama 分别设置内存限制避免其中一个把内存吃光导致系统 OOM。systemd 支持MemoryMax和CPUQuota参数[Service] MemoryMax8G CPUQuota300%MemoryMax8G表示这个服务最多用 8GB 内存超过会被限制。CPUQuota300%表示最多用 3 个核心的算力4 核机器上留一个核心给系统和其他服务。这些限制不是必须的但在资源有限的免费实例上加上它们能显著提升稳定性。监控方面我习惯用htop快速看一眼但长期监控还是得靠日志。Hermes 自己的日志加上 systemd 的 journal基本能覆盖大部分排查需求journalctl -u hermes -f tail -f ~/hermes/logs/hermes.log5.3 自动重启与健康检查的配合systemd 的Restartalways解决的是进程崩溃的问题但如果进程还在、只是卡死了systemd 是不会重启它的。这时候需要一个健康检查机制。最简单的做法是写一个定时任务定期请求 Hermes 的健康检查接口如果连续失败就重启服务。#!/bin/bash # /home/hermes/health_check.sh if ! curl -sf http://127.0.0.1:8080/health /dev/null; then echo $(date): Health check failed, restarting hermes /home/hermes/hermes/logs/health.log sudo systemctl restart hermes fi然后用 crontab 每 5 分钟跑一次crontab -e # 添加一行 */5 * * * * /home/hermes/health_check.sh这个脚本很简单但实际用下来很有效。我有一次遇到 Hermes 因为模型加载异常导致接口无响应进程还在但就是不返回结果健康检查脚本在 5 分钟内就把它重启了。6. 踩过的坑与排查实录部署过程中遇到的问题不少我挑几个有代表性的讲一下重点是排查思路因为具体问题可能因人而异但排查方法是可以复用的。6.1 端口不通两层防火墙的排查链路最开始配置的时候我在 Hermes 里设置了监听 8080 端口本地curl是通的但从外部访问就是不行。排查过程如下第一步确认 Hermes 确实在监听 8080ss -tlnp | grep 8080输出显示0.0.0.0:8080说明监听没问题。第二步检查实例内部的 iptablessudo iptables -L INPUT -n --line-numbers发现默认策略是 DROP而且没有放行 8080 的规则。添加规则sudo iptables -I INPUT 6 -p tcp --dport 8080 -j ACCEPT第三步回到 Oracle Cloud 控制台检查安全列表。发现入站规则里确实没有 8080。添加一条入站规则源 CIDR 设置为0.0.0.0/0如果你知道自己的 IP可以限制得更严格协议 TCP目标端口 8080。三步走完外部访问就通了。这个排查链路的关键是先确认服务本身没问题再查内部防火墙最后查云平台的安全列表。顺序反过来的话容易在云控制台里瞎找半天。6.2 模型加载失败ARM 架构下的依赖问题有一次我尝试换一个模型结果 Hermes 启动时报错说某个 Python 包导入失败。看错误信息是一个用于模型推理的库在 aarch64 上没有预编译轮子pip 尝试从源码编译但失败了。解决办法是安装编译所需的系统依赖sudo apt install -y build-essential cmake libopenblas-dev然后重新安装那个 Python 包。如果还是不行就找这个包的 ARM 兼容版本或者换一个不需要这个依赖的模型。这件事给我的教训是在 ARM 架构上部署 AI 相关项目一定要提前确认关键依赖是否有 ARM 支持。x86 上很成熟的东西ARM 上不一定有现成的轮子。6.3 内存不足导致服务被系统杀掉跑了一段时间之后我发现 Hermes 偶尔会莫名其妙地重启。查 journal 日志journalctl -u hermes | grep -i killed\|oom发现系统 OOM killer 把 Hermes 进程杀掉了。原因是 Ollama 加载模型后占用了大量内存加上 Hermes 本身的开销超过了可用内存。解决办法有两个一是给 Ollama 设置内存限制二是换一个更小的模型。我最后是把模型从 7B 换成了更小的量化版本同时给 Ollama 加了MemoryMax12G的限制。调整之后OOM 问题就没再出现过。问题现象可能原因排查命令解决方案外部无法访问防火墙未放行iptables -L放行端口 云安全列表启动报错ARM 依赖缺失查看错误日志安装编译依赖或换包服务自动重启内存不足 OOMjournalctl -u hermes限制内存或换小模型接口无响应模型加载卡死curl /health健康检查 自动重启7. 日常使用中的几个实用技巧部署完成之后日常使用中还有一些小技巧能让体验更好。这些不是必须的但用上了会省心不少。7.1 用别名简化常用命令我习惯在.bashrc里加几个别名减少重复输入alias hstatussudo systemctl status hermes alias hlogjournalctl -u hermes -f alias hrestartsudo systemctl restart hermes alias ollogjournalctl -u ollama -f这样查看状态、看日志、重启服务都是一条短命令的事。7.2 日志轮转避免磁盘写满Hermes 和 Ollama 的日志如果一直往一个文件里写时间长了会把磁盘占满。用 logrotate 来管理sudo vim /etc/logrotate.d/hermes内容/home/hermes/hermes/logs/*.log { daily rotate 7 compress missingok notifempty }这样日志每天轮转一次保留 7 天自动压缩。磁盘空间就不会被日志吃光了。7.3 定期备份配置文件和数据Hermes 的配置文件、skill 配置、以及data目录里的数据建议定期备份。我用的方法很简单写一个脚本打包这些文件放到另一个目录或者同步到对象存储#!/bin/bash BACKUP_DIR/home/hermes/backups mkdir -p $BACKUP_DIR tar czf $BACKUP_DIR/hermes-config-$(date %Y%m%d).tar.gz \ /home/hermes/hermes/app/config.yaml \ /home/hermes/hermes/data \ /etc/systemd/system/hermes.service # 只保留最近 7 天的备份 find $BACKUP_DIR -name hermes-config-*.tar.gz -mtime 7 -delete这个脚本可以加到 crontab 里每天跑一次。备份文件不大但关键时刻能省去重新配置的麻烦。7.4 根据使用情况调整模型和参数用了一段时间之后你会对自己的使用模式有更清楚的了解。如果主要是短问答小模型完全够用响应还更快如果需要处理长文本或者复杂推理可以考虑在需要的时候临时切换到远程 API。Hermes 的配置支持多模型切换的话可以配置一个本地模型作为默认一个远程 API 作为备选在 skill 或者请求参数里指定用哪个。我在实际使用中的体会是不要追求“一步到位”配置一个完美方案而是先跑起来用起来然后根据实际遇到的问题逐步调整。最开始我花了很多时间纠结选哪个模型、参数怎么调后来发现先把基础服务跑通用起来之后再优化效率高得多。8. 这套方案后续还能怎么扩展Hermes 跑起来之后它就是一个常驻的 AI 代理服务你可以围绕它做很多扩展。比如接入更多的 skill 让它能处理特定领域的任务或者把它和其他的自动化工具串联起来形成一个简单的自动化工作流。关键词里提到的“hermes skill”和“hermes 智能体”指向的就是这个方向——Hermes 本身是一个框架真正的价值在于你往里面加什么。另一个扩展方向是监控和告警。你可以让 Hermes 定期检查某些指标发现异常时通过它支持的渠道发通知。或者反过来把 Hermes 的日志接入到现有的监控系统里统一管理。最后再分享一个小技巧如果你有多台服务器可以把 Hermes 的配置和模型文件放在共享存储上这样换机器或者扩容的时候直接挂载共享存储就能用不用重新下载模型和配置环境。这个做法在需要快速迁移或者做冗余的时候特别有用。踩过几次坑之后我最大的感受是免费服务器跑 AI 助手这件事技术门槛没有想象中那么高但细节特别多。把系统层、网络层、服务层这三层都理顺了后面就是享受 7×24 小时在线的便利了。