算力基础设施正在经历一次重心迁移：企业不再只关心有多少 GPU、建了多少机房，而是开始追问这些资源能否被统一发现、快速调度，并根据任务需求弹性供给。国务院《AI+行动意见》强调智能算力互联互通和供需匹配，工信部相关行动则把目标进一步落到“盘活存量、精准对接、弹性供给”和“毫秒用算”上。
在这一背景下，超智算科技（S·AIDC）、共绩科技与开源中国围绕算力资源共享、算网平台建设、弹性算力协同、技术与商业信息共享以及用户生态展开战略合作。比合作主体本身更值得开发者和平台工程团队关注的，是它所指向的工程问题：如何把分散、异构、利用率不稳定的算力，变成可以查询、组合、调度和计量的服务。
算力互联不只是把集群接上网络
一套真正可用的算力互联平台，至少要处理四类差异。
资源差异包括 GPU 型号、显存容量、互联方式、驱动版本和可用区位置。一个需要 80 GB 显存的推理任务，不能只用“需要一张 GPU”来描述。
软件差异来自 CUDA、容器运行时、模型框架和依赖版本。硬件可用不代表任务可以直接启动，调度器还要检查运行环境是否兼容。
网络差异会直接影响分布式训练、模型加载和跨区域推理。对于需要频繁同步参数的任务，低价但高延迟的远端节点可能并不划算。
商业差异涉及价格、计费单位、服务等级和故障赔付。跨平台调度如果没有统一计量和可追踪的任务记录，很难形成稳定交易。
因此，“算网平台”不应只是资源展示页面。它需要一份标准化资源目录，以及贯穿提交、匹配、启动、观测、结算和退出的任务生命周期。
从资源库存表走向约束驱动调度
调度的关键不是找到一台空闲机器，而是在多个约束之间做选择。平台可以把一次任务请求拆成硬约束和软目标：
- 硬约束：GPU 型号、最小显存、节点数量、数据区域、运行时版本。
- 软目标：启动时间、单位价格、网络延迟、可靠性和碳排指标。
- 业务策略：是否允许抢占、是否可以跨区域、失败后能否降级到其他型号。
可以这样实践：先用一份供应商无关的 YAML 描述任务，再由适配器转换成各个算力平台或 Kubernetes 集群能够识别的请求。下面的字段是假设示例，需要按实际平台接口调整。
apiVersion: compute.example.io/v1alpha1
kind: ComputeRequest
metadata:
name: llama-inference-batch
spec:
workload:
image: registry.example.com/llm/worker:1.4.0
command: ["python", "serve.py"]
resources:
accelerator:
vendor: nvidia
models: ["H100", "A100-80GB"]
count: 2
memoryGiB: 80
cpu: 16
memoryGiB: 128
placement:
regions: ["cn-east", "cn-north"]
maxNetworkLatencyMs: 20
scheduling:
startWithinSeconds: 60
preemptible: true
fallbackModels: ["L40S"]
budget:
maxPricePerAcceleratorHour: 30
lease:
ttlSecondsAfterFinished: 300
这里的 startWithinSeconds 表达供给速度，maxNetworkLatencyMs 约束算网质量，maxPricePerAcceleratorHour 则把成本纳入调度。调度器可以先过滤不满足硬约束的资源，再对候选节点评分，而不是把所有 GPU 当成同质库存。
一个简化的评分公式可以写成：
score = 0.40 * availability
+ 0.25 * latency_score
+ 0.20 * price_score
+ 0.15 * reliability
权重不应固定在代码里。在线推理通常更看重启动速度和延迟，离线训练则可能愿意用更长排队时间换取更低价格。
给调度入口定义一个可演进的 API
当算力来自多个资源池时，业务系统不应该直接耦合每一家供应方的接口。可以在内部建立一个统一的任务入口，由算力网关完成身份校验、资源匹配和后端适配。
下面是一条可直接改造的 HTTP 请求示例。运行前将地址、令牌、镜像和区域替换为实际值：
export COMPUTE_API="https://compute-gateway.example.com"
export COMPUTE_TOKEN="replace-with-your-token"
curl --fail-with-body \
--request POST \
--url "${COMPUTE_API}/v1/jobs" \
--header "Authorization: Bearer ${COMPUTE_TOKEN}" \
--header "Content-Type: application/json" \
--data '{
"name": "embedding-index-build",
"image": "registry.example.com/ai/indexer:2.1.0",
"command": ["python", "build_index.py", "--input", "s3://dataset/docs"],
"accelerator": {
"models": ["A100-80GB", "H100"],
"count": 1,
"minimum_memory_gib": 80
},
"placement": {
"regions": ["cn-east"],
"maximum_latency_ms": 15
},
"policy": {
"start_within_seconds": 120,
"preemptible": false,
"maximum_price_per_hour": 28
}
}'
生产环境还需要补齐幂等键、任务取消、状态回调、日志地址、用量明细和错误分类。特别是跨资源池重试，不能简单地重复提交，否则可能在两个供应方同时启动任务并产生双份费用。
“毫秒用算”也不意味着所有 GPU 工作负载都能在毫秒内冷启动。模型权重加载、镜像拉取和容量扩容都可能耗时。更现实的实现路径是缩短资源发现与调度决策的时间，并通过预热镜像、模型缓存、常驻推理池和分层容量来控制端到端等待时间。
生态协同最终要落到接口和指标
技术、商业信息与用户生态共享，可以帮助资源方理解真实需求，也让开发者获得更多可选供给。但生态合作能否形成持续价值，取决于是否建立了可验证的共同语言。
接入算力互联平台时，可以优先检查以下事项：
- 资源是否有统一标识，GPU 型号、显存、拓扑和驱动信息是否可查询。
- 调度请求是否支持硬约束、价格上限、区域限制和降级策略。
- 是否记录排队、匹配、拉起、运行和释放各阶段的耗时。
- 用量计量能否追溯到租约、任务、租户和供应方。
- 跨平台失败是否有明确责任边界、重试规则和补偿机制。
- 数据是否被限制在指定区域，凭据和模型文件如何隔离。
对企业而言，第一步通常不是立刻迁移全部 AI 工作负载，而是选择可中断的批处理、评测或索引构建任务进行试点。这些任务对跨资源池调度更宽容，也更容易量化成本和利用率变化。等资源目录、计量和故障处理稳定后，再逐步接入在线推理和分布式训练。
算力互联的价值，不在于把更多硬件画进同一张拓扑图，而在于让供给真正变得可发现、可调度、可替换、可计量。只有这些基础能力形成标准化接口，“存量算力”才可能转化为开发者能够按需调用的生产资源。