私有化AI视频生成工作流：Seedanc 2.0与Nano-Banana-2部署实践

1. 项目概述：这不是又一个“AI玩具”，而是一套可落地的私有化内容生成工作流

Seedanc 2.0 和 Nano-Banana-2 这两个名字听起来像极了开源社区里常见的那种“炫技型”项目——起个带点科幻感的代号，发个 GitHub README，配几张惊艳的 demo 图，然后就沉入茫茫仓库海洋。但如果你真花十分钟翻过它的 GitHub Issues、Discussions 和最近三个月的 commit 记录，会发现它走的是另一条路：把视频生成和图像生成这两类最吃资源、最难调教的大模型能力，硬生生塞进中小团队能自主掌控的私有服务器里，并且让非算法背景的前端、运维甚至产品经理，也能在三天内完成从零部署到产出可用内容的闭环。它不追求 SOTA 指标，但死磕“能用、好改、不掉链子”。核心关键词 Seedanc、Nano-Banana-2、部署教程、Node.js、PM2，不是随意堆砌的标签，而是整套系统的技术锚点：Seedanc 是那个负责把文字指令翻译成视频时间轴与镜头语言的“导演大脑”，Nano-Banana-2 是那个在本地 GPU 上安静作画、不依赖任何云 API 的“画室”，而 Node.js 和 PM2，则是把这两个高冷模块拧成一股绳、让它 7×24 小时稳定呼吸的“工业级胶水”。我去年在给一家教育科技公司做内容中台升级时，就踩着初代 Seedanc 的坑一路摸爬滚打过来——当时为了跑通一个 15 秒的课程动画，光是模型加载失败就重试了 27 次，显存溢出日志堆了半屏。所以这次 2.0 版本发布前，我提前拿到了 beta 包，带着三台不同配置的测试机（一台 i9+RTX4090 工作站，一台 AMD EPYC+L4 服务器，还有一台被同事戏称为“电子古董”的 i7-8700K+GTX1080Ti 笔记本）反复压测。结果很实在：在 1080Ti 这台老机器上，Nano-Banana-2 的单图生成耗时从初代的 42 秒压到了 28 秒，而 Seedanc 2.0 的视频合成环节，首次实现了对输入文本的“分镜预判”——它会自动识别你文案里的“镜头切换”、“特写”、“慢动作”等关键词，在生成前就规划好帧率变化和关键帧位置，而不是像初代那样傻等所有中间帧算完再拼接。这意味着什么？意味着你不用再为“为什么生成出来的视频节奏像喝醉了”这种问题抓耳挠腮。这套系统真正瞄准的，是那些手握真实业务场景、却苦于 AI 工具太“黑盒”、太“娇气”、太“不听使唤”的一线内容生产者。它不承诺“一键大师级成片”，但保证“你改一行 prompt，就能看到这一行 prompt 对画面或节奏的真实影响”。

2. 系统架构与选型逻辑：为什么是 Node.js + PM2，而不是 Docker Compose 或 Kubernetes？

2.1 核心矛盾：大模型的“重”与业务系统的“轻”如何共存？

很多人看到“视频生成大模型”和“绘画私有化系统”这两个词，第一反应就是上 Docker，拉几个官方镜像，配个 docker-compose.yml，再加个 Nginx 反向代理，齐活。这思路没错，但放到 Seedanc 2.0 和 Nano-Banana-2 这对组合身上，就会立刻撞上三堵墙。第一堵是GPU 资源调度墙。Docker 默认的 nvidia-container-toolkit 虽然能透传 GPU，但它把整个容器当做一个黑盒来管理。而 Nano-Banana-2 的推理引擎（基于 PyTorch 2.3 + CUDA 12.2）对显存碎片极其敏感——它需要一块连续的、至少 8GB 的显存空间才能启动一个基础的 SDXL 画质模型。如果用 Docker 启动多个服务实例，每个实例都申请 8GB，哪怕你的卡有 24GB，也极大概率因为碎片化而报错CUDA out of memory。第二堵是热更新墙。Seedanc 2.0 的核心是一个用 TypeScript 编写的规则引擎，它负责解析用户输入的自然语言，拆解成镜头脚本、运镜参数、BGM 选择逻辑。这个规则库是业务方自己维护的，每周都要根据市场反馈迭代。Docker 镜像一旦构建完成，更新就得重新 build、push、pull、restart，整个过程至少 3 分钟。而 Node.js + PM2 的方案，只需要把新规则文件 scp 到服务器，执行一条pm2 reload seedanc命令，2 秒内新规则就生效了，用户无感知。第三堵是调试墙。当 Seedanc 生成的视频出现“人物眨眼频率异常”这类玄学 bug 时，你需要的不是看一串容器日志，而是能直接 attach 到进程里，用 VS Code 的 debugger 实时查看某个calculateBlinkInterval()函数的返回值。Node.js 进程天然支持这种深度调试，而 Docker 容器则需要额外配置调试端口、挂载源码、处理权限，步骤繁琐且容易出错。所以，最终架构图非常“反潮流”：它没有华丽的微服务网格，没有 Service Mesh，就是一个精简的三层结构——最上层是 Node.js 编写的 API 网关（Seedanc），中间层是 Python 编写的模型推理服务（Nano-Banana-2），底层是操作系统和 GPU 驱动。Node.js 不是作为“胶水”，而是作为整个系统的“神经中枢”和“调度员”，它用 HTTP 协议与 Python 服务通信，用 PM2 管理自身生命周期，并通过一套自研的gpu-pool-manager模块，实时监控每块 GPU 的显存占用、温度、功耗，动态决定把哪个用户的绘图请求分发给哪张卡。这个设计看起来“土”，但它把最复杂的资源调度问题，从容器编排层下沉到了应用逻辑层，反而获得了更高的可控性和更低的运维成本。

2.2 Node.js 版本选择：为什么必须是 v20.12.1，而不是最新的 v24 或 v26？

网络热词里反复出现node.js v24.16.0 is not yet released or is not available和warn cli npm v10.8.1 does not support node.js v16.20.2，这恰恰暴露了当前 Node.js 生态最真实的痛点：版本兼容性不是线性演进，而是断崖式跳跃。Seedanc 2.0 的 package.json 里，engines字段被严格锁定为"node": ">=20.12.1 <21.0.0"。这个数字不是拍脑袋定的，而是我们团队在 12 台不同 OS（Ubuntu 22.04/24.04, CentOS 7/8, macOS Sonoma/Ventura）的机器上，用自动化脚本跑了 72 小时压力测试后得出的结论。v20.12.1 是一个关键的“黄金交叉点”：它完整支持 ES2022 的所有特性（比如Array.prototype.findLastIndex，Seedanc 的分镜逻辑大量依赖这个），同时其内置的 V8 引擎版本（11.8.172.18）与 PyTorch 2.3 的 C++ ABI 兼容性最佳——这是通过ldd命令比对libtorch.so和node二进制文件的符号表确认的。而 v24.x 系列，虽然带来了更快的fetchAPI 和更好的 WASM 支持，但它默认启用了--experimental-permission沙箱机制，这个机制会拦截 Seedanc 代码里所有对/dev/shm（共享内存）的访问，而 Nano-Banana-2 正是通过/dev/shm来高速传递百万级像素的中间图像数据的。我们试过用--no-experimental-permission参数强行关闭，但随之而来的是npm install时node-gyp编译canvas模块失败，错误信息是fatal error: 'v8.h' file not found。至于 v26，它连node-gyp的最新版都不支持，官方文档明确写着 “v26 requires node-gyp v10+，but current stable v10.8.1 only supports up to v24”。所以，别被“最新版”三个字迷惑。在这个项目里，“最新”等于“不可用”。我们甚至在部署脚本里加了一行强制校验：if [ "$(node -v | cut -d'v' -f2 | cut -d'.' -f1,2)" != "20.12" ]; then echo "Node.js version mismatch! Please use v20.12.1"; exit 1; fi。这行代码看着有点“霸道”，但它省去了后续 90% 的线上故障排查时间。顺便说一句，网上那些教你“同时安装多个 Node.js 版本”的教程（比如 nvm），在生产环境里是个巨大的陷阱。nvm 本质是 shell 函数，它修改的是$PATH，而 PM2 启动的进程是脱离 shell 环境的 daemon 进程，它根本读不到 nvm 设置的NODE_VERSION。所以，生产环境只认/usr/bin/node这个硬链接，你必须用update-alternatives或者直接ln -sf /opt/node-v20.12.1/bin/node /usr/bin/node来确保全局一致性。

2.3 PM2 的角色：远不止是“让 Node.js 进程不死”

把 PM2 简单理解为“进程守护工具”，是对它最大的误解。在 Seedanc 2.0 的部署体系里，PM2 承担着三个远超其名义职责的核心任务。第一个是资源熔断器。我们在ecosystem.config.js里配置了max_memory_restart: '1.5G'，但这只是表象。更关键的是watch_options下的usePolling: true和interval: 1000。这意味着 PM2 不是被动等待进程崩溃，而是每秒主动轮询一次 Seedanc 主进程的 RSS（常驻集大小）。一旦发现 RSS 在 5 秒内增长超过 300MB，它就会立即触发pm2 restart，并记录一条Memory surge detected, restarting to prevent OOM的告警日志。这个机制，成功拦截了我们测试中 83% 的因长文本解析导致的内存泄漏事故。第二个是灰度发布控制器。Seedanc 2.0 支持 A/B 测试，比如同一套文案，可以同时用旧版分镜规则和新版规则生成两版视频，供运营同学对比点击率。PM2 的instances: 2和exec_mode: 'cluster'配合env环境变量，让我们能轻松实现：pm2 start ecosystem.config.js --env production-old启动旧版，pm2 start ecosystem.config.js --env production-new启动新版，再通过 Nginx 的upstream按权重分发流量。第三个是可观测性入口。pm2 monit命令不只是看 CPU 和内存，它还能实时显示每个进程的HTTP requests/s、Response time (ms)、Error rate (%)。更重要的是，pm2 show seedanc输出的Status字段，会精确到online (since 2024-05-12T08:23:41.123Z)，这个时间戳，是我们判断“上次重启是否由人为操作触发”还是“系统自动熔断”的唯一依据。很多线上问题，根源就在于运维同学以为自己手动重启了服务，其实 PM2 因为内存超标已经默默重启了三次，而日志里没有任何人工操作记录。所以，PM2 在这里，是运维决策的“事实来源”，而不仅仅是进程的“保镖”。

3. 核心组件详解与实操要点：Seedanc 2.0 与 Nano-Banana-2 如何协同工作？

3.1 Seedanc 2.0：从“文字”到“分镜脚本”的精密翻译器

Seedanc 2.0 的核心价值，不在于它能生成多炫酷的视频，而在于它把“AI 视频生成”这个模糊概念，拆解成了工程师能理解、能调试、能优化的确定性步骤。它的输入是一个 JSON 对象，例如：

{ "prompt": "一只橘猫坐在窗台上，阳光透过玻璃洒在它毛茸茸的背上，窗外是模糊的绿色树影，镜头缓慢推进，最后定格在猫的眼睛上", "duration": 8, "style": "cinematic" }

而它的输出，不再是直接的.mp4文件，而是一份结构化的shotlist.json：

{ "shots": [ { "id": "shot_001", "start_time": 0, "end_time": 3.2, "prompt": "wide shot, orange cat sitting on windowsill, sunlight through glass, blurred green tree outside window, cinematic lighting", "camera_movement": "static", "resolution": "1920x1080" }, { "id": "shot_002", "start_time": 3.2, "end_time": 8.0, "prompt": "close-up, orange cat's eyes, shallow depth of field, catchlight in eyes, cinematic", "camera_movement": "dolly_in", "resolution": "1920x1080" } ], "audio": { "bgm": "calm_piano", "volume": 0.7 } }

这份shotlist.json，就是 Seedanc 2.0 的全部“作品”。它不做任何图像或视频渲染，只做一件事：精准地告诉下游的 Nano-Banana-2，“在什么时间，用什么提示词，生成什么构图的画面”。这个设计带来了革命性的优势。首先，它是可验证的。你可以把shotlist.json里的prompt字段单独复制出来，粘贴到 Nano-Banana-2 的 Web UI 里，立刻就能看到这张图生成的效果，从而快速定位是“文案理解错了”，还是“画图模型崩了”。其次，它是可干预的。运营同学不需要懂代码，只需要编辑这个 JSON 文件，把camera_movement从"dolly_in"改成"pan_left"，或者把start_time微调 0.1 秒，就能立刻改变最终视频的节奏感。最后，它是可复用的。一份shotlist.json可以被多个不同的画图模型消费——你可以用 Nano-Banana-2 生成高清图，也可以把它喂给另一个轻量级的tiny-diffusion模型，生成低分辨率的预览图，用于快速审核。实操中，最关键的一步是prompt的工程化处理。Seedanc 2.0 内置了一个prompt-engineer模块，它会自动执行三步操作：1)实体识别：用 spaCy 提取“橘猫”、“窗台”、“阳光”、“树影”这些核心名词；2)风格注入：根据style字段，自动追加cinematic lighting, film grain, Kodak Portra 400这类专业摄影术语；3)负面提示强化：自动添加nsfw, deformed, blurry, bad anatomy, text, watermark等通用负面词，并根据实体类型动态增强，比如识别到“猫”，就额外加上extra limbs, fused paws。这个模块的配置文件prompt_rules.yaml是纯文本，运维可以随时修改，无需重启服务。我见过最典型的误操作，就是有人把prompt_rules.yaml里的negative_prompt_weight从1.3改成了5.0，结果所有生成的图都变得“过度干净”，失去了应有的光影质感。所以，我们的部署文档里第一条注意事项就是：不要盲目调高 negative_prompt_weight，它不是越大越好，而是要和你的训练数据分布匹配。

3.2 Nano-Banana-2：在本地 GPU 上安静作画的“画室”

如果说 Seedanc 2.0 是导演，那么 Nano-Banana-2 就是那个不声不响、只管画画的美术指导。它的设计理念非常朴素：把 Stable Diffusion 的复杂性封装起来，只暴露最必要的接口。它不提供 Web UI（那是给开发者调试用的），也不开放模型权重下载（防止商业泄露），它只提供一个极简的 REST API：

curl -X POST http://localhost:8080/generate \ -H "Content-Type: application/json" \ -d '{ "prompt": "a photorealistic portrait of a young woman, soft focus background, natural light, 8k", "negative_prompt": "deformed, ugly, text, signature", "width": 1024, "height": 1024, "steps": 30, "cfg_scale": 7.5 }'

响应体是一个 JSON，包含image_url（指向一个临时存储的 PNG 文件）和generation_id（用于后续查询状态）。这个设计背后，是无数次被用户“玩坏”的教训。初代 Nano-Banana 的 Web UI 开放了所有参数，结果有用户把steps设成 200，cfg_scale设成 25，然后抱怨“生成一张图要 12 分钟”。2.0 版本直接砍掉了 UI，所有参数都在config.yaml里做了硬性限制：

model: name: "sdxl-base-1.0" precision: "fp16" # 强制使用半精度，速度提升 2.3 倍，显存占用减半 api_limits: max_width: 1280 max_height: 1280 max_steps: 50 min_cfg_scale: 5.0 max_cfg_scale: 12.0

任何超出范围的请求，都会被 API 网关直接拒绝，返回422 Unprocessable Entity。这看似“不友好”，实则是对生产环境最大的尊重。实操中，最需要关注的是model配置。Nano-Banana-2 预装了三个模型：sdxl-base-1.0（通用）、realistic-vision-v6.0（写实人像）、dreamshaper-8.0（艺术风格）。它们不是放在同一个目录下，而是各自独立的子目录，每个目录里都有一个model_index.json文件，定义了该模型的pipeline_class（如StableDiffusionXLPipeline）和safety_checker（安全过滤器）。部署时，你只需要修改config.yaml里的model.name，重启服务，整个系统就切换到了新模型。这个机制，让我们能在 5 分钟内，为不同客户定制专属的“画风”。比如给一家婚纱摄影公司部署，就把model.name指向realistic-vision-v6.0，并把safety_checker设为None（他们需要生成高度拟真的新人照片，安全过滤器会误杀很多正常细节）；而给一家儿童绘本工作室部署，则用dreamshaper-8.0，并开启safety_checker。> 提示：safety_checker并非万能。它主要过滤 NSFW 内容，对“画面质量”毫无帮助。我们曾遇到一个案例：用户用dreamshaper-8.0生成“森林里的小鹿”，结果小鹿的角长在了肚子上。这个问题，safety_checker完全无法识别，因为它不违反任何安全规则。解决办法是启用refiner模型——Nano-Banana-2 支持在主模型生成后，用一个轻量级的refiner模型对局部进行重绘。这个功能在config.yaml里是开关式的：refiner: { enabled: true, model_name: "sdxl-refiner-1.0" }。实测下来，开启 refiner 后，这类“解剖学错误”的发生率下降了 68%，代价是单图生成时间增加 1.8 秒。

3.3 协同工作流：一次完整的“文字→视频”生成全过程

现在，让我们把 Seedanc 2.0 和 Nano-Banana-2 放在一起，走一遍从用户提交文案到最终拿到.mp4的完整链路。这个过程，被我们称为“三跳协议”，因为它跨越了三个独立的进程边界。

第一跳：Seedanc 接收请求，生成分镜脚本用户通过前端页面或 API 提交一个POST /api/v1/video请求。Seedanc 的 Express 路由接收到后，不做任何阻塞操作，而是立即将请求放入一个 Redis 队列queue:video_jobs，并返回一个job_id给用户。随后，一个后台的JobWorker进程（由 PM2 管理）从队列里取出这个 job，调用prompt-engineer模块生成shotlist.json，再将shotlist.json存入 Redis 的 Hash 结构hash:shotlist:{job_id}中，并发布一个shotlist:generated的 Pub/Sub 事件。整个过程平均耗时 120ms，用户几乎感觉不到延迟。

第二跳：Nano-Banana-2 接收分镜，生成图像序列Nano-Banana-2 的服务启动时，会订阅shotlist:generated事件。一旦收到事件，它就从hash:shotlist:{job_id}里读取shotlist.json，然后对shots数组里的每一项，发起一个异步的POST /generate请求。这里的关键是并发控制。Nano-Banana-2 的config.yaml里有一个concurrent_generations: 2参数，它限制了同一时间最多只有 2 个图像生成任务在 GPU 上运行。其余任务会排队等待。这个数字不是随便定的，而是根据你的 GPU 显存计算出来的：concurrent_generations = floor(available_vram_gb / 8)。比如你的 RTX 4090 有 24GB 显存，24 / 8 = 3，所以你可以设为 3。但要注意，concurrent_generations设得太高，会导致显存碎片化，反而降低整体吞吐量。我们测试发现，对于 24GB 卡，设为 2 是吞吐量和稳定性最好的平衡点。

第三跳：Seedanc 合成视频，交付成果当 Nano-Banana-2 完成一张图的生成，它会向 Redis 发布一个image:generated事件，并把generation_id和image_url作为 payload。Seedanc 的另一个ImageWatcher进程监听这个事件，一旦收到，就去检查hash:shotlist:{job_id}里所有shots的状态。当发现所有shots都已生成完毕，它就调用 FFmpeg 命令行，将所有 PNG 图片按start_time和end_time拼接成 MP4：

ffmpeg -y \ -framerate 24 \ -i /tmp/seedanc/{job_id}/%06d.png \ -c:v libx264 -pix_fmt yuv420p \ -vf "fps=24, scale=1920:1080:force_original_aspect_ratio=decrease, pad=1920:1080:(ow-iw)/2:(oh-ih)/2" \ /tmp/seedanc/{job_id}/output.mp4

最后，它把output.mp4上传到对象存储（如 MinIO），并将最终的播放 URL 写入hash:job_status:{job_id}，同时向用户推送一个 WebSocket 消息。整个“三跳”过程，从用户提交到收到视频，平均耗时 42 秒（以 8 秒视频为例），其中 85% 的时间花在了 GPU 图像生成上，Seedanc 自身的逻辑耗时不到 3 秒。这个清晰的分工，让问题排查变得极其简单：如果用户说“视频没生成”，你只需要查 Redis 里hash:job_status:{job_id}的status字段，如果是shotlist_generated，说明卡在第二跳，去查 Nano-Banana-2 的日志；如果是images_generated，说明卡在第三跳，去查 FFmpeg 的错误输出。

4. 部署教程：从零开始，在 Ubuntu 22.04 上完成全栈私有化部署

4.1 环境准备：硬件、系统与驱动的硬性要求

部署 Seedanc 2.0 + Nano-Banana-2，不是一场“下载即用”的游戏，而是一次对系统底层的深度握手。任何试图跳过这一步的“速成”，都会在后续的CUDA out of memory或segmentation fault错误中付出十倍的时间代价。我们以最主流的 Ubuntu 22.04 LTS 为例，详细列出每一个不可妥协的环节。

硬件层面：GPU 是唯一的门槛

  • 最低要求：NVIDIA GPU，计算能力（Compute Capability）≥ 7.5（即 Turing 架构及以后），显存 ≥ 12GB。这意味着 GTX 1660 Super（CC 7.5）勉强可用，但 GTX 1080（CC 6.1）绝对不行。RTX 3090（24GB）、RTX 4090（24GB）、A10（24GB）是理想选择。
  • 为什么是 12GB？Nano-Banana-2 加载 SDXL 模型（约 7GB）+ 启动 PyTorch（约 2GB）+ 保留 3GB 显存给图像缓存和 FFmpeg，这是一个经过反复压测得出的“安全边际”。低于这个值，你会频繁遭遇OOM when allocating tensor。
  • CPU 和内存：CPU 不是瓶颈，但建议 ≥ 8 核（如 Ryzen 7 5800X 或 Xeon E5-2680 v4）。内存必须 ≥ 32GB，因为 Seedanc 的 Node.js 进程、Redis、FFmpeg 以及 Nano-Banana-2 的 Python 进程，都会占用大量系统内存。我们曾用一台 16GB 内存的机器测试，结果在生成 4K 视频时，系统内存被占满，触发了 OOM Killer，直接干掉了 Nano-Banana-2 进程。

系统层面：纯净的 Ubuntu 是基石

  • 必须是Ubuntu 22.04.3 LTS 或更高版本。不要用 20.04，因为它的glibc版本太低，无法运行 PyTorch 2.3 的预编译 wheel；也不要轻易升级到 24.04，因为它的systemd版本与 PM2 的某些信号处理存在兼容性问题。
  • 系统必须是最小化安装（Minimal Installation），不带任何桌面环境（GNOME/KDE）。桌面环境会占用宝贵的 GPU 资源和内存，并可能与 NVIDIA 驱动产生冲突。
  • 关闭所有不必要的服务：sudo systemctl disable snapd,sudo systemctl disable bluetooth,sudo systemctl disable ModemManager。这些服务在后台静默运行，会偷偷占用 CPU 和内存。

驱动层面：NVIDIA 驱动是生命线

  • 必须安装NVIDIA 官方驱动，版本必须是535.129.03 或更高。这个版本是 PyTorch 2.3 官方认证的“黄金驱动”。不要用 Ubuntu 自带的nvidia-driver-525，也不要迷信“最新版”，535.129.03 是经过我们 72 小时连续压力测试验证的最稳版本。
  • 安装命令必须是：
    sudo apt update && sudo apt install -y linux-headers-$(uname -r) wget https://us.download.nvidia.com/XFree86/Linux-x86_64/535.129.03/NVIDIA-Linux-x86_64-535.129.03.run sudo chmod +x NVIDIA-Linux-x86_64-535.129.03.run sudo ./NVIDIA-Linux-x86_64-535.129.03.run --silent --no-opengl-files
    --silent确保无交互，--no-opengl-files是关键！它禁止驱动安装 OpenGL 库，因为 Nano-Banana-2 完全不需要 OpenGL，安装它反而会与系统自带的 Mesa 库冲突，导致nvidia-smi命令失效。安装完成后，务必执行sudo nvidia-smi -q | grep "Driver Version"确认版本，并nvidia-smi查看 GPU 是否被正确识别。

4.2 核心依赖安装：Node.js、Python、CUDA 与 cuDNN 的精确匹配

现在，我们进入真正的“炼丹炉”环节。这里的每一个依赖，都必须像化学实验一样，精确到小数点后一位。任何偏差，都会导致整个系统在启动时就报错。

Step 1: 安装 Node.js v20.12.1放弃apt install nodejs，它提供的版本永远滞后。也放弃nvm，它不适合生产环境。我们必须用官方二进制包：

cd /tmp wget https://nodejs.org/dist/v20.12.1/node-v20.12.1-linux-x64.tar.xz tar -xf node-v20.12.1-linux-x64.tar.xz sudo mv node-v20.12.1-linux-x64 /opt/node-v20.12.1 sudo ln -sf /opt/node-v20.12.1/bin/node /usr/bin/node sudo ln -sf /opt/node-v20.12.1/bin/npm /usr/bin/npm # 验证 node -v # 应输出 v20.12.1 npm -v # 应输出 10.2.4

注意：npm的版本10.2.4是node-v20.12.1自带的，不要用npm install -g npm@latest升级它。我们测试过，npm@10.8.1与node@20.12.1组合，在安装canvas模块时会出现gyp ERR! stack Error: Can't find Python executable "python"的错误，根源是npm@10.8.1的node-gyp调用逻辑变了。所以，原版npm@10.2.4是唯一经过验证的组合。

Step 2: 安装 Python 3.10 和 PyTorch 2.3Ubuntu 22.04 自带 Python 3.10，但我们仍需确保它是系统默认：

sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 1 sudo update-alternatives --config python3 # 选择 3.10

然后，安装 PyTorch。必须使用官方提供的 CUDA 12.1 版本，因为 Nano-Banana-2 的 wheel 是针对此版本编译的：

pip3 install torch==2.3.0+cu121 torchvision==0.18.0+cu121 --extra-index-url https://download.pytorch.org/whl/cu121

安装完成后，用 Python 代码验证：

import torch print(torch.__version__) # 应输出 2.3.0+cu121 print(torch.cuda.is_available()) # 应输出 True print(torch.cuda.device_count()) # 应输出你的 GPU 数量

Step 3: 安装 CUDA 12.1 和 cuDNN 8.9.2虽然 PyTorch 的 wheel 已经包含了 CUDA 运行时，但 Nano-Banana-2 的一些底层优化（如 TensorRT 加速）需要完整的 CUDA Toolkit。我们安装的是cuda-toolkit-12-1：

wget https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run sudo sh cuda_12.1.1_530.30.02_linux.run --silent --override --toolkit

--silent和--override是关键，它会跳过所有图形界面和冲突检查。安装完成后，将 CUDA 的 bin 目录加入 PATH：

echo 'export PATH=/usr/local/cuda-12.1/bin:$PATH' | sudo tee -a /etc/profile.d/cuda.sh echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH' | sudo tee -a /etc/profile.d/cuda.sh source /etc/profile.d/cuda.sh nvcc --version # 应输出 Cuda compilation tools, release 12.1, V12.1.105

cuDNN 的安装更简单，只需下载cudnn-linux-x86_64-8.9.2.26_cuda12-archive.tar.xz，解压，然后复制文件：

sudo cp cuda/include/cudnn*.h /usr/local/cuda/include sudo cp cuda/lib/libcudnn* /usr/local/cuda/lib64 sudo chmod a+r /usr/local/cuda/include/cudnn*.h /usr/local/cuda/lib64/libcudnn*

4.3 Seedanc 2.0 与 Nano-Banana-2 的部署与配置

现在，所有地基都已打好，我们可以开始部署核心应用了。整个过程分为四个阶段：下载、配置、启动、验证。

**