Vercel Data Cache 將轉 Runtime Cache：不用改程式，為何仍要先算讀寫費用？
Vercel Runtime Cache 將承接 Data Cache 讀寫。看懂新舊團隊遷移時間、每八 KB 計費單位、免費額度與代理唯讀檢查，避免關快取反增來源負擔。
Runtime Cache 將承接 Vercel 既有 Data Cache，對使用 Next.js 的團隊而言，程式沒有改，雲端計費卻可能改變。這次要看的不只是效能宣傳，而是原本未計費的讀寫，何時會納入帳單。
Vercel 在 10 月 30 日宣布 Data Cache 結束測試並併入新機制。原有 fetch 快取與 unstable_cache 會改由同一套執行期快取承接，所有 Next.js 版本都不需要為此修改程式。
快取是把可重複利用的資料放在程式執行區域附近，減少每次都查來源資料。這次不是首次推出快取服務，而是既有 Next.js 資料快取的遷移、儲存範圍與計費改變。
新建團隊自 10 月 30 日起使用新機制。既有 Hobby 團隊預計 11 月 29 日遷移，Pro 會另外收到日期通知，Enterprise 由客戶團隊聯絡。若既有團隊提早加入，新計價會立即適用。
更容易算錯的是單位：儀表板看到的讀取次數，不一定等於帳單上的讀取單位。每八 KB 向上計一單位，一筆很大的資料，讀一次就可能花掉多個單位。
因此，準備遷移的第一步，是理解自己的快取在替哪些請求省事，又在累積多少單位。兩邊對起來，才能決定該減少重複讀寫、調整快取時間，還是保留現有做法。
Runtime Cache 不用改程式，也要先確認遷移時間
這次遷移保留既有程式呼叫方式，但不代表所有團隊同一天開始用新帳務。10 月 30 日是新建團隊的分界，既有團隊則依方案安排。
Hobby 的既定日期是 11 月 29 日，Pro 會收到自己的遷移日與帳務生效通知，Enterprise 則由客戶團隊聯絡。讀到公告時，應先辨認自己是新團隊還是既有團隊。
既有 Hobby、Pro 團隊也能從團隊的 CDN 設定提早加入。CDN 是讓內容靠近使用者傳遞的網路，這裡只是設定所在位置，不能因為從 CDN 選單操作，就把資料快取和整頁快取當成同一層。
提早加入後，新計價立即適用。所以如果只是想先看資料，不需要把加入新機制當成查看用量的必要前置動作，應先取得自己的讀寫紀錄。
官方提到 Pro 每個專案、每個環境獲得獨立儲存配置，容量相較原本團隊共享的 Data Cache 增加八倍，Enterprise 則是十倍。這些倍數指儲存空間，不是免費額度或讀取速度。
Hobby 仍由團隊內的專案共用快取，因此其中一個專案大量寫入，仍可能影響其他專案可留住的內容。升級後有哪些範圍獨立，必須按方案分開看。
程式相容降低了搬遷工作，但日期、儲存範圍與費用仍會改變。先把生效點確認，才有辦法用遷移前的用量估算後續影響。
讀一次不等於一單位：先把八 KB 的算法算對
Runtime Cache 計的是每筆讀寫的資料單位，而不只是操作次數。官方文件以八 KB 為一單位，每次操作分別向上取整，不能先平均所有大小再計算。
一筆一 KB 的資料讀一次，仍算一個單位。一筆一百 KB 的資料則算十三個單位，因為十二個單位只涵蓋九十六 KB，剩下部分也要再計一個。
假設一百萬次讀取，資料每次都是一 KB，就約是一百萬個讀取單位。若每次都是一百 KB，相同操作次數就變成一千三百萬個單位。這是純假設的算術，不是任何讀者的實際用量。
混合大小時，更要逐筆計算。假設各有一筆一 KB 與十五 KB，分別是一個與兩個單位，合計三個。把十六 KB 總量直接除以八，只算成兩個，就忽略了每次操作獨立取整。
公告列出讀取起價每百萬單位 0.40 美元、寫入起價每百萬單位四美元，實際依區域不同。相同單位數下，寫入的費用級距與讀取有明顯差別，不能只比較兩種操作各有幾次。
Hobby 每月包含一百萬讀取、二十萬寫入單位，計算範圍是團隊的所有專案。Pro 則從每月二十美元的基礎設施額度扣抵，超出後按區域費率計價。
這二十美元是方案的基礎設施額度，不應被當成另外贈送、只限快取使用的一筆錢。團隊估算時，還得一起看其他基礎設施資源已使用多少。
官方文件列出的各區域範圍為讀取每百萬單位 0.40 至 0.64 美元、寫入四至 6.40 美元。Enterprise 價格另外確認，不能把起價套到每個地區與合約。
Hobby 超過額度後不會因此收取超額費，而是暫停當期剩餘時間的快取。免費不等於沒有運作影響，來源資料服務仍要能承受快取暫停後的請求。
快取命中愈高，不代表每張圖表都能直接比較
看懂費用之後，還要知道哪些請求與程式路徑產生讀寫。官方的 Usage 介面以計費單位呈現，Observability 則會顯示操作次數，兩者回答的問題不同。
可觀測性可以理解為從紀錄與量測追查程式正在做什麼。只看到操作次數增加，還不能知道是流量變多、每個請求讀太多次，或每筆資料變大。
若次數相近、單位卻上升，資料大小是值得先看的原因。若次數跟網站流量一起增加，則可能是更多請求帶動使用量，不能直接指控某一段程式重複呼叫。
命中率也有不同分母
官方文件指出，命中率圖表只計新鮮命中，項目與標籤表格的命中率則納入沒有完全落空的讀取，包括過期或重新驗證的情況。同一段時間看到不同百分比，不一定表示數據出錯。
因此，比較前後變化時，要固定專案、部署環境與相同長度的時窗，再使用同一張圖表的口徑。拿本週表格的數字和上週圖表對照，可能把定義差異誤判成改善。
函式呼叫次數也不是全部快取活動的分母。建置期間的資料讀取，可以產生讀寫而不對應一次執行期函式呼叫，部署日的變化要另外辨認。
假設網站流量沒變，但每次部署都出現讀寫高峰，就應先看建置流程。若流量穩定而每次請求平均讀取增加，才比較像某次改版加入更多資料呼叫。
把同一專案、環境與時窗的數據對起來，才有辦法把用量連回具體改動。這比只盯著一個總額，更能指出應先檢查哪段程式。
遷移、重新部署與資料過期，是三種變化
快取何時失效，不能只用一句「部署後會不會保留」回答。資料可能因期限到期需要更新，也可能仍在儲存中，卻因新版本使用不同鍵值而無法讀到。
鍵值可以理解為查找某筆快取的索引。如果每次請求都拿不同索引，就算內容一樣，程式也可能一直找不到可重用資料，反覆向來源查詢並寫入。
這次遷移時，官方會從實際流量重新填入原有 fetch、unstable_cache 與 use cache: remote 的項目，因此初期可能有更多落空與後端請求。透過 getCache 寫入的項目則保留。
另一方面，一般新部署不會直接清掉底層儲存，但 Next.js 16 的 use cache: remote 目前把建置或部署識別放進鍵值，新版本就讀不到前一版的那些項目。
使用 fetch、unstable_cache，或自行控制 getCache 鍵值，則有不同的跨部署行為。因此，看到部署後重新查資料，應先確認用的是哪個介面，而不是一律認定平台已清空快取。
資料存在也不代表必定留到設定期限。這是區域性、非耐久的快取，空間不足時會優先移除較久沒被讀取的內容，不能拿來代替唯一資料庫。
如果程式改了保留時間或標籤，也不能一律假設舊項目會自動依新設定重整。官方提醒，部署之間的期限與標籤更新不會彼此協調，需要更新行為時，應明確考慮清除或改用新鍵值，並評估重新填入造成的來源請求。
各區域有各自快取，正式與預覽環境也分開。來源服務如何準備流量，要連同程式執行區域與環境安排一起看，不能假設一個地方已暖好，其他地方就都有資料。
因此，先分清資料被移除、鍵值改變與遷移重填，才能解釋後端流量為何短暫上升。這些原因不同，應採取的處理方式也不同。
讓代理先找重複讀寫，再決定怎麼改
Vercel 提供的最佳化提示詞，先要求代理唯讀檢查程式與用量，不能自行改設定、清快取或部署。這讓調查和修改分成兩步，先提出可解釋的原因。
代理會先辨認 Next.js 版本。第十四版的某些一般 fetch 預設會快取，第十五版以後則要明確選用，所以相同一段查找方式，不能不分版本就判斷是否產生快取使用。
接著把繁忙的項目或標籤，連回程式檔案、呼叫位置、鍵值與更新時間。這一步能讓建議具體到某個來源，而不是只說「流量太高，請最佳化」。
重複呼叫是其中一種可能。例如在清單迴圈裡，每個項目都另外查資料並存快取，讀寫量就可能隨清單長度增長。是否能改成一次查整份清單，還要看資料大小與更新需求。
官方指引還特別區分重複呼叫：相同 fetch 在一次渲染中可以去重，但多次呼叫同一個 unstable_cache 輔助函式，不應直接假定有相同效果。若問題來自同一請求內反覆讀取，就要先檢查呼叫路徑，而不只提高保留時間。
快取鍵過於細碎也是另一種原因。若把每次不同的時間戳放進索引，就難以重用。若資料與使用者身分有關，則不能為了增加共用程度，就移除隔離使用者所需的條件。
資料更新時間太短，可能造成反覆重寫，但拉長時間又可能讓內容過期。商品庫存、權限與一般說明文字的容忍度不同，不能用同一個保留時間處理全部內容。
停用 fetch 與 unstable_cache 快取，也不會取消這次遷移。它會讓更多請求到資料來源，可能把原本的快取費用問題，轉成資料庫負擔或較長回應時間。
因此，每一項節省都要連回資料新鮮度和來源負擔，不能只追求儀表板數字下降。代理能幫忙追查，最後要改哪一項仍應依具體影響決定。
先做一個有前後對照的小修正
適合先改的，是能指出程式位置、用量原因與預期影響的那一項。如果讀寫增加有明確原因，就能在不改動所有快取的情況下，驗證一個假設。
例如把重複的列表資料查詢集中處理，仍要確認結果大小小於原來分散項目的負擔，也沒有超過單項兩 MB 的限制。這是假設的調整方向，不代表每個清單都應合併。
修改後比較相同長度的時窗，同時看每次請求的讀寫單位、命中率與來源請求。若快取讀取下降，資料庫請求卻大增，就還不能把改動說成整體成本改善。
另外，整頁 HTTP 回應和函式內取用的資料是不同快取層。資料在執行期快取更新，不能直接證明已經送到 CDN 的整頁回應也更新。若兩層一起使用，就要依各自的失效方式管理，才能讓讀者實際看到最新內容。
同樣地，只讓某次部署後的數字變好，也不足以證明日常流量下有效。要留意比較期間是否有不同流量、資料大小或部署頻率，避免把外部變化當成程式修正成果。
遷移準備做得好，代表費用與資料流量都能說明，而不是只把快取打開或關掉。當團隊知道每筆單位從哪裡來，新的帳務規則就比較容易轉成可管理的工程選擇。
延伸閱讀：Vercel Virtual Models 教學：同一個模型名稱，如何管理團隊 AI 設定？
延伸閱讀：【Vibe Coding】AI 生出網頁卻只能自己看？Vercel 免費部署完整教學指南
常見問題
Runtime Cache 從 10 月 30 日起，所有舊團隊都立即付費嗎？
不是。新團隊自該日起預設使用，既有團隊依方案時程遷移。Hobby 有免費配額，Pro 有基礎設施額度，提早加入的既有 Hobby、Pro 則會立即適用新計價。
關掉快取，就能取消遷移嗎？
官方明示不能。停用相關快取只會改變請求如何到資料來源，既定遷移仍會發生，所以應先評估來源負擔與回應時間。
能把它當成保證保留資料的儲存服務嗎？
不能。它是區域性、非耐久的快取，項目可能在期限前因空間壓力被移除。需要長期保存且不能遺失的資料，仍要放在適合的持久儲存系統。
如果你想追蹤 AI 開發工具與雲端部署如何影響實際成本，歡迎免費訂閱 AI 郵報。
