> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 優先費用與計算預算

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

<Info>
  **本頁內容由 AI 自動翻譯，所有內容以英文版本為準。**

  [查看英文版 →](/integration-guides/priority-fee-tuning)
</Info>

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

## 兩個設定

```ts theme={null}
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 提供商都會發布一個優先費用估算器，查詢特定帳戶上的最近費用：

```ts theme={null}
// 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：

```ts theme={null}
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`。

診斷：

```bash theme={null}
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`](/zh-Hant/integration-guides/routing-and-mev)。套件繞過公開封包佇列。

重試邏輯骨架：

```ts theme={null}
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`](/zh-Hant/integration-guides/routing-and-mev) — Jito 套件策略。
* [`integration-guides/aggregator`](/zh-Hant/integration-guides/aggregator) — 交易組裝。
* [`integration-guides/cpi-integration`](/zh-Hant/integration-guides/cpi-integration) — 跨組合 CPI 的 CU 堆疊。
* [Solana 計算預算程式文件](https://docs.solana.com/developing/programming-model/runtime#compute-budget)

來源：

* [Solana `getRecentPrioritizationFees` RPC](https://docs.solana.com/api/http#getrecentprioritizationfees)
* [Helius 優先費用 API](https://docs.helius.dev/solana-apis/priority-fee-api)
* 基準：主網執行日誌（Raydium SDK 整合測試，2026 年 4 月）。