Benchmarks: GPU seconds by resolution, frames and samples

Measured on JANCTION Render with one NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition (96 GB): a 24-frame 720p MP4 at 64 samples takes about 59 GPU seconds, 48 frames at 1080p/128 samples about 322 s, and a 4-frame preview about 4 s. The price column uses 0.1 JPY per GPU second; a welcome credit of up to 500 JPY for a new key (100 JPY with no card, 400 JPY more after saving a card that is not charged)

These are individual production measurements (2026-09-30 to 2026-10-01 UTC), not averages, medians or speed guarantees. The 4-GPU-second preview used a rotating cube, four 640x360 tiles, 16 samples and scene lights on the GPU named above; its measured round trip was about 8 seconds.

GPU seconds measure worker run time including Blender startup and scene loading, not GPU-chip utilization alone. Round trip runs from submission to receiving the result, with no queue wait in these measurements. Whether input upload is included depends on the measurement path; do not treat every case as upload-inclusive or infer unmeasured transfer and queue time from GPU seconds.

Complex geometry, volumes and large textures can change the result; simple scaling with samples or resolution is not guaranteed. See the machine-readable measurements (CSV, one row per measurement) and the downloadable scene files in the matrix below. Those files reproduce the matrix scenes, not the historical Claude.ai example.

Same scene, different settings

The same scene with only the settings changed (2026-10-01, Cycles, denoising on, PNG frames). Scenes: cube_scene = glass sphere, cube, torus and a monkey on a floor, 24-frame orbit (samples/cube_scene.py), polyhaven_room = Poly Haven table on a textured floor under an HDRI (samples/polyhaven_room.py, assets by name). Download the files (cube_scene.py · polyhaven_room.py) and run the same settings on your own GPU or another service to compare. Command: janction-render render cube_scene.py --frames 1-24 --size 1280x720 --samples 64 --output png --wait

What the table says: on scenes this simple the sample count hardly matters (32 to 128 samples adds about 10%); the time is dominated by fixed work per frame (scene build, denoising, writing the file): about 2.4 s per 720p frame and 5.2 s per 1080p frame, and 100 frames cost about 4 times 24 frames. These observations apply to these scenes; sample count may have a larger effect elsewhere. Check an estimate and a small preview for your own scene.

Blender's own demo files at fixed settings (reproduce anywhere)

Two demo scenes distributed by Blender, rendered on the production service on 2026-10-08. Download the same zip (sha256 below), render it with the same settings on your own GPU or on another service, and compare seconds and price per frame directly. The numbers come from scripts/bench_same_scene.py (MIT).

• Final: frames 1-3, 1920x1080, 128 samples, denoising on, PNG, Cycles, Blender 5.2. Preview: frame 1, 1280x720, 16 samples. One NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition (96 GB).
• Prices at 0.1 JPY per GPU second. Each new key starts with 100 JPY of free GPU time (no card) and 400 JPY more after saving a card that is not charged, up to 500 JPY (14 days); after that, previews stay free up to 2 GPU-minutes a day and finals cost 0.1 JPY per GPU-second.
• "New key to first image" runs from an ordinary PC over the internet and includes POST /v1/keys, uploading the .blend (66 MB and 12 MB), the preview and downloading the image. There is no sign-up step.
• The service takes one .blend, so the script first makes a self-contained copy with a local Blender (linked libraries made local, images packed); the image does not change. The Barcelona zip lacks one legacy texture (water bump.jpg) that Cycles does not use.
• These are stills, so frames 1-3 are the same image; three frames only average out start-up noise.

• classroom.zip: sha256 0f0ecc58d45f12b2f4272a53e2d8e69135518e16e956b118f10c20d8dcfdf5e6
• pabellon_barcelona_v1.scene_.zip: sha256 0a85bf512329f1780563069512b934d679a6c543eeb1a4ec4f60cddeab706697

The same files on a laptop GPU

Laptop: NVIDIA GeForce RTX 5070 Ti Laptop GPU (12 GB), Blender 5.2.0 LTS, Cycles (OptiX), the same zip (sha256 match) and settings, measured 2026-10-20. Mean of 3 frames rendered in one open Blender; Blender start-up and scene loading are not included (the service's GPU seconds include start-up). A gaming laptop renders these in about 14 s a frame, so a few stills are fine locally. The service pays off for animations with many frames (it renders parts in parallel), when you want your laptop free, and for heavy scenes that do not fit in 12 GB (96 GB here).

From an agent's script to a finished video (one measured loop)

One loop measured on the production GPU on 2026-10-12. HTTP API; the bpy script was written by an agent from the request 'a matte ceramic mug on a wooden table, soft studio light, slow turntable'. GPU seconds and round trip per step:

Total 49.6 GPU-seconds, about 5.0 JPY at the per-second price; this run was inside a new key's free time, so nothing was charged. The preview verdict said the object was cut by the frame edge; applying the fix code it returned made the next preview clean.

Cases

What the outputs look like

Prompts and calls used

• preview, 4 of 24 (tiled) @ 640x360 tiles: Using JANCTION Render, build a glossy red cube rotating on a grey floor and show me a 4-frame preview.
• final, 24 @ 1280x720: Render 24 frames at 1280x720 as an MP4.
• final, 48 @ 1280x720: janction-render render cube_scene.py --frames 1-48 --size 1280x720 --samples 64 --wait
• final, 48 @ 1920x1080: Render the final 48 frames at 1080p with 128 samples.
• preview, 1 @ 960x540: Show me one preview frame at 960x540.
• preview, 1 @ 640x360: POST /v1/files pyramid.gltf, then POST /v1/jobs {kind: preview, environment: studio, environment_visible: false}
• preview, 1 @ 640x360: blender="5.2", environment="night"
• final (EEVEE, webm), 24 @ 960x540: POST /v1/jobs {kind: final, engine: "eevee", output: "webm", frame_start: 1, frame_end: 24, width: 960, height: 540, samples: 32}
• final (Cycles, mp4), 24 @ 960x540: Same scene on Cycles: POST /v1/jobs {kind: final, frame_start: 1, frame_end: 24, width: 960, height: 540, samples: 32}
• final (ProRes), 6 @ 640x360: output: "prores"
• preview (EEVEE), 4 of 24 (tiled) @ 640x360 tiles: engine: "eevee" (slower than Cycles for a preview: EEVEE compiles shaders for about 7 s in every fresh container; the same 4 frames on Cycles took 2.2 GPU s)
• preview (compare), 1 x 4 presets @ 320x180 tiles: POST /v1/jobs {kind: preview, environment: "compare", width: 640, height: 360, samples: 16} (all four presets in one Blender session)
• preview (orbit), 4 angles (0/90/180/270 deg) @ 320x180 tiles: orbit=true, environment="sunset"
• final (orbit), 48 (one full turn) @ 960x540: render_final(orbit=true, orbit_frames=48, width=960, height=540, samples=24, environment="studio")

How to read the numbers

• GPU seconds are the container's run time including Blender start-up and scene loading; the free quota counts exactly this.
• render_estimate uses the scene's own earlier measurement when it exists, otherwise the median of recent chunks.
• Short jobs are dominated by the fixed start-up (1-2 s); long jobs scale with frames x pixels x samples. EEVEE adds about 7 s of shader compilation per job and then costs about two-thirds of Cycles per frame (same scene, 720p, 120 frames: 142 vs 223 GPU-seconds, 2026-11-06), so it pays off on animations, not on previews.
• The price column is a reference at 0.1 JPY per GPU second; whatever the free time covers (such as a welcome credit of up to 500 JPY for a new key (100 JPY with no card, 400 JPY more after saving a card that is not charged)) costs nothing.

Updated 2026-10-20. Operated by JasmyLab Inc.