多模型概念验证 — 主机操作指南

多模型计算验证（PoC）于 v0.2.12 版本引入，并在 v0.2.13 版本进一步扩展。

委托指南更新（2026年7月）

在 epoch 328–329 事件之后，选择委托方时适用以下两条规则：

• 不要将委托授予守护节点。 守护节点是备用机制

用于PoC验证。将委托集中于它们会将主要投票机制和备用机制绑定到同一硬件上，因此两者会同时失效。此前建议将守护节点作为委托目标的指导已撤回。v0.2.14计划引入协议级限制。 - 避免将委托集中于任何单个主机。 委托仅在委托方在该周期提交PoC存储提交时才有效。如果一个被大量委托的主机宕机，所有委托给它的权重将同时消失，模型组可能失去验证多数票。如果您运营多个账户，请将它们指向不同的委托方。目前尚不支持从一个账户基于百分比向多个主机进行委托。 在该周期内提交PoC存储提交时才有效。如果一个被大量委托的主机宕机，所有委托给它的权重将同时消失，模型组可能失去验证多数票。如果您运营多个账户，请将它们指向不同的委托方。目前尚不支持从一个账户基于百分比向多个主机进行委托。

v0.2.12和v0.2.13中的变更

在v0.2.12之前，网络仅运行一个强制模型：Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。v0.2.12增加了moonshotai/Kimi-K2.6作为第二个治理批准的模型，并引入了按模型的参与、委托和惩罚时间。v0.2.13重新校准了模型系数，并增加了MiniMaxAI/MiniMax-M2.7作为第三个治理批准的模型。

自纪元 308 起，Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 已被治理（提案 78）退役，MiniMaxAI/MiniMax-M2.7 为基础模型。自纪元 360（提案 94）起，deepseek-ai/DeepSeek-V4-Flash-0731 也成为 PoC 模型组。自 提案 101 起，zai-org/GLM-5.3-Flash 是一个 PoC 模型（penalty_start_epoch 394），moonshotai/Kimi-K2.6 / zai-org/GLM-5.2-FP8 不再属于 poc_params.models。主网上的 poc_params.models 包含：

model_id	链上备注
MiniMaxAI/MiniMax-M2.7	自纪元 308 起的基础模型（提案 78）
deepseek-ai/DeepSeek-V4-Flash-0731	自纪元 360 起的 PoC 组（提案 94）。系数位于 poc_params。
zai-org/GLM-5.3-Flash	自提案 101 起的 PoC 组。penalty_start_epoch 394。系数位于 poc_params。

moonshotai/Kimi-K2.6 和 zai-org/GLM-5.2-FP8 仍保留在 GET /v1/governance/models（推理目录）中，但不是 PoC 模型。

一个模型在 poc_params 中有资格获得该纪元的缺失/拒绝处罚，仅当其投票权满足 v_min 和 w_threshold。模型的 weight_scale_factor 仅在该组有资格时产生共识权重。无投票权的 poc_params 模型是下一个 PoC 的引导候选者。请查看 poc_params 和该纪元的 confirmation_weight_scales。实时服务是独立的检查：/v1/epochs/current/participants。请勿从上表推断任一内容。

每模型的 weight_scale_factor 和 penalty_start_epoch 通过治理变更过于频繁，无法在此可靠列出。请始终从您所用链的实时 params 查询中读取：

./inferenced query inference params --node "$NODE" -o json

查看 poc_params → models。

为何多模型 PoC 如此运作

本设计的目标是在保留相同的安全模型（BFT 假设）的同时，允许网络支持多种模型，而无需每个主机都运行所有模型。

无委托时：

- 降低新模型的验证阈值会使网络的一小部分获得不成比例的影响力。
- 保持标准的 2/3 阈值会使新模型的激活变得非常困难，因为需要大多数主机先部署它们。

委托解决了这个问题：

- 不运行某个模型的主机仍可将其权重贡献给验证过程
- 新模型可以安全启动，而无需强制全网采用
- 网络在保持安全保证的同时保持灵活性

治理模型

新模型通过治理添加：每个新模型都应有自己的治理流程、参数和激活计划。对于每个获批的模型，主机可选择运行、委托、拒绝或不采取任何操作。

范围与前提条件

包含在内： 升级前的模型清理、按模型的参与选择、委托和意向交易、委托查询、PoC v2 提交诊断，以及影响您选择的链参数。

签名： 本指南中的所有内容均假设您使用您的冷主机密钥（--from 指向该账户）进行广播。若要从热密钥提交意向、委托或拒绝，请参阅如何从热密钥声明 PoC 意向？。

开始前： 确认您的二进制文件和网络支持以下命令：

./inferenced query inference --help
./inferenced tx inference --help

进一步阅读（设计与费用）： 多模型 PoC 提案 README。

---

我该做什么？（快速决策指南）

Do you run the model?

├─ YES
│  └─ Do nothing → you are fully participating (no penalties)

└─ NO
   ├─ Do you have another node that runs this model?
   │
   │  ├─ YES
   │  │  └─ Delegate to your own node
   │
   │  └─ NO
   │     ├─ Do you trust another host?
   │     │
   │     │  ├─ YES
   │     │  │  └─ Delegate to that host (share 5% of weight)
   │     │  │     Never a guardian node; prefer a host that is
   │     │  │     not already a top delegation target
   │     │
   │     │  └─ NO
   │     │     └─ Refuse delegation (~10% penalty)
   │
   └─ If you do nothing
      └─ Risk highest penalty (~15%)

在大多数情况下：

• 如果您未运行该模型，委托是最安全的默认选项
• 一旦惩罚启用，不采取任何操作是最差的选择

推荐操作

如果您未运行某个模型：

• 如果您运行多个节点，且至少有一个节点运行该模型：将该模型委托给您的节点
• 如果您完全不运行该模型：委托给一个您信任的主机。选择时：
  • 它不能是守护节点；
  • 它应能在最近几个纪元中稳定地提供该模型（委托 仅当代理在该纪元提交了PoC存储提交时才计数）;
  • 它在上一个纪元应具有非零共识权重;
  • 优先选择不是主要委托目标的主机——如果 max_model_voting_power_percentage 被设置时，超出上限的委托权重 将被销毁，集中度会使整个群体变得脆弱。
• 如果你不信任任何代理：对该模型使用 refuse-poc-delegation

当某个模型达到 penalty_start_epoch 时，不直接或通过有效委托参与该模型可能会根据治理配置的参数降低您的共识权重。

您的选项（每个模型）

要获取所有治理批准的 model_id 值列表，请运行：

./inferenced query inference params --node "$NODE" -o json

查看 poc_params → models。

您想要的	命令	主机选择它的原因
自行运行该模型的PoC	（无单独的链上“加入”操作；您的堆栈提交PoC v2存储提交）	您将在该模型的组中保持到本轮次结束。
信任其他主机对该模型的验证投票	set-poc-delegation	如果您在验证时满足规则，您的权重可以计入该模型的PoC检查影响力中（参见您的委托是否有效？）。
明确选择不为该模型委托	refuse-poc-delegation	清除委托的"否"选项；在该模型的惩罚启用后，如果治理配置了相关规则，可能会适用拒绝型扣减。（参见当您的链上选择被冻结时）
不做额外操作	(无交易)	默认行为；一旦启用，可能导致最高惩罚
在新模型完全上线前发出计划信号	declare-poc-intent	仅用于引导报告；它不替代运行PoC。您仍需在PoC中提交存储提交才能算作自己为该模型提供服务。参见引导预资格事件。

策略对比

策略	结果
运行模型	完全参与，无惩罚
委托	轻微权重损失（约5%），避免惩罚
拒绝	约10%权重损失
不做任何操作	如果配额形成而您未参与，最多损失约15%权重

每个模型仅存储一个选择：对于每个model_id和您的地址，链上最多仅保留一个委托/拒绝/意向。这三个选项中的任一新交易将替换之前的选项。在链应用该周期规则时，您自己为模型提供服务（在该周期中拥有有效存储提交）优先于上述三个选项。

没有通用的默认建议。运行、委托、拒绝或什么都不做是每个主机和每个模型的战略决策。

当前主网参数（撰写时）

• refusal_penalty：您权重的约10%
• no_participation_penalty：约15%（如果共识在您未参与的情况下形成）
• delegation_share：您权重的约5%将转移给委托方

这些值由治理控制，可能会更改。请始终使用 params 进行验证。

宽限期

升级后，新引入模型的惩罚不会立即生效。

主机通常有较短的时间窗口（约3天）来：

• 部署模型
• 配置委托
• 或明确拒绝

请在 params 中检查 penalty_start_epoch 以获取确切时间。

---

什么是PoC委托

每个已批准的模型都有其自己的PoC。您在上一个周期的共识权重仍会影响您未自行运行的模型的PoC验证投票权。

委托意味着：对于给定的 model_id，您告诉链该权重在该模型的验证投票中应如何行为——您可以支持他人的投票、书面选择退出、仅表明对新模型的计划，或保持默认（无额外交易）。

如果您在该周期内通过正常的PoC堆栈提交了有效的PoC v2存储提交，则您被视为自行运行该模型的PoC。这将覆盖您之前通过委托/拒绝/意向设置的参与方式。

---

您的链上选择何时冻结

链在两个不同时间点读取您的设置——它们回答不同的问题并适用于不同的内容。

1. 本周期PoC验证开始时 链记录您委托给谁以及您是否拒绝。这适用于已正常运行的模型。此处不读取意向。

2. 下一个PoC开始前 deploy_window 个区块处——高度 next_poc_start − deploy_window 链记录委托和意向，用于引导/预资格信号，针对尚未进入正常集合的模型。如果 deploy_window 为零或负数，则此第二次捕获不会运行。

您是否实际运行了PoC并不来自这些存储行：链使用您在该周期内对该模型的PoC v2存储提交。

您的委托是否真的有效？

set-poc-delegation 可随时发送，但仅在验证开始时满足以下所有条件时，才对委托方有帮助：

• 委托方在该周期内运行了该 model_id 的PoC（以常规方式提交了相应工作），并且
• 委托方在上一个周期拥有非零共识权重。

否则，您的委托在该周期内对该模型无效（与未委托的实际结果相同），一旦启用，惩罚规则仍可能适用。

如果您的委托方宕机，您可能被惩罚

如果委托方未能在该周期内为该模型提交PoC存储提交， 您的委托将被忽略，您将被视为未参与该模型——即使 您出于善意进行了委托，no_participation_penalty 仍可能适用于您。请定期重新检查委托方的参与情况 （例如，在任何网络事件后），并在委托方变得不可靠时更换委托方。

当委托确实有效时，您的全部权重将计入该主机对该模型PoC验证的影响力。此外，delegation_share 在 params 中可将您原始共识权重的一部分转移给他们——这与拒绝/不参与百分比是不同的调节器；请阅读 params 以获取确切数值。

引导预资格事件

如果您计划为新模型配置硬件，请关注类型为 bootstrap_model_preeligibility 的链事件。典型属性包括：model_id、pre_eligible、meets_weight_threshold、meets_v_min、meets_reachability、intent_host_count、intent_weight、reachable_voting_power、total_network_weight、snapshot_height。

利用它们决定何时声明意向以及何时必须让提交生效：

• 如果 pre_eligible = false 且您计划提供此模型：检查 meets_weight_threshold 和 meets_v_min。如果两者均为假，您的质押可能不足。
• 如果仅 meets_reachability 为假，请在下一次捕获高度前确认您的节点可访问。

---

复制粘贴设置命令

会话变量（在此shell中仅设置一次）

在使用以下命令前，在同一shell中运行一次。调整值，然后运行该块。以下所有示例均使用 NODE、CHAIN_ID、KEY（您的密钥环中的冷密钥名称）和可选的 KEYRING_BACKEND。

export NODE="<PUBLIC_URL>"
export CHAIN_ID="gonka-mainnet"
export KEY="gonka-account-key"   # cold key; see note at top on warm-key grants
export KEYRING_BACKEND="file"

export MY_ADDR="$(./inferenced keys show "$KEY" -a --keyring-backend "$KEYRING_BACKEND" 2>/dev/null || true)"
# If keys show fails, set your address explicitly:
# MY_ADDR="gonka1..."

以下每个 tx inference … 示例都重复了相同的 --from / --node / --chain-id / --keyring-backend / gas 标志，因此您可以复制一个代码块而无需从其他地方合并行。如果您的密钥环已是默认值，可以省略 --keyring-backend。

可选——减少重复标志： 为这台机器的 CLI 客户端配置默认 RPC 节点和链 ID（Cosmos 风格的 client.toml；使用 ./inferenced config --help）。之后您可以从下面的交易行中省略 --node 和 --chain-id。

参数和纪元

./inferenced query inference params --node "$NODE" -o json

./inferenced query inference get-current-epoch --node "$NODE" -o json

查询委托状态

所有模型：

./inferenced query inference poc-delegation "$MY_ADDR" --node "$NODE" -o json

一个模型（第二个参数可选）：

./inferenced query inference poc-delegation "$MY_ADDR" "$MODEL" --node "$NODE" -o json

响应分别列出了委托、拒绝和意向；对于给定模型，您最多只会拥有三者之一。

---

交易

委托（发送交易时，委托方无需已运行该模型的 PoC）：

MODEL="your-model-id"
DELEGATEE="gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

./inferenced tx inference set-poc-delegation "$MODEL" "$DELEGATEE" \
  --from "$KEY" \
  --node "$NODE" \
  --chain-id "$CHAIN_ID" \
  --keyring-backend "$KEYRING_BACKEND" \
  --gas auto \
  --gas-adjustment 1.3 \
  -y

清除委托：

MODEL="your-model-id"

./inferenced tx inference set-poc-delegation "$MODEL" "" \
  --from "$KEY" \
  --node "$NODE" \
  --chain-id "$CHAIN_ID" \
  --keyring-backend "$KEYRING_BACKEND" \
  --gas auto \
  --gas-adjustment 1.3 \
  -y

拒绝：

MODEL="your-model-id"

./inferenced tx inference refuse-poc-delegation "$MODEL" \
  --from "$KEY" \
  --node "$NODE" \
  --chain-id "$CHAIN_ID" \
  --keyring-backend "$KEYRING_BACKEND" \
  --gas auto \
  --gas-adjustment 1.3 \
  -y

引导意向：

以下示例使用冷主机密钥。若要从热密钥提交，请参阅如何从热密钥声明 PoC 意向？。

MODEL="your-model-id"

./inferenced tx inference declare-poc-intent "$MODEL" \
  --from "$KEY" \
  --node "$NODE" \
  --chain-id "$CHAIN_ID" \
  --keyring-backend "$KEYRING_BACKEND" \
  --gas auto \
  --gas-adjustment 1.3 \
  -y

---

惩罚与参数

惩罚和委托份额在构建下一个纪元的活跃集合时应用于共识权重，在 PoC 结果已知之后。以下所有内容均来自 ./inferenced query inference params（JSON 字段因版本略有不同；请在输出中搜索这些名称）。

在 params 中的位置	字段	对主机的意义
在 poc_params → models 中的每个模型	penalty_start_epoch	在此纪元索引之前，该模型的惩罚规则不适用。按 model_id 跟踪。
在 poc_params → models 中的每个模型	weight_scale_factor	将该模型的 PoC 权重缩放为共识权重。
delegation_params	refusal_penalty	在 penalty_start_epoch 之后使用 refuse-poc-delegation 时，从原始共识权重中移除的比例。
delegation_params	no_participation_penalty	在未拒绝、无有效委托且未自行提供该模型服务时——惩罚应用后，被移除的比例。
delegation_params	delegation_share	当委托有效时，委托人原始权重重新分配给被委托人的比例。
delegation_params	deploy_window	在下一个 PoC 开始前选择引导快照高度的区块数（next_poc_start − deploy_window）。

高级资格参数（大多数主机可跳过）：w_threshold、v_min、cap_factor、initial_model_id、max_model_voting_power_percentage——资格阈值、上限和每模型投票集中度限制。最后一个为零通常表示“无上限”。

如果 refusal_penalty、no_participation_penalty 和 delegation_share 均为零，链不会应用这些扣除或转移（升级后常见，直到治理启用它们）。

---

主机检查清单

1. 升级前，清理您持久化的 MLNode 配置，使其仅包含受支持的模型。
2. 尽可能为每个 ML 节点使用一个逻辑模型。当多个模型存在于同一节点上时，配置错误更容易发生。
3. 升级后，确认 params 在 poc_params 下列出了您关心的每个模型。
4. 检查每个模型的 penalty_start_epoch。
5. 检查 refusal_penalty、no_participation_penalty 和 delegation_share 是否非零。
6. 对于每个模型，决定您是想运行它、委托、拒绝，还是什么都不做。
7. 如果您自行运行该模型，请确保您的 PoC 堆栈为该模型提交有效的 PoC v2 存储提交。
8. 如果您委托，请使用 poc-delegation 验证结果，并确认被委托方在当前纪元确实为该模型提交了 PoC。
9. 对于新模型，请监控 bootstrap_model_preeligibility 事件，并在捕获高度前发送 declare-poc-intent（如果您计划参与）。
10. 在任何配置更改、重启或新主机上线后，请确保持久化的 DAPI 配置中不存在不受支持的模型。
11. 绝不要将守护节点设为您的委托目标。
12. 任何网络事件后，请重新验证您的委托是否仍在提供模型；委托在验证开始时被快照，无法在epoch中途重新路由。