ito-inference

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Itô Inference

Itô 推理

ito-inference
is the sole canonical ECC skill for inference serving on Itô compute. Requests naming
ito-serve
route here; do not create or install a second
ito-serve
skill. ECC never SSHes to nodes, downloads weights, launches an engine, or exposes an endpoint; it never books, reserves, or spends.
ito-inference
是ECC在Itô计算上用于推理服务的唯一标准技能。请求指定
ito-serve
时会路由到此处;请勿创建或安装第二个
ito-serve
技能。ECC绝不会通过SSH连接到节点、下载权重、启动引擎或暴露端点;也不会进行预订、预留或产生费用。

Current production boundary

当前生产边界

Managed serving is unavailable today. The ECC bridge exposes only
login
,
auth
,
find
,
status
, and explicitly gated
evals
. It has no
serve
verb. The canonical runtime documents
inference
only as an unsupported compatibility probe; ECC does not invoke or depend on it. The MCP surface exposes only auth, find, and status. The locally enforceable guarantee is that ECC rejects
serve
before resolving or spawning the credential-bearing canonical client.
Therefore stop before authentication or any command invocation. Report the missing capability and return to the originating agent. Never substitute a local runner, SSH helper, browser workflow, purchase endpoint, or any untracked local
ito-serve
draft.
目前托管服务不可用。ECC桥接仅暴露
login
auth
find
status
以及明确 gated 的
evals
接口。它没有
serve
动词。标准运行时仅将
inference
记录为不受支持的兼容性探测;ECC不会调用或依赖它。MCP层面仅暴露认证、查找和状态接口。本地可强制执行的规则是,ECC在解析或生成带凭证的标准客户端之前会拒绝
serve
请求。
因此,请在认证或任何命令调用前停止操作。报告缺失的功能并返回给发起Agent。切勿使用本地运行器、SSH助手、浏览器流程、购买端点或任何未跟踪的本地
ito-serve
草稿替代。

Required entitlement

必要权限

When serving is implemented, its first gate is a server-verified completed booking. Harness memory, an RFQ, a quote, node IPs, or SSH access are not proof of entitlement. The backend must return fresh serving eligibility bound to the authenticated account, booking, GPU topology, region, fabric, term, and model policy. Expired, revoked, mismatched, incomplete, or already-released bookings fail closed before confirmation.
当服务实现后,第一道关卡是服务器验证的已完成预订。内存资源、RFQ、报价、节点IP或SSH访问都不能作为权限证明。后端必须返回与已认证账户、预订、GPU拓扑、区域、网络架构、期限和模型策略绑定的最新服务资格。过期、已撤销、不匹配、未完成或已释放的预订在确认前会直接失败。

Future CLI and API contract

未来的CLI与API契约

The intended command name is
serve
;
inference
may remain only as an explicitly deprecated compatibility alias after the production contract lands. The future handoff must be equivalent to:
sh
ecc ito serve \
  --booking <server-verified-booking-id> \
  --manifest <absolute-reviewed-json-file> \
  --confirmation-ref <opaque-non-authorizing-reference> \
  --idempotency-key <stable-retry-key> \
  --json
The reviewed manifest must identify the model revision, engine and version, quantization, tensor/pipeline topology, endpoint exposure policy, artifact checksums, storage ceiling, runtime limits, optional TTFT/TPOT objectives, and maximum incremental cost. No raw API key, SSH key, node password, or bearer token belongs in arguments, manifests, logs, MCP results, or chat.
The client must canonicalize the manifest path, reject symlinks, open a regular file without following links, require appropriate ownership and restrictive permissions, enforce a bounded size, and hash bytes from the opened descriptor. That digest must exactly equal the digest bound into confirmation before any workload mutation. A path swap, digest mismatch, oversized file, or mutable unsafe file fails closed.
The canonical API—not ECC—must own workload creation and return structured JSON with
ok
,
live_api_contacted
,
notice
, and either
data
or
error
. Serving data must include stable booking, workload, manifest, and idempotency IDs plus a state enum; it must not claim an endpoint is live until health and model checks pass. Errors must include a stable code and safe message without secrets.
预期的命令名称是
serve
;在生产契约落地后,
inference
可能仅作为明确弃用的兼容性别名保留。未来的移交操作必须等效于:
sh
ecc ito serve \
  --booking <server-verified-booking-id> \
  --manifest <absolute-reviewed-json-file> \
  --confirmation-ref <opaque-non-authorizing-reference> \
  --idempotency-key <stable-retry-key> \
  --json
已审核的清单必须明确模型版本、引擎及其版本、量化方式、张量/流水线拓扑、端点暴露策略、工件校验和、存储上限、运行时限制、可选的TTFT/TPOT目标以及最大增量成本。原始API密钥、SSH密钥、节点密码或Bearer令牌不得出现在参数、清单、日志、MCP结果或聊天内容中。
客户端必须规范清单路径,拒绝符号链接,打开常规文件而不跟随链接,要求适当的所有权和限制性权限,强制执行文件大小限制,并对打开的描述符中的字节进行哈希运算。该摘要必须与确认时绑定的摘要完全一致,才能进行任何工作负载变更。路径替换、摘要不匹配、文件过大或不安全的可变文件都会直接导致失败。
标准API(而非ECC)必须负责工作负载的创建,并返回包含
ok
live_api_contacted
notice
以及
data
error
的结构化JSON。服务数据必须包含稳定的预订、工作负载、清单和幂等ID以及状态枚举;只有在健康检查和模型检查通过后,才能声明端点已上线。错误信息必须包含稳定的代码和不含敏感信息的安全消息。

Confirmation and execution gates

确认与执行关卡

Before workload creation, require all of the following:
  1. Fresh entitlement and serving eligibility from the canonical backend.
  2. A reviewable immutable manifest and deterministic digest.
  3. A separate single-use confirmation bound to account, action, manifest, and cost, with a short expiry and replay protection. CLI arguments carry only an opaque, non-authorizing confirmation reference; the server resolves and consumes the bearer capability out of band.
  4. A caller-supplied idempotency key reserved atomically with the workload.
  5. Server-side fabric, capacity, model-policy, storage, and cost validation.
Authentication is identity, not workload authority. A login, API key, quote, or completed booking never substitutes for the serving confirmation. Inspection and plan generation must not create a workload. Cancel and cleanup are separate mutations with their own scoped confirmation and idempotency boundaries.
在创建工作负载之前,必须满足以下所有条件:
  1. 来自标准后端的最新权限和服务资格。
  2. 可审核的不可变清单和确定性摘要。
  3. 与账户、操作、清单和成本绑定的单独一次性确认,具有短有效期和重放保护。CLI参数仅携带不透明的、无授权的确认引用;服务器会通过带外方式解析并使用Bearer权限。
  4. 调用者提供的与工作负载原子性保留的幂等密钥。
  5. 服务器端的网络架构、容量、模型策略、存储和成本验证。
认证是身份验证,而非工作负载权限。登录、API密钥、报价或已完成的预订绝不能替代服务确认。检查和计划生成不得创建工作负载。取消和清理是单独的变更操作,具有各自的范围确认和幂等边界。

Lifecycle and recovery

生命周期与恢复

The production surface is incomplete until the same canonical client exposes tenant-scoped status, logs, metrics, cancel, and cleanup operations. Every operation needs bounded connect and overall timeouts, revocation-aware errors, and structured output. After an ambiguous transport failure, query status by the idempotency key before retrying; never create a second workload merely because the first response was lost. A revoked credential stops polling and returns control to the originating agent without starting login automatically.
Only report
ready
after endpoint health, model identity, and canary inference all pass. Report intermediate and terminal failure states honestly. Cleanup must be observable and must not release or modify the underlying booking unless that separate economic action was explicitly authorized.
只有当同一标准客户端暴露租户范围的状态、日志、指标、取消和清理操作时,生产层面才完整。每个操作都需要有限的连接超时和总超时、支持撤销感知的错误以及结构化输出。在传输失败不明确的情况下,先通过幂等密钥查询状态,然后再重试;绝不能仅仅因为第一个响应丢失就创建第二个工作负载。已撤销的凭证会停止轮询,并将控制权返回给发起Agent,不会自动启动登录。
只有在端点健康检查、模型身份验证和金丝雀推理全部通过后,才能报告
ready
状态。如实报告中间状态和最终失败状态。清理操作必须是可观察的,并且除非明确授权了单独的经济操作,否则不得释放或修改底层预订。

Proposed backend stages

建议的后端阶段

These stages describe the future backend, not code that exists in ECC:
  1. Verify entitlement, topology, fabric, and cost gates.
  2. Fetch checksum-pinned weights into backend-managed storage.
  3. Emit and validate a reviewable topology/engine plan.
  4. Launch through the provider control plane, never direct root SSH from ECC.
  5. Warm up, test health and model identity, run an SLO canary, then register the endpoint and redacted configuration.
Until every gate and lifecycle operation above exists in the canonical runtime, this skill remains a fail-closed availability check and documentation handoff.
这些阶段描述的是未来的后端,而非ECC中已存在的代码:
  1. 验证权限、拓扑、网络架构和成本关卡。
  2. 将校验和固定的权重提取到后端管理的存储中。
  3. 生成并验证可审核的拓扑/引擎计划。
  4. 通过提供商控制平面启动,绝不能从ECC直接进行root SSH连接。
  5. 预热、测试健康和模型身份、运行SLO金丝雀测试,然后注册端点和已脱敏的配置。
在上述所有关卡和生命周期操作都在标准运行时中实现之前,此技能仅作为故障关闭的可用性检查和文档移交工具。