Plan C · 混合架构：算力 + Token 共池

核心思路：一套算力底座、两条产品线，闲置卡自动灌 MaaS 消耗。
这是首推方案，90% 场景比单跑 A 或 B 都优。

1. 关键设计

双产品共池 + 优先级抢占：

                    ┌──────────────────┐
                    │  统一算力控制面    │
                    │  K8s + Volcano   │
                    └────────┬─────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
   ┌────▼─────┐         ┌────▼─────┐         ┌────▼─────┐
   │Plan A: 保障│         │Plan A: 抢占│         │Plan B:    │
   │ 客户长租  │         │  客户竞价 │         │  Token API│
   │ 优先级 P0│         │ 优先级 P2 │         │ 优先级 P1 │
   └──────────┘         └──────────┘         └──────────┘

优先级规则：

P0（IaaS 长租客户）：预付月租，不可打断，SLA 99.9%
P1（MaaS 保障请求）：付费用户默认，可挤 P2 但不挤 P0
P2（Plan A 抢占实例 + Plan B 抢占实例）：3-4 折价格，可被 P0/P1 随时打断

动态调度逻辑：

每分钟检查：
  空闲卡 = 总卡 - P0 已用 - P1 高峰值预留

if 空闲卡 > 0:
  → 灌进 P1（Plan B MaaS 常驻服务）
if 还有空闲卡:
  → 灌进 P2（抢占实例池，客户可竞价）
if P0 新订单进来:
  → 从 P2 抢回资源，30 秒 grace period
if P1 峰值来了:
  → 优先挤 P2，其次不动 P0

2. 收益模型对比

假设：单机 8×H800，成本 72,192 元/月。

场景	Plan A 出租率	折价率	月营收	毛利
Plan A 独占 100%	100%	1.0×	200,000	64%
Plan A 独占 60%	60%	1.0×	120,000	40%
Plan A 独占 40%	40%	1.0×	80,000	10%
Plan C 混合	40% P0 + 60% P1/P2	综合	160,000-220,000	50-70%

核心 insight：Plan C 让"空置"变成"低价高频出售"，机器永远在赚钱。

3. 关键组件

组件	选型	作用
调度	Kubernetes + Volcano + Kueue	Gang scheduling + 优先级抢占
计费统一	共用一套计费引擎	Plan A 卡时 + Plan B token 归一账单
调度决策	自研 controller	实时监控空闲卡，动态决定灌 P1 还是 P2
抢占通知	K8s PreemptionPolicy + PreStopHook	30 秒 grace period，保存 checkpoint
MaaS 副本管理	Deployment + HPA	空闲增 → 自动扩容 Plan B 实例

4. 客户视角

Plan A 客户看到：

保障型月租：正常价、SLA 99.9%
抢占型：3 折，随时被打断，适合训练可 checkpoint 场景
Spot 竞价：客户出价，最高价先得

Plan B 客户看到：

标准 token API：SLA 99.9%
抢占型 token API：3 折，可能 30 秒中断（异步任务专用）
批量 API：24 小时内完成，5 折

统一账户：同一账号可下 IaaS 单 + 用 MaaS API，账单合并。

5. 关键难点

难点	应对
抢占公平性	P0 抢 P2 时先通知 → 保存进度 → 已完成 token 不收费
P1 峰值预留	保留 20% 冗余给 MaaS 突发，避免抢占 P0
计费口径统一	用"卡·分钟"作为通用计量单位，Plan A 直接、Plan B 反推
抖动放大	P2 频繁被抢会影响客户体验 → 只卖给容忍中断的场景
成本归属	Plan A 客户和 Plan B token 都要归属对应 P&L

6. 分阶段落地

阶段 1（3 个月）：不真共池，逻辑分区

Plan A / Plan B 各自独立部署
计费系统统一
客户可跨 Plan 下单

阶段 2（6 个月）：算力池化

K8s 集群统一
Plan A 的整机资源可上下架
Plan B 常驻 + 抢占容量

阶段 3（9-12 个月）：真正的动态调度

空闲卡自动灌 MaaS
抢占实例双向流转
计费引擎按秒记账

7. 单机场景演算

假设 100 台 8×H800，每月总成本 720 万，来看不同混合比：

场景	Plan A 长租占比	Plan A 抢占	Plan B 常驻	Plan B 抢占	月营收	毛利率
纯 A 独占	100%	-	-	-	2000 万	64%
A 高 + B 少	70%	5%	15%	10%	1900 万	62%
平衡	40%	10%	30%	20%	1850 万	59%
B 主打	20%	5%	50%	25%	1700 万	55%
纯 B	0%	0%	60%	40%	1500 万	50%

结论：混合模式比"纯 A 出租满"少赚 ≈ 8%，但风险显著降低：

纯 A 出租满是理想情况，实际 60-80% 出租率下，收入远低于混合
Plan B 侧客户结构分散，抗风险强
混合模式毛利率更稳定

8. 具体建议

第一天就搭 K8s，即使 v1 只是整机租，也用 K8s 起底座
计费系统从一开始就要统一，最贵的是后期迁移
Plan A 和 Plan B 团队独立 KPI，避免内部抢资源
调度决策先手工：闲置 > 30% 手工上下架 Plan B 实例；量大后再自动化
抢占实例价格永远 3-4 折：让市场教育客户"便宜但可能被打断"是常态
透明化定价：Plan C 复杂度大，客户搞不懂就买不起；用简单档位表包装

9. 风险

调度 bug → 抢错客户：抢占策略务必先 dry run 3 个月
计费引擎错乱：跨产品线归口错误，客户投诉
P0 SLA 破防：混合模式下 P0 客户可能感知抖动
人力：Plan C 需要既懂 IaaS 又懂 MaaS 的团队

10. 演进路径

月 1-2: Plan A v1 单跑 + Plan B v1 单跑（独立集群）
月 3-4: 计费系统合并
月 5-6: 集群合并 + 简单优先级
月 7-9: 完整抢占调度上线
月 10-12: 抢占市场化定价 + 客户看到统一控制台

Plan C · 混合架构：算力 + Token 共池

On this page