2026 上海开源软件应用创新大赛设置了 AI+工业软件、智算云、开源 AI 工具三个赛道，总奖池 100 万元。其中，智算云赛道关注的不是单一模型能力，而是如何用云基础设施加速、简化并稳定 AI 运行。异构算力调度、GPU 池化、分布式训练、应用开发平台、模型部署服务和 Serverless 推理，都属于这一方向可以覆盖的工程问题。
对准备参赛或建设开源 AI 基础设施的团队来说，关键不是堆砌云原生名词，而是找到一个能测量、能复现、能部署的瓶颈，然后用开源项目把它解决掉。
智算云项目需要回答三个问题
1. GPU 是否真的被充分利用
GPU 池化的价值不只是把多台机器登记到同一个资源池。一个完整方案还需要处理设备发现、任务排队、显存隔离、故障迁移和利用率观测。
项目可以选择一个具体切口：
- 面向异构 GPU 建立统一资源描述和调度策略；
- 让多个低负载推理服务共享 GPU；
- 根据显存、吞吐量或队列长度执行动态装箱；
- 在训练任务中处理节点故障和断点恢复；
- 统计 GPU 已分配但实际空闲的时间，并触发重调度。
评价这类项目时，不能只看“成功调度了多少任务”。更有说服力的指标包括 GPU 平均利用率、显存碎片率、任务等待时间、失败恢复时间以及单位请求的算力成本。
2. 模型服务能否稳定扩缩容
Serverless 推理听起来像普通函数计算，但模型权重往往达到数 GB，冷启动还涉及镜像拉取、权重加载、显存预热和首轮算子编译。只根据 CPU 使用率扩容，通常无法反映推理服务的真实压力。
更适合观察的信号是：
- 等待执行的请求数量；
- 每个副本的并发序列数；
- 首 Token 延迟和完整请求延迟；
- KV Cache 占用率；
- 输入、输出 Token 吞吐量；
- 模型加载成功率和冷启动时间。
如果项目主打 Serverless，可以明确限定模型大小、GPU 类型和并发模式，再展示从零副本启动、突发流量扩容以及流量消退后的资源回收过程。边界条件越清楚，性能数据越容易复现。
3. 优化的是 Token 数量，还是端到端成本
“节省 Token”不能只靠截断提示词。真实系统还需要在回答质量、上下文完整性、缓存命中率和模型调用成本之间做权衡。
可落地的优化包括提示词模板去重、检索结果压缩、语义缓存、会话摘要、模型路由，以及对输出长度设置预算。项目最好同时报告质量指标和成本指标。例如，在任务成功率基本不变的前提下，比较每次请求的输入 Token、输出 Token、延迟与费用变化。
可以这样实践：部署一个可观测的 GPU 推理工作负载
下面是一个可以直接改造的 Kubernetes 示例。它假设集群已经安装 NVIDIA Device Plugin，并且存在名为 ai-inference:latest 的 HTTP 推理镜像。运行前需要把镜像地址、容器端口和健康检查路径改成项目的真实值。
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference
spec:
replicas: 1
selector:
matchLabels:
app: ai-inference
template:
metadata:
labels:
app: ai-inference
spec:
containers:
- name: server
image: ai-inference:latest
ports:
- name: http
containerPort: 8000
env:
- name: MAX_BATCH_SIZE
value: '16'
- name: MAX_INPUT_TOKENS
value: '4096'
- name: MAX_OUTPUT_TOKENS
value: '512'
resources:
requests:
cpu: '2'
memory: 8Gi
nvidia.com/gpu: '1'
limits:
cpu: '4'
memory: 16Gi
nvidia.com/gpu: '1'
startupProbe:
httpGet:
path: /ready
port: http
periodSeconds: 5
failureThreshold: 60
readinessProbe:
httpGet:
path: /ready
port: http
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: http
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: ai-inference
spec:
selector:
app: ai-inference
ports:
- name: http
port: 80
targetPort: http
部署并检查 GPU 是否被正确分配：
kubectl apply -f inference.yaml
kubectl rollout status deployment/ai-inference
kubectl get pods -l app=ai-inference -o wide
kubectl describe pod -l app=ai-inference
这里故意使用较长的 startupProbe 容忍模型加载，同时用 readinessProbe 阻止未预热的副本接收流量。生产环境还应接入 GPU 指标采集，并按队列长度或并发请求数扩容。直接套用 CPU 型 HPA，可能出现 GPU 已经排队、CPU 指标却仍然偏低的情况。
如果要展示 GPU 池化能力，可以在此基础上加入自定义调度器、设备共享插件或队列控制器。但必须说明隔离机制：时间片共享不等于显存隔离，多租户模型也可能带来显存耗尽、侧信道和性能抖动风险。
再加一层 Token 预算控制
下面的 Python 示例不依赖第三方库，可以作为网关侧预算策略的最小原型。由于不同模型使用不同 tokenizer，示例使用字符数近似估算 Token；接入真实模型时，应替换为对应 tokenizer 的精确计数。
from dataclasses import dataclass
@dataclass
class TokenBudget:
max_context_tokens: int = 4096
reserved_output_tokens: int = 512
chars_per_token: float = 3.0
def estimate(self, text: str) -> int:
return max(1, int(len(text) / self.chars_per_token))
def fit_context(self, system_prompt: str, passages: list[str]) -> list[str]:
input_budget = self.max_context_tokens - self.reserved_output_tokens
used = self.estimate(system_prompt)
selected = []
for passage in passages:
cost = self.estimate(passage)
if used + cost > input_budget:
break
selected.append(passage)
used += cost
return selected
if __name__ == '__main__':
budget = TokenBudget(max_context_tokens=1024, reserved_output_tokens=256)
prompt = '请根据资料回答问题，不要编造未提供的信息。'
passages = [
'GPU 池化需要处理设备发现、调度和隔离。' * 20,
'Serverless 推理的主要挑战包括冷启动和弹性伸缩。' * 20,
'语义缓存可以减少重复模型调用。' * 20,
]
selected = budget.fit_context(prompt, passages)
print(f'selected_passages={len(selected)}')
print(f'estimated_tokens={budget.estimate(prompt + "".join(selected))}')
执行方式：
python3 token_budget.py
这个原型只解决“不能超过上下文窗口”的硬约束。进一步改造时，可以按检索相关度排序段落，记录被删除内容，并在离线评测集上比较回答正确率。否则 Token 降低可能只是把必要证据删掉了。
参赛和落地时应准备什么
一个有竞争力的智算云项目，最好交付完整的复现实验，而不只是架构图。提交前可以检查：
- README 是否能让新用户在一小时内启动最小环境；
- 是否提供 Kubernetes YAML、Helm Chart 或自动化安装脚本；
- 性能数据是否注明 GPU 型号、模型版本、批大小和并发量；
- 是否同时测试吞吐量、尾延迟、冷启动与故障恢复；
- Token 优化是否保留质量基线，而不是只报告费用下降；
- GPU 共享是否解释显存隔离、安全边界和资源争用；
- 核心功能是否真正开源，外部服务依赖是否可以替换。
智算云赛道横跨底层算力与上层模型服务，选题范围很宽。更稳妥的做法是缩小问题：选择一种工作负载、一个可量化瓶颈和一组可复现基准。能让其他开发者部署、测量并验证收益的项目，才更容易从概念演示走向实际基础设施。