Firecrawl 硬件要求：4 vCPU、8GB 内存与显卡怎么选

Firecrawl 是面向 AI Agent 的网页搜索与抓取 API；使用云端服务通常不占用本地算力，自托管才需要按浏览器渲染量配置 CPU 和内存。

截至 2026 年 11 月 2 日，Firecrawl 官方同时提供云端 API、开源项目和 MCP Server（模型上下文协议服务器）。值得现在重新核对硬件要求，是因为接入个人脚本、Cursor 与完整自托管属于三种不同负载：只有后两种可能需要额外的浏览器与爬虫资源。

本文把官方明确说明的能力，与部署平台记录的 Firecrawl 资源建议分开标注；硬件数值来自平台对上游配置的记录，不写成 Firecrawl 官方承诺。

先选运行模式，别先买机器

只在自己写的 Python、Node.js 脚本或 Agent 工具中调用 Firecrawl，应直接使用云端 API。此时本地机器只负责发送请求和接收结果，不运行 Firecrawl 爬虫，也不承担 Playwright 浏览器渲染。

官方首页提供的试请求不需要账号或 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"]
}'

如果只是让 Claude Code、Cursor 或其他兼容 MCP 的客户端调用 Firecrawl，可使用官方 MCP Server。它既支持连接云端 Firecrawl，也支持自托管后端，因此“MCP Server 在本机运行”并不自动等于“本机还要部署整套爬虫”。

只有数据必须留在内网、必须自建爬取队列，或者批量任务需要自行控制执行环境时，才值得准备服务器。

这是使用方式对照，不是官方硬件评级。表中 4 vCPU、8 GB RAM 来自部署平台记录的 upstream 配置建议；官方首页和 MCP Server README 本身没有给出 CPU、内存或显存的最低值。

需要自托管时，CPU 和内存按容器拆开看

部署平台对上游 docker-compose.yaml 的记录显示：API 服务建议至少配置 4 vCPU、8 GB RAM，Playwright 服务建议至少配置 2 vCPU、4 GB RAM，并建议使用 Pro 套餐或独立服务器。

这里最容易被误配的地方，是把“整个 Firecrawl 需要多少资源”理解成一个固定数字。API 与 Playwright 是不同工作负载：前者负责接口、队列和调度，后者启动浏览器执行页面渲染。前者有较高并发请求时，内存和调度压力更明显；后者频繁抓取 JavaScript 页面时，浏览器进程才是主要负担。

按已有记录做选型，可采用下面的边界：

• 只验证 API 功能和连接方式：先做小规模测试，不直接按长期生产规格采购。
• 少量动态页面：给 Playwright 容器至少 2 vCPU、4 GB RAM。
• 持续抓取或多页 Crawl：把 Playwright 的内存余量提高到 8 GB 以上。
• 整个自托管环境同时运行 API 与浏览器：先按 API 4 vCPU、8 GB RAM、Playwright 2 vCPU、4 GB RAM 的组合验证，再根据队列长度和并发数扩容。

“持续抓取时准备 8 GB 以上”属于基于资源瓶颈作出的选型判断，不是官方给出的最低配置。真正需要扩容的信号包括容器被系统终止、浏览器响应明显变慢，以及任务队列持续积压；只看到单次请求变慢时，还不能直接认定是内存不足。

显卡要不要买：官方材料没有给出最低显存

就本次核对到的 Firecrawl 官方首页和 MCP Server README 而言，没有出现最低显存、CUDA 或 GPU 加速要求。官方仓库列出的主要能力是搜索、页面抓取、文档解析、站点 Crawl、URL Map、浏览器交互、Agent 任务和内容监控。

这意味着，自托管 Firecrawl 的典型任务并不是本地训练或推理大模型，而是网页访问与内容提取。因此选机器时，先把预算放在 vCPU、内存、磁盘和网络上，不要因为部署了 AI 工具就直接配置消费级显卡。

这是根据已列功能作出的边界推导，不等于官方承诺“永远不需要 GPU”。如果后续工作流另行加入本地视觉模型、批量截图分析或本地模型推理，GPU 需求应由那个新增组件决定，而不能继续沿用 Firecrawl 页面抓取的资源结论。

部署前按这三项完成可执行检查

1. 确认调用模式。 在脚本或 MCP 客户端配置中检查 Firecrawl 后端地址：使用 https://api.firecrawl.dev 时，本机无需部署 API 与 Playwright；只有地址指向自己的服务器时，才继续检查服务器资源。
2. 确认浏览器服务是否单独运行。 查看部署平台的容器列表，应能看到 API 与 Playwright 的职责和资源配额；不要只看到 API 容器正常就认定动态页面抓取具备足够资源。
3. 用最小请求验证链路。 执行前面的 curl 抓取命令，检查返回结果是否包含 success: true 和 data。随后再访问包含 JavaScript 渲染的测试页面，以确认 Playwright 路径确实可用。

如果只想快速接入 Agent，也可以直接执行官方首页给出的 CLI 初始化命令：

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

该命令会安装 Firecrawl CLI、通过浏览器完成认证，并给检测到的编码 Agent 添加 skills。官方特别提示：初始化后要重启编码 Agent，让客户端重新发现这些 skills。这里需要浏览器参与的是本机认证和后续交互流程，不意味着必须准备一块 GPU。

常见卡点：先判断请求落在哪一层

安装后 Agent 仍找不到 Firecrawl 工具：先重启编码 Agent。官方初始化说明明确要求重启，原因是 skills 不会在已经运行的会话中自动重新发现。

动态页面返回空内容或缺少目标元素：检查 Playwright 容器是否启动，以及浏览器渲染路径是否能访问目标 URL。静态抓取能返回内容，并不能证明 Playwright 已正常工作；分别用普通页面和动态页面测试，能把 API、浏览器与目标站点问题拆开。

请求频率很快触顶：先申请 API Key，再观察 Firecrawl 返回的限额信息。官方试请求允许在没有 API Key 的情况下运行，但明确说明增加 Key 可获得更高限额。MCP Server 还提供 firecrawl_credit_usage 工具，可查看按月或按日使用的额度。

搜索结果只有摘要，没有完整正文：这是调用方式差异，不一定是服务器故障。官方 MCP README 说明，搜索结果自带摘要；为少量结果获取全文时，应再对这些 URL 调用 firecrawl_scrape。如果在同一搜索调用中启用全文抓取，每个结果都会按一次 scrape 计费。

怎么确认配置成功

云端调用成功时，响应中应出现 success: true，抓取结果位于 data。搜索接口也可用下面的官方命令验证：

curl -s -X POST "https://api.firecrawl.dev/v2/search" 
-H "Content-Type: application/json" 
-d '{
"query": "firecrawl",
"limit": 3
}'

自托管还应多看两处：部署平台的容器状态应持续为运行，任务日志中不应反复出现浏览器启动失败或进程被终止；动态页面的测试结果则应包含脚本渲染后才出现的正文。确认这些标志后，才能判断不是“容器启动了，但实际不可抓取”。

官方入口与仓库

• Firecrawl 官方文档：云端 API、CLI、SDK、端点与自托管入口。完整文档索引位于 llms.txt。
• Firecrawl MCP Server 官方仓库：MCP 配置、云端与自托管支持、工具选择及额度查询说明。
• Firecrawl 开源项目官方仓库：完整自托管代码、服务组成与部署配置入口。

参考来源

• Firecrawl 自托管配置：CPU、内存与显卡要求
• Firecrawl 部署教程 – Zeabur 将于 2026/12/31 停止运营Zeabur 将于 2026/12/31 停止运营，部分服务 12/1 起陆续停止
• Firecrawl 部署教學