HuggingFace Provider: Image Generation

[Kamilbenkirane]

Sub-issue of #148

Scope

Add image generation via HuggingFace's hf-inference endpoint.

• Endpoint: POST https://router.huggingface.co/hf-inference/models/{model_id}
• Request: {"inputs": "prompt", "parameters": {...}}
• Response: Raw image bytes (PNG)
• Auth: Authorization: Bearer hf_XXX via HF_TOKEN
• Streaming: Not supported

Files

Create: src/celeste/providers/huggingface/inference/, src/celeste/modalities/images/providers/huggingface/
Modify: src/celeste/modalities/images/providers/__init__.py, src/celeste/modalities/images/models.py

[Kamilbenkirane]

While working on image generation support for HuggingFace (sub-issue of #148), we dug into how router.huggingface.co handles image sub-providers (Together, nscale, fal-ai — all accessible via HF_TOKEN).

Finding: each sub-provider uses a completely different image API format behind the router. HF isn't a unified API here — it's just a billing proxy. hf-inference itself only supports ~4 image models.

This maps exactly to the Vertex AI pattern we already have: Anthropic is its own Provider.ANTHROPIC, and auth=GoogleADC() reroutes it through Vertex. Same idea — Together/nscale/fal-ai should be their own Provider.* entries, and auth=HuggingFaceAuth() would reroute them through HF's router.

So we're rescoping: instead of building an hf-inference-only image client, we'll add HF routing support (auth=HuggingFaceAuth() / HF_TOKEN) when we implement these providers for images.

@LeoLejeune do you agree ? Is it fine for you ?

[Leo-le-jeune]

@Kamilbenkirane, you missed the dash in my username, it's actually @Leo-le-jeune. Sorry for the late reply!
I think your proposal is great; it really respects the SSOT (Single Source of Truth) concept I'm so fond of.