云端无头浏览器录制:成本与可行性研究(R3 预研输入)¶
研究目标:回答"一台机器能塞几路、单路每小时多少钱、Linux 还是 Windows",给 R3(无头单路成本 + 并发密度)提供有来源的数字,不是拍脑袋。
标注说明:确认 = 官方文档/一手来源明确写出;较可信 = 第三方博客/聚合站/社区经验贴,方向对但数字可能有出入;推测 = 没有直接数据,基于已确认事实做的第一性原理推导,务必用真实 PoC 校准。
结论摘要¶
- Linux 应该是云端唯一选项——不是"更便宜"这么简单,是 Windows container 跑不了 Qt/CEF 这种要开真实 GUI 会话的应用(Session 0 隔离决定的,确认),只能上完整 Windows VM;Windows 授权费另加 30%~100%+(不同计费口径差很多,较可信);而且 Windows Server 默认没有声卡设备,得自己装虚拟声卡驱动才能让播放器正常工作(确认)。如果现有 CEF fork 挪不到 Linux,这才是全盘最大的成本项,比选哪家云都贵。
- 真正的省钱杠杆不是选云厂商,是"要不要真的把画面解码出来"。现有引擎本来就靠网络层拦截分片、不做屏幕录像,这个架构优势天然延续到云端无头场景——不需要真显示器、不需要把像素编码成视频。但"不渲染画面"和"不解码画面"是两件事,能不能连解码都省掉,DRM 和非 DRM 是两个完全不同的答案(见第二节)。
- 非 DRM 流大概率能把 CPU 成本压到"只跑页面 JS + 网络 IO",不需要真解码——但播放器的 JS 逻辑会不会因为"没人看"就暂停要下一个分片,需要针对每个目标平台做 PoC 实测(推测)。有一个容易踩的坑:很多自适应码率播放器按"播放器容器的像素尺寸"选清晰度档位,窗口开成 1x1 省渲染成本,播放器可能自己把画质降到最低档,反而拿不到 1080p 分片了——这个要逐平台验证,不能默认所有站点行为一致。
- DRM 流躲不开解码成本:
--headless模式下 Widevine CDM 直接不可用,这是 Chromium 长期未解决的已知限制(确认);行业标准做法是不用--headless参数,改用 Xvfb 起一个没有物理显示器但内部是"headful"的 Chrome/CEF 进程。即便这样,只要走真播放路线,GPU 关闭时解密出的画面要经过 CPU 软件渲染通道,这部分算力成本是真实的、躲不掉的(较可信)。唯一能完全绕开解码成本的路径,是拿到 CDM 颁发的内容密钥后自己离线解密网络层截到的分片,全程不调用.play()——这类"与 CDM 做 license 交互取密钥"的技术路径在开源社区有公开先例,但这已经不是工程选型问题,而是和产品文档 R4 一样的法务灰区决策(较可信,不展开操作细节)。 - 目前没有任何公开数据是针对"小时级 1080p 播放"这个具体场景的并发密度。能查到的"一台机器能塞几个 headless Chrome"的数字全部来自截图/爬虫类秒级任务(8~16vCPU 塞 15~25 个,确认),套用到小时级持续播放会显著低估资源消耗——Replit 做类似量级的浏览器转视频管线时,官方原话是"Chrome 吃掉数 GB 内存、ffmpeg 吃满 CPU",单机并发直接设成 1(确认,但他们的负载比本场景更重,是渲染上限参考而非直接估值)。
- 第一性原理估一个量级(推测,务必用 PoC 校准):8 vCPU 机器,非 DRM/免解码的乐观情况下大概能塞 15~20 路,DRM/真解码的保守情况下大概 6~10 路。
- 单路成本量级:算力 $0.02~0.05/路·时(Linux CPU 机型,上述并发假设),存储 $0.01/路·时·月(R2/B2 这类零出口存储),下载出口带宽一次性 $0~0.27/路·时(走 Cloudflare R2/B2 几乎免费,直连 AWS/Azure/GCP 约 $0.08~0.09/GB)——这和产品文档 Appendix 3 原有"$0.1x/时"的量级估算基本对得上,只是把每一项换成了有来源的数字(见第七节完整成本模型)。出口带宽路径的选择(R2 vs 直连)比选哪家计算云贵 10 倍还多,是全表里波动最大的一项。
- 买不如自建:Browserbase / Browserless / Steel.dev / Hyperbrowser / Anchor 这几家托管浏览器服务,官方文档里都没提过视频/音频播放或 DRM 支持,产品定位统一是"给 AI agent/爬虫用的短任务浏览器"——会话时长上限普遍偏短(Browserbase 6 小时封顶,Steel 标准档只给 1 小时、24 小时要 Enterprise 定制价)。想录"小时级直播"这个量级,直接买基本都要谈非标准企业合同,不如自建(确认,来自各家官方定价/文档页)。
一、Linux headless 浏览器音视频采集技术栈现状¶
先讲清楚问题的本质:所有"从浏览器里把画面/声音抠出来"的方案,本质上都在解决同一件事——浏览器天生是给人看的,它的输出是"画面画到屏幕上、声音放到音响里",不是一份可以直接存盘的文件。你要么在浏览器外面架一台"摄像机"把输出录下来(Xvfb + ffmpeg 这一路),要么让浏览器自己把数据吐给你(CDP screencast / tabCapture / WebCodecs 这几路)。这两条路线的取舍,决定了 CPU 成本和长时稳定性的天花板。
| 方案 | 需要虚拟显示环境? | 画质 | CPU 成本 | 音频是否采集 | 长时录制的坑 | 生产实例 |
|---|---|---|---|---|---|---|
| Xvfb + PulseAudio/PipeWire + ffmpeg x11grab | 需要(虚拟 framebuffer) | 取决于 ffmpeg 编码参数,可以做到位 | 高——多一层"整屏光栅化 + 重新编码" | 支持,但 PulseAudio 时间戳不单调、要迁移到 PipeWire 才稳定(确认) | 长时间跑音视频时间戳漂移、静音流状态机要额外处理(确认) | Mux(视频云基础设施公司)的 headless Chrome as a service 就是这条技术栈(mux.com/blog) |
Chrome --headless=new + CDP Page.startScreencast |
不需要(真 headless) | 帧率被压到约 30fps(网络开销限制),非原生分辨率 | 中 | 原生不支持,需企业版扩展或独立采集再对轨(确认,Browserless 文档) | 高频截屏对 IPC/带宽有持续压力 | Browserless Screencast API(企业版) |
chrome.tabCapture(扩展 API) |
需要真实扩展运行环境,不是纯自动化 API | 原生 MediaStream,质量取决于下游 MediaRecorder 设置 | 中低(拿到的是已解码流,不用二次截屏) | 支持(音视频都在同一个 MediaStream 里,官方文档) | 需要 Manifest V3 offscreen document 拼后台录制,工程量不小 | 会议录制类 bot 的常见技术路径之一(较可信,Recall.ai 工程博客) |
| Playwright / Puppeteer 内置 video recording | 不需要 | 差——Chromium 端目标码率硬编码 1Mbit/s、单线程编码、CPU 目标占用 50%(确认,Playwright issue #31424) | 低,但画质代价高 | 不含音频(纯画面) | 官方定位就是"测试产物"用来复盘失败用例,不是生产级媒体质量旋钮(确认) | 各类 CI 系统的失败重放(确认) |
| WebCodecs 自定义管线(画布重渲染) | 不需要虚拟显示,但要在页面内接管时间/解码 API | 可以做到位,但工程量巨大 | 极高——原话"Chrome 吃掉数 GB 内存、ffmpeg 吃满 CPU",单机并发直接设为 1(确认,Replit 工程博客) | 需要另外劫持 Web Audio API,逐个音源重建混音(确认) | 光是搞定一个 <video> 元素就要五层 workaround(DOM 监听→服务端 ffmpeg 转 fMP4→ mp4box.js 解封装→ WebCodecs 解码→ canvas 按虚拟时钟重绘)(确认) |
Replit 的"网页转视频"渲染引擎(确认,但这是更通用的"任意网页转视频"场景,比本场景重) |
谁在生产环境真用这些方案:Mux(Xvfb 技术栈)、Browserless(CDP screencast 企业版功能)、Recall.ai 这类会议录制 SaaS(tabCapture/自动化混合路径)、Replit(自研 WebCodecs 管线,因为前面几种都不够用)。Playwright/Puppeteer 自带的 video recording 明确是测试工具产物,官方从没把它当生产级媒体采集方案卖。
对本场景的启示:这几条路线全部是"把画面重新录一遍"的思路,而现有引擎压根不需要这套——它在网络层直接拿分片字节,相当于绕过了这张表里所有方案都要解决的"怎么把渲染结果抠出来"这个难题。这是第二节要讲的核心。
二、"不用录屏"这条路能走多远¶
2.1 渲染(rendering)和解码(decoding)是两件事,只有前者绑定"要不要有屏幕"¶
打个比方:解码是"厨房把菜做熟",渲染是"服务员把菜端上桌给客人看"。现有引擎的做法相当于——菜刚做好、服务员还没端出去之前,就在厨房后门把菜"复制"了一份带走,压根不需要餐厅有没有客人在等着吃。这是现有架构本来就有的优势,不需要额外发明技术,直接延续到云端 headless 场景:不需要真实显示器、不需要把像素重新编码成视频文件,这一层的成本在 Linux/CEF 上应该和 Windows/CEF 上是一样的,不是新增负担。
但"不渲染画面给人看"不等于"不解码"。解码这一步(把 H.264/AVC 压缩帧变成可用的 YUV 像素数据)是播放器逻辑本身依赖的内部状态,不是单纯为了"画给你看"才做的——这才是真正决定 CPU 成本的部分,而且非 DRM 和 DRM 两种情况答案完全不同。
2.2 非 DRM 流:大概率可以不解码,但要防"播放器偷懒"和"自适应码率降级"两个坑¶
分片本身是可以直接从网络层原样拿到的明文字节,浏览器是否真的把它解码成像素跟"能不能拿到这些字节"完全无关——只要播放器的 JS 逻辑(hls.js / dash.js / shaka-player 等)不会因为"没人在看"就停止请求下一个分片就行。
已知能用来防止 Chrome"偷懒"的命令行参数(均为已确认存在的 flag,但是否足以防止所有目标平台的播放器暂停加载,没有一个通用答案,要逐平台 PoC):
--autoplay-policy=no-user-gesture-required:不加这个,.play()在无用户手势场景下直接会被浏览器拒绝(确认)。--mute-audio:静音播放,不需要真实声卡也能跑(确认)。--disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-renderer-backgrounding:防止 Chrome 因为"窗口不在前台/被遮挡"而给 tab 降频、降进程优先级——这三个 flag 是 headless 自动化圈的标配组合(确认,chrome-launcher 官方文档)。
一个容易被忽略、后果很大的坑(推测,但原理成立):很多自适应码率(ABR)播放器是按"播放器容器的像素尺寸"来决定请求哪个清晰度档位的。如果为了省渲染成本把窗口开成 1x1,播放器完全可能自己判断"反正显示区域这么小,给你个最低画质就够了",于是主动请求 480p 分片而不是 1080p——这样反而拿不到目标清晰度的数据了,跟"1080p 录制上限"的产品承诺直接冲突。这个必须针对每个目标直播平台单独实测,不能假设所有站点行为一致。
2.3 DRM 流:解码成本躲不掉,除非绕开播放本身(这已经是法务问题不是技术问题)¶
三个环环相扣的已确认/较可信事实:
--headless模式下 Widevine CDM 直接不可用,这是 Chromium 官方 issue tracker 里长期存在、未解决的已知限制(确认,Chromium issue #40551636 / 历史编号 #788662)。- 行业标准做法不是"想办法让 headless 模式支持 DRM",而是压根不用
--headless参数,改用 Xvfb 起一个没有物理显示器、但对 Chromium 内部代码路径而言是完整"headful"的进程——这两者走的是完全不同的代码分支,Widevine 在后者里能正常工作(较可信,多个来源交叉印证;CEF 官方论坛也说明"CEF 在 Linux 下即使做 OSR 离屏渲染也依赖窗口管理器,推荐用 Xvfb")。这意味着 DRM 场景下,云端机器要比非 DRM 场景多背一层 Xvfb + 完整合成器的基础开销,不是纯"无头"能省下来的。 - GPU 硬件加速关闭时(云端 CPU-only 机型的常态),Widevine 解密出的画面会被送进普通 CPU 内存、走 Skia 软件渲染通道,而不是受保护的 GPU overlay 通道(这也正是为什么关掉 GPU 加速的 Chrome 更容易被截屏工具捕获到 DRM 内容——保护机制本身依赖 GPU 硬件通道)。换句话说,只要走"真播放"这条路线,DRM 流的软解码 CPU 成本是真实存在、几乎躲不掉的(较可信)。
唯一能完全绕开解码成本的路径:不走播放,走"密钥"——向 CDM 发起标准的 license 请求流程,拿到许可证响应后解析出内容密钥,再用标准 AES-CTR(CENC)逻辑自己离线解密网络层拦截到的分片,全程不调用 .play()、不触发任何解码。这类"与 CDM 做 license 交互取内容密钥"的技术路径在开源社区有公开、文档化的先例(如 pywidevine 这类工具展示的调用模式:构造 license challenge → 发给 license server → 解析响应 → 过滤出 type == 'CONTENT' 的密钥)。
但这已经不是云端工程选型问题——和产品文档 R4 里已经点破的一样,这属于 Cablevision/DMCA 反规避条款的法务灰区,不建议把它当成"技术方案 A/B 选型"来评估,应该和法务一起拍板要不要走这条路,走了之后风险敞口有多大。本报告不展开任何操作层面的细节。
2.4 "播放但不渲染" vs "播放且渲染"的 CPU/RAM 差异:没有直接对比数据¶
这条标推测——没查到把两种场景直接放在一起测过的公开基准。能确认的间接证据:Playwright/BrowserStack 官方文档说 headless 模式比有头模式快 10~30%,但这省的是"跳过屏幕 UI 绘制这一步",官方原话特别强调这不影响视频录制质量,因为 Playwright 是从渲染引擎内部抓帧,不是从屏幕上抓(确认,BrowserStack 文档)——也就是说,即便你关掉所有能关的"画给谁看"相关开关,解码这块 CPU 成本大概率还在原地,除非走上面 2.3 节说的"跳过播放、只拿密钥离线解密"这条路。
如果要拿到真实数字,建议 PoC 阶段直接做 A/B 测量:同一条 1080p 流,一组用 --disable-gpu + 正常 <video> 播放,一组尝试各种"阻止解码但保持 JS 逻辑活着"的手段,对比 CPU/RSS,而不是相信任何二手估算(包括本报告的推测部分)。
三、实测口径的并发密度数字(以及为什么现有数字都不适用)¶
3.1 能查到的公开数字¶
| 来源 | 场景 | 数字 | 标注 |
|---|---|---|---|
| Browserless 官方博客 | 通用自动化(截图/爬取) | 经验法则:约 10 个并发请求 / 1GB 内存 | 确认(官方经验法则,非严格基准) |
| Browserless 私有部署文档 | 通用自动化 | CPU/内存到 90% 阈值就拒绝新请求,没给出具体每会话资源数字 | 确认(有阈值机制,无具体数字) |
| 社区经验贴(dev.to 系列) | 通用自动化 | 8~16 vCPU / 16~32GB 的机型,建议塞 15~25 个 Chrome 实例;冷启动 Chromium 占 50~150MB,基线约 100MB+ 每 tab 再加 50~200MB | 较可信(社区经验,非官方硬指标) |
| Puppeteer GitHub issue 讨论 | 通用自动化 | 单实例 100MB+ 起步,存在内存持续增长问题,需要定期回收进程 | 确认(内存增长是真实问题,数字量级为社区共识) |
| Replit 工程博客 | 网页转视频渲染(比本场景更重,含 WebCodecs 解码+重编码+画布合成) | "Chrome 吃掉数 GB 内存、FFmpeg 吃满 CPU",单实例并发数设为 1 | 确认(生产实践,但场景比本需求重,是上限参考不是直接估值) |
3.2 为什么这些数字不能直接套用¶
上面表格里除 Replit 外的所有数字,负载场景都是"打开页面、截个图/跑几秒 JS、关掉"这种秒级任务,不是"打开一条直播、连续播放并持续产出分片数小时"这种持续负载。两者的资源占用模式完全不同:
- 秒级任务的内存占用主要是"启动开销"(进程本身 + 页面 DOM/JS 堆),播放几秒钟视频缓冲区还没怎么涨起来就结束了。
- 小时级播放会持续占用媒体缓冲区(MSE SourceBuffer 里通常会缓存数十秒到几分钟的分片数据)、JS 堆可能随时间增长(尤其如果播放器自己有内存管理问题)、而且要连续扛住数小时不重启、不崩溃、不泄漏。
Replit 的案例是目前查到的、场景上最接近的参照,但他们的负载明显比本需求更重(要把整个页面渲染合成到画布、还要跑 WebCodecs 软解再重新编码成输出视频),所以他们"单实例并发 1"的结论应该当作资源消耗的上限参考,而不是直接套用到"只需要网络层拦截分片、不需要重新渲染合成"的本场景。
3.3 第一性原理估算(推测,PoC 前唯一能给出的量级)¶
用一台 8 vCPU 机器倒推:
- 乐观情况(非 DRM,解码可以规避):CPU 成本主要是页面 JS 执行 + 网络 IO,假设每路 0.4~0.5 vCPU,则 8 vCPU 能塞 约 15~20 路。
- 保守情况(DRM,或者非 DRM 但发现解码规避不掉):CPU 成本包含真实软解 + Xvfb/headful 开销,假设每路 0.8~1.3 vCPU,则 8 vCPU 能塞 约 6~10 路。
RAM 大概率不是瓶颈——按每路 400~800MB(比通用自动化场景的 100~200MB 高,因为要扛住数小时的媒体缓冲区和潜在的内存增长)估算,32GB 机器能塞 40~80 路,远高于上面 CPU 侧算出来的 6~20 路,所以这台机器大概率是 CPU-bound,不是 RAM-bound,选机型时不需要为了内存过度堆配置。
这组数字务必用真实 PoC 校准,不要直接拿去定价或做容量规划——这正是产品文档里 R3 要验证的事情,本报告只是把"没有实测前能讲出道理的最佳猜测"摆出来。
四、Windows 上云的现实情况¶
4.1 授权费溢价:不同计费口径打架,老实说清楚而不是编一个假的精确数字¶
- AWS 官方口径:Windows Server License Included 在 Dedicated Host / EVS 场景下按 $0.046/vCPU/时 单独计费(确认,AWS EVS 定价页)。但这个数字能不能直接套到标准按需 EC2 机型上存疑——拿 c7i.2xlarge 的 Linux 报价反推($0.357/时,8vCPU),如果按 $0.046/vCPU 线性加成,相当于每小时多付 $0.368,涨幅高达 103%;而第三方分析给标准 EC2 按需机型算出来的溢价是 30%(Strategic Blue)到 45%(较可信,二手分析)不等。这说明标准 EC2 的"License Included" AMI 定价和 Dedicated Host/EVS 的按 vCPU flat rate 计费大概率不是同一套算法,具体数字必须拿目标机型直接查 AWS 官方定价计算器,不要用本报告任何一个百分比反推账单。
- GCP:Windows Server 镜像按 vCPU 单独加收,量级同样在 $0.04~0.046/vCPU/时(较可信),小机型(f1-micro/g1-small)更低至 $0.023/时——不是线性同一档,机型越小相对溢价占比越高。
- Azure:授权费直接打包进整机报价,不是加成模式;第三方分析给出的量级是贵到两三倍(较可信,Amnic/MultiCloud Optimization)。可以用 Azure Hybrid Benefit(自带授权)省最多 40%,叠加预留实例最多省 80%(确认,Azure 官方定价页)。
结论:不管哪个云,Windows 授权费都不是小数目,量级在"多付三成"到"贵一倍以上"之间,具体取决于机型和计费产品线,上线前必须拿目标机型实测报价,不能假设一个固定百分比。
4.2 Windows container 装不下 Qt/CEF 这种 GUI 应用——这是能不能的问题,不是配置问题¶
Windows container(process isolation 模式)只有 Session 0 的服务控制台会话,没有交互式桌面 GUI 会话——这是 Windows 从 Vista/Server 2008 就开始的 Session 0 隔离机制决定的,专门用来防"shatter attack"这类提权攻击,不可配置、不能绕过(确认,Microsoft Session 0 Isolation 官方文档)。微软官方的 Windows-Containers 仓库里有人明确提过"给 Windows container 加 GUI 支持"的 feature request,建议做一个类似 X server 的 GUI 转发服务器,但截至目前没有实现(确认,GitHub issue #611)。
这意味着 Qt/CEF 这种要真正开一个可交互浏览器窗口的 GUI 应用,跑不进 Windows container,只能上带完整交互式桌面会话的 Windows VM。这是 Linux(Docker 天然支持 headless Chrome,Mux/Browserless/Recall.ai 一大批生产先例)和 Windows 之间最本质的差距——不是"配置复杂一点",是"这条路直接走不通",容器化带来的密度/成本优势在 Windows 这边基本拿不到。
4.3 Windows Server 默认没有声卡——经典的"RDP 之外没有音频设备"问题¶
Windows Server 的云端 base image 默认没有声音输入/输出设备,不管是 EC2、Azure 还是 GCP,原理相同——虚拟机本身没有物理声卡,操作系统也没预装虚拟声卡驱动。AWS 官方论坛明确确认 Windows Server 2022 Base AMI"无法检测到任何输出/输入设备,重启和各种排查都无效"(确认,AWS re:Post)。
即便通过 RDP 连接,Windows 默认也只把"本地默认音频设备"重定向到会话里,没法在 RDP 会话里直接用其他虚拟声卡设备,除非用 mstsc /admin 这种连到 console session 的方式(较可信,社区经验)。
常见 workaround:
- 装虚拟声卡驱动(如 VB-Audio Virtual Cable):相当于给系统伪造一个"耳机",让播放器以为有输出设备可以播放(较可信,社区方案,非官方支持)。
- 装 NICE DCV(现改名 Amazon DCV)远程协议服务端:原生支持最多 7.1 声道虚拟音频,且支持"没有真人登录"的 virtual session 模式(
dcv create-session console --type virtual),专门为无人值守的云端场景设计(确认,AWS DCV 官方文档)。 - 如果应用能接受完全没有声音输出(纯 muted),理论上可以绕开整个音频子系统——但要注意有些播放器的 JS 逻辑会检测"是否存在可用音频设备"来决定播放策略,静音不代表"没有声卡"这件事本身对应用不可见(推测,需要针对目标播放器实测)。
注意:本场景不需要"听到"声音,只需要拦截到音频分片数据——如果引擎本来就是在网络层截取分片而不是靠系统声卡录制音轨,理论上这个坑可以完全绕开(呼应第二节的核心逻辑),但要在 PoC 里验证目标播放器不会因为"检测不到音频设备"而拒绝播放或降级音质。
五、云计算 2025/2026 定价¶
5.1 算力(约 8 vCPU 量级,按需价)¶
| 厂商/机型 | vCPU / RAM | 按需价 | Spot/抢占价 | 备注 |
|---|---|---|---|---|
| AWS c7i.2xlarge(Intel x86) | 8 / 16GB | $0.357/时 | $0.156/时 | 确认(Vantage) |
| AWS c7g.2xlarge(Graviton3 ARM) | 8 / 16GB | $0.29/时 | $0.11/时 | 确认;但 CEF fork 目前是否有 ARM build 待验证,这个价格能不能吃到是未知数 |
| GCP c4-standard-4 | 4 / ~16GB | $0.1977/时(约合 $0.395/时 若按 8vCPU 线性换算) | 未查到 | 较可信(第三方聚合定价站,非 GCP 官方页面直接确认) |
| Azure F8s_v2(计算优化,2GB/vCPU) | 8 / 16GB | $0.338/时 | 未查到 | 较可信(同上来源) |
| Hetzner CCX 系列 | 视型号 | 2026年6月经历 113%~176% 的暴涨(CCX13: €15.99→€42.99/月;CCX63: €374.49→€853.49/月) | — | 确认,多篇独立报道交叉印证(wz-it.com 等);已经不是"白菜价",选型前必须查当天实价 |
| OVHcloud b3-16 | 4 / 16GB | $0.1132/时(约合 $0.0283/vCPU·时) | 未查到 | 确认(OVH 官方定价页),且带宽免费(见下) |
Spot/抢占实例的取舍:AWS 常见 c7i 这类主流机型 spot 折扣在 55%~75%(较可信),但录制任务如果被打断意味着一段直播录制失败——除非做好断点续录/多机冗余,否则不建议把录制核心链路压在 spot 上,这是可靠性和成本之间的第一性权衡,不是"能省钱就该用"。
5.2 出口带宽(egress,下载录制文件的成本)¶
| 厂商 | 价格 | 备注 |
|---|---|---|
| AWS | 首 100GB/月全网免费,之后 $0.09/GB(10TB 以内),阶梯降到 $0.05/GB(150~500TB 档) | 确认 |
| Azure | 首 100GB/月免费,之后北美/欧洲 $0.087/GB(10TB 档),阶梯降到 $0.05/GB(350TB 档) | 确认,官方带宽定价页 |
| GCP | 本次未能直接取到官方明细页数据 | 推测,量级应与 AWS/Azure 接近($0.08~0.12/GB 首档),建议用官方计算器复核 |
| Cloudflare R2 | 零出口费,任何存储档位出口都不收费 | 确认——这是这张表里最大的变量 |
| Backblaze B2 | 出口在"月均存储量 3 倍"额度内免费,超出 $0.01/GB;走 Cloudflare Bandwidth Alliance 通道则完全免费 | 确认 |
| Hetzner | 超出套餐自带流量后 €1/TB ≈ $0.0012/GB | 确认,基本可以忽略不计 |
| OVHcloud | Public Cloud 实例出口流量免费(亚太区除外) | 确认,官方定价页 |
这是全篇成本模型里波动最大的一项:同样下载 3GB 的 1080p 文件,AWS 直连约 $0.27,走 R2 是 $0——27 倍的差距,比选哪家计算云、Linux 还是 Windows 都更能决定单路成本。
5.3 存储($/GB·月)¶
| 厂商/档位 | 价格 |
|---|---|
| S3 Standard | $0.023/GB·月(前 50TB) |
| S3 Standard-IA | $0.0125/GB·月起 |
| Cloudflare R2 标准 | $0.015/GB·月 |
| Cloudflare R2 低频 | $0.01/GB·月 |
| Backblaze B2 | $0.006/GB·月 |
以上均为确认(各厂商官方定价页/权威聚合站交叉核实)。
六、托管浏览器基础设施厂商:买还是自建¶
| 厂商 | 计费方式 | 折合每浏览器·时 | 单会话时长上限 | 是否提及媒体播放/DRM |
|---|---|---|---|---|
| Browserbase | 月费 + 超额小时计费 | $0.10~0.12/时(超额部分) | 6 小时封顶(确认,官方文档) | 未提及 |
| Browserless | 30 秒为一个 Unit 计费 | 换算约 $0.05~0.12 量级(视套餐) | 未查到公开硬性上限 | 有 Screencast(企业版扩展),但明确说明原生不支持音频采集,需另配方案 |
| Steel.dev | 信用额度按套餐 | $0.08~0.10/时(标准档) | 入门档 15 分钟,Scale 档 1 小时,24 小时要 Enterprise 定制价(确认,官方文档) | 官方文档全篇未出现 video/audio/DRM 字样 |
| Hyperbrowser | 信用额度,1 信用 = $0.001 | $0.10/时 | 未查到公开上限 | 未查到媒体/DRM 相关字样 |
| Anchor Browser | 开机费 + 按时 | $0.05/时 + $0.01/次开机 | 未查到公开上限 | 主打反机器人检测,未见媒体/DRM 相关字样 |
结论很清楚:这几家的产品定位统一是"给 AI agent/爬虫用的短任务浏览器",不是为"小时级音视频录制"设计的——会话时长上限普遍是分钟到小时级(Steel 标准档只给 1 小时),想跑到"直播录几个小时"这个量级基本都要单独谈 Enterprise 定制价,而且没有一家把 DRM/媒体播放能力当卖点写进文档。直接买不能替代自建,顶多拿来做局部原型验证(比如先用 Steel/Browserbase 快速验证 2.2/2.3 节的技术假设,不代表最终生产架构应该基于它们)。
七、$/路·时 成本模型(附全部假设)¶
假设清单(请逐条检视,任何一条改变结论都会变):
- 内容:1080p 直播,文件体积按产品文档自己的假设沿用,约 3GB/小时。
- 计算实例:Linux,x86,以 AWS c7i.2xlarge(8 vCPU/16GB,$0.357/时按需价)为基准——用按需价不用 spot,因为录制任务对中断敏感,拿可靠性换折扣不划算(见 5.1)。
- 并发密度:沿用第三节的推测区间——乐观(非 DRM/免解码)18 路/机,保守(DRM/真解码)8 路/机。
- 存储:按 Cloudflare R2 标准档单价 $0.015/GB·月计,搭配产品文档里"未订阅套餐则免费保留 7 天"的假设(7 天 ≈ 0.23 个月)。
- 出口带宽:假设用户平均下载 1 次;分别给出"R2/B2 路径"(出口免费)和"云厂商直连路径"($0.09/GB)两种,因为这项差距太大不能只给一个数。
| 项目 | 乐观(非 DRM,免解码,18 路/机) | 保守(DRM,真解码,8 路/机) | 来源/说明 |
|---|---|---|---|
| 算力(每路每小时) | $0.357 ÷ 18 ≈ $0.020 | $0.357 ÷ 8 ≈ $0.045 | 并发数为推测,单价确认 |
| 存储(每路每小时,按 7 天免费保留期摊到月单价) | 3GB × $0.015 × 0.23 ≈ $0.010 | 同左 $0.010 | R2 单价确认,3GB/小时和 7 天假设沿用产品文档 |
| 出口带宽(每路每小时,下载 1 次,R2/B2 路径) | ≈ $0 | ≈ $0 | R2 零出口费确认 |
| 出口带宽(每路每小时,下载 1 次,云厂商直连路径) | 3GB × $0.09 ≈ $0.27 | 同左 $0.27 | AWS/Azure 直连单价确认 |
| 合计 · R2 路径 | ≈ $0.03/路·时 | ≈ $0.055/路·时 | |
| 合计 · 云厂商直连路径 | ≈ $0.30/路·时 | ≈ $0.33/路·时 |
Windows 版本再加算力项 30%~100%+ 溢价(存储/带宽不受操作系统影响,不变):乐观情况下算力从 $0.020 变成 $0.026~$0.04+,保守情况从 $0.045 变成 $0.059~$0.09+。
这张表最该拍板的三件事(按影响力从大到小排)¶
- 并发密度是最大的未知数,不是云厂商选择。乐观和保守两栏之间差了 2.25 倍($0.02 vs $0.045),这个差距完全取决于"DRM 流能不能规避真解码"这一个技术判断——在没有做 PoC 之前,任何单一数字都不该被当成定价依据。这正是产品文档 R3 要验证的事,建议先出这个数字,再谈定价。
- 出口带宽路径的选择($0 vs $0.27)比并发密度的影响还要大,而且这是纯商务决策,不需要技术验证——选 R2/B2 这类零出口费的对象存储做"冷存储 + CDN 分发",而不是让用户直连 AWS/GCP/Azure 下载,几乎是免费的成本优化,应该优先锁定。
- 和产品文档 Appendix 3 原有"$0.1x/时"的估算做个对照:本次研究给出的乐观区间($0.03/路·时,走 R2)比原估算更低,保守区间($0.33/路·时,DRM + 直连)比原估算更高——原估算的量级本身没有错,只是没有把"DRM 与否"和"出口带宽路径"这两个能相差一个数量级的变量拆开看。建议定价锚点按保守情况($0.055~$0.09/路·时,DRM+R2 组合)留出安全边际,而不是按乐观情况的 $0.02~$0.03 去定价,除非已经确认 DRM 流也能做到免解码。
附:本次研究方法论说明¶
本报告所有数字均来自公开网页搜索(WebSearch)与网页抓取(WebFetch),没有做任何实测。标注"推测"的内容是基于已确认事实做的第一性原理推导,不是凭空猜测,但也没有实测验证——尤其是第三节的并发密度数字和第二节"能否规避解码"的判断,这两项直接决定第七节成本模型的乐观/保守区间宽窄,是 PoC 阶段最优先要验证的两件事,验证结论出来后应该回来更新本文档,而不是继续拿推测数字做定价依据。