我一直想要一台能夠長時間開機、放在家中運作，又不必把每一段資料都送到雲端的 AI 主機。Jetson Orin NX 正好位在一個很有意思的位置：它不像桌上型工作站那麼龐大，卻具備 NVIDIA GPU、CUDA 生態系與足以執行小型語言模型的記憶體。對我來說，它不只是一塊開發板，而是一台放在網路邊緣、可以持續演進的個人 AI 伺服器。
Jetson Orin NX 是什麼？
Jetson Orin NX 是 NVIDIA 面向邊緣 AI 與自主機器所推出的 System-on-Module。我的主機採用 16GB 版本，整合 Ampere 架構 GPU、Arm Cortex-A78AE CPU 與 16GB LPDDR5 記憶體。依 NVIDIA 資料表，這個版本具有 1,024 個 CUDA cores、32 個 Tensor cores，記憶體頻寬最高為 102 GB/s；一般模式的稀疏 INT8 AI 效能最高為 100 TOPS。較新的 MAXN SUPER 組態可以提高上限，但實際可用效能仍會受到 JetPack 版本、電力模式與散熱條件影響。
這種規格不適合拿來和高階桌上型顯示卡硬碰硬。它真正的優勢是體積小、功耗相對可控，而且 CPU、GPU 與共享記憶體集中在同一個模組上。對需要長時間運作的推論服務、機器人、影像分析或家庭實驗環境來說，這比單純追求最高跑分更實用。
Jetson Orin NX 本地 AI 部署目標
我沒有把 Jetson 當作只跑一次展示程式的開發板，而是把它整理成一台可以透過服務互相串接的主機。目前的核心架構可以簡化成：
Discord / 使用者請求
↓
Hermes Agent
↓
任務路由與驗證流程
├── llama.cpp 本地語言模型
├── 即時網路搜尋
├── Terminal / File / Browser 等工具
└── Skills 與任務記憶
這個架構的重點不是塞進最多服務，而是讓每一層都有清楚的責任：模型負責生成，Agent 負責決定何時使用工具，搜尋服務補足即時資訊，最後再由驗證步驟檢查結果。因為這台 Jetson 只有一個本地推論 slot，我讓各階段依序執行，避免多個角色同時搶用有限的記憶體。
服務一：以 llama.cpp 執行本地語言模型
底層模型服務使用 llama.cpp，並透過 CUDA 使用 Jetson 的 GPU。現在載入的是 NVIDIA Nemotron 3 Nano 4B 的 GGUF 量化模型，保留 64K context window，並設定為單一並行 slot。這不是追求最大吞吐量的配置，而是優先保留較長對話與工具操作所需的上下文。
16GB 統一記憶體同時要供作業系統、模型權重、KV cache 與其他服務使用，因此記憶體調校很重要。我把 KV cache 的 K 設為 q8_0、V 設為 q4_0，並關閉額外的 RAM cache。實測常駐記憶體用量約從 5.89GB 降到 4.21GB，同時 API 與相關服務仍能正常運作。這項調整讓 64K context 在這台 16GB 主機上更有實際使用空間。
服務二：Hermes Agent 與 Discord 入口
模型之上運行的是 Hermes Agent。它不是另一個模型，而是把語言模型、工具、工作階段與外部入口串在一起的 Agent 層。我透過 Discord 與它互動，讓 Jetson 上的本地模型可以接收問題、呼叫工具，再把結果回傳到熟悉的聊天介面。
我也調整了 Agent 的語言工作流程：理解問題與操作工具時保留英文技術名稱，對使用者則以台灣繁體中文回覆。這個要求看似只是語言設定，實際上還必須處理舊工作階段保留舊提示詞的問題。曾經出現工具已啟用，但 Discord 裡的既有對話仍認為自己無法上網；在備份狀態資料並讓舊工作階段結束後，新工作階段才正確載入新的能力。
服務三：即時搜尋與工具操作
本地模型的知識有截止時間，也不應該憑記憶回答即時新聞、價格或新版軟體資訊。因此我替 Hermes 啟用了網路搜尋能力，並實際驗證 Discord 對話能觸發搜尋，而不是只看到「工具已安裝」就宣稱完成。
目前 Agent 也啟用了 Terminal、File、Web、Memory、Session Search、Cronjob、Todo、Delegation、Browser 與 Code Execution 等 Toolsets。這讓它不只回答問題，也能在授權範圍內檢查檔案、執行指令、整理待辦與處理需要多個步驟的工作。
服務四：依任務啟動的條件式工作流程
我沒有讓多個 Agent 在 Jetson 上同時自由對話，而是把它們設計成同一條流水線上的不同處理節點。簡單問題直接整理回覆；需要即時資料時，先搜尋、再驗證；需要操作主機時，先檢查現況、執行操作，再確認服務狀態；較複雜的問題才加入分析階段。
- 一般或創作任務：直接整理成最終回覆。
- 即時研究：Researcher → Verifier → Formatter。
- 系統操作：Operator → Verifier → Formatter。
- 深度分析：視需要加入 Researcher 與 Analyst。
這種設計很適合資源有限的邊緣裝置：只有任務真的需要時才啟動對應步驟，而且所有步驟依序共用同一個模型服務。它犧牲了一部分平行速度，換來更可控的記憶體使用與比較清楚的驗證邊界。
Skills：已安裝不等於全部能力都已驗證
除了內建工具，我也加入了三個 Hermes 官方 Skills：用來改善溝通結構的 one-three-one-rule、研究與文件檢索用的 qmd，以及協助軟體開發除錯的 rest-graphql-debug。目前可以確認它們在 Hub 清單中屬於官方來源並已啟用。
不過，Skill 顯示為 enabled，只代表它已被系統載入，不代表所有外部相依套件與端到端情境都已通過測試。特別是 qmd 的實際索引流程與瀏覽器 runtime，我仍會等到完成完整測試後，才把它們列為正式可用的服務。這也是我部署本地 AI 時很重視的一條原則：安裝成功、服務啟動與功能真的能用，是三件不同的事。
下一步：本地語音轉文字
我接下來想加入 Whisper 類型的語音辨識服務，讓錄音可以在 Jetson 上直接轉成文字，再交給 Hermes 摘要或整理。初步方向是使用 faster-whisper 與 multilingual small 模型，包成相容 OpenAI /v1/audio/transcriptions 的本地 API；即時收音則還需要 VAD、串流分段與喚醒詞處理。
這一段目前仍是架構提案，尚未在這台主機上完成部署與效能測試。我還需要依實際 JetPack、CUDA 與可用記憶體，比較 faster-whisper、whisper.cpp 和 Jetson 專用 TensorRT 路線，再決定最適合繁體中文語音的方案。
使用 Jetson Orin NX 之後，我真正學到的事
Jetson Orin NX 的價值，不只是把一個小型語言模型跑起來。真正有趣的是：當模型服務、Agent、搜尋、工具與驗證流程被接在一起後，它開始像一台屬於自己的邊緣 AI 節點。
它當然有清楚的限制。16GB 記憶體要求我仔細管理模型大小與 KV cache；單一推論 slot 也代表工作流程必須依序執行。但這些限制反而迫使整套架構保持精簡。我可以清楚知道資料在哪裡處理、哪些能力真的驗證過，以及哪些功能還只是下一階段的計畫。
對我而言，這比單純追求更大的模型更重要：讓 AI 變成一項可以長期維護、可以觀察，也能逐步改善的本地服務。