浏览器自动化成本（二）：代理和计算资源优化

代理优化：不省钱，但省钱不是目的

代理在总成本中占比不高，但代理配置不当会导致任务失败率上升，进而提高 Token 成本（失败重试需要更多的 LLM 推理）。

正确的代理选型决策

目标网站有没有反爬？
├── 没有 → 数据中心代理就够了（最便宜）
├── 有，但不严格 → 爬虫代理（隧道模式）
└── 有，Cloudflare Turnstile 等 → 住宅代理 / 独享代理 + GeoIP 对齐

不要默认用最贵的代理。先试试便宜的，被检测到再升级。

代理复用策略

代理连接的复用可以降低延迟：

class ProxySessionPool:
    """代理连接池——减少 TCP 握手次数"""
    def __init__(self, proxy_url, pool_size=10):
        self.session = requests.Session()
        self.session.proxies = {
            "http": proxy_url,
            "https": proxy_url,
        }
        # 使用连接池
        adapter = requests.adapters.HTTPAdapter(
            pool_connections=pool_size,
            pool_maxsize=pool_size * 2,
        )
        self.session.mount("https://", adapter)

出口 IP 的合理使用

场景	IP 需求	频率	成本
公共数据采集	轮换 IP	每次请求	高
登录态维护	固定 IP	不变	中
数据验证	少量 IP	低频	低

计算资源优化

选择对的实例类型

浏览器是内存密集型，不是 CPU 密集型。选择内存配比高的实例：

云服务商	推荐实例	vCPU	内存	月成本（按需）
AWS	r6i.large	2	16GB	~$70
AWS	r6i.xlarge	4	32GB	~$140
GCP	n2-highmem-2	2	16GB	~$60
Azure	E2s v5	2	16GB	~$75

并发数与实例配比

一个 16GB 的实例可以运行大约：

4-6 个简单页面浏览器实例（每个 256MB-512MB 请求）
2-3 个复杂 SPA 浏览器实例（每个 1GB 请求）
1-2 个多标签页浏览器实例（每个 2GB+ 请求）

超过这个密度，频繁的 GC 和 OOM 会导致任务失败率上升，反而提高了总成本。

预热池

对于对延迟敏感的场景，预热池可以减少启动成本：

# 预热池脚本——始终保持 N 个已启动的 Chrome 实例
WARM_POOL_SIZE=5
WARM_POOL_DIR="/tmp/warm-pool"
 
for i in $(seq 1 $WARM_POOL_SIZE); do
  google-chrome \
    --user-data-dir="${WARM_POOL_DIR}/instance-${i}" \
    --remote-debugging-port=$((9222 + i)) \
    --headless=new &
done

预热池在空闲时也在消耗内存（每个约 150MB），所以需要评估延迟收益是否值得这个开销。

规模化后的成本曲线

日任务量	Token 成本（Gemini Flash）	代理成本	计算成本	总成本
1,000	$9	$0.10	$1.50	~$11
10,000	$90	$1.00	$15	~$106
100,000	$900	$10	$150	~$1,060
1,000,000	$9,000	$100	$1,500	~$10,600

Token 成本始终占大头，且随任务量线性增长。代理和计算资源可以通过规模化摊薄，但 Token 不行。

总结

代理和计算资源的优化建议：

代理不要过配——根据目标网站的防护等级选择合适的代理类型
实例选型要匹配——浏览器用高内存配比的实例，不要浪费 CPU 资源
预热池评估后再用——不是所有场景都需要
规模化不降 Token 单价——Token 成本是线性增长的，没有规模效应

AI 浏览器自动化成本分析（二）：代理和计算资源的优化清单