優先費用與計算預算

為 Raydium 交易調整計算單位上限與優先費用——各指令基準、估算策略與擁堵處理模式。

本頁內容由 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」以及哪個指令耗盡。

修復：

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

​

處理卡住的交易

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

診斷：

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

修復：

1. 提高優先費用。 以 2 倍的當前費用重新提交。
2. 使用新 blockhash 重建。 Blockhash 生命週期 ~60 秒；超過該時間，無論費用如何，交易都無效。
3. 多 RPC 廣播。 某些 RPC 與領導者的連接比其他更好。並行提交到 3–5 個。
4. 切換到 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 月）。