# Spaces aren't allocating for ZeroGPU tonight

> Source: <https://discuss.huggingface.co/t/spaces-arent-allocating-for-zerogpu-tonight/178683#post_3>
> Published: 2026-08-15 03:08:12+00:00

Space never allocated: `hardware.current: null`

, builds succeed, app never runs

Claude wrote this up to save some time. Been a bit of a journey tonight trying to get it working, so far no dice.

**Space:** `AbstractPhil/alephllm-chat`

(Gradio SDK, ZeroGPU requested)

**Account:** AbstractPhil · **Observed:** 2026-08-14 → 2026-08-15

Symptom

The Space builds successfully on every commit and is never allocated a

machine. Runtime API reports:

```
stage    : APP_STARTING        (indefinitely)
hardware : {"current": null, "requested": "zero-a10g"}
errorMessage : null
```

`current: null`

persists for hours. Switching the request to `cpu-basic`

does not allocate either, so this is not ZeroGPU-specific.

Build is not the problem

Build log completes normally every time:

``` php
--> RUN --mount=target=/tmp/requirements.txt ... CACHED
--> COPY --link --chown=1000 ./ /home/user/app   DONE
--> Pushing image                                 DONE 0.8s
--> Exporting cache                               DONE 0.5s
```

The app is not the problem

The identical `app.py`

runs correctly outside Spaces (same Python 3.12,

same gradio, same `spaces`

package): it boots, serves `/config`

, and

answers requests. It is the canonical ZeroGPU shape — model loaded at

module level and moved to `cuda`

, `@spaces.GPU`

on the generator, plain

`demo.launch()`

. No threads, no locks, no asyncio, no coroutines, no

subprocesses of our own.

Related history on this account (may be the same underlying issue)

-
The predecessor Space (now `AbstractPhil/alephllm-chat2`

) spent ~16h

serving a **two-day-old commit**: new builds succeeded, containers

booted cleanly with `Running on local URL`

, but traffic kept going to

the old revision and `runtime.sha`

never advanced. Factory rebuild and

restart had no effect. Recreating the Space under a new name worked

once, then the new Space hit the `current: null`

state described above.

-
`alephllm-chat2`

is now **PAUSED but still reports**

`hardware.current: zero-a10g`

, with `requested: cpu-basic`

stuck in

flight. Re-issuing the hardware change and restarting the Space does

not apply it. It appears to be holding a hardware assignment it was

asked to release.

Similar reports

Ask

- Why is no machine being allocated for
`AbstractPhil/alephllm-chat`

despite a successful build and a pending hardware request?
- Can the stuck hardware assignment on
`AbstractPhil/alephllm-chat2`

(`current: zero-a10g`

while PAUSED, `requested: cpu-basic`

) be

released?

Additionally, what is this TWO LINKS PER POST thing for new users? I’m nowhere near a new user for huggingface.

Well on the plus side, the AlephLLM Mini-Beatrix is perfectly playable on cpu. Pretty fun ByteLM structured system turned out pretty smart.