# 只有一台机器能跑大任务，别再靠群里抢 | EasyNet

Source: https://easynet.run/cases/problems/queue-shared-large-machine

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 只有一台机器能跑大任务，别再靠群里抢

团队只有一台机器能跑大模型，一个临时试验占住显存，紧急交付只能在群里问谁能让一下。大家都能连接机器以后，资源竞争并没有消失，反而更需要清楚的提交规则。

已有作业调度器或批处理系统应继续负责资源管理。任务不多、不可中断时，固定预约也很实用。需要多个助手和项目提交时，可以统一入口，而不是重新写一套显存调度。

在调度器前接一个提交函数，只接受预先配置的作业类型、获准输入位置和规定大小以内的文件，通过 EasyNet 返回作业编号。显存上限等配置由运维为作业类型确定；查询函数返回等待原因、运行状态和产物位置，不接受任意启动命令。

项目身份决定能提交哪些作业和使用哪条队列，凭证由运行方持有。输入必须位于执行设备实际可读取且获准的位置；资源不足应排队或拒绝，不能让函数直接绕过调度器启动进程。

运维仍要配置资源上限、优先级和取消方式。预计开始时间受前面任务影响，应作为估算显示；机器离线也要明确报告。用固定返回值跑通接口，只能检查连接，不能代替真实硬件上的容量测试。

先用无害小作业检查紧急和普通任务的次序，再取消一项任务并重启测试服务。作业编号应能与调度器对上，旧请求不应重复启动，长期等待也要有解释；有了这些事实，再讨论团队的交付时限。

01

选择获准作业

不接受任意启动命令

02

调度器排队

资源不足有等待原因

03

按作业号查询

状态与产物对回真实调度记录

EasyNet 连接提交入口，资源分配仍由调度器负责。

返回等待原因，不承诺假开始时间

合成调度响应格式；不是 EasyNet 已实现 GPU 调度的证据，也没有真实作业被提交。
示例内容 · json

```
{
  "scheduler_job_id": "demo-job-42",
  "job_type": "approved-image-batch",
  "state": "queued",
  "queue": "ordinary",
  "reason": "required GPU allocation unavailable",
  "estimated_start": null,
  "output_location": null
}
```

预期结果：调用者知道任务在排队且尚无开始时间或产物，不能把接单误认为已经运行。

接入时的检查项

资源不足时作业等待或拒绝，不并发启动到机器失稳。

优先级依据业务规则生效，普通任务的等待有可见原因。

取消和机器重启后作业状态能与调度器核对，不出现重复执行。

源码与接入资料

[为资料检索准备文本向量](https://easynet.run/cases/warm-gpu-model)

[函数接入指南](https://easynet.run/docs/connect/function)