多模型议会跑在阿里云 ECS 上，先算清四路并行的机器账
@a1exsun/dsh-council 在一条 DSH 会话里做三件事：2–8 个模型独立作答、1–8 个评审人匿名互评、1 个裁决人汇总。网站记 154 星、57.5 / 100、周下载 174（快照截至 2026/9/16，比同批条目旧），MIT，npm 最新 0.1.0，本站档位 L5。
搬上 ECS，第一件要算的不是装什么，而是一次运行同时起多少东西。
一次 /council 是 4 到 17 个参与者
- 回答：2–8 个模型并行作答，彼此看不到对方。
- 评审：1–8 个评审人在不知道作者身份的前提下比较、指出遗漏、排名。
- 裁决：1 个裁决人综合回答与评审，落到一条建议。
下限 2+1+1=4，上限 8+8+1=17。README 直说：每轮 4–17 个参与者，每人可能多次请求、并用 Web 工具。角色复用你已配好的模型与凭据，各角色单独挑，一个模型可占多角。原始回答与评审留在子会话，主会话只给汇总：共识、分歧、盲点、平均排名。
默认限额：
- id: dsh-council
config:
answerMaxTokens: 16384
reviewMaxTokens: 16384
arbiterMaxTokens: 16384
childTimeoutMs: 300000
runTimeoutMs: 900000
subagentProvider: spawn
三个 16384 是单次请求上限，不是每轮总量；runTimeoutMs 不得小于 childTimeoutMs；subagentProvider 默认 spawn，起的是独立子会话。
规格按并发配，不按「一个 Node 进程」配
插件本身不推理，CPU 花在解析流式响应与写子会话上，内存花在并发缓冲上。锚点是同时有几个参与者，不是有几个用户。
| 单轮参与者 | 起步规格 | vCPU / 内存 | 说明 |
|---|---|---|---|
| 4（2 答 + 1 评 + 1 裁） | ecs.g7.large |
2 / 8 GiB | 两阶段都不挤 |
| 6–9 | ecs.g7.xlarge |
4 / 16 GiB | 评审是第二波并发 |
| 10–17 | ecs.g7.2xlarge |
8 / 32 GiB | 峰值在评审与裁决交界 |
表是并发到规格的映射，不是压测结论：回答 2–8 路、评审 1–8 路不重叠，峰值取较大者再留裁决余量。
盘上要留余量：系统盘默认 40 GiB，一轮跑满 17 个子会话、每人多次请求，会话文件涨得比代码快，挂一块 ESSD 数据盘到 /data，把会话目录指过去。
安全组：入方向收窄，出方向必须放通
入方向只留 22 并限源 IP；Web 界面要么监听 127.0.0.1 走 SSH 转发，要么 443 挂证书，别把这个面板端口按 0.0.0.0/0 直接开出去。
出方向才是重点：模型 API 走公网出口，要放通 443。没有公网 IP 时用同 VPC 的 NAT 网关做 SNAT，配条默认路由即可，实例不必绑 EIP。没配好不报错，只转圈：子会话建连超时，5 分钟一到整组失败。某个 provider 若有私网端点或专线，就走内网，别让私网域名解析到公网出口。
带宽：按使用流量，别按固定带宽估
请求体很小，响应体是流式 token，难点全在并发。固定带宽只买 1 Mbps，两路以上长回答就开始互相等；按使用流量计费更适合突发负载，但峰值带宽仍是上限，17 路同收照样堵。
抢占式实例不适合 15 分钟级长任务
runTimeoutMs 900000 意味着一次运行最长占住机器 15 分钟。抢占式实例便宜，但库存紧张时会被回收，回收前只给一段有限的通知窗口；正卡在评审阶段被收走，回答散在子会话里，重跑要从头。要压成本用包年包月或节省计划。
两份账，落在两个地方
ECS 侧在费用中心：实例时长、云盘、流量。模型侧的 token 在服务商用量页按 provider 分计，DSH 只负责发请求。想核真实开销，得两边对起来。
会话与日志放数据盘、按天归档，系统盘留给系统和 Node。写满的失败方式是静默的：新子会话建不起来，主会话只显示等待。
四个坑，从装到跑
坑一 · 少于两个已认证的模型，议会组不起来
现象：/council 敲进去，阵容选不了，或选完立刻退回。
原因：README 的安装前置表把「已配置并认证至少两个模型」写成硬条件。评审要匿名比较，一个模型自比没有意义。
解决：先配好两家以上 provider、跑通一次普通对话再进 /council；认证失败不单独提示，只表现为参与者起不来。
坑二 · 包名少了 scope，装到的是别人的预留包
现象：add dsh-council 装成功，/council 命令却没有。
原因：无 scope 的 dsh-council@0.0.1 属另一位作者（dushaobindoudou/dsh-plugin），描述直写「name reserved; first release in develop」。
解决：写全 dsh plugin --profile web add @a1exsun/dsh-council，要钉版本补 @0.1.0；装完用 dsh plugin list 核对名字里有没有 @a1exsun/。
坑三 · 成本是乘法的，规格和小带宽会先热起来
现象：一轮跑完，token 用量比预估高出数倍，机器开始 swap。
原因：参与者数 × 每人多次请求 × 每次 16384 token 上限。17 人各两三次请求就是单次问答的几十倍；CPU 同解析十几路流，内存同缓存十几份响应。
解决：先用最小阵容（2 答 + 1 评 + 1 裁）量出实际 token 与耗时再加人，规格与带宽按并发买。
坑四 · 每个参与者从干净上下文开始，问题得自带全部背景
现象：回答质量忽高忽低，有的模型像完全不知道前因后果。
原因：README 写得很直白：参与者使用全新上下文，看不到这轮对话前面说过什么，只看到写进议题的那段字。
解决：约束、数据、比较对象、期望的输出形状都写进问题。README 的例子就是先交代三个 worker 与两种方案，再要求说明崩溃恢复路径、推荐一种并列出假设。
顺带一句：README 里嵌了第三方模型服务商的邀请码横幅（链接带 aff 参数），与插件功能无关，不影响使用，这里不展开。
总结
开销与耗时都随参与者数相乘，机器账要按「同时几路」算：规格对并发、安全组放出网、带宽按流量、长任务避开抢占式、会话落到数据盘；DeepSeek Harness Hub 插件清单 里有同类评审插件的横向对照。
适合与不适合
适合：已配好两家以上模型、想对同一决策要多种独立判断的人；需要可追溯的评审记录（谁排第几、分歧在哪）的人；能接受单轮十几分钟、愿意先小阵容试跑的人。
不适合：只有一个模型凭据的人；把共识当正确答案的人，README 明说一致不保证正确；对 token 开销敏感又要开满 17 个参与者的人；打算用抢占式实例省这笔钱的场景。
标签：dsh-council、DeepSeek Harness、多模型评审、阿里云 ECS
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
