bios-mcp 0.1.1-dev.16 → 0.1.1-dev.17
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +24 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -116,6 +116,30 @@ the token in a platform Hugging Face integration and pass `hf_integration_id`.
|
|
|
116
116
|
original acknowledgement instead of creating another job, wallet hold, queue
|
|
117
117
|
entry, or GPU request. The MCP server generates a fresh key when it is omitted.
|
|
118
118
|
|
|
119
|
+
## Training lifecycle (book-before-reveal)
|
|
120
|
+
|
|
121
|
+
Like inference, `create_training_job` books a GPU before it reveals a job.
|
|
122
|
+
The call blocks while the ranked ladder is booked (~40s typical); a job id and
|
|
123
|
+
the "training started" email exist only once a real pod is secured. Read
|
|
124
|
+
`status` on the response and from `get_training_status`:
|
|
125
|
+
|
|
126
|
+
- `booked` — a GPU is secured (booked == secured); the job then provisions,
|
|
127
|
+
downloads, and runs on its own. Money is captured only after this point.
|
|
128
|
+
- `securing` — still booking at the deadline; the async tail continues.
|
|
129
|
+
Poll `get_training_status` until `booked`/`running` (or a terminal state).
|
|
130
|
+
Nothing is charged while securing.
|
|
131
|
+
- `queued` — returned only with explicit queue consent; waits for stock at
|
|
132
|
+
zero charge and books via the same path.
|
|
133
|
+
- A booking-time capacity miss returns the standard `CAPACITY_UNAVAILABLE`
|
|
134
|
+
(409) with fresh `available_gpus` and **no job exists** (nothing charged);
|
|
135
|
+
a transient `503 ADMISSION_UNAVAILABLE` is a retry, never out-of-stock, and
|
|
136
|
+
the platform never auto-substitutes a GPU.
|
|
137
|
+
|
|
138
|
+
If a started job loses its pod, it rests at `interrupted` — a self-heal state
|
|
139
|
+
distinct from `failed` in which billing is already stopped. Call
|
|
140
|
+
`resume_training_job` to continue from the last checkpoint; resume re-books on
|
|
141
|
+
secured capacity before reporting resumed, so the same guarantees apply.
|
|
142
|
+
|
|
119
143
|
Training and deployment share one authoritative GPU-capacity broker. Server
|
|
120
144
|
priority is evaluated first. Within an equal-priority class, the broker rotates
|
|
121
145
|
across users and preserves FIFO order within each user's own requests. This
|