動態計算的策略價值：讓 AI 模型「看情況出力」，是推論效率下一個 10 倍突破口

一、AI 的「一刀切」計算困境：你正在為每一個 Token 付相同的算力帳單

剪枝、蒸餾、量化——這三大模型壓縮技術有一個共同特徵：它們在部署前就永久改變了模型的大小或精度。一旦壓縮完成，模型對每一個輸入都投入相同的計算量。但現實是：不是所有輸入都同等困難。

想像一個翻譯系統處理一份合約：「The」這個詞幾乎不需要思考，但「indemnification」可能需要模型動用所有參數才能準確翻譯。傳統模型對這兩個詞投入完全相同的算力——這是一種系統性的浪費。Harvard Business Review 指出^[1]，全球 AI 基礎設施的能耗正以驚人速度膨脹，而其中大量算力正花在「不必要的計算」上。

MIT Sloan Management Review 的研究^[2]進一步指出，高效化的 AI 部署往往比追求最大模型帶來更高的商業回報。動態計算（Dynamic Computation）正是解決這個問題的技術範式：讓模型根據輸入的難度，自動調整投入的計算量。簡單的輸入快速通過，複雜的輸入才動用全部資源。

與靜態壓縮不同，動態計算不改變模型的大小或精度——模型保留完整能力，但只在需要時才使用。這讓它成為模型效率的第四根支柱，與剪枝、蒸餾、量化完全正交且可疊加使用。

二、技術演進：從自適應計算到條件式推論

2.1 自適應計算時間：讓網路自己決定「想多久」

動態計算的理論根源可以追溯到 2016 年。Alex Graves 提出了自適應計算時間（Adaptive Computation Time, ACT）^[3]：讓循環神經網路（RNN）自行學習每個輸入需要多少計算步驟。網路透過一個「停止機率」來決定何時結束計算——簡單的輸入只需一步，複雜的輸入可以「多想幾步」。

ACT 的核心洞察是革命性的：計算量本身可以是模型的一個可學習輸出。這個概念為後續所有動態計算技術奠定了基礎——從 Early Exit 到 Mixture of Experts，都是這個思想的不同工程實現。

2.2 Early Exit：讓簡單的 Token 提前畢業

現代 Transformer 模型通常有數十層。但是否每個輸入都需要經過所有層？Google 在 NeurIPS 2022 發表的 CALM（Confident Adaptive Language Modeling）^[4]證明了答案是否定的。

CALM 的機制直覺而優雅：在每一層的輸出上附加一個輕量級的「信心度分類器」。當某個 token 的預測信心度超過閾值時，它就可以提前退出——不再經過剩餘的層。CALM 在 T5 模型上展示了驚人的效果：平均計算量減少至原來的 1/3，而輸出品質幾乎不變。

微軟的 SkipDecode^[5] 進一步解決了 Early Exit 在實際部署中的痛點——批次推論的效率。在一個 batch 中，不同序列需要不同的計算深度。SkipDecode 用 token 級的跳層策略和自適應 KV cache，讓不同序列可以在不同層退出，同時保持 batch 推論的硬體效率。

2.3 Mixture of Experts：只啟動你需要的專家

如果 Early Exit 是「縱向」的動態計算（選擇經過多少層），那麼 Mixture of Experts（MoE）就是「橫向」的動態計算——每一層中只啟動一部分參數。

Switch Transformer^[6]（JMLR 2022）是 MoE 架構的里程碑。Google 的 William Fedus 等人將每個 FFN 層替換為多個「專家」子網路，每個 token 只路由到一個專家（top-1 routing）。這個看似簡單的設計讓模型參數擴展到了 1.6 兆——但每次推論只使用其中一小部分。

Mistral AI 的 Mixtral 8x7B^[7] 將 MoE 推向了實用化。8 個專家中每次選取 2 個（top-2 routing），總參數量 46.7B 但每個 token 只啟動 12.9B——用不到 LLaMA-2 70B 五分之一的算力，達到相當的性能。Mixtral 證明了 MoE 不只是研究概念，而是可以直接部署的高效架構。

DeepSeek-V3^[8] 是目前 MoE 架構的巔峰之作。671B 總參數中包含 256 個路由專家和 1 個共享專家，每 token 選取 top-8，實際啟動約 37B 參數。配合 Multi-head Latent Attention（MLA）壓縮 KV cache，DeepSeek-V3 在多個基準測試上與 GPT-4o 和 Claude 3.5 Sonnet 競爭——但訓練成本僅約 557 萬美元（2048 張 H800 訓練約兩個月），不到同級別密集模型的十分之一。

2.4 Speculative Decoding：用小模型替大模型「打草稿」

自回歸語言模型有一個根本瓶頸：每個 token 必須等上一個 token 生成完才能開始。這意味著生成 N 個 token 需要 N 次前向傳播，無法平行化。推測性解碼（Speculative Decoding）用一個巧妙的「草稿-驗證」機制打破了這個瓶頸。

2022-2023 年，Google 的 Leviathan 等人^[9]和 DeepMind 的 Chen 等人^[10]獨立提出了相同的核心想法：

1. 用一個小型草稿模型（如 OPT-125M）快速生成 K 個候選 token
2. 將這 K 個 token 一次性送入大模型驗證（大模型可以平行處理）
3. 用 rejection sampling 決定接受或拒絕每個候選 token

關鍵突破在於數學保證：最終輸出的機率分佈與純粹使用大模型完全相同。這不是「近似」——而是在數學上嚴格等價。這讓推測性解碼成為唯一一種零精度損失的推論加速技術。實踐中可實現 2-3x 的加速，特別是在大模型與小模型能力差距適中的場景下效果最佳。

ICML 2024 的 Medusa^[11] 則提出了一種更優雅的方案：不需要獨立的草稿模型，而是直接在原始模型上加裝多個解碼頭。每個頭負責預測不同位置的未來 token，透過 tree attention 機制一次性驗證。Medusa 的優勢在於部署更簡單（只需一個模型），且解碼頭只需少量微調即可使用。

2.5 Token Merging：合併冗餘的 Token

Vision Transformer（ViT）將圖片切成 N 個 patch token 來處理。但許多 patch 是高度冗餘的——一片藍天中相鄰的 patch 幾乎攜帶相同的資訊。Token Merging（ToMe）^[12]（ICLR 2023）的策略是：在每個 Transformer 層中，合併最相似的 token。

ToMe 使用二分圖軟匹配（bipartite soft matching）來找到最佳的合併配對。這個演算法不需要學習任何新參數，也不需要重新訓練——直接套用在預訓練的 ViT 上即可生效。在 ImageNet 上，ToMe 將 ViT-L/16 的吞吐量提升了 2 倍，精度僅下降 0.2%。

更令人興奮的是 ToMe 在擴散模型上的應用^[13]。Stable Diffusion 的每一步去噪都經過一個 U-Net（其中包含 attention 層），而 ToMe 可以在每一步中合併冗餘 token。tomesd^[14] 函式庫讓你一行程式碼就能將 SD 加速 2x，且生成圖片的品質肉眼幾乎無法區分。更重要的是，ToMe 可以與其他加速技術疊加——論文報告了最高 5.4x 的加速。

2.6 Mixture-of-Depths：讓每一層決定要不要計算

如果 MoE 選擇「用哪個專家」，那麼 Google DeepMind 的 Mixture-of-Depths（MoD）^[15]則更激進——讓 token 選擇「要不要經過這一層」。

MoD 在每一層加入一個輕量級路由器，根據 token 的重要性決定是否讓它「跳過」當前層。被跳過的 token 直接透過殘差連接傳到下一層，完全不需要計算。論文發現了一個驚人的結論：即使只用 12.5% 的計算容量（每層只處理 1/8 的 token），模型仍然能匹配全容量版本的表現。這意味著在理論上，MoD 可以讓推論加速超過 50%，同時保持相當的模型品質。

MoD 的意義在於它揭示了 Transformer 計算的驚人冗餘——大多數 token 在大多數層中根本不需要被處理。

2.7 Feature Caching：跳過重複的去噪計算

擴散模型的推論需要數十步去噪迭代，每一步都要通過完整的 U-Net。但相鄰步驟之間，U-Net 高層特徵的變化其實非常微小。DeepCache^[16]（CVPR 2024）利用了這個觀察：快取高層特徵，只更新變化較大的低層特徵。

具體做法是：每隔 N 步才完整執行一次 U-Net，中間的步驟只運行低層分支，高層特徵直接從快取中讀取。在 Stable Diffusion 1.5 上，DeepCache 實現了 2.3x 加速，CLIP Score 和 FID 幾乎不變。更重要的是：

• 完全免訓練——不需要修改模型權重
• 與其他技術相容——可以與 ToMe、量化疊加使用
• 通用性強——支援 SD 1.x、SD 2.x、SDXL、Stable Video Diffusion 等多種架構

三、文字生成式 AI 的實際應用

動態計算在文字生成 AI 中的應用已經從研究走向生產。以下是三個最具影響力的落地場景：

場景一：大規模 LLM 服務——MoE 架構

DeepSeek-V3 的成功證明了一個重要論點：下一代前沿模型不一定需要更多的計算，而是需要更聰明的計算分配。671B 參數的模型聽起來昂貴，但每次推論只啟動 37B——這讓其推論成本接近一個 30-40B 的密集模型。Mixtral 8x7B 的商業版本（通過 Mistral API 或 AWS Bedrock 部署）已經被大量企業採用，因為它在 LLaMA-2 70B 級別的品質下，推論速度快了 6 倍以上。

場景二：低延遲應用——推測性解碼

對話式 AI、即時翻譯、程式碼自動完成等應用對延遲極為敏感。推測性解碼讓大模型的回應速度提升 2-3x，而不犧牲任何品質。HuggingFace 在 Transformers v4.29+ 中已原生支援^[17]，只需一個 assistant_model 參數即可啟用。Google 的 Gemini 和 Anthropic 的 Claude 在推論引擎中也廣泛使用了類似技術。

場景三：分類與理解——Early Exit

對於文字分類、情感分析、實體辨識等理解型任務，大多數輸入根本不需要模型的全部深度。CALM 的 early exit 機制讓模型在前幾層就能處理完 80% 的簡單輸入，只有最困難的 20% 才需要經過所有層。這特別適合處理大量請求的 API 服務——平均延遲可降低 2-3 倍。

四、圖像生成式 AI 的實際應用

擴散模型的推論成本比 LLM 更高（數十步去噪 × 大型 U-Net），動態計算在此領域的價值更為顯著：

場景一：Token Merging 加速生成

tomesd^[14] 讓 Stable Diffusion 的每一步去噪中合併冗餘 token。在 50% 的合併比例下，SD 1.5 的生成速度提升約 2x，VRAM 使用降低，而生成品質的差異肉眼幾乎不可見。這對需要批量生成圖片的電商、廣告、設計工作流特別有價值。

場景二：DeepCache 快取加速

DeepCache^[18] 在 SD、SDXL 和 Stable Video Diffusion 上都展現了 2x+ 的加速。對於 SDXL（需要更多 VRAM），DeepCache 的節省更為明顯——讓原本需要高階 GPU 的模型可以在中階設備上流暢運行。

場景三：技術疊加——極致加速

動態計算技術最強大的特性之一是可疊加。在 Stable Diffusion 上同時使用：

• DeepCache（快取高層特徵）：2.3x
• ToMe（合併冗餘 token）：2x
• 量化（INT8/INT4）：1.5-2x

三者疊加可以實現 4-8x 的端到端加速，讓 Stable Diffusion 在消費級 GPU 上接近即時生成。

五、Hands-on Lab：Token Merging（電腦視覺）

我們從最直覺的技術開始——在 ViT 上實作 Token Merging，親手體驗「合併冗餘 token」如何加速推論。

打開 Google Colab（CPU 即可，T4 更快），新建 Notebook，依序貼入以下程式碼：

5.1 Step 1 — 環境設定與模型載入

!pip install timm tome Pillow requests -q

import timm
import tome
import torch
import time
import requests
from PIL import Image
from io import BytesIO

# 下載範例圖片（維基百科的貓咪圖片）
url = "https://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Cat_November_2010-1a.jpg/1200px-Cat_November_2010-1a.jpg"
img = Image.open(BytesIO(requests.get(url).content)).convert("RGB")

# 載入預訓練 ViT-Base/16（~86M 參數）
model = timm.create_model("vit_base_patch16_224", pretrained=True)
model.eval()

# 圖片預處理
data_config = timm.data.resolve_model_data_config(model)
transform = timm.data.create_transform(**data_config, is_training=False)
x = transform(img).unsqueeze(0)  # [1, 3, 224, 224]

# ImageNet 標籤
labels_url = "https://storage.googleapis.com/bit_models/ilsvrc2012_wordnet_lemmas.txt"
labels = requests.get(labels_url).text.strip().split("\n")

print(f"✓ 模型載入完成：ViT-Base/16")
print(f"  參數量: {sum(p.numel() for p in model.parameters()) / 1e6:.1f}M")
print(f"  輸入 Token: {(224//16)**2 + 1} = 196 patch tokens + 1 cls token")

5.2 Step 2 — 基準測量工具

def benchmark(model, x, n_warmup=20, n_runs=200):
    """測量 CPU 推論延遲（ms）"""
    for _ in range(n_warmup):
        with torch.no_grad():
            model(x)
    start = time.perf_counter()
    for _ in range(n_runs):
        with torch.no_grad():
            model(x)
    return (time.perf_counter() - start) / n_runs * 1000

def predict(model, x, labels):
    """取得預測結果"""
    with torch.no_grad():
        logits = model(x)
    probs = logits.softmax(-1)
    top_prob, top_idx = probs.max(-1)
    return labels[top_idx.item()], top_prob.item() * 100

# ---- 基準數據 ----
pred, conf = predict(model, x, labels)
base_ms = benchmark(model, x)

print(f"{'='*60}")
print(f"  基準模型（ViT-Base/16，無 Token Merging）")
print(f"{'='*60}")
print(f"  預測: {pred}")
print(f"  信心度: {conf:.1f}%")
print(f"  推論延遲: {base_ms:.2f} ms")
print(f"{'='*60}")

5.3 Step 3 — 套用 Token Merging

# ★ Token Merging：一行套用 ★
# tome.patch.timm 會修改模型的 forward，在每層中合併 r 個 token
tome.patch.timm(model)

print(f"\n{'='*60}")
print(f"  Token Merging 效果比較")
print(f"{'='*60}")
print(f"{'r 值':<8} {'延遲(ms)':<10} {'加速比':<8} {'預測':<25} {'信心度'}")
print(f"{'-'*60}")

for r in [0, 4, 8, 16, 24, 32]:
    model.r = r  # 每層合併 r 個 token
    pred, conf = predict(model, x, labels)
    ms = benchmark(model, x)
    speedup = base_ms / ms
    marker = " ★ 推薦" if r == 16 else ""
    print(f"r={r:<5} {ms:<9.2f} {speedup:<7.2f}x {pred:<25} {conf:.1f}%{marker}")

print(f"{'='*60}")
print(f"\n★ 關鍵觀察:")
print(f"  • r=0 等同原始模型（無合併）")
print(f"  • r=16 是品質與速度的最佳平衡點")
print(f"  • 即使 r=32（大量合併），預測結果通常仍正確")
print(f"  • ViT-Base 有 12 層 → r=16 意味著每層合併 16 token 對")
print(f"  • 全程免訓練——直接套用在任何預訓練 ViT 上")

六、Hands-on Lab：Speculative Decoding（語言模型）

接下來是動態計算在 LLM 中最實用的技術——推測性解碼。我們用 HuggingFace 的原生 assistant_model API^[17] 來體驗「用小模型替大模型打草稿」。

打開 Google Colab（選 T4 GPU），新建 Notebook，依序貼入以下程式碼：

6.1 Step 1 — 載入目標模型與草稿模型

!pip install transformers accelerate -q

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
import time

# ★ 關鍵：一大一小兩個同家族模型 ★
target_name = "facebook/opt-1.3b"   # 目標模型：1.3B 參數
draft_name  = "facebook/opt-125m"   # 草稿模型：125M 參數（小 10 倍）

print("載入目標模型 (1.3B)...")
tokenizer = AutoTokenizer.from_pretrained(target_name)
target_model = AutoModelForCausalLM.from_pretrained(
    target_name, torch_dtype=torch.float16, device_map="auto"
)

print("載入草稿模型 (125M)...")
draft_model = AutoModelForCausalLM.from_pretrained(
    draft_name, torch_dtype=torch.float16, device_map="auto"
)

target_mem = sum(p.numel() * p.element_size() for p in target_model.parameters()) / 1024**3
draft_mem = sum(p.numel() * p.element_size() for p in draft_model.parameters()) / 1024**3
print(f"\n✓ 模型載入完成")
print(f"  目標模型: {target_name} ({target_mem:.2f} GB)")
print(f"  草稿模型: {draft_name} ({draft_mem:.2f} GB)")
print(f"  草稿模型僅佔目標模型的 {draft_mem/target_mem*100:.1f}%")

6.2 Step 2 — 標準生成 vs. 推測性解碼

prompts = [
    "The key advantage of dynamic computation in AI is",
    "Large language models can be accelerated by",
    "In the future, efficient AI inference will",
]

print(f"{'='*70}")
print(f"  標準生成 vs. 推測性解碼 比較")
print(f"{'='*70}")

total_standard, total_spec = 0, 0

for prompt in prompts:
    inputs = tokenizer(prompt, return_tensors="pt").to(target_model.device)

    # ---- 標準生成（逐 token）----
    torch.cuda.synchronize()
    start = time.perf_counter()
    out_standard = target_model.generate(
        **inputs, max_new_tokens=80, do_sample=False
    )
    torch.cuda.synchronize()
    t_standard = time.perf_counter() - start

    # ---- 推測性解碼（assistant_model）----
    torch.cuda.synchronize()
    start = time.perf_counter()
    out_spec = target_model.generate(
        **inputs, max_new_tokens=80, do_sample=False,
        assistant_model=draft_model,  # ★ 只需加這一個參數 ★
    )
    torch.cuda.synchronize()
    t_spec = time.perf_counter() - start

    total_standard += t_standard
    total_spec += t_spec
    tokens = out_standard.shape[1] - inputs["input_ids"].shape[1]

    print(f"\n  Prompt: {prompt}")
    print(f"  標準: {t_standard:.2f}s | 推測: {t_spec:.2f}s | "
          f"加速: {t_standard/t_spec:.2f}x | Token: {tokens}")

    # 驗證輸出完全一致（推測性解碼的數學保證）
    match = torch.equal(out_standard, out_spec)
    print(f"  輸出完全一致: {'✓' if match else '✗'}")

6.3 Step 3 — 完整統計

print(f"\n{'='*70}")
print(f"  推測性解碼總結")
print(f"{'='*70}")
print(f"  標準生成總時間:     {total_standard:.2f}s")
print(f"  推測性解碼總時間:   {total_spec:.2f}s")
print(f"  整體加速比:         {total_standard/total_spec:.2f}x")
print(f"{'='*70}")
print(f"\n★ 關鍵觀察:")
print(f"  • 輸出與標準生成在數學上完全等價（零精度損失）")
print(f"  • 加速效果取決於草稿模型的「命中率」")
print(f"  • 草稿模型越接近目標模型的分佈 → 加速越明顯")
print(f"  • 同家族模型（如 OPT-125M → OPT-1.3B）效果最好")
print(f"  • HuggingFace Transformers v4.29+ 原生支援")
print(f"  • 可與量化疊加：4-bit 目標模型 + 小型草稿模型")

七、Hands-on Lab：DeepCache + ToMe（擴散模型加速）

最後，我們將兩種動態計算技術——DeepCache（特徵快取）和 ToMe（token 合併）——疊加在 Stable Diffusion 上，體驗「免訓練」加速的威力。

打開 Google Colab（選 T4 GPU），新建 Notebook，依序貼入以下程式碼：

7.1 Step 1 — 環境設定

!pip install diffusers transformers accelerate DeepCache tomesd -q

import torch
import time
from diffusers import StableDiffusionPipeline

# 載入 Stable Diffusion 1.5
pipe = StableDiffusionPipeline.from_pretrained(
    "runwayml/stable-diffusion-v1-5",
    torch_dtype=torch.float16,
    safety_checker=None,
)
pipe = pipe.to("cuda")

prompt = "a photorealistic mountain landscape at golden hour, 8k detailed"
gen = torch.Generator("cuda").manual_seed(42)

print("✓ Stable Diffusion 1.5 載入完成")
print(f"  VRAM 使用: {torch.cuda.memory_allocated()/1024**3:.2f} GB")

7.2 Step 2 — 基準生成

# ---- 基準：標準 50 步生成 ----
gen = torch.Generator("cuda").manual_seed(42)
torch.cuda.synchronize()
start = time.perf_counter()
image_base = pipe(prompt, num_inference_steps=50, generator=gen).images[0]
torch.cuda.synchronize()
base_time = time.perf_counter() - start

print(f"基準（50 步標準生成）: {base_time:.2f}s")
image_base.save("01_baseline.png")

7.3 Step 3 — DeepCache 加速

from DeepCache import DeepCacheSDHelper

# ★ DeepCache：快取高層 U-Net 特徵 ★
helper = DeepCacheSDHelper(pipe=pipe)
helper.set_params(
    cache_interval=3,    # 每 3 步才完整計算一次 U-Net
    cache_branch_id=0,   # 快取哪一層的特徵
)
helper.enable()

gen = torch.Generator("cuda").manual_seed(42)
torch.cuda.synchronize()
start = time.perf_counter()
image_dc = pipe(prompt, num_inference_steps=50, generator=gen).images[0]
torch.cuda.synchronize()
dc_time = time.perf_counter() - start

helper.disable()
print(f"DeepCache（interval=3）: {dc_time:.2f}s (加速 {base_time/dc_time:.2f}x)")
image_dc.save("02_deepcache.png")

7.4 Step 4 — ToMe 加速

import tomesd

# ★ ToMe：合併冗餘 token ★
tomesd.apply_patch(pipe, ratio=0.5)  # 合併 50% 的 token

gen = torch.Generator("cuda").manual_seed(42)
torch.cuda.synchronize()
start = time.perf_counter()
image_tome = pipe(prompt, num_inference_steps=50, generator=gen).images[0]
torch.cuda.synchronize()
tome_time = time.perf_counter() - start

tomesd.remove_patch(pipe)
print(f"ToMe（ratio=0.5）: {tome_time:.2f}s (加速 {base_time/tome_time:.2f}x)")
image_tome.save("03_tome.png")

7.5 Step 5 — DeepCache + ToMe 疊加

# ★ 兩者疊加：DeepCache + ToMe ★
tomesd.apply_patch(pipe, ratio=0.5)
helper = DeepCacheSDHelper(pipe=pipe)
helper.set_params(cache_interval=3, cache_branch_id=0)
helper.enable()

gen = torch.Generator("cuda").manual_seed(42)
torch.cuda.synchronize()
start = time.perf_counter()
image_both = pipe(prompt, num_inference_steps=50, generator=gen).images[0]
torch.cuda.synchronize()
both_time = time.perf_counter() - start

helper.disable()
tomesd.remove_patch(pipe)
print(f"DeepCache + ToMe: {both_time:.2f}s (加速 {base_time/both_time:.2f}x)")
image_both.save("04_deepcache_tome.png")

7.6 Step 6 — 完整比較

print(f"\n{'='*60}")
print(f"  擴散模型動態加速完整比較")
print(f"  Stable Diffusion 1.5 / 50 步 / T4 GPU")
print(f"{'='*60}")
print(f"{'方法':<20} {'時間(s)':<10} {'加速比':<8} {'需要訓練？'}")
print(f"{'-'*60}")

results = [
    ("標準（基準）", base_time, 1.0, "—"),
    ("DeepCache", dc_time, base_time/dc_time, "否"),
    ("ToMe (50%)", tome_time, base_time/tome_time, "否"),
    ("DeepCache + ToMe", both_time, base_time/both_time, "否"),
]

for name, t, speedup, train in results:
    print(f"{name:<20} {t:<9.2f} {speedup:<7.2f}x {train}")

print(f"{'='*60}")
print(f"\n★ 關鍵觀察:")
print(f"  • 兩種技術都完全免訓練——即裝即用")
print(f"  • DeepCache 和 ToMe 加速效果可以疊加")
print(f"  • 再加上 INT8 量化，總加速可超過 5x")
print(f"  • 生成的圖片請在檔案中比較品質差異（通常肉眼不可辨）")
print(f"  • 這些技術同樣適用於 SDXL 和 Stable Video Diffusion")

八、生態系工具全景

動態計算的工具生態正在快速成熟，從研究原型到生產部署都有對應方案：

Mixture of Experts 框架

• vLLM（GitHub）：高效 LLM 推論引擎，原生支援 Mixtral、DeepSeek-V3 等 MoE 模型，PagedAttention + tensor parallelism
• SGLang（GitHub）：由 LMSYS 團隊開發，RadixAttention 共享前綴快取，MoE 專家平行化
• MegaBlocks（GitHub）：Databricks 的高效 MoE 訓練框架，解決專家負載不均問題

Speculative Decoding

• HuggingFace Transformers^[17]（文件）：v4.29+ 原生 assistant_model 參數，最簡單的使用方式
• Medusa（GitHub）：多解碼頭推測解碼，不需獨立草稿模型
• EAGLE（GitHub）：基於特徵層的推測解碼，比 Medusa 更快（3x+ 加速）

Token Merging

• ToMe（GitHub）：Meta Research，pip install tome，一行套用至 timm ViT 模型
• tomesd^[14]（GitHub）：pip install tomesd，一行套用至 Stable Diffusion pipeline

擴散模型加速

• DeepCache^[18]（GitHub / PyPI）：pip install DeepCache，U-Net 特徵快取，支援 SD / SDXL / SVD
• HuggingFace Diffusers（文件）：DeepCache 整合於 Diffusers 的優化文件中
• PAB（Pyramid Attention Broadcast）（GitHub）：針對影片生成（如 Open-Sora）的注意力快取加速

九、從技術指標到商業影響

動態計算對企業 AI 部署的影響是多維度的：

• 推論成本直降 60-80%：MoE 模型只啟動部分參數，推測性解碼讓大模型以小模型的速度服務。對於每月百萬級 API 呼叫的企業，這意味著數十萬美元的直接節省
• 延遲降至半數以下：推測性解碼 2-3x、Token Merging 2x、DeepCache 2.3x。對話式 AI 的回應延遲從可察覺降到即時
• 不犧牲品質：與靜態壓縮不同，推測性解碼保證零精度損失，MoE 在同等算力下反而更強。這消除了「加速 = 降質」的傳統顧慮
• 與其他技術完全相容：動態計算可以疊加在量化（INT4/INT8）、剪枝、蒸餾之上。一個 4-bit 量化的 MoE 模型 + 推測性解碼，可以實現 10x+ 的端到端效率提升
• 硬體門檻大降：DeepSeek-V3 的 671B 模型以 MoE 架構讓推論成本接近 40B 密集模型；DeepCache + ToMe 讓 SD 在中階 GPU 上接近即時生成
• 永續 AI：條件式計算的本質是「不浪費算力在不需要的地方」。Harvard Business Review^[1] 指出，這類計算效率的提升是控制 AI 碳足跡最直接的手段

十、導入路徑：三階段落地策略

1. 立即見效——使用現有動態計算模型與工具：部署 Mixtral 8x7B 或 DeepSeek-V3 作為 LLM 推論後端（通過 vLLM/SGLang）；圖片生成加上 tomesd + DeepCache（兩行程式碼，免訓練）。這些操作不需要任何模型修改，可在一天內完成
2. 小步驗證——推測性解碼提速現有模型：為你現有的 LLM 配一個同家族的小型草稿模型（如 Phi-3-mini 配 Phi-3-small），用 HuggingFace 的 assistant_model 參數啟用推測性解碼。測量延遲下降與輸出一致性，確認適合你的使用場景
3. 深度優化——全棧動態計算整合：考慮 Medusa 或 EAGLE 替代標準推測性解碼（更高加速）；評估 MoE 微調（如在 Mixtral 上用 LoRA 微調特定專家）；將動態計算與量化、剪枝結合，建立完整的推論效率棧。圖片生成管線中疊加 DeepCache + ToMe + INT8 量化，目標 5x+ 端到端加速

動態計算是模型效率的「第四根支柱」——它不改變模型的大小或精度，而是讓模型學會「看情況出力」。與剪枝（永久移除參數）、蒸餾（訓練新模型）、量化（降低精度）不同，動態計算讓模型保留完整能力，只是更聰明地分配計算資源。這四種技術完全正交、可以疊加，共同構成了 AI 從實驗室走向大規模部署的完整工具箱。

如果您的團隊正在評估如何在不犧牲模型品質的前提下大幅降低推論成本，或需要在延遲敏感場景中加速大模型回應，歡迎與我們進行深度技術對話。超智諮詢的研究團隊能夠陪伴您走完從效能瓶頸診斷到全棧優化部署的完整旅程。