📘 《AI 時代系列（6）：進階通訊工程——邁向2035年太空星鏈網路時代》
📘 第 14周: 🧠 AI × MLOps × 太空網路資料管線
139／150單元：AI 模型部署在衛星端 🚀克服太空硬體限制的 AI 設計與部署架構
________________________________________
🎯 單元導讀
在 LEO / NTN 星座中，衛星不再只是轉發器，而是：
⭐ 具備運算
⭐ 具備路由
⭐ 具備即時決策
真正的「Edge-Space Compute」。
但衛星端不像地面：
✘ 沒 GPU farm
✘ 沒大型 RAM
✘ 沒法全天候 OTA
✘ 沒高頻寬資料回傳
✘ 不能重開機
✘ 運算太久會熱當
因此 AI 模型部署在衛星端是整個 NTN 的工程瓶頸。
本節會說明：
✔ 模型如何被壓縮、量化、蒸餾
✔ 空間等級晶片運算限制
✔ 如何做抗輻射 AI
✔ 如何安全 OTA 模型更新
✔ 如何避免 inference 太慢造成 routing 失序
________________________________________
🧠 一、太空硬體的真相：AI 模型不是說跑就跑
________________________________________
🌡 ① Radiation-Hardened（抗輻射晶片）限制巨大
太空晶片常用：
• RAD750（已 20 年歷史）
• GR740
• LEON SPARC 系列
• SpaceFPGA（Microsemi / Xilinx）
它們特點：
✔ 穩
✔ 抗輻射
✘ 超級低算力（500 MHz、幾 GFLOPS）
這意味著：
⭐ transformer 不可能照原樣跑
⭐ CNN 要被壓到「瘦身版」
⭐ LSTM 要減層
⭐ 全部需要 quantization
________________________________________
⚡ ② 功耗限制
典型 LEO satellite：
• 整體運算設備：5–30 W
• AI 模型只能拿 1–5 W
• inference latency 必須 < 10 ms（避免 routing 失序）
→ 不能跑大量矩陣乘法
→ 不能跑大型 attention
→ 不能 load 太多權重進 SRAM
________________________________________
🔥 ③ Thermal（溫度）問題
衛星在陽光面會加熱，在陰影面會急速降溫。
AI 運算是「局部高熱源」，熱控很嚴格。
如果模型太大 → 運算太久 → 局部過熱 → 自動降頻 → routing fail。
________________________________________
🛰 ④ 通訊頻寬限制
OTA 更新不能像手機：
✘ 不能 1GB 模型傳上去
✘ 不能天天更新
✘ 中途掉封包會讓衛星失能
所以模型一定要：
⭐ 小
⭐ 可 incremental update
⭐ 可多版本 fallback
________________________________________
🧠 二、AI 部署策略：把大型模型變成「太空版」
________________________________________
🚀 ① Model Quantization（量化）
把 FP32 → INT8 / INT4 / INT2
優點：
• 重量縮小 4–16 倍
• 運算量減少
• 能用 space-grade FPGA 直接跑
現代 LEO 衛星常用：
⭐ INT8 quant
⭐ INT4 for routing model
⭐ 有些甚至 INT2 進行流量預測
________________________________________
✂️ ② Model Pruning（剪枝）
把不重要的 weights 刪除。
CNN 可砍 40–70%
Transformer 可砍 20–40%
Routing-GNN 可砍 30–50%
剪枝後：
• 記憶體少
• latency 降低
• power 更低
________________________________________
🔥 ③ Model Distillation（蒸餾）
地面 teacher model：大、準
衛星 student model：小、快
典型縮減比例：
🟦 300M params → 30M params
🟦 1B params → 50M params
🟦 GNN 40 層 → 8 層 student GNN
這是把 AI 模型塞進 LEO 的最重要方法。
________________________________________
🧊 ④ Weight Compression（權重壓縮）
適合 OTA 更新：
✔ Huffman coding
✔ entropy coding
✔ incremental patch（只傳差異）
模型不會一次傳整包，而是：
⭐ 傳「權重增量」
⭐ 傳「第 N 層更新」
⭐ 傳「bit-mask patch」
讓更新變成：
📦 原本 80MB → OTA 只有 0.5–3 MB
________________________________________
⚙️ ⑤ FPGA / ASIC mapping
衛星 AI 推理多半跑在：
• Space-grade FPGA
• low-power ASIC
• custom NPU（新一代）
模型要事先 mapping 成：
✔ 多路 pipeline
✔ low-parallel MAC
✔ fixed DSP blocks
✔ LUT-friendly graph
________________________________________
🧠 三、AI 模型怎麼在軌運作？
________________________________________
① Onboard Inference（實時推理）
用於：
• Doppler correction
• beam steering
• routing selection
• anomaly detection
• power control
• SNR drop prediction
Latency 要求：
⭐ < 10 ms 才不會讓 routing miss
⭐ < 5 ms 才能做 beam tracking
⭐ < 1 ms 可做 power fast-loop
________________________________________
② Onboard Scheduling（排程）
衛星 CPU 要同時：
• 跑 AI
• 跑 routing
• 跑功率控制
• 跑熱控
• 跑姿態控制
• 跑 TT&C
所以 AI 任務會被編排：
⭐ 優先級最低（除非是 critical routing）
⭐ 不能占用過久（task time slice 小）
⭐ 遇到溫度高會自動降頻
________________________________________
③ Multi-version model（多版本模型）
衛星端永遠保留：
• v_current
• v_backup（上一版）
• v_safe（最小功能模型）
OTA 更新失敗時：
→ 立即 fallback
→ 不中斷 routing 功能
________________________________________
🧠 四、ASCII 圖：太空端 AI 模型部署流程
┌────────────────────┐
│ Earth AI Training │
│ (big model) │
└────────────────────┘
│ Distill / Prune / Quantize
▼
┌────────────────────┐
│ Small Space Model │
│ INT8 / pruned │
└────────────────────┘
│ OTA (patch)
▼
┌──────────────────────────┐
│ LEO Satellite Runtime │
│ - FPGA/NPU Inference │
│ - Multi-version fallback │
│ - Thermal-safe control │
└──────────────────────────┘
這張圖說明的是一個**「地面訓練、太空推論」的安全型 AI 部署流程**：大型 AI 模型先在地面端進行高算力訓練與驗證，接著透過 模型蒸餾、剪枝與量化，轉換為適合衛星資源限制的 小型太空模型（如 INT8、pruned）；模型再以 OTA 補丁方式 上傳至 LEO 衛星，在 FPGA／NPU 推論環境中執行，並搭配 多版本回退機制 與 熱安全控制，確保即使在輻射、功耗與溫控受限的太空條件下，AI 功能仍能穩定、可控且可持續演進。
________________________________________
🧠 五、模擬題
1️⃣ 專業題
為何衛星 AI 需大量使用量化（INT8 / INT4）？
📜 答案：
因為 space-grade 晶片運算力有限，量化可降低功耗、縮少權重大小並加速運算，是在軌 AI 推論必要條件。
________________________________________
2️⃣ 應用題
若 OTA 只能傳 3 MB，以下哪個策略最適合更新 AI 模型？
A. 全模型重新上傳
B. incremental weight patch
C. 升級成更大模型
D. 全部使用 teacher model
📡 答案：B
👉 當 OTA 頻寬受限（僅 3 MB） 時，透過 incremental weight patch 只更新關鍵權重差異，可大幅降低傳輸量並維持模型一致性，是太空端 AI 模型更新的最佳實務。
________________________________________
3️⃣ 情境題
某衛星因溫度升高導致 AI fusion 模型降頻，造成 routing latency 增加。最適合解法？
A. 增加模型層數
B. 啟動 safe-mode 小模型
C. 增加 OTA 頻率
D. 不處理
📦 答案：B
👉 衛星溫度過高導致推論降頻時，切換至功耗與熱負載較低的 safe-mode 小模型，可立即穩定 routing 延遲並確保服務連續性，比重新訓練或頻繁 OTA 更安全有效。
________________________________________
🧪 六、實務演練題
1️⃣ 把 50M 參數 CNN 量化成 INT8 並測試 latency
2️⃣ 對 Transformer Routing Model 做 pruning（50% sparsity）
3️⃣ 設計 satellite-safe multi-version fallback 機制
4️⃣ 測試 1 MB OTA patch 更新流程
5️⃣ 模擬溫度升高時 NPU 降頻行為
________________________________________
✅ 七、小結
衛星端 AI 的核心精神：
🌌 不是追求最大模型，而是追求：
小、快、穩、抗輻射。
🟪 小 → 量化、剪枝、蒸餾
🟩 快 → FPGA / NPU mapping
🟦 穩 → multi-version fallback
🟧 抗輻射 → 硬體容錯、錯誤偵測
未來的 NTN / 星鏈系統將由：
⭐「太空級 AI」＋「地面 MLOps」
組成一套真正的 AI-native 星座網路。
