優先費用與計算預算

本頁內容由 AI 自動翻譯，所有內容以英文版本為準。查看英文版 →

每筆 Solana 交易都會設定（隱式或顯式）兩個參數：計算單位上限（交易可能消耗的最大 CU；預設為指令數 × 200,000，有每筆交易上限）和優先費用（每 CU 的微 lamports）。如果任一參數設定不足會導致交易失敗——CU 上限太低會拋出 ProgramFailedToComplete；優先費用太低會導致交易未確認直到過期。

兩個設定

import { ComputeBudgetProgram } from "@solana/web3.js";

const tx = new Transaction()
  .add(ComputeBudgetProgram.setComputeUnitLimit({ units: 250_000 }))
  .add(ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 50_000 }))
  .add(yourRaydiumSwapIx);

setComputeUnitLimit(units) — 限制計算量；交易最多支付 units CU。
setComputeUnitPrice(microLamports) — 優先費用出價，單位為每 CU 的微 lamports。總優先費用 = units × microLamports × 1e-6 lamports。

成本計算：250k CU 上限、50k 微 lamports/CU 的出價為 250_000 × 50_000 / 1e6 = 12,500 lamports ≈ 0.0000125 SOL ≈ $200 SOL 時的 $0.003。對於大多數用戶交換，此規模的優先費用影響不大，但對於每天執行 1000 筆交易的機器人來說則相當可觀。

每個指令的 CU 基準

基準來自主網執行日誌，平均最近運行結果。數字是近似值（±15%）；針對特定流程重新測量。

指令	SPL Token	Token-2022（簡單）	Token-2022（轉帳費）
CPMM initialize_pool	180,000	200,000	—
CPMM swap_base_input	140,000	180,000	200,000
CPMM swap_base_output	150,000	185,000	205,000
CPMM deposit	130,000	160,000	180,000
CPMM withdraw	120,000	150,000	170,000
CLMM create_pool	70,000	85,000	—
CLMM open_position_v2	120,000	140,000	160,000
CLMM increase_liquidity_v2	150,000	175,000	195,000
CLMM decrease_liquidity_v2	140,000	165,000	185,000
CLMM swap_v2（0 tick 穿越）	170,000	205,000	225,000
CLMM swap_v2（1 tick 穿越）	220,000	255,000	275,000
CLMM swap_v2（3 tick 穿越）	320,000	355,000	375,000
CLMM collect_fee	80,000	95,000	105,000
AMM v4 swap_base_in	140,000	—	—
AMM v4 deposit	120,000	—	—
AMM v4 withdraw	110,000	—	—
Farm v6 create_farm	70,000	85,000	—
Farm v6 deposit（1 獎勵槽）	130,000	155,000	175,000
Farm v6 deposit（3 獎勵槽）	220,000	255,000	275,000
Farm v6 withdraw	與 deposit 相同
Farm v6 harvest	與 deposit 相同
Farm v3/v5 deposit	100,000	—	—
LaunchLab initialize	100,000	—	—
LaunchLab buy_exact_in	140,000	—	—
LaunchLab graduate	250,000	—	—

CLMM 的「tick 穿越」行是最大的 CU 變數。如果你不知道交換將穿越多少 tick，就預算最壞情況——8 個穿越是硬上限（程式最多載入 8 個 tick 陣列）。

組合交易

將各個預算相加，並添加：

每個 CPI 框架 +1,500 CU — 運行時對每個跨程式呼叫的固定開銷。
每個 ATA 建立 +20,000 CU — create_associated_token_account 不是免費的。
setComputeUnitLimit / setComputeUnitPrice 各 +5,000 CU。

範例：建立輸出 ATA 並包裝原生 SOL 的用戶交換：

wrap_sol (create_ata + system transfer + sync_native)   ≈ 30,000
CPMM swap_base_input (SPL)                              ≈ 140,000
close_account (unwrap)                                  ≈ 5,000
ComputeBudget instructions                              ≈ 10,000
────────────────────────────────────────────────────────
Total                                                   ≈ 185,000 → budget 250,000

填充：將 CU 上限設定為預期使用量的 ~25% 以上。低估成本會導致整個交易失敗；高估只會按比例提高優先費用成本（優先費用是 units × microLamports，所以 ~25% 高於預算會額外花費 25% 的優先費用）。

優先費用估算

Solana 的本地費用市場意味著優先費用是每個可寫帳戶的。寫入熱帳戶（熱門池狀態）的交易支付的費用比寫入冷帳戶的多。全域費用水準不是 Raydium 交換的正確指標；你想要的是針對你接觸之特定池的費用。

策略 1：RPC 提供商估算器

每個主要 RPC 提供商都會發布一個優先費用估算器，查詢特定帳戶上的最近費用：

// Helius
const response = await fetch(`https://mainnet.helius-rpc.com/?api-key=${apiKey}`, {
  method: "POST",
  body: JSON.stringify({
    jsonrpc: "2.0",
    id:      "fee-estimate",
    method:  "getPriorityFeeEstimate",
    params: [{
      accountKeys: [poolStatePubkey.toBase58()],
      options:     { priorityLevel: "High" },
    }],
  }),
});
const { result } = await response.json();
const microLamports = result.priorityFeeEstimate;

大多數提供商的優先級：Min / Low / Medium / High / VeryHigh / UnsafeMax。將它們映射到百分位：

級別	百分位	用途
Min	第 25 百分位	背景、非緊急機器人流量
Low	第 50 百分位	正常用戶交換
Medium	第 60 百分位	錢包 UI 的預設值
High	第 75 百分位	時間敏感的套利
VeryHigh	第 95 百分位	清算、最後機會出場

提供商：Helius（getPriorityFeeEstimate）、Triton（getRecentPrioritizationFees 含帳戶清單）、QuickNode（類似）。

策略 2：直接 RPC 查詢

使用標準 getRecentPrioritizationFees RPC：

const fees = await connection.getRecentPrioritizationFees({
  lockedWritableAccounts: [poolStatePubkey],
});

// fees: Array<{ slot, prioritizationFee }>
// 最近 N 個 slot；預設 ~150 個 slot。

const median = percentile(fees.map(f => f.prioritizationFee), 0.5);

這是 vanilla Solana RPC 方法；適用於任何提供商。缺點：樣本很小（150 個 slot ≈ 60 秒）且噪訊大。要獲得更平滑的估計，使用提供商的聚合。

策略 3：歷史自調整

對於執行恆定流量的機器人，追蹤你自己的著陸與過期率：

每個池目標：在 <30s 內達到 80% 著陸率
if current_land_rate < 80%: priorityFee += 10%
if current_land_rate > 95%: priorityFee -= 5%

這比公開估算器更快地自我修正，並捕捉公開估算器不總是看到的每個池的結構。

處理 CU 耗盡失敗

症狀：交易失敗，出現 exceeded maximum number of instructions allowed (200000) 或 ProgramFailedToComplete。診斷：

solana confirm <tx-sig> -v
# 查找「consumed N of M compute units」以及哪個指令耗盡。

修復：

提高 CU 上限。 如果交易使用了 200k 預算中的 195k，升級到 300k。
分割交易。 如果達到 1.4M 每筆交易上限，拆分為兩筆交易。當獎勵很多時，Farm 的「harvest then stake」是經典的分割案例。
修剪帳戶。 每個額外的可寫帳戶增加 ~2,000 CU。修剪未使用的帳戶有助於邊界情況。
使用查詢表。 LUT 查詢約為 ~50 CU 每個已解析位址，為每個條目節省 5,000 CU 的完整帳戶參考。

處理卡住的交易

症狀：交易已提交，從不確認，最終以 BlockhashNotFound 過期。診斷：

getSignatureStatuses([sig]) 返回 null → 領導者從未看到它。
返回 { confirmationStatus: null } → 領導者看到它但未包含。

修復：

提高優先費用。 以 2 倍的當前費用重新提交。
使用新 blockhash 重建。 Blockhash 生命週期 ~60 秒；超過該時間，無論費用如何，交易都無效。
多 RPC 廣播。 某些 RPC 與領導者的連接比其他更好。並行提交到 3–5 個。
切換到 Jito 套件。 參見 integration-guides/routing-and-mev。套件繞過公開封包佇列。

重試邏輯骨架：

async function submitWithRetry(buildTx, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const tx = await buildTx({
      priorityFee: basePriorityFee * Math.pow(1.5, attempt),
      blockhash:   (await connection.getLatestBlockhash()).blockhash,
    });

    try {
      const sig = await connection.sendRawTransaction(tx.serialize(), {
        skipPreflight: attempt > 0,  // skip after first try to save latency
      });

      const result = await connection.confirmTransaction(sig, "confirmed");
      if (result.value.err) {
        // Logic error; don't retry.
        throw result.value.err;
      }
      return sig;

    } catch (e) {
      if (isExpiredError(e)) continue;  // retry
      if (isRevertError(e)) throw e;    // don't retry; deterministic failure
      throw e;
    }
  }
  throw new Error("submit: exhausted retries");
}

擁堵情況下

當網路擁堵（Jupiter / Jito 套件儀表板顯示積壓、RPC 延遲尖峰、交易過期率攀升），調整：

參數	正常情況	擁堵情況
CU 上限	預估值上方 +25%	預估值上方 +25%（無變化）
優先費用百分位	第 50 百分位	第 75–95 百分位
重試計數	3	5–7
重試退避	500ms	1000ms
使用 Jito 套件	可選	強烈建議
重試時刷新 blockhash	是	是，強制

監視擁堵信號：

優先費用第 75 百分位 > 500k 微 lamports：擁堵。
Jito 第 50 百分位小費 > 0.001 SOL：擁堵。
RPC 回應 p99 > 2s：RPC 特定問題或擁堵。

機器人的費用預算

每天執行 ~1000 筆交易的交易機器人需要優先費用預算。粗略估計：

平均 CU 每筆交易：          ~250,000
第 50 百分位費用：        ~20,000 微 lamports/CU
每筆交易成本：                250_000 × 20_000 × 1e-6 = 5_000 lamports = 5e-6 SOL
每日成本（1000 筆交易）：       5e-3 SOL ≈ $200 SOL 時的 $1
每月成本：               ~$30

這是最低限度。在擁堵期間，乘以 5–10 倍。為穩定流量機器人計劃 ~$150–300/月的優先費用。必須在特定 slot 著陸的機器人（清算、套利）持續支付第 95 百分位，支出 ~10 倍以上。在該規模，Jito 套件小費佔主導——通常 $1000+/月——但替代方案（被搶先或過期）更糟。

陷阱

1. 遺忘 CU 上限

預設是 200k CU × （交易中的指令）。單個指令交換預設為 200k；這對 CPMM on SPL Token 足夠，但對於 CLMM with tick 穿越或任何 Token-2022 則不足。總是明確設定它。

2. 在錯誤的帳戶上設定優先費用

如果你根據 token 鑄造估算優先費用，但熱帳戶是池狀態，估算太低。池狀態是針對 Raydium 的正確可寫帳戶目標。

3. 費用隨 CU 上限縮放

total_priority_fee = units × microLamports。在 50k 微 lamports/CU 時將 units 從 200k 提高到 1M 會使優先費用乘以 5 倍。不要只是為了以防萬一而高估 CU；測量。

4. 預設交易版本

舊版交易有較低的帳戶限制；V0 交易帶有位址查詢表解鎖更大的路由。SDK 在 txVersion: TxVersion.V0 中預設使用 V0。除非需要錢包相容性，否則不要降級為舊版。

5. `skipPreflight` 隱藏 CU 錯誤

skipPreflight: true 發送交易而不進行本地模擬。你節省 ~100ms，但失去 CU 耗盡的早期反饋。僅在重試時使用，不在首次嘗試時使用。

指標

integration-guides/routing-and-mev — Jito 套件策略。
integration-guides/aggregator — 交易組裝。
integration-guides/cpi-integration — 跨組合 CPI 的 CU 堆疊。
Solana 計算預算程式文件

來源：

Solana getRecentPrioritizationFees RPC
Helius 優先費用 API
基準：主網執行日誌（Raydium SDK 整合測試，2026 年 4 月）。

Solana 基礎

快速開始

SDK 與 API

整合指南

優先費用與計算預算

兩個設定

每個指令的 CU 基準

組合交易

優先費用估算

策略 1：RPC 提供商估算器

策略 2：直接 RPC 查詢

策略 3：歷史自調整

處理 CU 耗盡失敗

處理卡住的交易

擁堵情況下

機器人的費用預算

陷阱

1. 遺忘 CU 上限

2. 在錯誤的帳戶上設定優先費用

3. 費用隨 CU 上限縮放

4. 預設交易版本

5. `skipPreflight` 隱藏 CU 錯誤

指標

Solana 基礎

快速開始

SDK 與 API

整合指南

Documentation Index

​兩個設定

​每個指令的 CU 基準

​組合交易

​優先費用估算

​策略 1：RPC 提供商估算器

​策略 2：直接 RPC 查詢

​策略 3：歷史自調整

​處理 CU 耗盡失敗

​處理卡住的交易

​擁堵情況下

​機器人的費用預算

​陷阱

​1. 遺忘 CU 上限

​2. 在錯誤的帳戶上設定優先費用

​3. 費用隨 CU 上限縮放

​4. 預設交易版本

​5. skipPreflight 隱藏 CU 錯誤

​指標

兩個設定

每個指令的 CU 基準

組合交易

優先費用估算

策略 1：RPC 提供商估算器

策略 2：直接 RPC 查詢

策略 3：歷史自調整

處理 CU 耗盡失敗

處理卡住的交易

擁堵情況下

機器人的費用預算

陷阱

1. 遺忘 CU 上限

2. 在錯誤的帳戶上設定優先費用

3. 費用隨 CU 上限縮放

4. 預設交易版本

5. `skipPreflight` 隱藏 CU 錯誤

指標