Patricija Žemaitytė · Oxylabs
這支影片在講：AI 產品要先能在真實網路世界活下來
模型只是入口。當產品必須即時拿資料、承受客戶需求變形與高流量時，勝負取決於延遲、可靠性、可觀測性，以及持續調整的基礎設施。
AI Engineer · 約 16 分鐘 · 2026-08-14
60 秒速讀
01 / 問題
開發可用，不等於現實可用
瀏覽器慢、昂貴且容易被封鎖；demo 能跑與系統能在客戶面前存活，是三件不同的事。
02 / 反轉
需求不是「一個 API」
客戶先要影片逐字稿，接著要字幕、搜尋、metadata；一次交付很快長成資料產品組合。
03 / 解法
量測、拆瓶頸、持續重算
從 layout、parser、session、proxy 逐秒找時間；高流量下連 telemetry 也必須被當作負載的一部分。
Signals
四個不能忽略的訊號
Latency
4s → 550ms
把搜尋 API 壓到次秒級，不是單一技巧，而是逐層挖掉等待時間。
Deadline
2 週
大型資料需求常以不合理時程進場；架構要能先交付、再擴張。
Data scale
5 → 30 PB
原本每月 5 PB 的底線，最後累積到 30 PB；成本與商業條件也會一起漂移。
Throughput
10k → 60k RPS
在約 20k 的 load test 撞牆後，問題變成：測得的數字到底可信嗎？
Core stories
三個故事，三個 production 教訓
01
次秒回應，卻在客戶 call 上被封鎖
重建後的搜尋 API 平均 550ms，但 live demo 仍遭封鎖。教訓是 SLO 不該只看 latency：session、proxy、反爬與失敗復原都要算進「可用」。
02
逐字稿需求，演變成資料產品套件
從 transcripts 到 subtitles、search、metadata，需求會沿著使用情境擴張。把介面、資料模型與商業條件設計成可延展的，才能避免每次加需求都重做一遍。
03
60,000 RPS 前，先問測試是否說真話
高量測試在約 20,000 RPS 出現瓶頸；合成流量、監控與資料收集本身都會扭曲結果。觀測系統不是旁路，而是被測系統的一部分。
Practical checklist
給 AI / data 團隊的實務啟發
把「可存活」定義進 SLO除延遲與成功率外，追蹤封鎖率、session 耗損、proxy 可用性與復原時間；避免只有 happy-path dashboard 漂亮。
以演進式合約處理客戶需求區分可快速加入的資料維度與必須重構的產品承諾，讓需求從單點 API 長成 suite 時仍可管理。
在負載測試中驗證觀測成本量測 instrumentation 對吞吐、延遲與採樣品質的影響；必要時把遙測設為可降級的工作負載。
保留持續改造的預算「Project 60 已變 Project 150」提醒我們：容量規劃應保留重新設計空間，不要把首次規模當成終點。
Content map
影片章節
00:00
從 infrastructure 而非模型開始用真實案例定位 web data 的工程難題。
02:23
兩週交付的 video API需求如何從逐字稿延展成搜尋與 metadata。
07:25
次秒 API 與現場被封鎖從 4 秒到 550ms 的重建，以及 production 的反擊。
12:26
擴到 60,000 RPSload test 在 20,000 RPS 撞牆，重新檢視測試與 telemetry。
15:31
Project 60 變 Project 150資料基礎設施不是 build once，而是 adapt forever。
Source video