9.1 為什麼還要自架：資料主權、GPU 與混合架構#

本節目標#

理解前八章「全上邊緣」之後，哪些工作仍必須回到自己手裡
掌握自架的四大理由：資料主權、GPU、原生資料庫、特殊硬體
學會「塞在 Cloudflare 後面」的混合架構設計，以及何時不該採用

從「全部外包」到「關鍵部分自持」#

1970 年代的 ARPANET 時代，「連上別人的電腦」本來就是網路的原初功能；1990 年代主機代管、2000 年代雲端 VM、2020 年代邊緣運算，趨勢一直是把自己擁有的機器往外推。但這條曲線在 2020 年代中期出現了回擺：

資料主權與法規：GDPR（2018）、各國個資法要求資料「落地」，有些資料法律上根本不能放進第三方處理器
GPU 經濟學：AI 推理需要 GPU，而雲端 GPU 時租費長期偏高；一張消費級卡數個月的雲端費用就等於硬體價格
搜尋與關聯資料：SQLite、Postgres 的全文檢索與複雜 JOIN，在 D1/KV 這類邊緣儲存上仍是弱項
特殊硬體：ZFS 檔案系統、NAS、SMB 傳輸、印表機——這些東西天生就該待在LAN 裡

工程直覺是：同質的、可無狀態複製的東西交給邊緣；異質的、有狀態的、吃硬體的東西留在本地。

四大理由逐一拆解#

1. 資料主權#

所謂主權，用一條公式表達：

\[ P(\text{資料被第三方讀取}) = P(\text{第三方被入侵}) + P(\text{第三方受法令要求}) \]

自架並不能把這個機率降到零（你家可能被闖入），但它把第一項的控制權收回自己手中：磁碟全槽加密、離線備份、物理隔絕——這些是雲端帳號密碼之外的第二道防線。

2. GPU 與算力#

雲端一張 H100 每小時數十美元；本地一張二手卡一次買斷、功耗自付。對非量產的個人 AI 專案（Local-LLM、Stable Diffusion），自有硬體 + 邊緣當閘門是最省的組合：Cloudflare 處理排隊與驗證，GPU 只服務「通過驗證」的請求。

3. 原生資料庫#

第 7 章的 D1 是 SQLite，但邊緣版有寫入延遲與大小限制。Postgres 的 JSONB 查詢、pgvector 的語意搜尋、連續聚合（TimescaleDB），都要一顆真正在你控制下的引擎。混合架構的標準做法：

D1 / KV 放熱資料（邊緣讀取快）
自架 Postgres 放事實來源（source of truth）
Workers 透過 Hyperdrive 連線池回源到自架資料庫

4. 特殊硬體#

NAS、時間機器備份、自架光影伺服器（Jellyfin 的硬體解碼）、家庭自動化的 Zigbee 橋接器——這些服務無法在 FaaS 上執行，卻值得從外網存取。

混合架構圖：塞在 Cloudflare 後面#

核心思想只有一句：本地機器不開任何入站（ingress）連接埠，全部流量經由 Cloudflare 邊緣轉發。外部世界只認識邊緣：

                        ┌──────────────────────────────┐
   使用者                │         Cloudflare 邊緣       │
     │                  │  ┌────────┐ ┌──────────────┐ │
     │  https://        │  │  DNS   │ │ Zero Trust   │ │
     │  home.example────┼─▶│  WAF   │▶│ Access 驗證   │ │
     │  .tk             │  │  CDN   │ │ (見 9.3)     │ │
     ▲                  │  └────────┘ └──────┬───────┘ │
     │                  └────────────────────┼─────────┘
     │ 只回源到                             │ Tunnel
     │ cloudflared                          ▼ (cloudflared
┌────┴──────────┐  ┌──────────┐   ┌──────────────────┐  主動連出,
│   C 段路由器   │  │  NAS     │   │  家用伺服器/VM     │  無須開 Port)
│  NAT/防火牆    │──│ ZFS/Borg │   │ ┌──────┐ ┌─────┐ │
│ （無入站規則）  │  │  檔案    │   │ │GPU+LLM│ │PgSQL│ │
└───────────────┘  └──────────┘   │ └──────┘ └─────┘ │
      純 LAN（不推暴露）            └──────────────────┘

三個關鍵詞對應本書前三章的「鏡像」：

混合架構元素	對應純邊緣章節
DNS + WAF	第 2 章 DNS 原理
Access 驗證	第 9.3 節
Tunnel 回源	第 9.2 節

何時不該基於這個架構#

自架不是信仰，是取捨。以下情境請直接用雲端：

無人值守的關鍵營運服務：你家的電、網、磁碟都會掛；Cloudflare Workers 的可用性 SLA 遠高於「家用 UPS + 備援光纖」
需要全球低延遲的寫入工作：寫入請求離邊緣很近、離你家很遠；回源一趟等於犧牲了本章節前八篇努力爭取的 P50 延遲
流量會被 ISP 限制：許多家用寬頻的「上傳」只有 15-30 Mbps，且大量對外服務可能違反 ISP 的居家條款
無人會維運：自架的本質是「拿時間省錢」。沒有定期維護時間的家庭伺服器，最終狀態是開機時散熱風扇咆哮、資料從未備份
高併發寫入：本地的單機 Postgres 撐不起邊緣進來的雷暴式流量（thundering herd），你沒有辦法像雲端一樣水平擴容

一條好的工程判準：

\[ \text{適合自架} \iff \text{資料敏感} \vee \text{需要特殊硬體} \vee \text{寫入稀疏} \wedge \text{可接受偶爾多維運} \]

小結與練習#

自架與邊緣不是對立，而是分工：握有資料主權、吃硬體、有狀態的部分回本地；全球分發、無狀態、易橫向擴展的部分上邊緣
混合架構的安全性根基在於「本地無入站 Port」——秘密是 9.2 節的 Tunnel
判斷「不自架」比判斷「要自架」更需要紀律，因為從雲端搬回本地的成本遠高於反向

練習：

列出你手上所有服務，依「資料敏感度 / 硬體需求 / 寫入頻率」三軸做成表格，決定哪些上邊緣、哪些自架。
說明為什麼「家用 Up=30 Mbps」會讓圖中的 NAS 直接暴露在外網時，成為整個架構的最弱環節（weakest link）。
若你的 GPU 服務只在深夜被鄰居使用、請求每小時不足 20 次，試估算雲端 GPU 與自架 GPU 的損益兩平衡點（考慮電費、折舊、十年壽命）。