直播要用 WebRTC 還是傳統 CDN？先看觀眾要不要開口
拍賣開始，倒數第三秒，主持人喊出新一輪的起標價——而你螢幕上的價格欄，還停在上一輪。等數字跳出來，出價最快的買家已經舉完手了。
這三秒，是架構的天性：選了什麼播法，觀眾就被放在對應的延遲檔位（延遲的檔次）上，活在幾秒之前。
把這三秒當成「先進不先進」的技術題，判斷就從第一步錯起：聽說 WebRTC（瀏覽器與 App 間低延遲雙向連線的通訊技術）延遲低，就以為該上 WebRTC。這篇給一個更準的判斷法：**先看你的觀眾是要看，還是要開口，還是要跟著畫面即時出價作答。**會開口、或要跟畫面即時反應的場景，WebRTC 才是它該買的東西；只是看的場景，低延遲頻道用簡單得多的方式就能做到夠用。開口指連麥發言；發彈幕不算，彈幕走普通聊天通道，不吃這個延遲。
延遲到幾秒，玩法就開始變形？
延遲不是一個數字，是一整排檔位。同一場活動，不同播法讓觀眾身處差幾十秒的世界，玩法就長在這些秒數上。
拿 AWS IVS 官方文件當尺（IVS 是 AWS 旗下包辦直播轉發與計費的託管服務，本篇費率都拿它當樣本；官方規格是最佳化目標而非保證值，跨境與晚尖峰一律以當地實測為準）：
| 播法 | 觀眾看到的世界 | 官方規格 | 長在這個檔位上的玩法 |
|---|---|---|---|
| 傳統 HLS（普通 CDN 分發） | 慢半分鐘的世界 | 走普通 CDN 的傳統串流可高達 30 秒 | 賽後重播、純存檔 |
| 低延遲頻道（LL-HLS，把影片切得更碎、邊錄邊發的播法） | 慢幾秒的世界 | 5 秒以內 | 帶貨講解、賽事解說、遊戲實況 |
| RTC（WebRTC 房間） | 幾乎同處一室的世界 | 亞秒級 | 競拍答題、連麥 PK、語音房 |
台灣的電商拍賣台把出價與畫面綁在一起，屬於第三列；香港的遊戲賽事解說、新加坡的帶貨場，多數落在第二列就夠；只有賽後重播才該回第一列。
低延遲頻道有個常被誤解的前提：不是開了頻道就自動 5 秒。**相容播放器（hls.js 的低延遲模式、Safari 原生等）＋支援 chunked 傳輸（影片還在錄就一段一段先送出去的送法）的 CDN＋觀眾頻寬夠，三者同時成立才達標。**用不相容的普通播放器接同一條流，會回落傳統 HLS、跳回約 10 秒。這時問題不在頻寬，在播放器；檢查時先換播放器再查網路，順序錯了會白燒一週。這是 LL-HLS 的通用配方，個別廠商另有官方口徑：IVS 只對自家 Player 擔保 5 秒以內，第三方播放器連 Safari 原生都約 10 秒，用哪家頻道就核哪家的支援清單。
數據來源: Amazon IVS Low-Latency Streaming 文件（LL 5 秒以內、傳統 OTT 可達 30 秒）、IVS Player SDK 文件（第三方播放器約 10 秒）、hls.js API 文件（lowLatencyMode 低延遲模式設定），2026-09-16 經搜索索引引官方文件，以官網最新為準。
WebRTC 賣互動，CDN 賣分發
新加坡開台團隊的技術評估裡常出現一行：「建議採用 WebRTC 架構，延遲更低、體驗更好。」把這行翻譯成採購語言，其實是「多買一種商品」：WebRTC 賣的是互動，每個連進房間的人都佔一個參與者席位，按人頭乘時長計費；直播 CDN 賣的是分發，把一條成品流複製給越多觀眾越划算，按流量或觀看小時計費。
兩種商品常被排成新舊關係，採購上它們平起平坐，單價高低不該直接互比。對著指標看：
| 指標 | WebRTC（RTC 即時網路） | 傳統直播 CDN（HLS／LL-HLS） |
|---|---|---|
| 買的商品 | 觀眾的「在場」：雙向、可開口 | 觀眾的「收看」：單向、標準播放器就能開 |
| 計價語言 | 參與者小時或千分鐘（音訊與視訊分階） | 觀看小時或每 GB 流量 |
| 接入方式 | 整合 SDK（裝進 App 或網頁的現成程式零件），沒有標準播放器退路 | HLS 播放器生態全兼容 |
| 人數天花板 | 有：單一房間開麥與訂閱都有官方配額 | 沒有房間概念，按流量擴張 |
| 換供應商 | 觀眾端整合要重寫 | 換一家 CDN，播放器照用 |
天花板那列不是嚇人，是寫進官方配額頁的數字：以 AWS IVS 為例，單一 stage（IVS 對即時連線房間的叫法）公開的開麥上限 12 位、不可調；訂閱上限 10,000 位、可調；參與者單次連線還有 24 小時上限。2026-09-16 對照官網配額頁查得，以官網最新為準。
數據來源: Amazon IVS Pricing（RTC 與低延遲頻道計價語言）、Amazon IVS Endpoints and Quotas（stage 配額），2026-09-15／2026-09-16 擷取。
觀眾進 RTC 房間，帳單真的會爆炸嗎？
「觀眾進房是天價」這句話，先用費率對讀檢驗：以 AWS IVS 東南亞費率為例，stage 裡被動收看的觀眾，每人每小時費率與 HD 頻道輸出的觀看小時幾乎相同（皆 US$0.092，純音訊同為視訊價的十分之一）。這組對讀在〈前進新加坡做互動直播的採購清單〉拆過。在 IVS 的計價結構裡，費率不是拒絕觀眾進房的理由；TRTC、Agora 等其他家的房內觀眾計費口徑不同，逐家核過再下結論。
真正的代價，一個都不在費率上：房間配額（開麥 12 位先擋住輪麥設計）、接入方式（觀眾端得整合 SDK，標準播放器當退路）、連線維持（每個觀眾與伺服器之間要保持一條加密的雙向通道，手機發熱、耗電、吃行動數據）、最後一哩（印尼、越南的行動網路品質波動大，開麥發言的上行感受最深）。還有一個很少被提的：24 小時單次連線上限。語音房掛房機器人要排程重進，否則到點整房斷線。
所以結論要說準：觀眾規模一大就往 CDN 走，是接入工程與體驗取捨的決定，跟單價無關。把成本論述換成配額與接入方式，討論就不會停在「貴不貴」上打轉。
數據來源: Amazon IVS Pricing（stage 被動訂閱費率與頻道輸出同價）、Amazon IVS Endpoints and Quotas，2026-09-15／2026-09-16 擷取。
把玩法對號入座
做低延遲直播的架構判斷，收攏成一張表：先認觀眾的角色，再落架構。
| 玩法 | 觀眾的角色 | 建議架構 | 一句理由 |
|---|---|---|---|
| 帶貨講解、賽事解說、遊戲實況 | 純收看，晚幾秒不影響結果 | 低延遲頻道（LL-HLS） | 5 秒檔位夠用，觀眾端標準播放器 |
| 電商競拍、答題搶答 | 要跟著畫面即時反應 | 亞秒檔位：WebRTC；出價、作答若走自家 API，低延遲頻道也做得到 | 畫面本身就是競價與作答依據時，慢一拍玩法就破 |
| 連麥 PK、連線訪談 | 台上少數人開口，台下旁聽 | 混搭：開口進 RTC、旁聽走低延遲頻道 | 兩種商品各買各的，錢不浪費 |
| 純語音房（無旁聽） | 全員輪流開口 | WebRTC（RTC 即時網路） | 只有一筆參與者帳，音訊價再低一個量級 |
| 千人以上單向大活動 | 全員純收看 | 低延遲頻道或傳統 CDN | 為單向收看給每位觀眾接一條房間連線，不值 |
兩種走法先別選。一是玩法還沒有「開口」需求，就為了顯得先進改上全包 WebRTC：帳單未必多付，觀眾端整合與 SDK 綁定的工程卻一定多做。二是圖省事，把上千觀眾塞進同一個 RTC 房間：每位觀眾都得裝 SDK 才進得來，萬人級活動才撞訂閱配額，單向內容完全用不到這條房間連線。香港做賽事解說的平台、印尼做帶貨的賣場，都能在前三列找到自己；架構判斷錯了，後面每一項帳都會跟著錯。
拿千人活動把三種搭法各算一遍帳
講完判斷，講錢。場景：1,000 位觀眾看 HD、台上 3 個連麥席位、開 2 小時（與新加坡篇同一場景，費率同源：IVS 日本、香港與東南亞同一計價區）。三種搭法並排：
| 搭法 | 算式 | 帳單 |
|---|---|---|
| 全 RTC：1,003 人（1,000 位觀眾＋3 個台上席位）全進 stage | 1,003 人 × 2 小時 × US$0.092 | 約 US$185 |
| 純低延遲頻道：單一直播主單向 | 輸入 2 小時 × US$2.00 ＋ 輸出 1,000 人 × 2 小時 × US$0.092 | 約 US$188 |
| 混搭：3 席連麥＋千人觀看 | RTC 0.55（3 席 × 2 小時 × 0.092）＋混流 0.60（HD 混流 US$0.30/小時 × 2）＋輸入 4.00＋輸出 184 | 約 US$189（新加坡篇算過，此處不重算） |
在這個規模，三張單幾乎疊在一起：差距不到 5 美元。所以「WebRTC 天價」和「CDN 便宜」都講錯了重點。**選架構看的不是這張帳。**表裡的混流，指把多路畫面與聲音在伺服器合成一條成品流；輸入，指節目流送進直播頻道的推流時長費，兩者都是獨立小項（新加坡篇有逐項拆解）。
帳單開始分道，是換了規模之後的事。純音訊便宜一個量級：IVS 音訊是視訊價的十分之一，語音房天生省。連麥規模往上加，參與者小時就跟著人數一路往上爬。觀眾規模怎麼分道，看計價語言：按流量計的（如騰訊雲國際站的直播流量），1080p 每位觀眾每小時約 2.25 GB（以 5 Mbps 計），人一多流量線性壓過一切；IVS 這種按觀看小時計的，隨人數與畫質檔位往上加。這條算術新加坡篇拆過，帳單真跑起來之後的查法在〈直播 CDN 帳單為什麼暴增〉。
數據來源: Amazon IVS Pricing，2026-09-15 自官網擷取；算式為官方費率自算，不含機房、儲存等底座費用，正式預算以書面報價為準。
對照完還拿不準自己的玩法落在哪一檔，把玩法帶到 Telegram，我先幫你對檔位，再往下看帳。
帳單外面的差距
三張帳單打平之後，架構之間的差距落在帳單不會列印的地方。
先看開發這頭。WebRTC 的觀眾端必須整合 SDK，連線過程要處理 NAT 穿透（讓兩台互不相識的設備找到彼此的技術）與連線品質調校，穩定性是持續工程；HLS 這邊，標準播放器生態現成、換廠商播放器照用。同樣一個「觀眾能看」的需求，兩條路的前期投入不同量級。
再看觀眾那頭。連進 RTC 房間，觀眾的手機要保持一條與伺服器之間的加密連線並持續解碼，發熱、耗電、吃行動數據都是真的；開麥發言的人還要多扛一路上行。這筆錢不出現在你的帳單，出現在觀眾的退出率，印尼、越南的行動網路品質波動大，體感落差也最大。
最後是供應商壽命。Twilio 在 2024 年 12 月 5 日終止了 Programmable Video，官方建議至少 3 個月遷移，SDK 綁得越深，退出越貴。Cloudflare Stream 的 WebRTC 交付原本免費，官方公告 2026-10-15 起開始計費。免費的 RTC 分發也會變成計費項，「先用免費 WebRTC 撐量」的預算假設要重新算過。
已經在跑帳單、想先核架構費用的，直播 CDN 成本健檢有完整的拆帳維度。
數據來源: Twilio 官方協助中心：Programmable Video End of Life (EoL)、Cloudflare Stream Pricing（WebRTC 交付計費時程），2026-09-15 擷取。
大多數互動直播的正解：連麥進 RTC，觀眾走低延遲頻道
把全篇判斷收攏成一句：台上會開口的少數人進 RTC 房間，台下純收看的多數人走低延遲頻道，中間用混流與直播頻道把兩個世界接起來。這道橋的計價結構，新加坡篇的三筆帳已經拆過。有一個前提要先認：旁聽觀眾看到的，比房內的人晚幾秒，混流與封裝再加一截；玩法若要求台下跟台上同步反應，混搭不夠，回到全員進房間的小房間方案。台灣的連線節目、香港的賽事直播、新加坡的帶貨場，走到「有人開口、更多人收看」這一步，混搭都是同一個形狀。
第一天就這樣設計，買到的是選擇權：觀眾端從標準播放器開始，台上換哪家 RTC 供應商、甚至臨時換方案，都不用動觀眾端；先全押再往回收，每一步都是遷移工程。
已經全押 WebRTC 的團隊，收斂路徑按順序走：
- 盤點綁定面：觀眾端的播放、禮物、連麥入口，哪些功能寫死在該家 SDK 上。
- 新內容不再擴 RTC：新增的單向內容全部往低延遲頻道長，RTC 房間只留真正開口的人。
- 觀眾端分批收回：先低風險的單向頻道，再逐步收回標準播放器，每批驗過機型與電信網路再下一批。
- 看清退出條款：合約的終止與資料可攜條款先讀，預留至少一個遷移期。
把玩法寫成三行（觀眾會不會開口，定檔位；預期同時在線，定能不能全進房間；單場時長，定帳單總額），帶到 Telegram 找我，我先幫你對檔位、把兩邊的帳各算一遍，這一步免費。
關於新星雲
新星雲是我一個人的顧問生意，做遊戲與直播的雲選型與代客採購：跟你聊的就是做判斷的人，不代理任何一家廠商的產品線。
正在選直播架構的團隊，通常用得上：
- 把玩法描述變成架構判斷：觀眾角色、延遲檔位、兩種帳單模型一起看。
- 拆現有的 WebRTC 與 CDN 帳單，標出哪一項是架構造成的、哪一項調模式就好。
- 深夜與假日的故障先走原廠管道；要跟原廠開的跨國工單，我代開、工作日跟進。
文中費率與配額都標了採集日期，拿去談判前先核當期數字。
相關閱讀
- 前進新加坡做互動直播，6 類雲服務的採購清單與預算邏輯：RTC、混流、CDN 三筆帳怎麼算，本篇的費率與算式同源於此。
- 直播 CDN 帳單為什麼暴增？拆成四塊自己查：架構選對之後，帳單跑起來的查漏方法。
- 台灣玩家連香港還是新加坡？用 3 種玩家分佈決定遊戲節點：機房與觀眾所在地的關係，低延遲分發同樣適用。
- 回到部落格總覽看其他選型與成本拆解文章。
FAQ
5 秒以內的延遲，對我的玩法算高嗎？
看觀眾的角色。帶貨講解、賽事解說、遊戲實況這類單向內容，觀眾晚幾秒聽到不影響結果，5 秒以內的低延遲頻道就夠；競拍出價、答題搶答、連麥對談這類要即時反應的玩法，才需要亞秒級的 WebRTC。先列玩法再選架構，多數團隊會發現自己要的是低延遲頻道，不是 WebRTC。
觀眾進 WebRTC 房間，費用是不是天價？
費率不是問題。以 AWS IVS 東南亞費率為例，stage 裡被動收看的觀眾每人每小時費率，與 HD 頻道輸出的觀看小時幾乎相同。真正的限制是：單一 stage 開麥人數有官方上限（IVS 公開為 12 位、不可調）、訂閱人數有配額，參與者單次連線上限 24 小時；觀眾端必須整合 WebRTC SDK，沒有標準播放器的退路，手機要保持加密連線並持續解碼，耗電又吃流量。觀眾走 CDN 是接入方式的決定，不是單價的決定。
同樣的觀眾數，WebRTC 和直播 CDN 的帳單結構差在哪？
兩種商品。WebRTC 按參與者時長計費，人數乘時長直接得出費用；CDN 按觀看小時或流量計費，跟編碼位元率掛鉤。WebRTC 房間的伺服器轉發與混流要另算，CDN 方案的轉碼與頻道輸入也是獨立條目。比價前先把兩張帳單換算成同一個場景，否則計價單位對不上。
已經全站上了 WebRTC，之後想遷回 CDN 行嗎？
行，但比一開始就選對貴。觀眾端整合的 WebRTC SDK 要整批換掉或重寫，測試要覆蓋各機型與電信網路；連麥、禮物與互動系統若綁在該 SDK 上，遷移是專案級工程。先確認合約的終止與資料可攜條款，再把新增的單向內容導向低延遲頻道，觀眾端分批收回標準播放器。
低延遲直播的機房要選在哪？
跟著觀眾，不跟著直播主。以 IVS 為例，低延遲頻道的分發計費依觀眾連接位置認定，其他家口徑不同；機房開在哪不等於觀眾體驗，香港、台灣觀眾與印尼、越南觀眾可能落在不同計價區。動手前先拉 30 天觀眾地區分佈，方法見〈台灣玩家連香港還是新加坡？用 3 種玩家分佈決定遊戲節點〉。
語音房 24 小時掛房，有什麼要對的數字？
兩個。IVS 的 stage 參與者單次發布或訂閱上限為 24 小時，掛房機器人要排程重進，否則到點斷線；每天固定開幾小時的語音房遠低於此，不用處理。另一個是開麥上限 12 位，超過要設計輪麥機制。掛房場景的成本算法，見〈前進新加坡做互動直播，6 類雲服務的採購清單與預算邏輯〉。