Firecrawl 自托管配置：CPU、内存与显卡要求

猫仔 技术创作者 2026-11-03 292 阅读

截至 2026 年 7 月 30 日抓取时，Firecrawl 自托管的硬件瓶颈主要在 Playwright 无头浏览器，而不是显卡：API 服务建议至少 4 vCPU、8 GB 内存，Playwright 建议至少 2 vCPU、4 GB 内存，持续抓取时宜准备 8 GB 以上。之所以现在值得重新核对，是因为 Firecrawl 官方仓库已同时提供云端 API 和开源自托管方案，配置选错会直接导致抓取过程中被系统终止。

下文中的官方能力和命令来自 Firecrawl 官方文档与仓库；资源数字来自部署平台对上游配置的记录，凡属平台建议或据此得出的选型判断均单独注明。

先选运行模式：不要为 API 请求购买本地服务器

Firecrawl 是给 AI Agent 提供网页搜索、页面抓取和结构化数据的 API。若只需要在自己的脚本、Claude Code、Cursor 或其他 MCP 客户端中调用它，直接使用云端 API 最省事：本机无需运行 Firecrawl 服务，也不需要配置独立 CPU、内存或显卡。

云端 API 的试请求甚至不要求账号或 API Key。需要更高限额时，再创建免费账号并取得 API Key：

curl -s -X POST "https://api.firecrawl.dev/v2/scrape" 
-H "Content-Type: application/json" 
-d '{
"url": "https://firecrawl.dev",
"formats": ["markdown", "html"]
}'

如果响应中出现 "success": true 和 data，说明 API 已经可用。这个请求来自 Firecrawl 官方文档 Introduction。

只有当页面必须在内网处理、数据不能交给 Firecrawl 云端，或者需要自行部署完整爬取队列时，才需要本地或服务器部署。官方仓库的 Firecrawl MCP Server 同时支持云端与自托管，但它属于 MCP（Model Context Protocol，模型上下文协议）服务层：MCP 是让 AI 客户端调用外部工具的一套接口约定，并不等于已经替你配置好浏览器和爬虫容器。

使用方式 本地需要部署 Firecrawl CPU 与内存重点 显卡要求 适合谁
云端 API 否 本机只承担普通客户端开销 官方测试页未提出独立显卡要求 个人脚本、Agent 集成、快速验证
本地 MCP Server 视后端而定 MCP 客户端本身较轻，后端资源另算 官方仓库测试页未提出独立显卡要求 需要连接 Cursor、Claude 等 MCP 客户端
自托管 API 是 API 建议至少 4 vCPU、8 GB 内存 来源未列出最低显存 内网部署、长期批量任务
自托管 Playwright 是 最低建议 2 vCPU、4 GB；生产宜 8 GB 以上 来源未列出最低显存 JavaScript 页面、动态交互、持续抓取

CPU 与内存怎么配：先看有没有浏览器渲染

根据 Zeabur 的 Firecrawl 部署说明，上游 docker-compose.yaml 的资源建议是：API 服务至少配置 4 vCPU、8 GB RAM，Playwright 服务至少配置 2 vCPU、4 GB RAM。这不是 Firecrawl 官方文档统一公布的套餐配置，因此它更适合作为部署基线，而不是所有场景的硬性下限。

部署 Firecrawl 到 Railway 的说明进一步指出，Headless Chromium，也就是 Playwright 使用的无界面浏览器，是内存占用最高的组件：4 GB 可以支撑轻量使用，但持续抓取时可能不够，生产环境建议为 Playwright 准备 8 GB 或更多内存。

按实际任务选择：

  1. 只抓静态网页：先用 2 vCPU、4 GB 内存测试 API 服务，不启动不需要的浏览器渲染流程。
  2. 偶尔抓 JavaScript 页面：至少给 Playwright 2 vCPU、4 GB 内存，并观察抓取期间是否发生内存回收或进程退出。
  3. 持续或并发爬取：先按 API 4 vCPU、8 GB、Playwright 8 GB 以上配置，再依据并发数增加资源。
  4. 多人共享的内部服务：不要照搬个人电脑配置，优先使用独立服务器或可单独扩容 Playwright 服务的部署平台。

这是按上述部署资料作出的选型判断：资源应随渲染任务和并发量增加，而不是只按官网演示页的复杂度估算。

显卡要不要买：目前没有独立显卡门槛

已给出的 Firecrawl 官方文档和 MCP Server 仓库说明都没有列出最低 GPU 型号、显存容量或 CUDA 要求；第三方部署资料同样只讨论 CPU 与内存。由此可以判断，搜索、静态页面抓取、解析及常规 MCP 调用不应把独立显卡列为采购前提。

动态网页确实需要浏览器执行 JavaScript，但这不等于必须使用 GPU。现有资源建议也只把 Playwright 的 CPU 和内存列为主要瓶颈。因此，服务器没有独立显卡也能先部署和验证。

需要注意，这不等于所有浏览器功能都没有计算差异：视频页面、超大脚本或特殊渲染任务可能增加 CPU 压力，但现有来源没有给出可复现的显卡门槛，不能据此声称“显存必须达到某个数值”。如果业务确有这类页面，应先记录失败页面和抓取耗时，再针对具体任务做扩容，而不是预先购买显卡。

按三步装好并验证

1. 取得官方代码并确定部署入口

进入 Firecrawl 官方仓库，选择 Code → Download ZIP，下载并解压源码。仓库还提供完整文档索引：Firecrawl llms.txt。在索引中搜索 Self-hosting，再进入对应页面核对当前容器参数；这样可以避免照抄旧教程中的端口、镜像名或配置项。

部署前确认三项：

  1. 服务器能运行项目当前 README 指定的容器版本，运行 docker --version 能看到版本号。
  2. API 与 Playwright 分开规划内存，不要把两者都放进同一个低配容器（部署资料的建议是 API ≥4 vCPU/8GB、Playwright ≥2 vCPU/4GB）。
  3. 若采用云端 API，只需准备 API Key；不要额外搭建本地爬取服务。

取到源码后的自托管启动命令（上游 compose 的五件套：postgres、redis、rabbitmq、playwright-service、api）：

cd firecrawl/docker        # 以仓库当前 compose 文件所在目录为准
docker compose up -d       # 一次拉起五个服务
docker compose ps          # 五项都应为 Up / running

镜像名与数量以上游 compose 为准（本次抓取到的五件套为 nuq-postgres、redis:7-alpine、rabbitmq:3-management、ghcr.io/firecrawl/playwright-service、ghcr.io/firecrawl/firecrawl），少一项都会导致后续抓取链路缺环节。

2. 需要 MCP 客户端时运行官方初始化命令

MCP Server 可让兼容 MCP 的 AI 客户端调用 Firecrawl 的搜索、抓取、解析、爬站和页面交互能力。官方文档给出的完整初始化命令如下：

npx -y firecrawl-cli@latest init --all --browser

该命令会安装 Firecrawl CLI、在浏览器中完成认证，并为检测到的编码 Agent 添加技能。执行后需要重启编码 Agent，让客户端重新发现技能。

若接入现有 MCP 客户端，则应以 官方 MCP Server README 中的配置格式为准，填入云端 API Key，或按自托管说明指向自己的服务地址。

3. 用自托管地址做健康检查

这一步不要再打云端地址（第 1 节那条 api.firecrawl.dev 只是演示请求格式）。自托管的检查顺序是：

# ① 五服务活着（部署层）
docker compose ps
# ② 服务自身的健康端点——官方说明 GET /health 对任何 host 都应答，专为 health check 设计
curl -s http://localhost:3000/health
# ③ 用你自己的部署地址发起抓取（把主机换成你的 API 服务地址）
curl -s -X POST "http://localhost:3002/v2/scrape" -H "Content-Type: application/json" -d '{"url":"https://firecrawl.dev","formats":["markdown"]}'

成功标志不是容器“正在运行”，而是 ③ 的响应中同时出现 "success": true、data 以及抓取结果（端口以你 compose 里 api 服务实际映射为准，上面的 3002 是常见默认值，改端口不影响判定逻辑）。

若使用 MCP 客户端，再让它调用一次 firecrawl_scrape。官方仓库对工具的定位很清楚：已知 URL、需要取得 Markdown 或符合指定结构的 JSON 时使用 firecrawl_scrape；需要发现站点 URL 时使用 firecrawl_map；需要抓取多页时才使用 firecrawl_crawl。

如果只有抓取动态页面失败，优先检查 Playwright，而不是先换显卡或升级 API 服务。

常见卡点：内存不足与工具用错

部署资料记录的高负载症状是：Playwright 服务在抓取途中被 OOM-killed，即进程因内存不足被系统终止。对应解法是把 Playwright 内存提高到 8 GB 以上；持续抓取仍不稳定时，再降低并发或扩容，而不是仅重启容器。

另一个常见误区是抓到搜索结果后立即启动整站爬取。官方仓库说明，firecrawl_search 返回结果摘要和链接；需要全文时，只对选中的 URL 调用 firecrawl_scrape。如果把 scrapeOptions 放在搜索请求中，每个结果都会作为一次 scrape 计费并抓取全文。

因此，排查顺序应是：

  1. 先用单个已知 URL 验证抓取。
  2. 再验证搜索，只取少量结果。
  3. 最后测试多页 crawl，并观察 Playwright 内存与任务数量。
  4. 只有动态页面失败时才检查浏览器渲染配置。

怎么算配置成功

完成部署后，应同时看到三类可观察结果：

  • CLI 初始化后，重启的 Agent 能识别 Firecrawl 技能。
  • 把 /v2/scrape 的主机换成自己的部署地址后，返回 "success": true 和 data（云端那条演示请求不算自托管验收）。
  • 在持续抓取期间，Playwright 容器没有再次出现 OOM-killed，API 请求也没有因资源不足超时。

如果只验证了演示页，不能据此证明高并发配置成功。最终应使用自己的目标站点跑一轮接近生产负载的任务；这是基于官方工具职责与部署资料给出的验证方法，不是官方公布的性能测试标准。

官方入口与后续配置

参考来源

# AI# 知识

评论区

0 条评论

登录后可评论。

猫仔 292 阅读