Phos Turbo worker

RunPod Serverless worker for the first Phosphene-owned image-generation mode: Phos Turbo v0.1.

It runs Microsoft Mage-Flow Turbo at four inference steps and returns a single WebP image as base64. Phosphene, not this worker, owns user authentication, credit reservations, durable job state, and object-storage persistence.

RunPod configuration

Create a Queue endpoint from this repository's Dockerfile with:

• Model cache: microsoft/Mage-Flow-Turbo
• Active workers: 0
• Max workers: 1
• GPUs per worker: 1
• Idle timeout: 5 seconds
• Execution timeout: 600 seconds
• Initial GPU: A6000 or A40 (48 GB)

Set only non-secret handler variables in the endpoint:

MODEL_ID=microsoft/Mage-Flow-Turbo
MODEL_VERSION=phos-turbo-v0.1

The Dockerfile pins the Microsoft Mage source revision and starts from NVIDIA's CUDA 12.6 development image. It installs the matching official PyTorch 2.13 CUDA 12.6 wheels and compiles the required native FlashAttention 2.8.3 extension. The extension is deliberately limited to its SM80 kernels because this endpoint is restricted to Ampere A40/A6000 GPUs. It is also specialized to Mage-Flow Turbo's published runtime contract: BF16, head dimension 128, forward-only inference. The build retains causal, non-causal, and split native forward kernels, while unsupported dtypes, head sizes, and backward calls fail explicitly. This avoids compiling training and alternate-model kernels that the worker cannot execute. Python packages live in an isolated virtual environment. Do not replace FlashAttention with Mage's SDPA fallback or add object-storage credentials: Phosphene persists successful output through its existing generation-job transaction.

The head-dimension-128 specialization was verified against both models that reach FlashAttention on the text-to-image path: the MageFlow DiT (hidden size 3072 over 24 heads) and the Qwen3-VL-8B text encoder both use head dimension 128 in bfloat16, and both call flash_attn_varlen_func with dropout_p=0.0, window_size=(-1, -1) and no alibi or softcap.

Constraint this creates. Qwen3-VL's vision tower uses head dimension 72, so the specialized extension cannot serve it. That path only runs when an image is passed to the text encoder, which this worker's contract does not expose. Adding reference-image or edit support therefore means restoring the head-dimension dispatch in specialize_flash_attention.py and compiling the hdim-72 kernels, not just widening the request schema.

Building the image

RunPod's managed GitHub builder caps docker build at 30 minutes and this image compiles FlashAttention from source, so the image is built by the Build worker image GitHub Actions workflow and pushed to ghcr.io/targix/phos-turbo-worker. The endpoint is created from that image rather than from this repository. Compiling CUDA needs no GPU, and the runner has under 8 GB of RAM, so nvcc runs one translation unit at a time: parallel jobs exhaust the machine and the OOM killer ends the build with no compiler output.

Request and response contract

{
  "input": {
    "prompt": "A precise editorial perfume photograph",
    "width": 1024,
    "height": 1024,
    "seed": 42
  }
}

width and height must be 512..1024 and divisible by 16. seed: -1 requests a worker-generated seed. The response contains image_base64, mime_type, the resolved seed, dimensions, model version, and execution time.

Verification

Run the request and image-build configuration tests locally:

python3 -m unittest test_contract.py test_dockerfile.py

The CUDA image is intentionally not built on an Apple Silicon Mac. RunPod builds the Linux/amd64 image after the repository is connected in its console.