Remotion 渲染脚本在 Node.js 层面是“单线程 JS”但在实际渲染时是“高度并行”的。我给你一个非常明确、工程级的结论不绕概念。✅ 一句话结论你的脚本JS 主逻辑单线程Remotion 实际渲染多线程 多进程最终效果是会吃满 CPU 详细拆解1️⃣ Node.js JS 层确实是单线程await bundle(…)await selectComposition(…)await renderMedia(…)• 这些都是 异步但串行• 没有• worker_threads• Promise.all并发渲染• 手动多进程✅ JS 执行模型 单线程 Event Loop2️⃣ 但 renderMedia() 内部 ≠ 单线程重点remotion/renderer 在底层做了这些事 PuppeteerChrome• 启动 Chrome 进程• 每一帧 从 Chrome 截图 / 抓取媒体• Chrome 本身是 多线程 GPU 加速 帧渲染并发Remotion 会• 并行渲染多个帧不是一帧一帧死循环• 使用 线程池 / 并发任务队列即使你没有写并发代码Remotion 已经帮你并发了 音频处理• 音频混合、编码• 使用 FFmpeg / 原生音频库• FFmpeg 是 重度多线程✅ 实际渲染 多进程 多线程3️⃣ 你这个脚本的真实并发情况层级 是否多线程Node.js JS 主线程 ✅ 单线程Puppeteer / Chrome ❌ 多线程帧渲染并发 ❌ 多线程FFmpeg 编码 ❌ 多线程音频混合 ❌ 多线程 结论CPU 会被吃满4️⃣ 为什么你感觉“像单线程”因为• 你看到的日志是 线性打印• onProgress 是回调汇总后的结果• JS 没写 for spawn但这只是 API 封装得好不是真的单线程。5️⃣ 如果你想控制并发很重要Remotion 支持限制并行度防止机器卡死await renderMedia({composition,serveUrl: bundled,codec: “h264”,outputLocation: outputPath,browserExecutable: CHROME_PATH,concurrency: 4, // ← 最大并行帧数});推荐设置Windows 桌面 CPUCPU concurrency8 核 4–612 核 6–816 核 8–10如果不设• Remotion 会自动根据 CPU 核心数决定• 很容易 100% 占满6️⃣ 最终总结给你一个“能拿去说”的版本该脚本在 Node.js 中是单线程执行但由于 Remotion 内部使用 Chrome FFmpeg 帧级并发渲染实际渲染过程是多线程、多进程的能够充分利用多核 CPU。如果你愿意我可以帮你• ✅ 评估当前渲染是不是 CPU 瓶颈• ✅ 优化 concurrency Chrome 参数• ✅ 判断 音频渲染慢 还是 帧渲染慢• ✅ 给你一套 Windows 下最稳的 Remotion 配置那我就专门针对你的这颗 1055T6 核老 U给你一套能跑、不炸机、尽量快的 Remotion 渲染配置。下面都是实战向结论不是理论。✅ 一、先给结论直接用✅ 推荐 renderMedia 参数1055T 专用await renderMedia({composition,serveUrl: bundled,codec: “h264”,outputLocation: outputPath,browserExecutable: CHROME_PATH,// ✅ 关键限制并发concurrency: 2,// ✅ 降低 Chrome 资源占用chromiumOptions: {args: [“–disable-gpu”,“–disable-dev-shm-usage”,“–single-process”,],},onProgress: ({ progress, stage }) {const pct (progress * 100).toFixed(1);if (progress % 0.05 0.005) {console.log([${stage}] ${pct}%);}},}); 二、为什么这样配针对 1055T1️⃣ concurrency: 2 是最稳选择设置 结果concurrency: 3 ⚠️ 容易满载、掉速concurrency: 4 ❌ 严重卡顿 / 崩溃concurrency: 2 ✅ 稳定 可接受速度原因• 1055T 单核弱• Chrome FFmpeg 本身就很吃线程• 留点余量给系统避免 IO / 音频卡死2️⃣ --single-process 非常关键这颗 U 不适合 Chrome 多进程默认 Chrome├─ Browser├─ Renderer × N├─ GPU├─ Audio 在 1055T 上会• 进程爆炸• 上下文切换暴增• 渲染反而变慢✅ --single-process 能把 Chrome 压成一个进程3️⃣ 禁用 GPU老硬件必做“–disable-gpu”• 1055T 没好 GPU• Windows 老显卡驱动 Chrome GPU 崩溃高发 三、还能再快一点的小技巧可选✅ 1. 降低分辨率渲染强烈推荐如果是教程视频// Composition 里export const HpcTutorial {width: 1280,height: 720,fps: 30,}; 比 1080p 快 23 倍✅ 2. 音频慢多半是 FFmpeg你可以强制用本地 FFmpeg更快await renderMedia({ffmpegExecutable: “C:\ffmpeg\bin\ffmpeg.exe”,});不要用 Remotion 自带的那套✅ 3. 内存别爆1055T 通常只有 8GchromiumOptions: {args: [“–max-old-space-size2048”,],} 四、预期性能参考真实经验值视频 1055T 表现720p301 分钟 ✅ 2–3 分钟1080p301 分钟 ⚠️ 5–8 分钟大量音频轨道 ❌ 明显变慢✅ 五、最终总结你可以直接记住这句1055T 跑 Remotionconcurrency 2 Chrome 单进程 720p 最稳解如果你愿意下一步我可以帮你• ✅ 判断 现在是 CPU / IO / 音频瓶颈• ✅ 给你一个 “最低配置可跑”的 Remotion 模板• ✅ 或直接帮你 算一版 1055T 的极限渲染参数你可以直接说一句 “帮我分析现在是不是卡在音频”