LLM 推論的可重現性策略

重點摘要

在 Zokforce，我們觀察到大型語言模型（LLM）的推論過程本質上就具有非確定性：即使提示詞完全相同，模型仍可能產生不同的輸出。刻意設計的隨機性有助於創意型任務，但正式環境中的系統，卻深受一種更深層、系統性的非確定性所困擾。

Thinking Machines Lab 等團隊的最新研究指出，傳統的「並行 + 浮點數」假說並不完整。根本原因在於缺乏「批次不變性」（batch invariance）——伺服器負載難以預測，迫使推論引擎動態調整批次大小，進而改變內部 kernel 的執行策略，導致輸出在位元層級出現差異。

關鍵區別：隨機性與非確定性

要理解 LLM 的非確定性，必須區分兩種隨機現象：

為何可重現性對企業至關重要

深入剖析：非確定性的來源

LLM 非確定性相同的提示詞，產生不同的輸出

影響高批次不變性問題批次大小動態變化，改變 kernel 的執行方式

影響中等浮點數運算的非結合性變異的載體，而非根本原因

可控內在隨機性隨機取樣：temperature、top_p 與 seed

造成 LLM 推論系統非確定性行為的三大主要來源

1. 批次不變性問題

正式環境中的 LLM 服務，會將多位使用者的請求打包成批次，以充分利用 GPU。核心問題在於：批次大小一改變，內部的 kernel 策略就會完全不同。

# Example: Same operation, different batch contexts
# Batch size = 4 users
result_1 = process_batch([user1, user2, user3, user4])

# Batch size = 1 user (different kernel strategy)
result_2 = process_batch([user1])

# Result: Different outputs for user1 due to kernel optimization differences

當批次太小、無法用滿所有 GPU 核心時，工程師會改用「分割歸約」（split-reduction）策略，由多個核心協同完成單一運算；這會改變運算順序，破壞批次不變性。

2. 浮點數運算的非結合性

浮點數運算雖然常被視為主因，但它其實只是變異得以顯現的載體。研究顯示，像 torch.mm(A, B) 這樣的單一運算，只要輸入相同，重複執行的結果都是確定的。

3. LLM 的內在隨機性

LLM 透過預測下一個 token 的機率分布來生成文字。主要有三種解碼策略控制這個生成過程：

多層次解決方案框架

第 1 層Kernel 與框架

• 批次不變的 kernel
• 確定性演算法
• 框架控制設定

第 2 層API 與應用程式

• Seed 參數
• Temperature = 0
• 結構化輸出

第 3 層提示工程

• 確定性提示詞
• 少樣本範例
• 負面提示

第 4 層MLOps 與工作流程

• 版本控制
• 快取層
• 環境紀錄

四個相互整合的層次協同運作，實現企業級的可重現性

第 1 層：kernel 與框架基礎

主要實作策略：

• RMSNorm：無論批次大小，歸約順序固定
• 矩陣乘法：kernel 組態固定，不受批次形狀影響
• 注意力機制：採用固定分割大小的分割歸約

各框架的確定性控制設定：

在不同框架中實作確定性控制的技術參考

第 2 層：API 與應用程式控制

第 3 層：卓越的提示工程

精心設計具確定性的提示詞，能有效縮小模型的輸出空間：

# Example: Deterministic Prompt Structure
prompt = f"""
Task: Extract key information from the following contract.
Output Format: JSON with fields: party1, party2, date, amount
Requirements: 
- Use exact text from document
- Return "N/A" if information not found
- No additional commentary

Contract: {contract_text}

JSON Response:
"""

第 4 層：MLOps 與工作流程管理

效能與可重現性的取捨

可重現性 ↑

1 2 3 4

效能 →

1

預設（非確定性）

2

批次不變 kernel

3

框架確定性模式

4

受控取樣

依效能影響與可重現性程度定位的各種做法

量化成本

實現確定性，需要付出可量化的效能代價：

企業導入指南

第 1 階段：評估與奠基（第 1-2 個月）

第 2 階段：實作與測試（第 3-6 個月）

# Example: PyTorch Deterministic Configuration
import torch
import os
import random
import numpy as np

def setup_deterministic_environment():
    # Set all random seeds
    torch.manual_seed(42)
    torch.cuda.manual_seed(42)
    torch.cuda.manual_seed_all(42)
    np.random.seed(42)
    random.seed(42)
    
    # Enable deterministic algorithms
    torch.use_deterministic_algorithms(True)
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark = False
    
    # CUDA environment variables
    os.environ['CUBLAS_WORKSPACE_CONFIG'] = ':16:8'
    os.environ['PYTHONHASHSEED'] = str(42)

第 3 階段：正式上線部署（第 6-9 個月）

真實案例研究

案例 1：金融服務業的文件處理

案例 2：醫療研究平台

未來展望與新興解決方案

新興技術

• 進階批次不變 kernel：在維持確定性的同時降低效能負擔
• 混合式做法：在確定性與非確定性模式之間動態切換
• 硬體加速：專為確定性 AI 推論最佳化的專用晶片
• 協定標準化：可重現 AI 部署的產業標準

參考文獻與延伸閱讀

1. Sitation.com，〈Output from AI LLMs is Non-Deterministic. What that means and why you should care.〉連結
2. AIMultiple Research，〈Reproducible AI: Why it Matters & How to Improve it.〉連結
3. StartupHub.ai，〈The Real Reason for LLM Inference Nondeterminism.〉連結
4. Thinking Machines Lab，〈Defeating Nondeterminism in LLM Inference.〉，刊載於 Medium。
5. Microsoft Azure，〈How to generate reproducible output with Azure OpenAI.〉連結
6. PyTorch 官方文件，〈Reproducibility Guidelines.〉連結
7. Hugging Face，〈Reproducible pipelines documentation.〉連結
8. NVIDIA GTC 2024，〈Restoring the Scientific Method to HPC: High Performance Reproducible Parallel Reductions.〉