遊戲串流的延遲預算：為什麼雲端遊戲永遠追不上本地
很多人以為雲端延遲高，是因為「伺服器不夠快」或「編碼沒優化好」。這種說法只對了一半。雲端串流的延遲可以分成兩大類：可控延遲（編碼、解碼、排程、伺服器運算）與不可控延遲（光速傳播、路由繞路、家用網路抖動）。可控的那一半，工程師確實可以逐年壓縮；但不可控的那一半，是宇宙的常數，你只能選擇「接受」或「縮短距離」，沒有第三條路。
光速不是無限的：跨越半個地球的代價
光在真空中的速度約為每秒 299,792 公里，但在光纖中，由於玻璃的折射率（約 1.47），實際傳播速度大約是每秒 20 萬公里左右。這意味著，光纖每公里大約需要 5 微秒。聽起來微不足道，但累積起來就很可觀。
假設你住在台北，而你連上的雲端機房位於美國西岸（這是許多國際雲遊戲服務的實際情況）。台北到洛杉磯的直線距離約為 10,900 公里，光纖路徑不會是直線，通常要走海底電纜，實際路徑可能拉長到 13,000～15,000 公里。單趟的理論下限就是 13,000 × 5μs ≈ 65ms。而串流需要「去程」與「回程」：使用者的輸入要傳到機房，機房的畫面要傳回使用者。來回一趟就是 130ms 起跳，而且這還是「光纖以直線鋪設、中間零延遲」的理論值。現實中的路由跳轉、交換機排隊、海底電纜的節點，會再往上加 30～80ms。
換句話說，光是「距離」這一項，就足以讓跨洲的雲端遊戲延遲突破 150ms，而這個數字已經遠遠超過多數動作遊戲的體感容忍上限。這不是誰的錯，這就是地球的尺寸。
編碼、傳輸、解碼：三個無法完全消除的環節
除了距離，雲端串流還多了一組本地遊戲完全沒有的環節：視訊編碼與解碼。流程如下：伺服器端的 GPU 渲染出畫面後，必須先由硬體編碼器（如 NVENC、AMD VCN）壓縮成 H.264 / H.265 / AV1 串流，經由網路送出；使用者的裝置收到後，再由解碼器還原成畫面顯示。
這一段的延遲有多長？以目前主流的低延遲編碼設定來說，伺服器端編碼約 5～15ms，客戶端解碼約 3～10ms，再加上緩衝佇列（jitter buffer）為了對抗網路抖動而預留的 10～30ms，總共就是 20～50ms 的額外開銷。而且這個開銷有個討厭的特性：它跟畫質是互相拉扯的。你要更低的延遲，就得犧牲壓縮率、拉高比特率；你要更好的畫質，就得接受更長的編碼時間或更大的緩衝。這是一個無法同時滿足兩端的取捨。
家用網路與最後一哩的隱形損耗
還有一個經常被忽略的環節：你的家用網路。從你的電腦或主機到電信機房之間，可能經過 Wi-Fi 路由器、交換器、數據機、社區網路、光纖轉換器。Wi-Fi 的空中傳輸本身就有 2～10ms 的排程延遲，如果訊號不好、頻道擁擠，抖動可以高達 50ms 以上。有線乙太網路雖然穩定，但家用路由器的 NAT、防火牆、QoS 排程也會貢獻幾毫秒。
把這些全部加總，你就會得到一個殘酷的結論：雲端串流的延遲預算，天生就比本地多出一整條「網路鏈路」的開銷。而這條鏈路中，距離與光速是無法用軟體優化掉的。
三、延遲預算的實際算術：一場注定不公平的比賽
讓我們用一個具體的數字模型，把兩邊的預算攤開來比。這樣讀者會更清楚「差距」到底有多大，以及哪些部分是可以縮小的、哪些不是。
以 60fps 為例：16.7 毫秒的預算怎麼分
60fps 意味著每幀 16.7ms。對遊戲開發者來說，這 16.7ms 是硬預算，超過就會掉幀。我們來看看本地與雲端各自怎麼花這筆錢：
延遲環節
本地遊戲（典型值）
雲端串流（同城機房）
雲端串流（跨洲機房）
這張表要表達的重點不是精確數值（每個人的配置差異很大），而是結構性的差距。同城機房的雲端串流，延遲大約是本地的 1.5～2.5 倍；跨洲機房則是 3～6 倍。而這個倍數，並不會因為你買了更貴的顯示卡或更快的網路而消失——因為多出來的那幾項，本來就不在你的控制範圍內。
不同遊戲類型對延遲的敏感度差異
當然，「延遲多 50ms」對不同遊戲的影響天差地遠。這也是為什麼有些人覺得雲端「完全沒問題」，有些人卻覺得「根本不能玩」。我們可以依敏感度把遊戲類型分級：
換句話說，「雲端遊戲追不上本地」這個命題，並不是所有遊戲都成立——但對於那些以延遲為核心體驗的遊戲類型，它成立得非常徹底。
四、那些讓雲端看起來「快要追上」的技術，究竟解決了什麼
過去幾年，雲端遊戲產業投入了大量資源在「降低延遲」上。這些技術確實有效，也讓體驗從「無法遊玩」進步到「勉強可玩」甚至「大致順暢」。但如果我們誠實地檢視，會發現它們解決的多半是「可控延遲」，而不是「不可控延遲」。以下逐一拆解。
邊緣運算與區域機房
最有效的策略，其實不是優化，而是縮短距離。把機房從美國西岸搬到使用者所在的城市或鄰近區域，光速傳播的延遲可以從 130ms 降到 5～15ms。這也是為什麼各家雲遊戲服務都在瘋狂蓋邊緣節點：GeForce NOW 在全球有數十個資料中心，Xbox Cloud Gaming 依託 Azure 的區域機房，Google Stadia（已停止服務）當年也是主打邊緣部署。
邊緣運算的效果非常顯著——在同城機房的情境下，雲端延遲確實可以壓到 40～60ms，接近「可接受」的範圍。但它的限制也很明確：你不能把機房蓋在每個人家裡。對於居住在都市的使用者，這是好消息；對於居住在偏鄉、或想連到海外伺服器與朋友同樂的玩家，這個優勢就不存在了。而且，邊緣機房的建置成本極高，服務商只會覆蓋人口密集區，這注定了它的覆蓋率天花板。
幀生成、預測輸入與延遲補償
另一條路線是「用演算法騙過時間」。常見的手法包括：
這些技術的共同點是：它們讓「平均體驗」變好，但無法改變「最壞情況」的延遲下限。對於需要穩定手感的玩家來說，這種「有時準、有時不準」的體驗，往往比穩定的高延遲更難適應。
網路側的最佳化：Wi-Fi 6/7、5G、光纖
網路技術的進步確實有幫助。Wi-Fi 6 的 OFDMA 與目標喚醒時間（TWT）降低了排程延遲，Wi-Fi 7 的多鏈路操作（MLO）進一步減少了空中傳輸的抖動；5G 的超低延遲通訊（URLLC）在理想環境下可以壓到 10ms 以下；光纖到府（FTTH）則消除了最後一哩的銅線瓶頸。
但這些技術解決的是「最後一哩的品質」，而不是「距離」。就算你的家用網路延遲是 0ms，資料從你家到跨洲機房的光速傳播時間仍然存在。而且，無線網路再怎麼進步，空中介質的干擾與排程本質，仍然讓它難以達到有線的穩定性。對於追求極致延遲的玩家，有線仍然是唯一選擇，而這也限制了雲端遊戲的「行動場景」優勢。
五、為什麼「追上」在數學上不成立：同構問題與不可壓縮的距離
談到這裡，我們可以開始處理最核心的命題：為什麼雲端遊戲「永遠」追不上本地？注意，這裡的「永遠」不是情緒性的誇飾，而是一個可以在邏輯上證明的結構性結論。關鍵在於三個不可跨越的鴻溝。
本地永遠保有的一個優勢：零網路距離
雲端串流的架構本質是「把遊戲執行環境搬到遠端，再把畫面串回本地」。這個架構必然引入一段網路傳輸，而本地遊戲的架構必然沒有這段傳輸。這不是「誰優化得比較好」的問題，而是兩種架構的定義差異。
打個比方：你可以把厨房蓋得離餐桌很近，但你不能把厨房蓋在餐桌「裡面」——除非你就是在家裡煮飯（本地）。雲端串流再怎麼進化，最多只能做到「厨房就在餐桌旁邊」（同城邊緣機房），但永遠不可能讓「厨房與餐桌的距離」變成零。而這個距離，就是那多出來的 20～50ms 起跳的延遲。
更精確地說：假設某天雲端串流的編碼、解碼、伺服器運算延遲全部被優化到理論極限（比如各 1ms），網路傳輸的距離延遲仍然存在。而同一天，本地遊戲的延遲也可能被優化到更低。兩邊都在進步，但云端的「進步」有一個無法消除的常數項，本地的「進步」沒有。這個常數項，就是結構性的差距。
當本地也在進步：硬體迭代並不會停下來等雲端
這是一個經常被忽略的動態觀點。很多雲端樂觀論者的論證是：「現在雲端延遲 50ms，等技術進步到 20ms，大家就會接受了。」但問題是，當雲端從 50ms 進步到 20ms 的同時，本地端的體驗也在進步——甚至可能進步得更快。
舉例來說，這幾年本地端的延遲優化有幾個明顯的進展：高刷新率螢幕從 144Hz 普及到 240Hz、360Hz 甚至 500Hz；NVIDIA Reflex 與 AMD Anti-Lag 直接把渲染管線的延遲砍掉一半；OLED 螢幕的像素反應時間壓到 0.1ms 等級；有線滑鼠的輪詢率從 1000Hz 提升到 8000Hz。這些進步讓本地遊戲的總延遲從過去的 40～60ms，壓到現在的 15～25ms。
換句話說，這是一場「兩邊都在跑」的比賽，不是「雲端追趕靜止的本地」。而云端的追趕速度，受限於物理常數與基礎建設的投資報酬率，很難比本地的硬體摩爾定律更快。差距可能會縮小，但不會歸零。
成本結構的差異：為什麼服務商不會為你無限燒錢
還有一個現實層面的因素：雲端串流的延遲優化，邊際成本極高。要在每個城市蓋邊緣機房、部署高階 GPU、買頻寬、維護冷卻與電力，這些都是天文數字。而服務商能收到的月費，卻被本地遊戲的「一次性買斷」或「Steam 特價」壓得很低。這導致一個結果：服務商必須在「延遲」、「畫質」、「覆蓋率」、「價格」之間做取捨，而使用者永遠會感受到那個取捨的痕跡。
相對地，本地遊戲的延遲優化，成本是由玩家自己承担的——你買更好的硬體，就得到更好的延遲。這是一個「願意花錢就能變好」的市場機制，而云端的延遲則是一個「你花錢也不一定能變好」的黑盒子（因為你無法控制機房距離與路由）。這種控制權的落差，才是雲端遊戲「永遠追不上」的深層原因。
六、實務建議：什麼情況下雲端串流仍然值得使用
寫到這裡，可能會讓人以為雲端遊戲一無是處。其實不然。雲端串流有它無可取代的優勢：免安裝、跨裝置、隨時隨地、不用買高階硬體。只要認清它的限制，選對使用場景，它仍然是一個非常有價值的工具。以下是實務上的建議。
適合雲端的情境
不適合的情境
七、結語：不是「能不能」，而是「願不願意付這個代價」
回到文章標題：「為什麼雲端遊戲永遠追不上本地？」答案其實很簡單：因為雲端串流的架構，天生就多背了一條網路鏈路的延遲預算，而這條鏈路中，光速與距離是無法用工程優化掉的常數。你可以把機房蓋得更近、把編碼做得更聰明、把網路鋪得更快，但你無法讓資料傳輸的時間變成零。而本地遊戲，從定義上就沒有這個問題。
但這不代表雲端遊戲沒有未來。它只是代表：雲端遊戲不會取代本地遊戲，而是會成為一個「互補」的存在。就像串流影音沒有取代電影院、外送沒有取代自己煮飯——它們各自服務不同的需求、不同的場景、不同的人。對於追求極致手感的硬核玩家，本地設備仍然是唯一選擇；對於想要隨時隨地、跨裝置、低成本體驗遊戲的玩家，雲端串流是一個非常有價值的工具。
真正該問的問題不是「雲端什麼時候追上本地」，而是「在什麼情境下，我願意用多少延遲換取多少便利」。當你搞清楚這筆延遲預算的每一項花費，你就能做出對自己最有利的選擇——而不是被行銷話術牽著鼻子走。這，才是身為玩家最實在的功課。
最後補一句給雅寶社區的朋友們：如果你手上有一台不错的本地設備，別急著把它賣掉去訂閱雲端服務。本地遊戲的那份「即時回饋感」，是雲端串流再怎麼進化也無法完全複製的。而如果你還沒有高階硬體，雲端串流確實是一個不错的入門選項——只要你選對遊戲、選對網路、選對機房距離。遊戲好玩與否，終究取決於內容與樂趣，而不是那幾十毫秒的差距。但如果你玩的是格鬥或射擊，那幾十毫秒，就是勝負的分界線。
```