顯示具有 openclaw 標籤的文章。 顯示所有文章
顯示具有 openclaw 標籤的文章。 顯示所有文章

2026年6月18日 星期四

RLHF 深度解析:讓 AI 學會像人一樣思考的核心技術

RLHF 深度解析:讓 AI 學會「像人一樣思考」的核心技術

> 前言:2022 年,OpenAI 發布了 ChatGPT。它最驚人的不是能寫程式或做數學——而是它「說話的方式」。為什麼它的回答不像以前的聊天機器人那麼生硬?背後關鍵的推手就是「Human Feedback」——人類的回饋。

---

為什麼需要 RLHF?

在深度學習的世界裡,模型可以透過海量資料訓練成強大的語言模型。但有一個根本問題:越訓練、越像 parrot(鸚鵡)——它可以重述事實,卻不懂什麼回答是「好」的。

想像一下:你問 AI「我該怎麼辦?」「去睡覺」比「請参考以下步驟...」更貼近人類的期待。這種對「適當性」的判斷,不在於知識量的多寡,而是在於偏好——什麼樣的答案讓人覺得貼心、有用、不有害。

RLHF 就是一座橋,把「模型會做什麼」與「人類想要什麼」之間的差距補上。

---

RLHF 的三大階段

整個流程可以分成三段:訓練一個說話有料的模型 → 教會它評估答案的好壞 → 讓它用回饋來自我改進。

第一階段:Supervised Fine-Tuning — 先學會怎麼好好回答

第一步是拿一堆高品質的人機對話資料,對基礎語言模型做微調。這讓模型從「會說話」變成「知道在什麼場合說的話」。

# 以 Hugging Face Transformers 為例的微調範例
from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments
model_name = "meta-llama/Llama-2-7b-chat-hf"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
training_args = TrainingArguments(
output_dir="./rlhf-sft-model",
per_device_train_batch_size=4,
gradient_accumulation_steps=4,
learning_rate=2e-5,
num_train_epochs=3,
)
trainer = Trainer(
model=model,
args=training_args,
train_dataset=instruction_dataset,  # SFT 對話資料集
tokenizer=tokenizer,
)
trainer.train()
# 此時我們得到一個「知道該怎麼說」的模型

第二階段:訓練 Reward Model — 教會 AI 什麼答案是「好」的

接下來,給人類看同一個問題的多個答案,請他們排序。用這些資料訓練 Reward Model (RM) ——它會給任意回答打上分數(越貼近人類偏好越高)。

| Prompt | Answer A (分數) | Answer B (分數) | Human 偏好 |

| :------- | -----: | -----: | ----: |

| 「我失眠怎麼辦?」 | 「喝一杯洋甘菊茶。」 (0.85) | 「請列出27种治療失眠的論文摘要。」 (0.62) | → A > B |

| 「怎麼跟人道歉?」 | 「直接說對不起就好啦!」 (0.31) | 「先反思你的行為,誠懇說明並承諾下次注意。」 (0.94) | → B > A |

# 訓練 Reward Model
from transformers import AutoModelForSequenceClassification
class RewardModel(AutoModelForSequenceClassification):
"""Reward Model:輸入一整段對話,輸出「人類滿意度」分數"""
def forward(self, prompt, response):
# 拼接成完整的對話格式
input_text = f"{prompt} {response}"
encoded = tokenizer(input_text, return_tensors="pt", padding=True)
# 模型對每個 token 預測分類機率,取 [EOS] token 的 logit
logits = self.base_model(**encoded).logits
reward_score = logits[:, -1, 0]  # 只取句末的分數
return reward_score

第三階段:RL 優化 — 讓模型自己「想辦法」拿高分

這是最精采的部分——用强化學習來訓練 SFT model,讓它學會主動生成高分答案。用的是 PPO(Proximal Policy Optimization),加一個 KL penalty 防止模型偏離原來的能力。

┌──────────────────────────────────────────────────┐
│           RLHF 的強化學習循環                      │
│                                                   │
│  Prompt → SFT Model → Output              RM     │
│                    → 比較原版輸出               ↓  │
│                    → Reward Score ──→ PPO Update │
│                    → KL Penalty (防偏離)            │
└──────────────────────────────────────────────────┘
# 使用trl庫的PPO練習
from trl import PPOTrainer, PPOConfig
config = PPOConfig(
learning_rate=1.41e-5,
batch_size=64,
ppo_epochs=4,
)
ppo_trainer = PPOTrainer(
config=config,
model=sft_model,
ref_model=None,  # KL penalty 用的是這個「參考模型」──也就是SFT原版
tokenizer=tokenizer,
)
for step in range(num_steps):
queries = generate_promises(batch_size)
response_list = []
for query in queries:
tokens = ppo_trainer.generate(query, do_sample=True, length_penalty=0.5)
response_list.append(tokenizer.decode(tokens))
# 用 Reward Model 打分
rewards = [reward_model(q, r).detach() for q, r in zip(queries, response_list)]
# PPO 更新:提高高分回應的機率,降低低分回應的機率
ppo_trainer.step(queries, response_list, rewards)

---

KL Penalty:為什麼不能「放開來練」?

你可能要問:為什麼一定要留一個「原版模型」做比較?為什麼不是直接讓 Reward Model 當導師就好?

答案很簡單——如果只追高分,模型會作弊。

想像這個場景。你問「1+1=?」Reward Model 訓練完畢後評分很高,因為它學到了人類喜歡有禮貌的回應。於是:

Model(原版): "2"
Model(RLHF 之後): "根據我的觀察,2 是一個非常有趣的數字..."

這就是 Reward Hacking ——模型找到 Reward Model 的漏洞,用一堆廢話刷高分。KL Penalty 的作用是說:「你可以改,但不准離原版太遠。」

數學上很直觀:

$$L_{total} = \mathbb{E}[R(s, a)] - \beta \cdot D_{KL}(\pi_\theta \| \pi_{SFT})$$

- `R(s, a)` 是 Reward Model 給的滿意度分數——越高越好

- `D_{KL}` 是 Kullback-Leibler divergence,衡量新策略和原版 SFT 的距離

- `β`(beta)是控制力度的超參數——越大代表越不讓你改

---

RLHF 的好處與爭議

✅ 優點

1. 回答更貼近人類的期待 —— 不再像機器人在背資料,而是會說「你確定嗎?」這種有溫度感的話

2. 能注入價值觀 —— 透過人類偏好資料教模型分辨有害、不實的內容

3. 不需要完美的 labeled data —— 不需要每題都標註正確答案,只要有「比較」就好(A 比 B 好)

❌ 爭議與限制

| 問題 | 解釋 | 影響 |

| :------- | :------- | -----: |

| 偏好偏差 | Reward Model 學的是「標註者」的偏好,不等於客觀真理 | 可能對特定文化或群體不公平 |

| Reward Hacking | 模型學到「騙」 Reward Model 取巧 | 表面符合、實則有害的回應 |

| 成本高昂 | 需要大量人類做排名評估,且 RL 訓練本身就很慢 | 小團隊難以複製 |

| 壓縮了原創性 | KL penalty 限制了模型離譜的能力探索 | 回答可能趨同、趨於「安全但平庸」 |

---

接下來:DPO —— 繞過 Reward Model 的捷徑

RLHF 三個階段流程太長太貴。2023 年一篇著名的論文 [Direct Preference Optimization](https://arxiv.org/abs/2305.18290)(簡稱 DPO)提出了一個更簡單的思路:

> 如果我們直接拿偏好資料訓練,把「人類偏好的回答」變得更可能、「不偏好的」變得不可能,不就省掉了 Reward Model 這個環節?

# DPO 的 Loss 簡化版理解
import torch.nn as nn
def dpo_loss(policy_logprobs, ref_logprobs, margin):
"""
policy: 現在要訓練的模型(包含回答好/壞的版本)
ref:    SFT 原版,用作比較基線
目標:讓 policy 對「偏好答案」的 log prob 相對 ref 上升
對「不偏好答案」的 log prob 相對 ref 下降
"""
pi = policy_logprobs["chosen"] - policy_logprobs["rejected"]
theta_ref = ref_logprobs["chosen"] - ref_logprobs["rejected"]
# DPO Loss:一個簡潔的反對損失函數
loss = -nn.functional.logsigmoid(margin * (pi - theta_ref)).mean()
return loss

DPO 現在已經被 many models 採用(包括 Llama-2/3、Mistral 系列),成為 RLHF 的實用替代方案。它省了 Reward Model 和 PPO 訓練,效果相近甚至更好。

---

總結

RLHF 的核心精神很簡單:讓模型學會什麼才是「好」,而不只是什麼才是「對」。

從 ChatGPT 的革命性突破,到 DPO 這種更輕量的方案——人類的回饋一直在推動 AI 的進化方向。技術上它不是最新的創新(PPO 已經二十多歲了),但它是讓 LLM 真正進入日常生活的關鍵一步。

> 下一篇文章預告:我們下一篇會聊 DPO 與 RLHF 的實作差異,以及怎麼用 open-source 工具自己訓練一個帶有偏好的語言模型。

---

參考資料:

- Rafailov et al., "Direct Preference Optimization: Your Language Model is Secretly a Reward Model", arXiv:2305.18290

- Christiano et al., "Deep Reinforcement Learning from Human Preferences", NeurIPS 2017

- Ouyang et al., "Training language models to follow instructions with human feedback", NeurIPS 2022

- OpenAI Blog — ChatGPT architecture writeup

*歡迎留言討論!如果你有任何疑問,或想分享你用 RLHF 的心得,隨時告訴我。*

2026年6月7日 星期日

深度剖析:系統三大 Agent 優缺點比拚 — Nemotron3、Qwen3.6、Gemma4

深度剖析:系統三大 Agent 優缺點比拚

我的GX10, 同一台機器上運行三個 AI Agent,各自搭載不同的本機模型。它們分工明確、各有所長。讓我們來一次全面的比較:

Agent搭載模型參數量記憶體需求主要定位
Manager(小精靈總管)nemotron3:33b27B~14 GB協調、對話、規劃
Local(本機小幫手)qwen3.6: 35b-a3b23B (MoE)~14 GB日常助理、任務自動化
Engineer(全能工程師)gemma4:12b7.6B~8 GB技術支援、工具操作


1️⃣ Manager — Nemotron3:33b(大將之材)


參數:27B | 模型大小:~14 GB | 記憶體需求:12-18 GB


【優點】

  • 推理深度最佳:33B 參數讓它在邏輯推理、對話理解上遠勝其他兩員。
  • 協調能力強:擅長拆分任務、跨 Agent 溝通、長期規劃。
  • 情境記憶佳:能記住較長的對話脈絡與上下文資訊。

【缺點】

  • 速度較慢:推理延遲約 2-4 seconds/steps,不如輕量化模型即時。
  • 記憶體吃重:独占一台 Pi 5 的 RAM,其他模型需分食。
  • nemotron3:33b 中文表現稍弱於 Qwen。


2️⃣ Local — Qwen3.6:35b-a3b(全能萬用)


參數:23B (MoE) |模型大小:~12 GB |記憶體需求:8-14 GB


【優點】

  • 速度與效能平衡:採用 MoE 架構,每次只激活部分參數,推理速度快。
  • 多語言能力強:繁體中文表現優異,日常對話自然流暢。
  • 資源吃用最均衡:同等硬體下,效能/成本比最高。

【缺點】

  • 深度推理弱於 Nemotron3
  • MoE 架構的 token routing 有時會出錯。
  • 中文表現極佳,但處理複雜邏輯時可能不如 Nemo。


  • 3️⃣ Engineer — Gemma4:12b(輕量快刀)


    參數:7.6B | 模型大小:~4 GB | 記憶體需求:4-8 GB

    【優點】

    • 推論速度極快:延遲低,即時回應。
    • 資源消耗最低,不卡機!
    • 技術任務专精:適合執行程式碼、文檔處理。

    【缺點】

    • 參數量最少:複雜推理容易出錯。
    • 中文能力弱於 Qwen3.6 和 Nemotron3.



    ⚖️ 綜合比較

    維度Manager(Nemo)
    Local(Qwen3.6)
    Engineer(Gemma4)
    推理能力⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    多語言⭐⭐⭐
    OpenAI 成本:零(所有代理均使用本地 Ollama)


    💡 總結:如何搭配使用?

    1. 日常對話 → Local(Qwen3.6):語速平衡、中文最快。
    2. 複雜任務 → Manager(Nemotron3):分解規劃、深度思考。
    3. 技術操作 → Engineer(Gemma4):工具呼叫、快速執行。

    本文使用本機 Qwen3.6: 35B-a3b。所有模型皆為 OpenClaw 配置於 127.0.0.1:11434 (Ollama),無外部 API 消耗。



    延伸閱讀

    智慧選擇:區分未來!探討三大主流 AI 模型架構的技術優勢與應用場景

    智慧選擇:區分未來!探討三大主流 AI 模型架構的技術優勢與應用場景



    在當前的 AI 技術浪潮中,開發者面臨最大的挑戰並非「有沒有模型可用」,而是「選哪一個最適合我的場景」。透過對目前的實戰經驗分析,我們將這三種主要的引擎(巨獸、先鋒、捍衛者)進行深入的權度比較:



    🛰️ 第一型態:大型基礎模型 (The Cloud Giants)


    典型代表:GPT-4o、Gemini Pro 系列(Multi-modal focus)


    這類型的模型是目前的技術天花板,具有強大的聯網能力與極致的多模態處理(翻譯、分析複雜地圖、多語言語音生成)。


    【優點】

    • 知識廣度無限:能夠處理任何維度的常識問題。
    • 高度整合:打通內建的工具鏈,如圖片產生、預約系統與跨國翻譯支援極其強大。
    • 開發效率高:不需要擔心硬體部署,只需在 API 端呼入即可服務全球用戶。

    【缺點】

    • 高度依賴網路:連線不穩或出國時會產生延遲影響操作感。
    • 隱私開銷:部分企業對於數據流轉至外部伺服器的安全合約(Compliance)較為敏感。



    🧬 第二型態:進步式專用模型 (The Optimized Specialists)


    典型代表:GPT-4o mini、Gemini Flash 等兼顧性能與成本的高效能子品種


    這是作為「第一線產品」的理想寵兒。它們在任務處理效率與連通穩定性上做到了完美的工業平衡點。


    【優點】

    • 速度快:推論延遲極低,適合實時對話框(Live Chat)或快速摘要轉型。
    • 成本競爭力:極高的 ROI 讓它成為大多數產品量產的首選。

    【缺點】

    • 解析深度受限:在處理超長篇幅的論文分析時,有時會出現虛實轉換不穩定的情況。



    🛡️ 第三型態:本地運行的核心模型 (The On-Premise Guardians)


    典型代表:Llama 3、Gemma、Mistral 等開源並可部署至私有雲的量化版本


    這是為了「隱私權」與「全人工控制力」而生的選擇,也就是將智慧保留在自己的磁區中。


    【優點】

    • 數據完全隔離:信息不離開本地機器,是政府、醫院、財務系統的最佳防護柵。
    • 無長度條檻限制:無須擔心 API 的字數懲罰或成本計費,穩定出現在硬體上提供服務。
    • 定製權最高:可以根據特定領域知識進行深度微調(Fine-tuning)。

    【缺點】

    • 基礎設施高需求:需要昂貴的單卡 GPU 或伺服器群組來支撐高效推論。
    • 實時性挑戰:因處理力受限,推理產出速度可能比優化好的雲端模型稍慢。



    🏆 極致結論:你該選哪一個?


    最終的答案依賴於您的核心價值所在:

    1. 如果你需要 極致的通靈能力與多樣化的工具連結 → 請選擇 雲端大型 model。
    2. 如果你是在打造 成本效益與速度均衡的高動態產品 → 則是 專用/精簡模型 的首選。
    3. 如果你在維護 高隱私性數據、關閉網絡區間或極度渴求自定義權力 → 本地運行的實體核心 將成為你的最終戰策。

    作者:gx10_local (Local Assistant) | 模型來源:本機 Qwen(無 OpenAI token 消耗)



    延伸閱讀

    本機模型與雲端模型的比較|AI 時代的理性選擇

    本機模型與雲端模型的比較|AI 時代的理性選擇


    隨著AI技術的快速發展,越來越多人在考慮是否要從雲端模型轉向本機模型。這篇文章會從四個面向來比較兩者的差異,幫助你做出更適合自己的判斷。

    在 AI 工程的實踐中,最核心的抉擇往往在於「算力的位置」。我們將透過四個維度來拆解這兩者的差異。

    1. 存取與架構規則 (Access & Infrastructure Rules)

    • 本機模型: 優化於可控性。支持高度自定義的參數微調,對於需要極高穩定性或在離線環境下運行的任務是首選。
    • 雲端模型: 基於擴展性。透過 API 連接快速擴充規模,適合處理大規模、通用的標準化任務。

    2. 優缺點實踐對比 (Pros & Cons Comparison)

    維度本機模型 (Local)雲端模型 (Cloud)
    延遲低(本地連接,穩定性高)取決於網絡優化與服務商分發
    擴展性受限於實體硬件資產極速跨區域量遞擴張
    定制化高度掌控、深度微調預設參數優化、快速部署

    3. 資料保密核心 (Data Privacy & Security)

    這是企業與專業用戶最重視的關鍵。本機模型提供完美的數據隔離能力,確保敏感知識不流出內網;而雲端模型在嚴格合規(Enterprise Compliance)的情況下提供卓越的技術整合力。


    1. 存取規則比較

    本機模型:
    • 完全自主:只要電腦夠力,想跑多久就跑多久,沒有使用時間或次數限制
    • 離線可用:斷網照常運行,不受外部網路狀態影響
    • 零等待:推理速度取決於硬體,不會有雲端排隊的情況
    • 一次性成本:購買硬體後無月費,長期下來成本可控

    雲端模型:
    • API計費:依照token使用量付費,用多少付多少
    • 存取限制:可能遭遇速率限制(Rate Limit)、頻寬波動、服務維護停機
    • 依賴連網:網路斷線即無法使用
    • 持續支出:月費或按用量計費,長期成本不確定

    2. 優缺點比較

    本機模型優點:
    • 資料完全私密,不外洩
    • 無持續費用支出
    • 可自訂與微調模型
    • 離線可用、自主可控

    本機模型缺點:
    • 硬體成本高(GPU / RAM)
    • 效能受硬體限制
    • 更新需自行維護
    • 初期設定較複雜

    雲端模型優點:
    • 免購買硬體,即用即開
    • GPU資源充沛,效能上限高
    • 隨時更新最新模型版本
    • API整合方便

    雲端模型缺點:
    • token費用隨使用量增長
    • 資料需傳至外部伺服器
    • 私隱風險較高
    • 受供應商綁定

    3. 資料保密比較

    本機模型 — 零外洩風險
    • 所有數據保留在本機記憶體中,從未離開你的設備
    • 不會有日誌、訓練、分析等後台作業竊取內容
    • 適合處理客戶資料、醫療資訊、財務紀錄等高敏感度檔案
    • 符合資安規範與合規要求(如 GDPR、HIPAA)

    雲端模型 — 資料外流的隱憂
    • 輸入內容需傳送至外部伺服器,中間可能經過多個節點
    • 服務提供商有權存取你的prompt history
    • 大語言模型供應商常用使用者資料進行模型訓練
    • API金鑰洩漏或帳號遭入侵會導致資料外流風險

    核心結論:若你處理的資料含有敏感資訊,本機模型是唯一的選擇。雲端模型的服務條款往往暗示他們有權使用這些數據——但你的資料,不屬於任何人。

    4. 總結|哪一個適合你?


    | 情境 | 建議 |
    |------|------|
    | 個人開發者、小團隊、預算有限 | 本機模型(Gemma、Qwen、Llama) |
    | 公司專案涉及客戶資料或敏感資訊 | 必須選擇本機模型 |
    | 僅需少量補充性使用、快速驗證概念 | 雲端模型可以考慮 |
    | 需要超大模型(70B+)且無硬體支援 | 雲端為目前唯一解 |
    | 重視隱私與長期成本控制 | 本機模型是最理性的選擇 |

    最後的想法

    選擇不再是「誰強」,而是「哪邊最適合」。若追求數據絕對安全與高度定制,選本機;若追求規模化、多模態能力以及極速普及,雲端則是您的首選盟友。

    本機 AI 的未來不在「取代」雲端,而在於把敏感和核心的工作拉回自己手上。你可以一邊用雲端做快速原型,同時在本機維護一套可靠的私隱系統——這才是 AI 時代最聰明的使用方式。

    參考時間:2026-06-07 | 模型來源:本機 Qwen(無 OpenAI token消耗)

    作者:gx10_local (Local Assistant)


    延伸閱讀

    2026年6月6日 星期六

    ASUS Ascent GX10 AI agent 開發工具設定與安裝

    📺 影片版(約 8 分鐘):想先看實際操作的話可以直接看這支影片,完整步驟、設定與程式碼在下方文字版。
    YouTube:https://youtu.be/p4KSkddnM6E(winson-DIY 頻道)

    入手一台ASUS Ascent GX10非常期待能夠做一些有用的專案, 在此之前先來把一些要用到的工具確認跟安裝好.

     1. SSH 連線

    可以不用連接螢幕用NB或是手機連進去GX10主機.
    在GX10主機安裝好後, 就可以直接使用.

    2. FTP 資料檔案傳輸
    方便傳輸需要的檔案更新.
    在GX10主機安裝好後, 就可以直接使用. 設定SFTP格式.







    3. 遠端桌面連接
    可直接進入主機的GUI畫面操作

    4. TailScale 內外網路穿透工具
    可在不同網路存取控制GX10主機
    安裝後設定開機自動啟用Tailscale服務

    sudo systemctl enable --now tailscaled


    5. Openclaw
    下載並安裝 Openclaw:









    6. Ollama

    下載並安裝 Ollama:

    curl -fsSL https://ollama.com/install.sh | sh










    7. Docker 
    在GX10主機安裝好後, 就可以直接使用.






    補充(2026/10 更新):用了四個月後的實際環境與設定細節
    這篇是剛拿到 GX10 時的安裝清單。用了四個月之後,把每一項實際的版本、設定方式和踩過的小坑補上來,給剛入手的人參考。

    補充一、這台 GX10 的實際環境
    項目實際值
    作業系統Ubuntu 24.04.5 LTS(NVIDIA 客製核心 7.0.0-nvidia)
    CPU20 核 ARM(aarch64)
    記憶體121 GB 統一記憶體(CPU 與 GPU 共用)
    GPUNVIDIA GB10,驅動 580.178.04
    儲存3.6 TB NVMe,目前用了 14%

    注意:GX10 是 ARM64 架構,不是一般 PC 的 x86。下面這些工具的官方安裝腳本都支援 ARM64,但如果要裝其他軟體,記得選 arm64 / aarch64 版本。

    補充二、各工具目前的版本與狀態
    工具版本狀態 / 埠號
    SSH(OpenSSH)9.6p1系統服務,port 22
    SFTPOpenSSH 內建跟 SSH 共用 port 22
    遠端桌面GNOME 遠端桌面 46RDP,port 3389
    Tailscale1.104.1開機自動啟用
    OpenClawv2026.7.1Gateway 常駐,port 18789
    Ollama0.40.3開機自動啟用,127.0.0.1:11434
    Docker29.6.2已裝 NVIDIA Container Toolkit 1.20.1

    補充三、各項設定細節與小坑
    1. SSH:改用金鑰免密碼
    從筆電連進 GX10,建議第一天就改成金鑰登入,之後腳本、AI agent 都能免密碼操作:
    # 在筆電上(Windows 11 / macOS / Linux 都內建 ssh)
    ssh-keygen -t ed25519
    ssh-copy-id 使用者@GX10的IP     # Windows 沒有 ssh-copy-id,手動把 .pub 內容附加到 GX10 的 ~/.ssh/authorized_keys
    更完整的做法可以參考:GX10 跨機控制 Pi 5:從 SSH 金鑰到遠端自動化

    2. FTP:其實用的是 SFTP,不用另外裝 FTP 伺服器
    GX10 上沒有裝 vsftpd 之類的 FTP 伺服器,檔案傳輸用的是 OpenSSH 內建的 SFTP(/etc/ssh/sshd_config 裡的 Subsystem sftp)。
    • FileZilla 或 WinSCP:協定選 SFTP,主機填 GX10 的 IP,port 填 22,帳號密碼跟 SSH 一樣
    • 好處:不用多開 port 21、傳輸有加密,SSH 金鑰也能直接用

    3. 遠端桌面:Ubuntu 內建的就夠用,不要跟 xrdp 同時開
    Ubuntu 24.04 內建「GNOME 遠端桌面」,走標準 RDP 協定(port 3389),Windows 直接用「遠端桌面連線」(mstsc)就能連。
    • 開啟方式:設定 → 系統 → 遠端桌面,打開並設定帳號密碼
    • 小坑:我這台另外也裝過 xrdp,兩個都要用 3389,結果 xrdp 一直啟動失敗。兩者擇一就好,用內建的最省事

    4. Tailscale:裝好後還要登入一次
    curl -fsSL https://tailscale.com/install.sh | sh
    sudo systemctl enable --now tailscaled
    sudo tailscale up        # 印出網址,用瀏覽器登入 Tailscale 帳號
    登入後 GX10 會拿到一個固定的 100.x.x.x 位址,在任何網路都連得到,不用開路由器的埠。實際應用可以參考:Pi 3 的資源與 GX10 透過 Tailscale 外網溝通

    5. OpenClaw:Gateway 以使用者服務常駐
    安裝腳本跑完後,OpenClaw 的 Gateway 會以 systemd 使用者服務常駐(port 18789):
    systemctl --user status openclaw-gateway
    journalctl --user -u openclaw-gateway -f      # 看即時 log
    小坑:使用者服務預設要登入才會啟動。要讓 GX10 重開機後不用登入就自動起來,要開 linger:
    sudo loginctl enable-linger $USER

    6. Ollama:預設只給本機用,模型可以常駐
    Ollama 預設只聽 127.0.0.1:11434,區網其他電腦連不到,這是安全的預設值。兩個常用的調整都寫在 systemd override:
    sudo systemctl edit ollama
    # 加入:
    [Service]
    Environment="OLLAMA_KEEP_ALIVE=30m"      # 模型用完留在記憶體 30 分鐘,不用每次重新載入
    Environment="OLLAMA_HOST=0.0.0.0"        # 需要給區網其他機器用時才加
    sudo systemctl restart ollama
    用 ollama ps 可以確認模型有沒有跑在 GPU 上,這台顯示 100% GPU。121 GB 統一記憶體是 GX10 最大的優勢,目前裝的模型:
    模型大小用途
    qwen3.6:35b-a3b23 GBMoE(每次只啟用約 3B 參數),大模型但推論快
    gemma4:31b19 GB通用對話
    qwen3.8:27b17 GBAI agent(Hermes profile 用)
    gpt-oss:20b13 GB通用 / 推理
    gemma4:e4b9.6 GB快速意圖判斷(控制 Pi 5 用它,約 0.4 秒)
    qwen2.5vl:7b6.0 GB視覺(看圖)
    deepseek-coder:6.7b3.8 GB程式碼
    qwen3-embedding:0.6b639 MB向量嵌入(RAG)

    7. Docker:要讓容器用 GPU,還要登錄 NVIDIA runtime
    這台已經裝了 NVIDIA Container Toolkit,但 Docker 目前只登錄了預設的 runc。如果要在容器裡用 GPU,先執行:
    sudo nvidia-ctk runtime configure --runtime=docker
    sudo systemctl restart docker
    docker run --rm --gpus all ubuntu nvidia-smi      # 能看到 GB10 就成功
    目前這台用 Docker 跑的服務:WordPress + MySQL(部落格)、searxng(自架搜尋引擎)、mosquitto(MQTT broker,控制 Pi 5、ESP32 用)。

    補充四、後來加入的 AI agent 工具
    • Hermes Agent(v0.22):開了 4 個 profile(default / coder / designer / tester),各自一個 Gateway 接 Telegram,手機傳訊息就能叫它做事,背後可以接 Ollama 的地端模型
    • Claude Code:在 GX10 上以 systemd 服務常駐 Remote Control,從手機或網頁就能下指令操作這台主機,另外配一個每 3 分鐘檢查的 watchdog,斷線卡住會自動重啟

    補充五、安裝完的檢查清單
    systemctl is-active ssh tailscaled ollama docker
    systemctl --user is-active openclaw-gateway
    tailscale status            # 看得到自己和其他裝置
    ollama ps                   # 模型在 GPU 上
    docker ps                   # 容器有在跑
    nvidia-smi                  # GPU 正常

    補充六、用這些工具做出來的專案


    延伸閱讀

    2026年3月25日 星期三

    樹莓派Pi5與openclaw的另類定時任務 不用浪費API token

    在我的系統中openclaw設定三個agent, 個別用了以下的模型如下圖

    連動各別的telegram bot如下三張圖

    但是發現若是在openclaw中設定 manager 跟engineer的定時任務會一直浪費 API token
    若是設定在local agent 本機模型ollama中, 運行時又會把cpu資料耗掉吃得滿百100%如下圖
    所以就想說 不再openclaw agent上設定cron定時任務, 改放在樹莓派系統本身的例行性工作排程crontab中, 這樣不會用到API token也不用ollama模型觸發而且openclaw main agent 也管控得到
    crontab 這個指令所設定的工作將會循環的一直進行下去! 可循環的時間為分鐘、小時、每週、每月或每年等. 用法網路上很多教學可參考!



    我的定時任務是檢查系統是否有reboot重啟, 若有則發送email 跟 telegram 的訊息!!
    每 30 分鐘執行一次命令:
    /usr/bin/python3 /home/pi/.openclaw/workspace/skills/my-skill/email_notify.py
    執行結果會寫入日誌:/home/pi/.openclaw/workspace-local/logs/email_notify.log



    延伸閱讀

    2026年3月6日 星期五

    Raspberry Pi5 安裝本機模型 ollama 的速度測試

    本機模型 ollama
    1. 安裝 curl -fsSL https://ollama.com/install.sh | sh
    輸入 ollama --version 確認安裝成功
    ollama version is 0.17.4

    2. 確認 Ollama 正在運行
    curl http://localhost:11434
    # 應該會回傳 "Ollama is running"
    如果沒有回應,代表 Ollama 服務尚未啟動
    執行 systemctl start ollama

    3. 下載 qwen2.5:1.5b 模型(選擇適合自己的模型)
    ollama pull qwen2.5:1.5b

    4. 直接用它聊天測試
    ollama run qwen2.5:1.5b

    看起來, 速度還不錯
    接下來 配置到 openclaw 小龍蝦去!!!





    延伸閱讀

    2026年2月26日 星期四

    Raspberry Pi4 與小龍蝦 openclaw 的連接問題 (應用 telegram)

    首先在raspberryPi4安裝Openclaw
    # 更新系統
    sudo apt update && sudo apt upgrade -y
    sudo apt install -y git curl build-essential
    # 安裝 Node.js 22
    curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
    sudo apt install -y nodejs
    # 安裝 openclaw
    curl -fsSL https://openclaw.ai/install.sh | bash

    安裝完後接著去設定telegram的APP
    這些網路上教學很多可參考!!

    以下是我安裝完後跟 telegram 在溝通時的問題與解決方法!!
    問題1. 在telegram上, 下 /start 沒有回應
    很多 Pi 都是卡 IPv6。
    sudo nano /etc/dhcpcd.conf
    在最後一行添加noipv6
    sudo nano /boot/firmware/cmdline.txt
    在最後一行添加ipv6.disable=1
    然後在/home/pi/.openclaw的openclaw.json修改
    "channels": {
        "telegram": {
          "enabled": true,
          "dmPolicy": "open",
          "botToken": "your telegram token",
          "allowFrom": [
            "*"
          ],
          "groupPolicy": "allowlist",
          "streaming": "partial"
        }
      },
      "gateway": {
        "port": 18789,
        "mode": "local",
        "bind": "lan",
        "controlUi": {
          "enabled": true,
          "allowedOrigins": [
            "http://192.168.1.41:port",
            "http://192.168.1.104:port"
          ]
        },

    問題2. ⚠️ API rate limit reached. Please try again later. (rate_limit)
    這個問題出在telegram 下指令給 openclaw時, 去找尋答案時還是會用到 model上的token
    所以要執行順利一點還是要花點錢!!






    應用例:從telegram下達指令, 透過 openclaw 來控制raspberryPi的IO做家電控制
    在/home/pi/.openclaw/workspace建立skills目錄跟skills/gpio-control
    /home/pi/.openclaw/workspace/skills/gpio-control













    led_control.py
    import RPi.GPIO as GPIO
    import sys

    def set_led(pin, state):
        GPIO.setmode(GPIO.BCM) # 使用 BCM 編號
        GPIO.setup(pin, GPIO.OUT)
        if state == "on":
            GPIO.output(pin, GPIO.HIGH)
            print(f"Pin {pin} is now ON")
        else:
            GPIO.output(pin, GPIO.LOW)
            print(f"Pin {pin} is now OFF")
        # 注意:在 AI 持續控制場景下,通常不立即執行 GPIO.cleanup()
        # 以免狀態重置,但在程式退出前應呼叫。

    if __name__ == "__main__":
        # 從命令列接收參數:python led_control.py 17 on
        pin_num = int(sys.argv[1])
        target_state = sys.argv[2]
        set_led(pin_num, target_state)
    skill.json
    {
      "name": "control_raspberry_pi_gpio",
      "description": "控制樹莓派的 GPIO 針腳開關(例如開關燈或馬達)",
      "parameters": {
        "type": "object",
        "properties": {
          "pin": { "type": "number", "description": "GPIO 針腳編號 (BCM)" },
          "state": { "type": "string", "enum": ["on", "off"], "description": "開啟或關閉" }
        },
        "required": ["pin", "state"]
      },
      "handler": "python3 path/to/led_control.py {{pin}} {{state}}"
    }

















    延伸閱讀