← M04 深度學習 M04 深度學習

M04.09｜深度學習框架：PyTorch vs TensorFlow

工具不重要？錯了 — 選錯框架可能讓你的專案多花三個月

L2-AI技術應用-開發框架 L2-AI技術應用-工具選擇

🇺🇸 DOL AI Literacy 🎯 有效指揮 AI 🤲 啟動體驗式學習

📋

本講學習重點

動態計算圖和靜態計算圖各有什麼優缺點？

PyTorch 為什麼成為研究社群的首選？

TensorFlow 在哪些場景仍有優勢？

Keras 和 HuggingFace 在框架生態中的定位是什麼？

選擇框架時最重要的考量是什麼？

PyTorch（Meta AI，2016 年）： - 動態計算圖（Define-by-Run）：每次前向傳播即時構建計算圖 - Pythonic 風格，除錯直覺（可以用普通 Python 斷點） - 研究社群標準（NeurIPS/ICML 論文幾乎都用 PyTorch） - HuggingFace 生態建立在 PyTorch 之上 - 部署工具：TorchScript、ONNX、TorchServe TensorFlow（Google Brain，2015 年）： - 原生靜態計算圖（Define-and-Run），TF2.0 之後預設 Eager 模式 - 生產部署工具鏈成熟：TF Serving、TFLite（行動/邊緣）、TF.js（瀏覽器） - Google Cloud TPU 的最佳支援 - Keras 是 TF 的高階 API（TF2.0 後已合併） Keras： - 高階深度學習 API，設計簡潔易用 - TF2.0 後成為 TensorFlow 的官方 API - Keras 3（2024）同時支援 TensorFlow/PyTorch/JAX 後端 HuggingFace： - 預訓練模型的 GitHub（Transformer 模型托管平台） - Transformers 函式庫：幾乎所有主流 LLM/Vision Transformer 都有支援 - Datasets、Tokenizers、Evaluate、PEFT 等豐富的配套工具 - 主要基於 PyTorch，也支援 TensorFlow JAX（Google，2018 年）： - 以 NumPy API 為基礎，自動微分 + XLA JIT 編譯 - 函數式編程風格（無狀態） - 大型 LLM 研究（Google DeepMind）首選 - 較陡峭的學習曲線，生態工具少於 PyTorch

📌 選擇深度學習框架不是信仰問題，是工程決策。 PyTorch 在研究、快速原型、NLP/LLM 任務上幾乎是預設選擇； TensorFlow/Keras 在需要跨平台部署（行動、邊緣、瀏覽器）和 Google Cloud 整合時有優勢。 HuggingFace 已成為 LLM 時代的事實標準高階 API，大多數新專案從 HuggingFace + PyTorch 出發最能快速上手。

🎙️ Podcast（中文）

0:00 / 0:00

一句話搞懂

PyTorch 是研究者的白板——隨寫隨改、所見即所得、除錯直覺；TensorFlow 是工廠的生產線——嚴謹的部署工具鏈、跨平台支援、生產環境穩定；而 HuggingFace 則是把幾乎所有主流 AI 模型打包成可以一行載入的函式庫，大幅降低了上手的門檻。

白話解說

計算圖：理解兩大框架最核心的差異

要理解 PyTorch 和 TensorFlow 的差異，必須先理解計算圖（Computation Graph）的概念。

深度學習框架需要知道「模型做了哪些計算」，才能執行反向傳播（算梯度）。這些計算的紀錄就叫計算圖：節點是計算操作，邊是資料流（張量）。

不同框架的關鍵差別在於計算圖何時被建立。

靜態計算圖（Static Computation Graph）——TensorFlow 1.x 的方式

TensorFlow 1.x（2015 年）採用「先定義，後執行（Define-and-Run）」的模式：

第一步：定義計算圖（僅描述計算，不執行）

# TensorFlow 1.x 風格（已不推薦，僅用於說明概念）
import tensorflow as tf

# 這只是在「畫藍圖」，沒有實際計算
x = tf.placeholder(tf.float32, shape=[None, 784])   # 占位符，尚無真實資料
W = tf.Variable(tf.zeros([784, 10]))
b = tf.Variable(tf.zeros([10]))
y = tf.matmul(x, W) + b
loss = tf.reduce_mean(tf.nn.softmax_cross_entropy_with_logits(labels=y_, logits=y))

第二步：在 Session 中執行計算圖

# 開啟執行環境，送入真實資料，才會實際運算
with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())
    result = sess.run(loss, feed_dict={x: batch_x, y_: batch_y})

靜態計算圖的比喻：就像建築師先畫完整張藍圖（定義圖），工人拿到藍圖再照著蓋房子（執行計算）。藍圖在施工前就是固定的。

靜態計算圖的優點：

框架拿到完整的計算圖後，可以做全局優化（如算子融合、自動並行化）
計算圖可以被序列化儲存，部署時直接載入圖執行（不需要 Python）
適合生產環境，服務延遲更可預測

靜態計算圖的缺點：

除錯困難：Python 的 print 無法在計算圖執行期間查看中間值，需要特殊的 TF Debug 工具
難以撰寫「根據資料決定計算邏輯」的模型（如可變長度序列、動態 RNN 步數）
學習曲線陡峭，心智模型和一般 Python 程式設計截然不同

動態計算圖（Dynamic Computation Graph）——PyTorch 的方式

PyTorch（2016 年）採用「邊定義邊執行（Define-by-Run）」的模式，每次執行前向傳播時，計算圖即時被構建：

import torch
import torch.nn as nn

# PyTorch 中，每次 forward() 被呼叫時，計算圖即時構建
class SimpleNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.fc1 = nn.Linear(784, 256)
        self.fc2 = nn.Linear(256, 10)

    def forward(self, x):
        # 這裡是實際的 Python 代碼，每次執行都可以加入不同的邏輯
        x = torch.relu(self.fc1(x))

        # 甚至可以根據資料決定計算流程！
        if x.mean() > 0:  # 這種條件分支在靜態計算圖中很難實現
            x = torch.dropout(x, p=0.5, train=self.training)

        x = self.fc2(x)
        return x

model = SimpleNet()

# 前向傳播：就像普通 Python 函數呼叫，計算圖在這一行即時建立
output = model(input_data)

# 反向傳播：根據剛才建立的計算圖，自動計算梯度
loss = criterion(output, labels)
loss.backward()  # 框架追蹤了計算圖，這裡自動執行反向傳播

動態計算圖的優點：

除錯直覺：可以用普通的 Python 斷點（pdb）、print，在任何地方查看中間值
靈活性高：可以輕易撰寫條件分支、迴圈、遞迴等複雜計算邏輯
開發速度快：Pythonic 風格，和一般 Python 程式設計思維一致，學習曲線平緩

動態計算圖的缺點：

無法在執行前做全局圖優化（因為圖是即時建立的）
部署時通常需要額外步驟（如 TorchScript、ONNX 轉換）才能脫離 Python 執行
相對靜態圖，理論上有一定的計算圖構建開銷（實際中被 torch.compile 等工具大幅緩解）

兩大框架的發展軌跡

TensorFlow 2.0 的轉向（2019 年）

面對 PyTorch 在研究社群的快速崛起，Google 在 TF2.0 中做了重大調整：

預設啟用 Eager Execution：像 PyTorch 一樣，TF2 預設也是「即時執行」（動態計算圖）
Keras 整合：把 Keras 作為 TF2 的官方高階 API，大幅簡化 API
廢棄 Session：TF1.x 的 Session 和 placeholder 被廢棄，代碼更直覺

TF2 的改變讓它更易用，但研究社群的慣性已形成——大多數新的論文代碼和開源模型都以 PyTorch 為主。

市占率的變化（學術研究）：

NeurIPS 2018 論文 PyTorch vs TensorFlow 使用比例：
  PyTorch 使用率：約 6%
  TensorFlow 使用率：約 69%

NeurIPS 2022 論文使用比例：
  PyTorch：76%
  TensorFlow：16%
  其他（JAX 等）：8%

→ 四年間，PyTorch 成為研究的絕對主流

生態系比較：HuggingFace 和 Keras 的角色

HuggingFace：LLM 時代的事實標準 API

HuggingFace 最初是一家聊天機器人新創，後來轉型成為 NLP 模型的托管平台和函式庫。如今，它已成為深度學習生態中最重要的基礎設施之一：

HuggingFace Hub（模型倉庫）：
  模型數量：超過 300,000 個公開模型（截至 2026 年初）
  包含：LLaMA、Mistral、Stable Diffusion、Whisper 等幾乎所有知名模型
  → 任何公開的主流模型，通常只需要幾行代碼就能載入並使用

HuggingFace Transformers（核心函式庫）：
  支援架構：BERT、GPT、T5、LLaMA、Mistral、Phi、Gemma...（200+ 模型架構）
  任務支援：文字分類、生成、問答、翻譯、圖像分類、物件偵測...
  一行載入預訓練模型：from transformers import AutoModelForCausalLM

HuggingFace 的使用範例（說明其抽象層級）：

from transformers import pipeline

# 一行代碼載入預訓練情感分析模型並執行推論
# 不需要了解底層 Transformer 架構、tokenizer 細節、模型格式
sentiment = pipeline("sentiment-analysis",
                     model="uer/roberta-base-finetuned-jd-binary-chinese")

result = sentiment("台灣高鐵的服務非常令人滿意，準時率極高")
# 輸出：[{'label': 'POSITIVE', 'score': 0.9876}]

HuggingFace 配套生態：

Datasets：海量公開資料集的統一下載和存取 API
Tokenizers（Rust 實作）：快速的文字 tokenization
PEFT：LoRA、QLoRA 等參數高效微調方法的統一實作
Accelerate：多 GPU、多節點訓練的簡化接口
Evaluate：各種評估指標（BLEU、ROUGE、accuracy）的統一 API

Keras 3.0：後端無關的高階 API

Keras 在 2024 年發布了 Keras 3.0，最大的突破是支援多後端：同一份 Keras 代碼，不修改，可以在 TensorFlow、PyTorch、JAX 三個後端上執行。

import keras

# 這份代碼可以在 TF / PyTorch / JAX 三個後端上執行
model = keras.Sequential([
    keras.layers.Dense(256, activation='relu'),
    keras.layers.Dropout(0.3),
    keras.layers.Dense(10, activation='softmax')
])

model.compile(optimizer='adam', loss='categorical_crossentropy')
model.fit(X_train, y_train, epochs=20, validation_split=0.2)

這讓 Keras 從「TensorFlow 的高階 API」升格為「後端無關的深度學習 API」，降低了不同框架之間的切換成本。

部署考量：框架選擇影響深遠

PyTorch 的部署路徑：

PyTorch 模型

  方案 1：TorchScript
    → 把 Python 模型編譯成靜態圖（JIT 追蹤或 JIT 腳本）
    → 可用 LibTorch（C++ API）在沒有 Python 的環境執行
    → 適合 C++ 服務或嵌入式系統

  方案 2：ONNX（Open Neural Network Exchange）
    → 把 PyTorch 模型匯出成跨框架的標準格式（.onnx 檔）
    → 用 ONNX Runtime 在 CPU/GPU/ARM 上高效推論
    → 可以進一步轉換成 TensorRT（NVIDIA 高性能推論引擎）
    → 最通用的跨平台部署方式

  方案 3：TorchServe
    → PyTorch 官方的模型服務框架
    → RESTful API、多模型管理、動態批次
    → 適合雲端推論服務

  方案 4：torch.compile（PyTorch 2.0+）
    → 自動編譯 PyTorch 模型，加速訓練和推論
    → 不需要改代碼，一行 model = torch.compile(model)

TensorFlow 的部署路徑（長期優勢）：

TensorFlow 模型（SavedModel 格式）

  TensorFlow Serving：
    → gRPC / REST API，高性能生產推論
    → Google 在大規模服務中的戰備選擇
    → Docker 部署一鍵啟動

  TensorFlow Lite（TFLite）：
    → 模型量化 + 輕量化，部署到行動裝置（iOS/Android）和嵌入式系統
    → 支援 NNAPI（Android）、Core ML（iOS）、Edge TPU 加速
    → 台灣製造業在 ARM 工業電腦上廣泛使用 TFLite 部署視覺 AI

  TensorFlow.js：
    → 在瀏覽器中執行深度學習模型（客戶端推論）
    → 不需要後端 API，隱私保護更好（資料不離開用戶設備）
    → 台灣的教育科技應用、隱私敏感應用的選擇

  TensorRT（NVIDIA，跨框架）：
    → 雖然 TensorRT 不是 TF 專屬，但 TF-TRT 整合最成熟
    → 將模型量化（INT8/FP16）並優化 NVIDIA GPU 上的推論速度

JAX：研究前沿的第三選擇

JAX 是 Google 在 2018 年推出的數值計算函式庫，以 NumPy 的 API 為基礎，加上自動微分和 XLA JIT 編譯。

JAX 的核心特點：

函數式編程：JAX 的函數必須是純函數（無副作用），這讓 JIT 編譯和並行化更容易
XLA 編譯：自動把計算圖編譯成高效的 XLA 代碼，在 GPU/TPU 上極快執行
vmap（向量化）：自動把單樣本函數向量化，處理批次資料
pmap（並行化）：自動把計算分散到多個 GPU/TPU 上

import jax
import jax.numpy as jnp

# JAX 風格：函數式，用 jax.grad 自動微分
def loss_fn(params, x, y):
    prediction = jnp.dot(x, params['W']) + params['b']
    return jnp.mean((prediction - y) ** 2)

# 自動微分：計算 loss_fn 對 params 的梯度
grad_fn = jax.grad(loss_fn)
grads = grad_fn(params, x_batch, y_batch)

# JIT 編譯：第一次呼叫時編譯，後續呼叫極快
@jax.jit
def train_step(params, x, y):
    loss, grads = jax.value_and_grad(loss_fn)(params, x, y)
    return loss, grads

JAX 的適用場景：大型語言模型的預訓練研究（Google DeepMind 的 Gemini 就是用 JAX 訓練的）、需要 TPU 加速的任務、研究新型優化演算法。

JAX 的限制：學習曲線最陡（函數式思維對習慣 OOP 的工程師有挑戰），生態工具少（調試工具、預訓練模型庫不如 PyTorch 豐富），主要在 Google 內部和頂尖研究機構使用，台灣企業應用較少。

應用場景

不同使用情境的框架選擇對照

使用情境	推薦框架	理由
NLP / LLM 研究與開發	PyTorch + HuggingFace	幾乎所有預訓練 LLM 在 HuggingFace 上，PyTorch 是主流
電腦視覺研究	PyTorch	torchvision、detectron2 等視覺庫都以 PyTorch 為主
快速原型驗證	PyTorch（或 Keras）	動態圖除錯方便；Keras 的 API 更簡潔
行動裝置 App（iOS/Android）	TensorFlow Lite	TFLite 的行動端工具鏈最成熟，Apple CoreML/Android NNAPI 整合好
瀏覽器端 AI	TensorFlow.js	唯一成熟的瀏覽器深度學習框架
Google Cloud / TPU 訓練	TensorFlow 或 JAX	TPU 對 TF/JAX 支援最佳，PyTorch-XLA 仍有限制
企業生產 API 服務	PyTorch + TorchServe 或 ONNX Runtime	兩者均成熟，視現有技術棧決定
教學/入門	Keras（後端用 PyTorch 或 TF）	API 最簡潔，學習曲線最平緩
學術研究（LLM 預訓練）	JAX（Google 系）/ PyTorch	視研究機構的工具鏈而定
製造業嵌入式 AI	TFLite 或 ONNX Runtime	ARM 設備的最佳支援

常見誤區

誤區一：PyTorch 比 TensorFlow 更快

這是一個廣泛流傳但不準確的說法。兩個框架底層都調用高度優化的 CUDA/cuDNN 核心，在同樣的硬體和模型架構下，訓練速度的差異通常在 5% 以內，屬於工程實作細節導致的微小差距，而非框架本身的根本速度差異。PyTorch 在研究者中更受歡迎的原因是開發效率（動態計算圖更好除錯、代碼更 Pythonic），而非計算速度。若有人告訴你「PyTorch 訓練速度比 TensorFlow 快 2 倍」，那很可能是因為代碼實作細節不同，而非框架本質差異——例如一方啟用了混合精度訓練，另一方沒有。

誤區二：既然 HuggingFace 什麼模型都有，學 PyTorch 已經不重要

HuggingFace 確實大幅降低了使用預訓練模型的門檻，但「呼叫 API 得到答案」和「理解模型在做什麼並能調試、優化、修改」是兩回事。當你的 HuggingFace 模型在特定資料上效果不佳、記憶體不夠、速度不達標，或需要對架構做客製化修改時，你必須深入 PyTorch 層面才能解決問題。HuggingFace 是加速器，不是替代品。把 HuggingFace 當作入口，把 PyTorch 當作核心能力來培養，才是正確的學習路徑。

誤區三：TensorFlow 已經過時，學 TensorFlow 是浪費時間

PyTorch 在研究社群的主導地位是事實，但 TensorFlow 在企業生產環境，尤其是行動裝置部署（TFLite）和瀏覽器端 AI（TF.js）方面，仍然是最成熟的解決方案。台灣許多金融、零售、製造業的 AI 系統是在 TF 興盛期建立的，維護這些系統需要 TF 知識。此外，Google 的 Keras 3 和 Vertex AI 都以 TF 生態為核心。TensorFlow 的市占率確實在研究界下滑，但在企業部署端、行動端、Google Cloud 用戶中仍有大量使用。「TF 已過時」是研究者視角的偏見，不是工業界的完整事實。

小練習

練習一：框架選擇決策

你是一家台灣新創的首席 AI 工程師，公司正在開發三個 AI 功能，你需要為每個功能選擇合適的深度學習框架，並說明理由：

功能 A：為公司的客服中心建立一個即時對話 AI，後端服務部署在 AWS 上，需要整合公司自己的知識庫（RAG 架構），對話模型基於 Llama-3-8B 微調，需要支援繁體中文。

功能 B：開發一個「產品包裝瑕疵偵測」功能，部署在工廠的 ARM 架構工業電腦（無 GPU），需要在 < 100ms 內完成一張圖片的推論，模型需要能輕量化到 50MB 以內。

功能 C：開發一個「AR 試妝鏡」功能，用戶在品牌的官方網站上使用網頁攝影機即時試用口紅顏色，所有推論在用戶的瀏覽器中執行（不傳送人臉影像到伺服器）。

請為每個功能選擇框架，並說明從訓練到部署的完整技術路徑。

看解答

**功能 A：客服對話 AI → PyTorch + HuggingFace + TorchServe** 完整技術路徑：第一步（模型準備）： ```python from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model # 載入基底模型（HuggingFace Hub） model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct", torch_dtype=torch.bfloat16) # 使用 QLoRA 微調（節省 VRAM，適合有限 GPU 預算） lora_config = LoraConfig(r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"]) model = get_peft_model(model, lora_config) ``` 第二步（微調訓練）： - 用公司的繁體中文客服對話資料（問題-答案對）微調 - 使用 HuggingFace Trainer 或 TRL（Transformer Reinforcement Learning）的 SFTTrainer - 硬體需求：A100 40GB × 1 張，或使用 AWS SageMaker 的受管 GPU 第三步（部署）： - 模型量化：使用 bitsandbytes 的 4-bit 量化，把 8B 模型 VRAM 需求從 16GB 降至 5GB - 服務部署：TorchServe 或 vLLM（開源高性能 LLM 推論框架，比 TorchServe 更適合 LLM） - RAG 整合：LangChain 或 LlamaIndex 連接向量資料庫（如 Qdrant）和 LLM，實現知識庫問答選擇 PyTorch + HuggingFace 的原因：Llama-3 的官方實作是 PyTorch；幾乎所有 LLM 微調工具（TRL、PEFT）都基於 PyTorch；繁體中文 NLP 的資源和社群主要在 PyTorch 生態。 **功能 B：包裝瑕疵偵測 → PyTorch 訓練 → TFLite 或 ONNX Runtime 部署** 完整技術路徑：第一步（訓練）： - 使用 PyTorch + torchvision，從 MobileNetV3-Small（輕量視覺模型）出發做遷移學習 - 訓練資料：工廠收集的良品/瑕疵圖片，配合資料增強第二步（模型輕量化）： ```python import torch from torch.quantization import quantize_dynamic # 訓練後動態量化（把 FP32 模型壓縮成 INT8） quantized_model = quantize_dynamic(model, {torch.nn.Linear, torch.nn.Conv2d}, dtype=torch.qint8) # 模型大小可從 ~20MB 壓縮到 ~5MB # 匯出為 ONNX 格式 torch.onnx.export(quantized_model, dummy_input, "defect_detection.onnx") ``` 第三步（ARM 部署）： - 使用 ONNX Runtime（ARM 後端）在工業電腦上推論 - ONNX Runtime 對 ARM 有官方優化（NEON 指令集加速），無 GPU 的 ARM 上也能達到 30–100ms 的推論速度或者選擇 TFLite 路徑：用 ONNX 轉換工具把模型轉成 TFLite 格式，使用 ARM NN（ARM 官方神經網路加速框架）進一步加速。選擇此路徑的原因：ARM 工業電腦上，ONNX Runtime 和 TFLite 都是成熟的無 GPU 推論選項，模型大小（< 50MB）和速度（< 100ms）需求通過量化後完全可行。 **功能 C：AR 試妝鏡（瀏覽器端推論）→ TensorFlow.js** 完整技術路徑：第一步（模型設計）： - 使用 Python + TensorFlow/Keras 訓練人臉偵測 + 嘴唇分割模型 - 選用 MobileNetV2 + DeepLab 等輕量化架構（瀏覽器記憶體和算力有限） - 嘴唇分割輸出：一個二值遮罩（Mask），標記哪些像素是嘴唇第二步（模型轉換）： ```bash # 把 Keras/TF 模型轉換成 TensorFlow.js 格式 tensorflowjs_converter --input_format=tf_saved_model \ --output_node_names='output_mask' \ ./saved_model ./tfjs_model ``` 第三步（瀏覽器部署）： ```javascript // 在網頁 JavaScript 中載入和執行模型 import * as tf from '@tensorflow/tfjs'; const model = await tf.loadGraphModel('tfjs_model/model.json'); // 取得攝影機影像 const video = document.getElementById('webcam'); const tensor = tf.browser.fromPixels(video); // 推論：找出嘴唇遮罩 const mask = model.predict(tensor.expandDims(0)); // 疊加選擇的口紅顏色 // ... 用 Canvas API 在遮罩區域填色 ``` 選擇 TensorFlow.js 的原因：這是唯一成熟的瀏覽器深度學習框架；人臉影像不需要上傳到伺服器（隱私保護），符合歐盟 GDPR 和台灣個資法的精神；TF.js 支援 WebGL 加速，在現代瀏覽器上有足夠的推論速度。注意：如果公司未來打算同時出 iOS/Android App，可以考慮用 ONNX 格式作為中間橋樑：用 PyTorch 訓練 → 轉 ONNX → ONNX to TF.js（給網頁）/ TFLite（給行動 App）/ ONNX Runtime（給工業電腦）。

練習二：評估框架轉移的成本

你的公司有一個用 TensorFlow 1.x 建立的生產模型（三年前開發，目前每日為公司創造重要業務價值）。新的 AI 工程師加入後，發現以下問題：

TF1.x 的代碼風格（Session、placeholder）讓新工程師很難理解和修改
公司想要加入新功能：用 HuggingFace 的 BERT 模型做文字特徵提取，與原有模型結合
最近有一篇論文提出了改進的模型架構，論文代碼是 PyTorch，想要評估是否引入

你的任務是評估「是否應該把現有 TF1.x 系統遷移到 PyTorch」，並提出具體建議。

請回答：

遷移框架的主要成本有哪些？列出至少五個考量點。
如果決定不全面遷移，如何把 HuggingFace BERT 整合進現有 TF1.x 系統？
如果決定全面遷移，建議分幾個階段執行，每個階段的目標是什麼？

看解答

**問題 1：遷移框架的主要成本** **成本一：代碼重寫工作量** 把 TF1.x 代碼（Session/placeholder 風格）改寫成 PyTorch，幾乎等同於從頭重寫模型代碼。若原有模型包含複雜的自定義層、自定義訓練迴圈、特殊的資料 pipeline，估計工作量為 2–6 個月（視代碼規模和複雜度）。不同框架之間的等效 API 需要逐一查找和測試。 **成本二：行為一致性驗證** 重寫後的 PyTorch 模型必須產生與原 TF1.x 模型「完全一致」的預測結果（在數值精度允許的範圍內），否則業務指標可能退步。這需要在相同的測試集上跑 A/B 對照，耗時且繁瑣，任何微小的實作差異（如隨機數生成方式、邊界填充策略）都可能導致結果不一致。 **成本三：部署流程重建** 原有 TF1.x 的部署流程（TF Serving、SavedModel 匯出、監控系統）需要配合新框架重建。包括：CI/CD pipeline 的修改、模型上線 / 回滾流程的更新、性能監控和告警指標的重新設定。 **成本四：線上服務風險** 遷移期間，新模型上線前需要充分的影子測試（Shadow Testing）——讓新模型和舊模型同時處理線上請求，但只使用舊模型的結果，觀察新模型的輸出是否一致。若沒有這個步驟，直接上線存在生產事故的風險。 **成本五：工程師學習曲線** 老工程師（熟悉 TF1.x）需要時間學習 PyTorch；同時，遷移期間的業務功能開發會被暫停或減緩，有機會成本。 **額外考量**：現有 TF1.x 系統是否有完整的單元測試？測試覆蓋率越低，遷移的風險越高。是否有詳細的文件記錄原有模型的設計決策？文件越少，「還原」原有行為越困難。 **問題 2：不遷移的整合方案——把 BERT 整合進 TF1.x 系統** 不需要全面遷移，可以採用「服務化（Microservice）」的方式把 BERT 整合進現有系統： **方案：BERT 作為獨立的特徵提取微服務** ``` 現有 TF1.x 主模型（保持不變） ↑ 接收 BERT 提取的文字特徵向量 BERT 特徵提取服務（獨立部署）：技術棧：PyTorch + HuggingFace Transformers + FastAPI 輸入：文字字串輸出：BERT [CLS] token 向量（768 維）部署：Docker 容器，REST API 現有系統的調用方式： 1. 把輸入文字發送給 BERT 服務（HTTP 請求） 2. 取得 768 維向量 3. 把向量作為新特徵，拼接進原有特徵集，送入 TF1.x 模型 ``` 這個方案的優點是： - 對現有 TF1.x 代碼的修改極小（只是增加一個 HTTP 呼叫和特徵拼接） - BERT 服務可以獨立升級（換成更好的 BERT 版本不影響主模型） - 風險低，可以 A/B 測試「有 BERT 特徵」vs「無 BERT 特徵」的模型效果缺點：增加了一次網路 RPC 呼叫的延遲（通常 5–50ms，視部署距離），對延遲敏感的應用需要注意。 **問題 3：全面遷移的分階段計劃** 若決定全面遷移，建議分四個階段執行： **第一階段（2 個月）：並行建立 PyTorch 模型** 目標：在不影響現有生產系統的前提下，在 PyTorch 中建立等效模型。工作項目： - 用 PyTorch 重寫模型架構（可先不管訓練流程，只重寫推論部分） - 在相同的測試集上比對 TF1.x 和 PyTorch 模型的輸出，確保數值一致 - 整合 HuggingFace BERT 特徵提取 - 撰寫充分的單元測試 **第二階段（1 個月）：重建訓練流程和資料 Pipeline** 目標：讓 PyTorch 模型可以用現有資料重新訓練，並達到與現有 TF1.x 模型相同或更好的效果。工作項目： - 重寫資料載入和前處理（PyTorch DataLoader） - 重寫訓練迴圈（含驗證、Early Stopping、模型儲存） - 重新訓練一個完整的 PyTorch 模型版本 - 評估訓練結果，確認效果不退步 **第三階段（1 個月）：部署流程重建和影子測試** 目標：建立 PyTorch 模型的生產部署流程，並通過影子測試驗證可靠性。工作項目： - 建立 TorchServe 或 ONNX Runtime 的部署流程 - 更新 CI/CD pipeline 以支援 PyTorch 模型的自動化測試和部署 - 影子測試：讓 PyTorch 模型並行處理線上請求（不實際使用結果），比對輸出 **第四階段（2 週）：正式切換和舊系統下線** 目標：把線上服務正式切換到 PyTorch 模型，保留 TF1.x 系統作為緊急回滾備援。工作項目： - 灰度發布：先讓 5% → 20% → 50% → 100% 的流量走 PyTorch 模型 - 監控關鍵業務指標（不只是技術指標，還有業務結果） - 確認穩定後，TF1.x 系統保留 2–4 週作為回滾選項，之後下線 **總結建議**：在沒有緊迫的業務需求驅動遷移的情況下，「不全面遷移，BERT 作為微服務整合」的方案風險更低、成本更小、收益更快。全面遷移適合以下情況：現有系統已無法滿足新功能需求（如論文新架構必須整合到核心模型中）、現有代碼品質差到維護困難、有充足的工程資源和時間視窗。

關鍵字自我檢核

✅ PyTorch ✅ TensorFlow ✅ dynamic computation graph ✅ static computation graph ✅ eager execution ✅ Keras ✅ HuggingFace Transformers ✅ ONNX ✅ TensorRT ✅ TensorFlow Serving ✅ TFLite ✅ JAX ✅ 動態計算圖 ✅ 靜態計算圖 ✅ 模型部署