d97e194383
- 注册表:docs/architecture/README.md §2,37 份 canonical(frontmatter topic+canonical:true)与表双向机器对账
- 门:.agents/tools/docs-gate.py 六检(品牌根/canonical唯一/死链/入口卫生/留痕隔离/设计档申报),挂 .githooks/pre-commit(本仓已激活)+ .gitea/workflows/docs-gate.yml(待runner)+ wave-close 第8步;旧 check-deadlinks.sh 退役并入 G3
- 清缩:删 54 项历史档(plans 16/agent-specs 设计与spike 20/brainstorms 5/memorys 3/goals+作战清单完成史归档/王蓝莓design/SAA现状html/add-game-template);channel-spike 564K 代码资产迁仓级 spikes/;六件删前蒸馏已迁(代码评审16条open项→进度总账§5、prefix-cache字段表→cheap-model skill、意图基线29条→需求清单附录、九门降级rationale→验收门、A11 TODO→tech-decisions、3layer边界→littlejs-game-dev 指针)
- 修口径约90处:六处SAA『现行主线』旧标、Nacos/RocketMQ『未部署』旧述(07-01反转)、gameDefinition残留、全部死链改 git show 定位;AGENTS.md 249→136行(决策史归tech-decisions);_index 改纯在飞板;对外演示版 md→html
- 依据:docs/agent-specs/2026-07-02-文档治理-{全量普查与裁决-report,SoT注册表与治理门-设计}.md(四路普查191份md+Codex/Opus双评审必修项已折入);恢复基线 8ea97234(单档 git checkout 8ea97234 -- <路径>)
6.9 KiB
topic, canonical, date
| topic | canonical | date |
|---|---|---|
| 生成容量与并发 | true | 2026-06-26 |
生成容量与并发规划
这是什么:回答"一次游戏生成占多少资源、一台机器能扛多少并发、要支撑 N 个并发要几台机器"。它是运维域 §1.4 可用性/成本约束在生成主线上的展开,也是 WU-F 生产容量门的输入。 给谁看:定生产机器规格的人、排生成产线容量的人、关心规模化成本的创始人。 怎么读:先看容量画像(钱花在哪、资源占在哪),再看分档阶梯表取数;具体机器口令与端点以《内网凭据与端点.md》为准。 数据来源:2026-06-26 便宜档 Python 对照实跑的实测 + 架构推断,文中区分"实测"与"推断"。
1. 容量画像:重活在云端,本地只做编排 + 构建 + 真玩门
一次便宜档生成的资源,大头不在我们的机器上。模型推理走 new-api 网关转发到 MiniMax 云,算力和显存是云端的,我方只按 token 付费(便宜档每局 < ¥10,实测远低于上限)。落在本地机器上的只有三类活:生成编排进程(Python/Node 的 ReAct 循环,多数时间在等模型返回、CPU 近乎空闲)、构建(node 语法检查 + esbuild 打包,几秒级的 CPU 突发)、真玩门(Chrome headless 跑九门,~30-60 秒的窗口,吃 1-2 核加几百兆内存)。
这个画像决定了容量的两条独立约束。远程一侧是 MiniMax 经 new-api 的并发配额——100 个并发生成意味着峰值约 100 路并发模型推理流,这是云端配额说了算,加多少台我方机器都买不到。本地一侧是真玩门的 Chrome 加 esbuild 抢 CPU,这才是"几台机器"要算的部分。两条约束里,本地这条便宜、好扩;远程那条是真正的天花板。
实测把本地这条钉到了具体数字:8 核 32G 机器上同时跑 3 局生成,常驻内存合计 2.3G(每局约 0.7-0.8G),其中编排进程只占百兆级,大头是构建期的 node 进程。内存很省,撑不住的从来不是内存,是 CPU——同时跑 9 局时,单局墙钟从独立跑的约 150 秒被争用拉到全批约 25 分钟,CPU 在真玩门和构建突发上互相挤。
2. 生产模型:异步队列加有界 worker 池
"10 个用户发起生成"不等于"10 个生成同时在跑"。生成是异步后台任务——创作页提交后立即返回任务受理,任务进队列,由一个有界的 worker 池按固定并发 N 消费,用户轮询进度。这条链上 A2A 任务状态(受理/执行中/完成/失败)、D12 配额扣减、fire-and-forget 提交都是为这个异步模型服务的。
所以容量问题落到两个数:worker 池的并发 N(一台机器稳跑几局),以及队列尾延迟(最后一个用户等多久)。单局墙钟约 2-5 分钟(慢在云端模型,不在本地),10 个任务在 N=4 时约等三批、末位等 10-12 分钟,在 N=8 时约两批、6-8 分钟。提速的杠杆首先是缩短单局时延(更贴近模板、砍模型轮次),其次才是堆并发——并发只决定队列消化速度,不改单局快慢。
3. 一台机器能跑多少并发:分档阶梯表
每局本地约 0.8G 内存、真玩门期间 1-2 核,且约 150 秒里只有 30-60 秒真占 CPU。据此按机器规格估算单台安全并发,内存在小机器上会先于 CPU 变成约束:
| 单机规格 | 好吞吐 N(真玩门不互相拖) | 硬上限 N | 先撞的约束 |
|---|---|---|---|
| 4 核 8G | ~3-4 | ~5-6 | 内存(8G)先紧 |
| 8 核 32G | ~6-8 | ~15 | CPU(真玩门抢核) |
| 16 核 | ~12-16 | ~26-30 | CPU |
| 32 核 | ~25-32 | ~50 | CPU |
两个口径要分清。好吞吐是真玩门不互相拖、单局墙钟不被争用显著拉长、九门不因抢核超时误判的稳态;硬上限是机器还能塞下、但单局会明显变慢、且逼近超时误判风险的天花板。生产按好吞吐排,留出余量;硬上限只是"最多别超过这条线"。8 核 32G 上,实测同时 9 局就已经看到单局被拖慢,所以这一档的好吞吐落在 6-8、而非贴着 15 的天花板跑。
便宜档的生成并发上限定为 ≤15(创始人 2026-06-26),对应的是 8 核级机器的硬天花板;4 核 8G 这样的小机器到 5-6 就到顶,用不上这条上限,硬件本身先卡住。
4. 支撑 100 并发要多少台
把阶梯表除一下:100 并发用 4 核 8G 机器要约 30 台,8 核 32G 约 13-16 台,16 核约 7 台,32 核约 3-4 台(均按好吞吐口径,再加一台冗余顶可用性)。
但这个除法本身是个信号:用小机器堆 100 并发是错的架构,30 台 4 核机器既难运维又不划算。真到 100 并发这个量级,正解是两条里挑——要么上更大的单机(16-32 核,几台搞定),要么走云 microVM 弹性(每局生成起一个 microVM、按秒计费、用完即停,不再有固定机器数)。后者正是生成引擎沙箱适配器选定的方向(E2B / 阿里云 AgentRun,见架构域生成引擎子树),弹性正好吻合生成负载的突发性。
而且无论堆几台,100 并发的真瓶颈不是我方机器数,是 MiniMax 配额加 new-api 网关。100 路并发模型推理流要 MiniMax 先把账号的并发配额放到这个量级(目前只实测验证过约 12 路并发可用),而这 100 路流全过 mini-infra 上那一个 new-api 网关,它要么扩容要么横向扩成多实例,否则成了单点。我方加服务器解决的是真玩门那一层,解决不了这两道。
5. MVP 与规模期是两套账
MVP 阶段(百级 DAU)根本到不了 100 并发。每局 2-5 分钟、百级日活散在全天,实际并发生成是低个位数,内网现有机器(真玩门只在 mini-desktop,见《内网凭据与端点.md》)一台就够,这也正是 < ¥5,000/月 那个成本盒子能成立的前提。100 并发是规模期场景——按持续负载算,约等于每小时 2000 局、token 费每小时 < ¥2 万,这是规模化的经济决策,不是 MVP 量级,该配套上云 microVM 的弹性与按量成本,而不是给内网物理机硬扩到 30 台。
所以容量规划分两段落地:MVP 用内网物理机、单台扛低个位数并发,不为不会到来的高并发提前买单;放量前再把生成产线从固定 worker 池切到云 microVM 弹性,同时把 MiniMax 并发配额谈到目标量级、给 new-api 网关做容量。两段之间的切换点由实际并发增长触发,不提前。
6. 给准数前要先定的三件
- MiniMax 经 new-api 的真实并发与 QPS 配额——这是 100 并发的第一约束,实测只验过约 12,硬上限没有数。配额不放到目标量级,机器堆多少都没用。
- 走内网物理机还是云 microVM——决定答案是"固定 N 台"还是"弹性 microVM",两套成本结构完全不同。
- mini-desktop 的真实核数与内存——它是当前唯一的真玩门运行机,定它的好吞吐 N 才能把第 3 节的台数从估算校到实数(2026-06-26 一次 ssh 未连上、规格待量)。
这份是容量的设计与估算骨架,落到 WU-F 生产容量门时,以第 6 节三项确认后的实数为准重算台数与配额。