顯示具有 ASUS Ascent GX10 標籤的文章。 顯示所有文章
顯示具有 ASUS Ascent GX10 標籤的文章。 顯示所有文章

2026年10月7日 星期三

用 SSH/ADB 遠端控制 Android 平板(Android on Raspberry Pi)完整記錄

把之前的文章 Raspberry Pi4 Project - Android system用我的gx10做控制

用 SSH/ADB 遠端控制 Android 平板(Android on Raspberry Pi)完整記錄

這台「平板」其實是一台跑 Android 15 on Raspberry Pi 4 的開發機(aosp_rpi4,userdebug build),區域網路 IP 固定 192.168.1.254。它的特殊之處:

  • Android 是 userdebug 版——有 su 0 可以直接進 root
  • 系統內建 root sshd(不是 Termux 開的),port 22
  • 金鑰放 /data/ssh/authorized_keys

本文記錄從 GX10 連到這台平板的完整步驟,以及過程中踩到的坑。

一、設備規格

項目 值
核心 Raspberry Pi 4(ARM64), Android 15(userdebug)
Kernel Linux 6.6
記憶體 7.6 GB
/data 分區 12 GB
IP 192.168.1.254(wlan0)
SSH

port 22,root 金鑰登入

二、連線前的準備(GX10 端)

1. 安裝 ADB client

GX10 是 Ubuntu 24.04 ARM64,adb 套件依賴舊的 OpenSSL 1.0,直接裝會缺庫。解法:

  • 從 Ubuntu bionic 的 android-tools-adb .deb 抽出 aarch64 的 adb 二進位
  • 搭配 bionic 的 libssl1.0(放 /tmp/ssl10/)
  • 建立 /home/gx/.local/bin/adb 包裝腳本,執行時設 LD_LIBRARY_PATH=/tmp/ssl10/ext/lib/aarch64-linux-gnu

2. 確認 SSH 金鑰

艦隊統一用 ~/.ssh/id_ed25519(同一支金鑰,所有設備)。

三、ADB 授權流程(最關鍵的一步)

adb devices -l
192.168.1.254:5555     device product:aosp_rpi4 model:Raspberry_Pi_4

坑: 第一次連上狀態是 offline,不是壞掉——是平板螢幕上彈著「允許從此電腦遠端調試嗎?」的對話框。

必做: 在平板上勾「永遠允許」→「允許」。否則永遠是 offline。(注意:離人時做這步會卡住,務必在平板前操作。)

四、找對 SSH 用戶(踩坑最多的部分)

坑 1:先試了十幾個用戶全被拒

pi / root / winson / user / shell / android ... 都 Permission denied。

解法:用 ADB 看 sshd 到底用誰跑

adb shell "ps -A | grep sshd -v grep"
root   2168   1   ...   S   sshd

→ sshd 是以 root 跑的。

坑 2:金鑰檔裡的公鑰「不是我的」

userdebug build 可以 su 0:

adb shell "su 0 sh -c 'wc -l /data/ssh/authorized_keys; cut -c1-40 /data/ssh/authorized_keys'"

檢查結果:檔裡有 5 支公鑰,沒有一支是 GX10 的——之前「已放金鑰」其實是另一台的。

坑 3:經 shell 貼多行文字會被轉義

解法:一律 base64 傳輸

KEY=$(cat ~/.ssh/id_ed25519.pub)
B64=$(printf '%s\n' "$KEY" | base64 -w0)
adb shell "su 0 sh -c 'echo $B64 | base64 -d >> /data/ssh/authorized_keys'"

放完立刻測:

ssh root@192.168.1.254 "id"
uid=0(root) gid=0(root)

✅ 成功。

五、使用方式

需求 指令
SSH ssh root@192.168.1.254(免密碼)
裝 APK adb install xxx.apk
截圖 adb exec-out screencap -p > screen.png
進 root 直接就是 root(免 su)
看 log adb logcat

六、注意事項(重點整理)

  1. ADB 授權框要人在場——沒按允許就是永遠 offline;重開機/清資料後權限可能被清,要重新授權
  2. root sshd 是安全敏感點——這是 userdebug 開發機,金鑰檔 /data/ssh/authorized_keys 等於 root 後門,只放自己人的公鑰;別用 password 登入
  3. 金鑰要對「這台」的金鑰檔核對——艦隊多台設備共用流程,但每台公鑰不同,放完一定要 ssh 驗證一次,並對照 cut -c1-40 確認是自己這支
  4. userdebug 的特性:有 su 0、adb root 可用,但不能當正式版用——升級 ROM、重刷後 sshd 服務可能不見
  5. IP 固定 192.168.1.254,走區網(wlan0),不在 Tailscale 上——GX10 須在區域網路內才連得到
  6. /data 只有 12G——裝模型/大檔案要挑,別當資料盤用

七、一句話總結

Android on Pi 平板 = ADB 授權(人在場)+ root sshd + 金鑰經 base64 放 /data/ssh/authorized_keys;userdebug 的 su 0 是找路徑的金鑰工具。放完公鑰先 ssh root@192.168.1.254 驗證,才算是真的接入艦隊。

2026年10月5日 星期一

Windows 11 接入 SSH 遠端控制:從 OpenSSH Server 到 TTS 中文朗讀的完整記錄

Windows 11 接入 SSH 遠端控制:從 OpenSSH Server 到 TTS 中文朗讀的完整記錄

ASUS Ascent GX10控制的第四台: windows 介面的 NB

AI fleet 第 5 台入列:WinsonNB(Windows 11 25H2、Ryzen 7 5900HS、RTX 3050 Ti)透過 Tailscale + 內建 OpenSSH Server,GX10 可以免密登入、遠端跑指令、甚至叫它喇叭念「XXX ,起床了」。

跟 Android 那台(Termux)不同,Windows 的 SSH 是官方內建的,不需要第三方套件——但坑一個不少。全部記錄如下。

一、目標機

項目 值
型號 WinsonNB(筆電)
系統 Windows 11 25H2(26200)
CPU AMD Ryzen 9 5900HS(8C/16T)
GPU NVIDIA RTX 3050 Ti + AMD Radeon 集顯
RAM 32 GB(實測時只剩 0.9 GB 可用,正有重任務在跑)
C 碟 288 GB NVMe,剩 169 GB
Tailnet 100.95.23.8

二、四步接入(實際走過的順序)

步驟 1:啟用 OpenSSH Server

Win+X → PowerShell(管理員):

# 確認功能(可能已預裝)
Get-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 | Select-Object State
# 若 NotPresent:
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
# 啟動 + 自動
Set-Service -Name sshd -StartupType 'Automatic'
Start-Service sshd
# 確認監聽
Get-NetTCPConnection -State Listen | Where-Object {$_.LocalPort -eq 22}

確認:0.0.0.0:22 和 [::]:22 都 LISTENING(雙 stack 正常)。

⚠️ 排查小坑:用 netstat -ano | findstr ":22 " 會被其他埠號包含 22 的項目(如 22112)誤導,以為有在監聽——要用 Get-NetTCPConnection -State Listen | Where LocalPort -eq 22 才準。

步驟 2:防火牆

New-NetFirewallRule -Name sshd -DisplayName "OpenSSH Server (sshd)" -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

不加這條,tailnet 的探測會直接 timeout(我們的實測:規則建好前 22 埠從 GX10 連 = timeout,建好後秒開)。

步驟 3:放公鑰(最大的坑,見第五節)

步驟 4:驗證

# GX10 端
ssh winso@100.95.23.8 'whoami; hostname'
# → winsonnb\winso / WinsonNB

三、遠端能力(全部實測)

能力 方式 驗證
跑指令 ssh … "powershell -Command ..." ✅
讀資源(CPU/RAM/GPU/碟) WMI/CIM 指令 ✅ 抓到 5900HS + RTX 3050 Ti
TTS 中文朗讀 System.Speech.SpeechSynthesizer 內建,不需裝任何東西 ✅ 喇叭實播「XXX,起床了」
檔案傳輸 scp 雙向 ✅

TTS 關鍵腳本(Windows 內建,免安裝)

Add-Type -AssemblyName System.Speech
$synth = New-Object System.Speech.Synthesis.SpeechSynthesizer
$synth.Speak("張瑞琪,起床了")

比 Android 的 termux-tts-speak 更乾淨——Windows 的 SAPI 聲音引擎選擇多(可選女聲/男聲/不同腔調)。

四、跟 Android 端對照

項目 Android(vivo) Windows 11
SSH server Termux openssh(第三方) 內建 OpenSSH(官方)
監聽埠 8022(慣例) 22(標準)
免密原理 authorized_keys authorized_keys(同一把)
TTS termux-tts-speak System.Speech(內建)
重開機保持 手動 boot script(vivo 會殺) systemd 對等:服務,穩
難度 7 坑 4 坑
拍相機 termux-camera-photo ✅ 要寫 MediaCapture(未做)

五、踩坑記錄(4 個,依發生順序)

坑 1:netstat -ano | findstr ":22 " 的假陽性

  • 現象:findstr 抓到 127.0.0.1:22112(某 app 的本地埠),以為 sshd 在監聽
  • 解法:改用 Get-NetTCPConnection -State Listen | Where {$_.LocalPort -eq 22}
  • 教訓:shell 的 substring grep 是排查網路問題的第一陷阱

坑 2:Set-Content 預設 UTF-16 BOM

  • 現象:公鑰檔「內容完全一樣」(hash 都算過)但 sshd 一律拒認
  • 真相:Windows PowerShell 5.1 的 Set-Content 預設用 UTF-16LE + BOM 寫檔,OpenSSH 不認
  • 解法:重寫時加 -Encoding ASCII(公鑰是純 ASCII,安全)
  • 教訓:跨平台放金鑰,編碼要顯式聲明——Pi/手機都是 LF+UTF-8,Win 預設 CRLF+UTF-16

坑 3:粘貼又丟字元(老坑重演)

  • 現象:92 vs 93 bytes,第三次出現這個問題了(手機那次是 92 vs 93)
  • 解法:不再貼——GX10 開 python3 -m http.server,Win 上一行 curl.exe -o ... http://100.69.83.97:port/id_ed25519.pub,SHA256 雙邊校驗(F3498230…995E67D 一致)
  • 教訓:「長字串跨機器」一律走檔案傳輸 + 雜湊校驗。這已是第三台機器驗證的方法,可靠率 3/3。

坑 4(★最深★):管理員的公鑰根本不在 authorized_keys

  • 現象:編碼修好了、hash 對了、權限收緊了(icacls 只留 winso/SYSTEM),還是 Permission denied,連續 4 次
  • 真相:用 sshd.exe -d -o LogLevel=DEBUG 前台跑除錯模式,一眼看到:
    user winso matched group list administrators at line 87
    trying public key file PROGRAMDATA/ssh/administrators_authorized_keys
    Could not open authorized keys ... No such file or directory

    Windows OpenSSH 的預設 sshd_config對管理員帳號有獨立規定:金鑰必須放 C:\ProgramData\ssh\administrators_authorized_keys,根本忽略 C:\Users\winso\.ssh\authorized_keys
  • 解法:
    powershell
    Copy-Item "$env:USERPROFILE\.ssh\authorized_keys" "$env:PROGRAMDATA\ssh\administrators_authorized_keys"
    icacls "$env:PROGRAMDATA\ssh\administrators_authorized_keys" /setowner "BUILTIN\Administrators"

    → 一次過,ssh winso@100.95.23.8 立刻登入成功
  • 教訓:
  • 卡住時,看 log 比猜快 100 倍——sshd.exe -d -E file.log 前台除錯模式,每條拒絕原因都寫得出來
  • Windows 的管理員/一般使用者金鑰路徑不同,這個差異官方文件藏得很深
  • 對一般使用者(非管理員),~/.ssh/authorized_keys 照常有效——這坑只咬管理員帳號

六、最終連線方式

# 任何 fleet 成員(或你任何裝置上裝 Tailscale):
ssh winso@100.95.23.8          # 免密, 22 埠

# 遠端跑 Powershell:
ssh winso@100.95.23.8 "powershell -NoProfile -Command 'hostname'"

七、fleet 全景(5 台)

裝置 角色 接入方式
GX10 6679(100.69.83.97) AI 大腦 本機
Pi 5(192.168.1.236 / tailnet) GPIO 現場控制 SSH key
Pi 3(100.123.106.93) 鏡面時鐘 SSH key + systemd mm2.service
vivo V2248(100.117.225.79:8022) 行動終端/相機 Termux + sshd
WinsonNB(100.95.23.8:22) Windows 桌面 + TTS 內建 OpenSSH

同一把公鑰(hermes-gx10,sha256 校驗)開五台門。任何一台上線,都能從 GX10 一鍵觸達。

八、總結

Windows 的 SSH 接入比 Android 簡單得多——官方套件、標準埠、官方 TTS。但坑的品質更高:UTF-16 編碼和管理員金鑰路徑這類問題,不出錯時一切正常,出錯時沒有任何提示,只能靠除錯模式 sshd + 讀 log破案。

核心教訓(全 fleet 通用,第三次驗證):
1. 長字串跨機器,永遠走檔案傳輸 + 雜湊校驗:Pi 3 / vivo / Win 三台,手貼失敗率 100%,HTTP 下載+SHA256 成功率 100%
2. 卡住時,啟用除錯模式看 log:比無限猜快幾個數量級
3. Windows 管理員 ≠ 一般使用者:SSH 金鑰路徑、icacls 權限模型都不同

下一步可以做的:Windows 版「遠端打雷」(同一支 WAV + Start-Process)、相機遠端拍攝(MediaCapture)、或把它接進 fleet 的排程(定時 TTS 叫起床)。

用 SSH 控制 Android 手機:從 Termux 安裝到遠端拍照的完整踩坑記錄

用 SSH 控制 Android 手機:從 Termux 安裝到遠端拍照的完整踩坑記錄

ASUS Ascent GX10控制的第三台: Android 手機

這台 vivo(V2248,Android 15)原本只是口袋裡的電話。今天把它變成 AI fleet 的第 4 台成員:GX10 可以透過 Tailscale 直接 SSH 進去,甚至叫它用後鏡頭拍一張照回傳,再用 AI 分析畫面——全部不經過任何雲端服務。

過程比預期長,踩了 7 個坑。全部記錄如下。

一、目標架構

GX10 (100.69.83.97)
   │  ssh u0_a343@100.117.225.79 -p 8022   (Tailnet, WireGuard 加密)
   ▼
vivo 手機 (Termux + openssh + termux-api)
   │  termux-camera-photo
   ▼
實體相機 → 拍照 → scp 回 GX10 → AI 視覺分析

核心思路:Android 沒有正式的「SSH server」,但 Termux 可以跑一套完整的 Linux 環境,裡面直接裝 openssh,就成了。加上 Tailscale,手機永遠是固定 IP、免開埠、任何網路可達——跟 Pi 3 同一套玩法。

二、手機端安裝(3 個 app)

App 來源 用途
Termux(主程式) F-Droid 或 GitHub(⚠️ 不能用 Play Store 版,已棄置) Linux 環境
Termux:API 同上 相機/麥克風/感測器等硬體橋接
Tailscale 任何 store 都可以 加密私有網路

⚠️ 前兩個必須同來源(F-Droid 裝主程式+副程式,GitHub 也成對裝)——簽名金鑰不同就互相拒絕通訊,這是 Termux 生態最常見的坑。

三、踩坑總表(7 個,依發生順序)

坑 1:ssh-host-config: command not found

  • 現象:pkg install openssh 成功、主機金鑰都生好了,但這支腳本找不到
  • 真相:openssh 10.x 的 Termux 封裝裡,ssh-host-config 是獨立套件的一部分,沒裝上不影響 sshd 本身
  • 解法:根本不需要這支——手動把金鑰放進 ~/.ssh/authorized_keys 就行,sshd 預設就讀那裡

坑 2:sv enable sshd / sv start sshd 全部失敗

  • 現象:unable to change to service directory: …/service: No such file or directory,錯誤路徑裡還雜訊亂入字元(「y」)
  • 真相:Termux 的開源版本沒有預設的 service 骨架;「雜訊字元」是手機輸入法在長命令黏貼時拆行掉字
  • 解法:繞過 sv——用 nohup 背景跑 + 自己寫 boot script(見第五節)

坑 3:長命令黏貼全部變調

  • 現象:rm -f file 報 missing operand、nohup … & sleep 2 報 Extra argument: sleep、ls -ld ~ 變 unknown option -- -、-e 參數被吞……同一台手機、同一條命令,重貼 3-5 次才有一次成功
  • 真相:黏貼是這次最大坑。長命令經過輸入法層時會拆字、吞引號、吞 - 參數
  • 解法:(a) 命令盡量拆短、一詞一詞手打;(b) 需要放檔案時改用「GX10 開 mini HTTP + 手機 curl 拉取」——完全免黏貼(坑 5 的核心解法)

坑 4:Connection refused × 2

  • 現象:每次我連都拒接
  • 真相:第一次是 sshd 沒啟動;第二次是跑 sshd 的前台視窗被關掉了——Android 的記憶體管理會清掉「看起來背景」的行程
  • 解法:最後用純前台 sshd -p 8022 -D -e 跑通(螢幕上一直能看到 Server listening on :: port 8022);常駐方案見第五節

坑 5:金鑰 92 bytes vs 93 bytes,連 3 次 Permission denied(★最終坑★)

  • 現象:sshd 在聽、埠通、權限 700/600 都對了,但所有金鑰都被拒;root、u0_a123 也試過都不對
  • 真相:我貼進去的公鑰少了一個字元(92 vs 93)——又是坑 3 的輸入法拆字,只是這次是內容被吃而不是命令,完全無從對齊
  • 解法(妙手):GX10 上一行命令開 python3 -m http.server 8931,手機上一行 curl 從尾網直接拉取:
curl -o ~/.ssh/authorized_keys http://100.69.83.97:8931/id_ed25519.pub

然後雙邊 sha256 校驗(f3498230…995e67d 逐字一致)→ 下一次 SSH 一次過。這是整篇文章最重要的一課:凡是「長字串跨機器」,永遠走傳輸驗證,不要靠手貼。

坑 6:termux-camera-photo: missing file argument / unknown option -f

  • 真相:這台裝的是老版 Termux:API(0.60 代號,官方已 0.53 重編),語法跟線上文件不符——老版用位置參數、沒有 -f
  • 解法:直接 cat 那支 sh 腳本看 usage,一行就知道:termux-camera-photo <output文件路徑>(絕對路徑)

坑 7:閃光燈 = 軟體層沒打開

  • 硬體:✅ 有(termux-camera-info 顯示 ON_ALWAYS_FLASH 能力)
  • 軟體:❌ 翻完 Termux:API 原始碼(CameraPhotoAPI.java)確認:接收器只讀 file 和 camera 兩個參數,沒有 FLASH_MODE
  • 嘗試:am start -a android.media.action.IMAGE_CAPTURE --ei android.intent.extra.FLASH_MODE 1 → vivo 相機 App 的相容性問題,照片不落盤
  • 結論:A 方案(原生相機 App 手動設「閃光燈常亮」+ Intent 跳轉)最實際;B 方案(自己寫 Camera2 小程序)成本高;C 方案(等上游加參數)最被動

四、最終就緒的連線方式

# 從 GX10(或任何尾網成員, 包含你的筆記本/iPhone 如果裝了 Tailscale):
ssh u0_a343@100.117.225.79 -p 8022

# 免密、公鑰登入 (ed25519: hermes-gx10, 93 bytes, sha256 已校驗)

五、常駐設定(重開機不死)

檔 作用
~/sshd-start 一鍵重啟:pkill→nohup sshd -p 8022 -D→ps 自我檢查,報 SSHd-OK 或完整錯誤
~/.termux/boot-script.sh 調 ~/sshd-start,Termux 重開機時自動觸發
電池優化(手動設) 設定→應用程式→Termux→電池→不受限(不設的話 Android 幾個小時後會殺 sshd)
自動重啟(手動設) Termux 選單→「自動啟動」打開

⚠️ 實測發現:sv 這套在 Termux 開源版不好使(~/.sv 不存在、$PREFIX/var/service 也找不到),所以用上面的手動 boot script 方案,穩定且可控。

六、手機資源盤點(連上後第一時間拿的)

項目 值
型號 vivo V2248
Android 15 (API 35)
SoC 聯發科 MT6833 (Dimensity 700)
CPU 8 核 aarch64
RAM 7.4 GB(可用 ~3.2 GB)
內部儲存 228 GB,已用 129 GB(57%)
Termux 套件 86 個
尾網 IP 100.117.225.79(固定, 永不变)

七、遠端相機——已驗證成功的命令

# 從 GX10 遠端叫拍照 (手機後鏡頭):
ssh u0_a343@100.117.225.79 -p 8022 \
  'termux-camera-photo /data/data/com.termux/files/home/shot.jpg'

# 拉回來 (照片 3060×4080, 940KB~2MB):
scp -P 8022 u0_a343@100.117.225.79:/data/data/com.termux/files/home/shot.jpg ./

# 前置鏡頭:
ssh … 'termux-camera-photo -c 1 /path/to/front.jpg'

已實拍兩張驗證:第一張 940K,第二張 2.0M(客廳夜景、沙發上有人的場景)。

七.5、遠端聲音——打雷、TTS 中文朗讀(實測通過)

同一條 SSH 通道,手機喇叭也能被遠端控制,有兩招都實測成功:

招一:遠端播放音效
1. GX10 上用 Python 合成一段 8 秒低頻滾雷 WAV(布朗噪聲 + 三記指數衰減包絡,352KB)
2. scp -P 8022 thunder.wav u0_a343@100.117.225.79:thunder.wav
3. ssh … 'termux-media-player play ~/thunder.wav' → 手機喇叭響「轟——隆隆隆」三記雷聲
4. 已重播兩次,兩次都 rc=0,用戶親耳確認

招二:遠端 TTS 中文朗讀

ssh u0_a343@100.117.225.79 -p 8022 'termux-tts-speak "張瑞琪,起床了"'

→ 手機喇叭直接念中文繁體(用 Android 系統 TTS 引擎),一詞 rc=0。

附帶能力:termux-volume 可遠端讀/改六條音軌(ring/music/alarm/notification/system/call)的音量;配合 cron 可做「定時叫起床」「遠端報時」「警報推送」。

⚠️ 小坑:
– termux-media-player 要寫 play <檔案> 子命令,直接帶檔案會報 Invalid cmd
– SCP 落點要用相對家目錄(如 u0_a343@…:thunder.wav),用絕對路徑 /sdcard/ 在 Termux 環境會落錯位置
– TTS 要送繁體——手機端的引擎對簡體轉換不一定準確(「張」送成「张」聲母會跑)

八、總結

最難的不是 sshd 本身——Termux 把它包得很完整。

真正難的有兩個:
1. 輸入法黏貼長字串會掉字——任何跨機器的金鑰/設定,都應該走檔案傳輸 + 雜湊校驗,不要靠手貼
2. Android 的「活著」需要主動維持——電池優化、自動重啟、boot script 三件事都要做到,sshd 才會像你 Pi 3 的 pm2 一樣穩定常駐

這台 vivo 現在是 fleet 的第 4 台:GX10(大腦)、Pi 5(GPIO 控制)、Pi 3(鏡面)、手機(行動終端 + 遠端相機)——同一個 Tailscale,同一套 SSH key,任何一台上都能跳進另外三台。

2026年10月3日 星期六

Pi 3 的資源與 GX10 透過 Tailscale 外網溝通

把之前的文章 RaspberryPi Project - MagicMirror Function 用我的gx10做控制

ASUS Ascent GX10控制的第二台: Raspberry Pi3

這台 Raspberry Pi 3(1GB RAM、29GB SD 卡)在機架裡只有一項工作:當 Magic Mirror 2 的鏡面時鐘。而控制這台 Pi 3 的「大腦」是遠端的 ASUS Ascent GX10——兩台機器靠 Tailscale 建立一條加密的專有網路,無論在哪個物理位置都能直接對話。

一、Pi 3 的資源盤點

硬體規格

項目 值
CPU BCM2837 quadri-core(4 核 aarch64)
RAM 1GB(現用 527MB / 剩 378MB 可用)
磁碟 SD 卡 29GB,已用 20GB(70%)
溫 64.5°C(mirror 滿載下屬正常)
顯示 HDMI → 類比鏡面(lightdm + X11)
網路 Wi-Fi(區網)+ Tailscale(100.123.106.93)

資源使用現狀

Mem:  1.9G total, 527Mi used, 378Mi available
SD:   20G / 29G (70%)
temp: 64.5°C

1GB RAM 跑 Magic Mirror 2(Node + Electron + X 桌面)已經用到 55%——沒有餘裕再加大模型或瀏覽器多 tab。這台的定位是「只做一件事:時鐘 + 天氣 + 行事曆 + 新聞」,不適合當 LLM 或 Docker 主機。

二、Magic Mirror 2 的資源使用(鏡面程式)

mm2 在 1GB 機子上跑起來不輕——Node 後端 + Electron 前置 + 9 個 module(clock、weather、calendar、newsfeed、compliments、GoogleAssistant、iFrame、alert、updatenotification)吃掉了 527MB。

優化建議(如想省):
1. 把 updatenotification 關掉(每小時拉 git 檢查,吃 CPU)
2. weather 更新間隔改 30 分鐘(預設 15)
3. newsfeed 關掉或改 30 分鐘
4. 關 X 桌面用 start_x11=false(不需要的話)

三、GX10 側的資源(對比)

項目 GX10
CPU 20 核 ARM
RAM 121GB(統一記憶體)
GPU NVIDIA GB10(1 PFLOP AI)
角色 大腦(地端 LLM、監控、AI 決策)

Pi 3 是終端顯示器 + 輕量觸角;GX10 是中央處理 + 決策。兩者分工明確,互不干擾。

四、Tailscale 外網溝通的建置

為什麼選 Tailscale 而不是 VPN/Port Forward

方案 問題
Port Forward 需路由器開埠、動態 IP、攻擊面大
自建 VPN 需一台常開的中繼機
Tailscale 零配置、端到端加密、IP 固定(100.x)、任何網路可連 ✅

雙端 Tailnet 位址

GX10 : 100.69.83.97    (linux,  帳號 atstest666666)
Pi3  : 100.123.106.93  (linux, 帳號 atstest666666)

連線實測(區網 vs Tailnet)

路徑 延遲 用途
GX10 ↔ Pi3 區網(192.168.1.25 ↔ .236) 2-4ms 日常本地控制
GX10 ↔ Pi3 Tailnet(100.x) 88-323ms 出差/外網也能操控

外網路徑走 WireGuard 加密 + DERP 中繼(Pi 3 和 GX10 同時連到 Tailscale 的 DERP relay),雖然比區網慢 30 倍,但免設防火牆、免開埠、免動態 DNS——出差時一樣能 ssh pi@100.123.106.93 操作鏡面。

五、外網溝通的三種典型場景

場景 A:遠端 SSH 改鏡面

# 在出差酒店的筆電 / 手機 Termux — 只要同一 Tailscale 帳號
ssh pi@100.123.106.93
# 改 config.js、清日誌、重啟 mm2
pm2 restart mm2

場景 B:GX10 自動下達(今天的實作)

GX10 上的 AI(gemma4:e4b) → Tailnet HTTP → Pi3 mm2 網頁/模組

mm2 有 http://127.0.0.1:8080,GX10 可用 http://100.123.106.93:8080 遠端觸發 mm2 的 action(要開埠到 0.0.0.0 才有用;建議只開區網,重要操作走 SSH)。

場景 C:檔案交換(備份/圖檔)

# Pi3 → GX10
scp pi@100.123.106.93:/home/pi/20261003.tar.gz ~/backups/
# GX10 → Pi3(推圖給鏡面用)
scp photos.jpg pi@100.123.106.93:/home/pi/MagicMirror/assets/

六、安全模型

層 保護
傳輸 WireGuard 端到端加密(AES-256)
身份 Tailscale 帳號 + 裝置金鑰
來源限制 同一 Tailnet 才能看到 100.x,外部網路完全看不到這台 Pi
SSH 雙重金鑰(本機 key + 遠端 key)免密碼
防火牆 SD 卡上的 ufw 可選開;因為 100.x 已在 WireGuard 保護下,ufw 不必太嚴

重點:Pi 3 的公網 IP 可以是 0(完全 NAT 後面),外部掃埠根本掃不到 100.x——這是 Tailscale 最大的優勢。

七、實戰:今天完成的完整鏈路

[出差手機/家用筆電]
        ↓ (Tailscale, WireGuard)
     Pi 3 (100.123.106.93)
        ↓ SSH + 備份 tar
[出差中的 GX10, 100.69.83.97]
        ↓ (同一 Tailnet 或區網)
     鏡面(時鐘/天氣/行事曆)

今天實際發生過的:
– 17:04 區網 Wi-Fi 斷線 → Tailscale 路徑不受影響
– 18:00 備份 Pi3 鏡面 216MB → Tailscale scp 拉回 GX10
– 22:00 遠端 SSH 改 mm2(更新嘗試、中止、還原、重啟)— 全程 100.123.106.93,不用區網

八、結語

Pi 3 只有 1GB RAM,是最弱的一台;透過 Tailscale 跟 GX10 聯手,卻能從任何地方被控制、被備份、被遠端維護——弱機器也能當強終端。Tailscale 在這裡的核心價值不是「快」,而是「免配置 + 加密 + 固定位址」這三件事組合起來的無腦可達性。

一句話:區網是日常,Tailnet 是出差/急難,同一條 SSH 命令、同一份備份檔案、同一個遠端鏡面——不用記 IP 切換、不用開任何埠。

Pi 5 GPIO 控制踩坑實錄:AI 大模型下達指令的「GPIO busy」真相

上篇文章寫了 GX10 大腦 + Pi 5 現場 I/O 的架構,這篇文章記錄把它真的跑通的完整過程——包含一個花了很久的怪現象:同一支指令,別人能切、我就 busy。

最終成果(先講結論)

一句話 → 地端大模型判定意圖 → HTTP → Pi 5 真實切 GPIO,全程約 1 秒:

$ python3 gx10_ai_controller.py "把燈關了"
✅ Pi5 健康 | 目前: {'devices': {'relay1': 'on'}, ...}
⏱ LLM (gemma4:e4b) 耗時 0.4s
意圖: {"action": "off", "reason": "關燈"}
✏ Pi5 回應: {"dry_run": false, "pin": 22, "state": "off", "status": "success"}

兩端程式(已部署並在跑)

Pi 5 端 — HTTP 控制器(port 5001,systemd 常駐)

import logging, os, threading
from datetime import datetime
from flask import Flask, request, jsonify

DRY_RUN = os.environ.get("DRY_RUN", "0") == "1"
RELAY_PIN = int(os.environ.get("RELAY_PIN", "22"))
ACTIVE_HIGH = os.environ.get("ACTIVE_HIGH", "0") == "1"
logger = ...   # 省略

relay = None
if not DRY_RUN:
    from gpiozero import OutputDevice
    # 低電位觸發繼電器(active_high=False)
    relay = OutputDevice(RELAY_PIN, active_high=ACTIVE_HIGH, initial_value=False)

app = Flask(__name__)

@app.route("/api/device", methods=["POST"])
def control_device():
    data = request.get_json(silent=True) or {}
    action = data.get("action", "").lower()
    if action not in ("on", "off"):
        return jsonify({"status": "error", "message": "action must be on|off"}), 400
    if relay: relay.on() if action == "on" else relay.off()
    return jsonify({"status": "success", "state": action, "dry_run": bool(DRY_RUN),
                    "pin": None if DRY_RUN else RELAY_PIN})

systemd user service(~/.config/systemd/user/pi5-relay.service):

[Service]
Type=simple
Environment=DRY_RUN=0
Environment=RELAY_PIN=22
ExecStart=/home/pi/venv/bin/python3 /home/pi/pi5_relay.py
Restart=always

加上 loginctl enable-linger pi,重開機不需要登入就會自動起服務。

GX10 端 — AI 決策層

SYSTEM_PROMPT = """你是決策樞紐。只回一個 JSON 物件, 格式:
{"action":"on" 或 "off","reason":"簡短說明"}
開/open/turn on→on;關/close/turn off→off;無關控制→{"action":"none"}"""

# 1) 地端 Ollama(gemma4:e4b,temperature=0)解析意圖
# 2) 意圖 → POST http://<pi5>:5001/api/device
# 3) 非 on/off(含 none)一律不下達, 直接回報

踩坑實錄:「GPIO busy」的真相

這是本次最大的坑。現象:Pi 5 上已有一個程式(我稱它 search_bot)能用 gpiozero 正常切繼電器,我寫的新程式卻全部失敗,錯誤一路切換:

嘗試 結果
系統 python + OutputDevice(17) KeyError: PinInfo(number=11, ...)
RPi.GPIO Cannot determine SOC peripheral base address
sysfs GPIO export OSError: Invalid argument
換腳位再試 lgpio.error: 'GPIO busy'

一個一個排除下來,真相其實是最普通的一種:

GPIO pin 是排他的。search_bot 已經 claim 了 GPIO 14/15/17/18/21(4 顆 relay + 1 顆按鈕),任何新程序再 claim 同一支腳就会 busy。

驗證方式:挑一支 search_bot 沒用的腳(GPIO 22)做同一個測試——

✅ OutputDevice(22) 建立成功
GPIO22 -> on
GPIO22 -> off
--- gpiozero 在自由腳位上工作正常 ---

一次就通。所谓「怪現象」,就是「腳被佔用」。

為什麼 RPi.GPIO 會掛?

Pi 5 有多個 GPIO controller(/dev/gpiomem0~4、多個 gpiochip),RPi.GPIO 舊版要猜「SOC peripheral base」就猜錯;gpiozero + gpiozero/lgpio 走 gpiochip 介面,選對 controller 就正常——這就是同一台機子、同樣的 pin,一個能跑一個掛的原因。

三個實戰原則

  1. GPIO 是排他資源 — 多程序共用在 Pi 上一定會撞;分配腳位前,先用 journalctl 或 pids + 程式碼 grep 看誰已經 claim 了
  2. DRY_RUN 是上線安全閘 — 新控制器先跑 DRY_RUN=1,API 鏈路全通、GPIO 不碰,確認無誤再切 0
  3. 選對 pin factory — Pi 5 上 RPi.GPIO(舊)不穩;gpiozero + lgpio backend 是現行正解

可復用清單

項目 值
Pi 5 服務 systemctl --user status pi5-relay
狀態 API GET http://<pi5>:5001/api/status
下達 API POST /api/device {"action":"on\|off"}
換腳位 service RELAY_PIN= 改數字,restart 即可
反相 ACTIVE_HIGH=1
回滾 DRY_RUN DRY_RUN=1,API 鏈路照跑、不碰 pin

結語

「別人能跑、我不能跑」的坑,90% 是資源已被佔用而不是環境壞掉。這次的 GPIO busy 就是如此:把「腳位排他性」這個前提寫進腦子,下次一眼就能看出誰跟誰撞了。

ASUS Ascent GX10 × Raspberry Pi 5:邊緣大腦 + 現場 I/O 的完整控制架構

ASUS Ascent GX10(NVIDIA GB10 Grace Blackwell,1 PFLOP AI 算力)與 Raspberry Pi 5 的結合,是一種「大腦(Brain)+ 現場 I/O(Actuator & Sensor)」的強勢分工:GX10 沒 GPIO,但有頂級 AI 推論;Pi 5 有完整的 GPIO/I2C/SPI/UART,但算力只適合即時控制。兩者過區域網路結在一起,就是完整的邊緣 AI 控制系統。

ASUS Ascent GX10控制的第一台: Raspberry Pi 5

1. 核心分工:誰做什麼

ASUS Ascent GX10(大腦) Raspberry Pi 5(現場)
硬體角色 GB10 超級晶片、121GB 統一記憶體 GPIO 40 pin、I2C/SPI/UART、Hailo NPU 可擴充
做什麼 地端 LLM(DeepSeek-R1、Llama 3)、視覺辨識、多 Agent 協調 接馬達、感測器、繼電器、LED,產生 PWM/高低電位
輸出入 收環境數據 → AI 推論 → 下高階指令 收高階指令 → 轉實體電信號;感測數據回傳
典型指令 「辨識到異常,關 3 號馬達」 GPIO 17 拉低 → 繼電器動作

關鍵觀念:不要讓大模型直接碰 GPIO(延遲太高、不可重現),也不要讓 Pi 跑大語言模型(算力不够)。中間一層「結構化指令」(JSON)是最乾淨的分界線。

2. 通訊方案比較

兩台都跑 Linux,又都在區域網路內,網路通訊 > USB 序列埠(更快、可擴充、能跨房間):

方案 適用場景 本環境狀態
A. MQTT(推薦) 多設備、事件型、即時開關、可存最後值 ✅ GX10 上 mosquitto 已跑
B. SSH + 指令 除錯、一次性操作、批量指令 ✅ 金鑰免登入已建置
C. REST API 點對點、網頁整合、同步要回傳值 需在 Pi 端跑 Flask/FastAPI

實務分工:狀態與事件走 MQTT、控制與除錯走 SSH、要同步確認的用 HTTP。

3. 實作範例:AI 語音/視覺自動化開關

情境:大模型理解到「開燈」或視覺辨識到「有人進入」→ 自動開關實體繼電器。

步驟一:硬體的連法

  1. GX10 經 10G LAN 連區網(或 Wi-Fi)
  2. Pi 5 連同一區網(本環境實測:192.168.1.236)
  3. 5V 繼電器模組:VCC→Pi 5V、GND→GND、IN→GPIO 17

步驟二:Pi 5 端的 HTTP 控制器(Flask)

from flask import Flask, request, jsonify
import gpiozero

app = Flask(__name__)
relay = gpiozero.OutputDevice(17)   # 接在 GPIO 17 的繼電器/LED

@app.route('/api/device', methods=['POST'])
def control_device():
    action = (request.json or {}).get('action')
    if action == 'on':
        relay.on()
        return jsonify({"status": "success", "message": "Device turned ON"})
    if action == 'off':
        relay.off()
        return jsonify({"status": "success", "message": "Device turned OFF"})
    return jsonify({"status": "error", "message": "Invalid action"}), 400

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

request.json 加 or {} 避免沒有 body 時崩掉;if __name__ == '__main__' 才是正確的模組保護。

步驟三:GX10 端的 AI 決策

import requests, json

PI5_IP = "192.168.1.236"   # 本環境 Pi 5 的實際位址

def send_to_pi5(action):
    url = f"http://{PI5_IP}:5000/api/device"
    try:
        r = requests.post(url, json={"action": action}, timeout=5)
        print("Pi 5 回應:", r.json())
        return r.json()
    except Exception as e:
        print("連線失敗:", e)
        return None

# GX10 上的地端大模型(Ollama/vLLM)已把語音/視覺判斷成結構化意圖:
ai_decision = {"target": "light", "status": "on"}   # 來自 LLM 的 function-call 結果
send_to_pi5(ai_decision["status"])

requests.post(url, json=...) 會自動帶 Content-Type 並序列化,不用手動 dumps。

方案 A(MQTT)的對照版

# Pi 5:監聽主題,收到就動作
import paho.mqtt.client as mqtt
import gpiozero
relay = gpiozero.OutputDevice(17)

def on_msg(client, userdata, msg):
    if msg.topic == "iot/relay1" and msg.payload == b"on":
        relay.on()
    elif msg.topic == "iot/relay1" and msg.payload == b"off":
        relay.off()

c = mqtt.Client()
c.on_message = on_msg
c.connect("192.168.1.25", 1883, 60)   # GX10 上的 mosquitto
c.subscribe("iot/relay1")
c.loop_forever()
# GX10:AI 決策後 publish
import paho.mqtt.client as mqtt
c = mqtt.Client()
c.connect("192.168.1.25", 1883, 60)
# LLM 判斷 → 開燈
c.publish("iot/relay1", "on", retain=True)

MQTT 的好處:retain=True 讓 Pi 重開機後自動恢復最後狀態;多路繼電器只要多訂閱幾個主題,不用改架構。

4. 安全與穩定(必讀)

  1. Pi 5 的 GPIO 是 3.3V —— 接 5V 模組前確認模組本身有 3.3V 相容的 IN 腳(多數繼電器模組有)
  2. 馬達/繼電器回灌雜訊 —— 大電流迴路與 GPIO 分開供電,地線共接
  3. 網路權限 —— Flask 只綁區網(或用 firewall 限制來源 IP 只允許 192.168.1.25),5000 埠別對外
  4. MQTT 加認證 —— mosquitto 開啟 password_file + TLS,避免區網內誰都能開關燈
  5. 看門狗 —— Pi 端程式用 systemd service + Restart=always,斷線自動回連
  6. 安全聯動 —— 高風險動作(斷氣、斷電源)要「LLM 意圖 + 人工確認」兩段式,純自動只給低風險負載

5. 本機的落地優勢

這套架構的元件這台機房全部現成:
– MQTT broker(mosquitto)已在 GX10 跑
– Pi 5 16GB RAM + NVMe,連 Ollama 小模型都能跑(邊緣備援)
– Hailo NPU 可做視覺預判(偵測到人 → 才叫喚大模型),省算力
– Hermes multi-profile 可直接當「語音/對話層」,對話 → 意圖 → MQTT

下一步建議:①Pi 5 裝 Flask + systemd unit ②GX10 加 intent→MQTT 的 adapter ③用一個 LED 先跑通,再換繼電器。

2026年10月1日 星期四

GX10 跨機控制 Pi 5:從 SSH 金鑰到遠端自動化

這台 ASUS Ascent GX10 (121GB 統一記憶體、20 核 ARM)是我的主力;另一台 Raspberry Pi 5(16GB RAM、NVMe SSD、Debian 13)則是區網上的邊緣節點——跑 Hailo 視覺加速器、Ollama 小模型、RTSP 串流伺服器、兩支 Telegram bot。

這篇文章記錄我如何讓 GX10 透過網路、免密碼、用 terminal 完整控制 Pi 5 的完整流程與實際成果。

架構概觀

GX10(控制端) Pi 5(被控端)
角色 AI 主力機 + Hermes Agent 邊緣 AI + 媒體 + 自動化
記憶體 121GB 統一記憶體 16GB DDR5
特色 GB10 GPU、大模型推理 Hailo 加速器、mediamtx、低耗電
位址 192.168.1.25 192.168.1.236(Wi-Fi)

兩台都在同一區網,控制路徑非常直接:SSH。

第一步:SSH 金鑰免密碼(最關鍵)

原則:密碼只打一次,金鑰管往後。 在對話或腳本裡流傳密碼是壞習慣,金鑰才是對的答案。

# 1) 在 GX10 產生金鑰(ed25519,無密碼)
ssh-keygen -t ed25519 -N "" -C "hermes-gx10"

# 2) 把公鑰裝到 Pi 5(這一步需要 Pi 的密碼,只用這一次)
cat ~/.ssh/id_ed25519.pub | ssh pi@192.168.1.236 \
  'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

裝完金鑰後,GX10 端任何腳本、任何 AI agent 都能免密碼登入 Pi 5——這是「機器控制機器」的前提。

# 3) 驗證免密碼登入
ssh -o BatchMode=yes pi@192.168.1.236 'hostname && uptime'

BatchMode=yes 的作用:如果金鑰沒裝好,它會直接失敗而不掛起等密碼——適合放在自動腳本裡。

第二步:遠端執行命令的正確姿勢

單指令直接跑:

ssh pi@192.168.1.236 'systemctl status docker --no-pager'

多行腳本用 heredoc 一次送——不要寫 10 行 ssh 各跑一次(每次都有連線開銷):

ssh pi@192.168.1.236 bash -s <<'EOF'
echo "=== OS ==="
cat /etc/os-release | head -2
echo "=== 溫度 ==="
cat /sys/class/thermal/thermal_zone*/temp
echo "=== Docker ==="
docker ps --format '{{.Names}} | {{.Status}}'
EOF

bash -s 表示「把 stdin 當 script 跑」,heredoc 的引號 <<'EOF' 避免本地 shell 提前展開 $。

第三步:實際盤點結果

用上面的手法盤了一輪,這台 Pi 5 比我預想的豐富:

AI 堆疊

  • Hailo 邊緣加速器(/dev/hailo0)— 獨立 NPU,23~46 TOPS 級,專跑視覺推論
  • Ollama:qwen2.5:3b、Llama3:8b、gemma4:e2b、llama3.2:1b— 全是小模型,與 Pi 的定位吻合
  • Hermes Agent(Docker,跑了 2 個月)+ searxng

媒體與服務

  • mediamtx:RTSP 8554 / RTMP 1935 / HLS 8888— 一台完整的影音串流伺服器
  • Samba + NFS — 區網檔案伺服器
  • 兩支 Telegram bot(searchbot / cronbot)— cron 排程 + 搜尋自動化
  • VNC(5900) 桌面遠端

健康狀態

  • 溫度 36.4°C(GX10 滿負載 73~81°C,對比鮮明)
  • 16GB 只用 1.5GB、NVMe 234GB 用了 27%— 資源非常寬裕

控制管道選擇:SSH vs MQTT vs HTTP

管道 時機 本環境現況
SSH 萬能:指令、檔案、排程、除錯 ✅ 本次建置完成
MQTT 高頻、事件型、物聯網(溫控、開關) ✅ mosquitto 已在跑
HTTP/REST 服務化 API(如 Ollama、mediamtx) ✅ 各服務自帶

實務上:「控制與除錯用 SSH,狀態與事件用 MQTT,服務對服務用 HTTP」,三者互補,不需要三選一。

安全注意事項(重要)

  1. 別在對話/腳本裡放密碼 — 金鑰化之後,密碼只存在 Pi 的 /etc/shadow
  2. 防火牆 — Pi 5 的 VNC(5900)、Samba(445)目前對區網開放;若接出外網,務必只限可信 IP 或走 Tailscale
  3. authorized_keys — chmod 700 ~/.ssh、chmod 600 authorized_keys,且不要用 root 跑日常操作
  4. 金鑰管理 — 這支 id_ed25519 現在有 pi@.236 的完整家目錄權限,等同鑰匙;GX10 本身要有盤備份(已有每日備份)

接下來可以做的事

  • [ ] 從 GX10 直接部署 Hailo 視覺模型(偵測 → 推論 → 事件)
  • [ ] 把 Pi 5 的溫度/磁碟併入 GX10 的每週監控報表
  • [ ] mediamtx 接攝影機,GX10 做離線影片分析
  • [ ] 兩台 Hermes fleet 協作:GX10 跑推理、Pi 跑執行,透過 SSH + MQTT 交接

結論

「A 機控制 B 機」沒有黑科技,核心就三件事:金鑰免登入 + heredoc 遠端腳本 + 清楚的管道分工。有了這三樣,兩台機器在我日常的工作流裡已經變成一台——GX10 是頭腦,Pi 5 是觸角與四肢。

2026年6月7日 星期日

智慧選擇:區分未來!探討三大主流 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 開發工具設定與安裝

入手一台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主機安裝好後, 就可以直接使用.