邊緣與本地部署：離線環境的模型服務

模型選擇的取捨

• 優先選能在目標硬體上以充裕餘裕執行的尺寸，不要塞到極限。
• 量化幾乎是必然選擇，但要在目標硬體上實測，不能只看規格。
• 偏好單一模型完成多任務，而不是部署多個專用模型——維運成本是主要考量。

更新機制

# 離線更新包的結構
update-2026.08/
  manifest.json        # 版本、雜湊、相依、最低硬體需求
  model/               # 權重
  adapters/            # 介面卡
  prompts/             # 提示檔
  migrations/          # 資料庫或設定的遷移腳本
  rollback.sh          # 一鍵回滾
  CHECKSUM.sha256

離線環境的更新必須是原子的、可驗證的、可回滾的。現場沒有工程師能除錯，更新失敗就是服務中斷。

資源限制下的降級

import psutil

def pick_config():
    free_gb = psutil.virtual_memory().available / 1e9
    if free_gb > 24:  return {'model': '14b-q4', 'ctx': 8192, 'batch': 4}
    if free_gb > 12:  return {'model': '8b-q4',  'ctx': 4096, 'batch': 2}
    return                   {'model': '3b-q4',  'ctx': 2048, 'batch': 1}

沒有網路的可觀測性

• 日誌寫本地，設定輪替與大小上限（磁碟滿了會讓整台機器掛掉）。
• 提供一鍵匯出診斷包的功能，讓現場人員能把資料帶出來給你分析。
• 關鍵指標寫入本地檔案，並提供簡易的本地儀表板頁面。

預期會遇到的問題

1. 硬體老舊且不一致：每個站點的規格可能都不同，要有自動偵測與降級。
2. 沒有 GPU：CPU 推論要接受數秒的延遲，介面設計要配合（非同步、批次）。
3. 現場沒人懂技術：所有操作要能用一個腳本或一個按鈕完成。
4. 難以取得日誌：診斷包的設計要在第一版就做。