• Compute
  • Customers
  • Pricing
Sign In
More Blog Posts
XDiscordLinkedInYouTube

Products

  • GPUs
  • Inference
  • Studio

Developers

  • Model library
  • Documentation
  • Glossary

Company

  • About Us
  • Blog
  • Events
  • Partnership
  • Scale
  • Career
  • Ambassador program
  • Mission & Vision

Popular models

    Stay in the loop

    By submitting, you acknowledge that we may collect and use the information you provide, which may include personal information.

    XDiscordLinkedInYouTube

    Copyright ©2026 All rights reserved.

    Privacy PolicyTerms of UseLegal Documentation
    More Blog Posts
    Other

    Which Platforms Can Manage Workflow Versions for Kling 3.0 Turbo APIs and Private Video Workflows and Run Them Across GPUs?

    October 22, 2026

    A Turbo pipeline's "version" has three owners: the Studio graph owns the private stages, the Turbo request owns the model settings, and your asset store owns the inputs. A platform that versions only one of the three leaves you unable to say which change broke last week's output. On GMI, Kling 3.0 Turbo is available as two API models, kling-3.0-turbo-t2v and kling-3.0-turbo-i2v, and the private video graph around them is a GMI Studio workflow, so the Turbo calls and the workflow run from one GMI account.

    Studio keeps the graph as a versioned workflow with controlled updates and rollback, and it runs the GPU-heavy stages on single or multi-GPU infrastructure. Turbo itself stays an API step through the GMI inference API.

    What each layer owns

    Layer Where it lives on GMI What to pin
    Turbo generation Request queue API, model IDs kling-3.0-turbo-t2v and kling-3.0-turbo-i2v Model ID, prompt, resolution, duration, aspect_ratio (T2V) or first_frame (I2V), request_id
    Private video stages A Studio workflow: custom nodes, upscaling, restoration, compositing, review gates Workflow name, tag, who last modified it
    Files Inference Storage (gmi-studio-input, gmi-studio-output) and Upload API URLs The URL or file name of every input and output

    Studio runs the middle row. The Turbo call is made through the API and files move through storage, so your own job ID is what joins the workflow record to the request record. A Studio workflow is started from the canvas with Run, so plan the Studio stage as a step your team triggers there, and script the Turbo submission and polling around it.

    The Turbo API side

    Both Turbo models use the same asynchronous request queue as GMI's other video models. You POST a job with the model ID and a payload, receive a request_id, and poll the request. The Turbo guides list the statuses queued, processing, success, and failed, and on success the video URLs are in outcome.media_urls.

    The two models take these parameters:

    • Text-to-video (kling-3.0-turbo-t2v): prompt (required, up to 2,500 characters), resolution (720p by default, or 1080p), aspect_ratio (16:9 by default, 9:16, or 1:1), and duration (3 to 15 seconds, 5 by default).
    • Image-to-video (kling-3.0-turbo-i2v): first_frame (required, a Base64 string or a URL), an optional prompt, resolution, and duration. Output framing follows the dimensions of the source image.

    The Kling 3.0 Turbo text-to-video guide and the image-to-video guide list the full request and status format. Both models show as active in GMI's public model library.

    Why Turbo settings do not carry over to Studio's Kling nodes

    Studio's video node catalog includes Kling V3 Text To Video and Kling V3 Image To Video. They are a different model from Turbo, with their own inputs: the V3 nodes list negative_prompt and a sound toggle, and the image-to-video node accepts an optional end frame through image_tail.

    For a workflow that uses both, treat them as separate steps with separate settings:

    • Do not copy a Turbo payload into a V3 node and expect the same output. Keep one settings record per model.
    • Name the step after the model, such as "turbo-draft" or "v3-final", so the version history of the graph says which model each branch uses.

    Versioning the private workflow in Studio

    GMI Studio lists versioned workflows, persistent environments, and controlled updates with rollback among its production features. The canvas is ComfyUI-based. Managed model calls live in GMI Official nodes, while hand-built logic goes into native ComfyUI nodes on that same canvas.

    Studio's change-management features:

    • Auto-save on every change. The top bar shows a live save indicator, and the save button forces a save.
    • Duplicate for experiments. The Duplicate action in My Workflows makes a copy and leaves the original untouched.
    • Metadata and tags. Edit metadata lets you rename a workflow, update its description, and change its tags.
    • Team Space permissions. Shared workflows carry Can edit or Can view permissions and a Last modified by column, and teammates can subscribe to updates.
    • Publishing with confirmation. Saving never overwrites a published workflow without confirmation, and a published workflow exposes only its required inputs.
    • Reusable outputs. Anything a run saves stays in My Media, so you can review or reuse outputs without running the graph again.

    The Managing Workflows page covers these views. A release and rollback routine built on them:

    1. Treat each release as its own copy. Duplicate the current release and name the copy with a version suffix, for example promo-pipeline-v12.
    2. Change the new copy only. The released copy stays as it was, and a released copy is never edited afterward, because names and tags can be changed and auto-save applies every edit. In Team Space, give most teammates Can view on released copies and keep Can edit with the workflow's owners.
    3. Run the new copy on a fixed test set: the same Turbo outputs, the same inputs, the same settings.
    4. Compare its saved outputs with the approved ones in My Media.
    5. When it passes, mark it as the production copy in your release log and tag it. From then on, whoever runs production jobs opens the copy the log names. Keep the previous copy untouched and in place, so rollback is a single step.
    6. To roll back, point the release log at the previous copy, have production jobs open that copy, and run the same test set to confirm it still behaves as before.

    The node menu on the GMI Studio canvas, with Duplicate, Run Branch, Pin, and Bypass options Node menu on the Studio canvas: Run Branch is the entry behind the single-stage retest, and Bypass is the switch to check before a production run.

    Joining Turbo outputs and Studio stages

    Files move between the API and the graph through Inference Storage. Its folders gmi-studio-input and gmi-studio-output are referenced by Studio nodes, and files in them, as well as outputs written to gmi-studio-output, are served from hosted URLs. You can pass such a URL to any endpoint that accepts an image or video input.

    A Turbo pipeline has two hand-offs:

    • Studio to Turbo. For kling-3.0-turbo-i2v, a start frame prepared in the graph and saved to gmi-studio-output can be passed as first_frame by URL.
    • Turbo to Studio. Copy the clip from outcome.media_urls into your own storage first, then stage it where the next stage can read it. Studio nodes that take a video_url input, such as the Kling O1 Edit Video node, read a video from a URL.

    The Upload API in the Video API reference returns a stable public URL for jpeg, png, mp4, mp3, and wav files. Anyone holding such a URL can open it, so upload only files you are allowed to expose. For a start frame that should not sit at a public URL, first_frame also accepts a Base64 string, and Base64 data URIs suit small files.

    Running private stages across GPUs

    Jobs can spread over one GPU or several and run in parallel, with no shared queue in the way. Choose from L40, A6000, A100, H100, H200, and B200. H100 and H200 are available now, and B200, part of NVIDIA Blackwell, is on pre-order.

    Those GPUs run your private stages: upscaling, restoration, compositing, and the custom nodes in the graph. Measure the Turbo API path and the Studio stages separately in the pilot, since a slow queue on one side looks the same as a slow stage on the other.

    For failures, the execution panel names the node that failed and why. Run Branch runs only the selected node and its upstream dependencies, which lets you retest a private stage without calling Turbo again when the branch reads a saved Turbo output and no node upstream of the selected one submits a new generation. Bypass skips a stage while you test, so check the node states before a production run.

    Several teams on one pipeline can step up to Studio Enterprise, which covers production workflow support, org-level workflow ownership, RBAC with usage visibility, full architectural customization, and dedicated GPU clusters.

    Job record fields for tracing a clip back to its Studio copy

    Store this for every output, so each Turbo job traces back to the Studio version that processed it:

    • Studio workflow copy name, tag, and Last modified timestamp
    • Versions of private nodes and the environment they run in
    • Turbo model ID and the full request payload
    • request_id and final status
    • Input URLs, plus a hash of each file
    • Output location after copying to your own storage
    • Approval result and reviewer

    Five pilot tests for a Turbo and Studio pipeline

    1. Replay. Rerun one approved job from its record and confirm the Turbo payload, the workflow copy, and the private node versions are enough to set it up again. Generated video can differ between runs, so judge a replay against your acceptance criteria, not frame by frame.
    2. Release and rollback. Release a duplicated workflow copy, then return the release log to the previous copy and confirm the same test set runs.
    3. Single-stage retest. Break one private stage on purpose and recover with Run Branch.
    4. Throughput. Submit a realistic batch, and time Turbo jobs and Studio stages separately on the GPU option you plan to use.
    5. Cost per approved clip. Add every billed model call (Turbo requests, plus any Kling V3 or Kling O1 Edit Video nodes the graph runs), GPU time that is billed separately, and storage. Include rejected generations, take both figures from the same batch, and divide by approved clips.

    When the API alone is enough

    A direct Turbo integration is simpler when every job is one generation that goes straight to review. A workflow layer pays off once private post-processing, several editors, rollback after a change, or parallel GPU stages enter the pipeline.

    FAQ

    Can we reuse one private stage, such as our upscale-and-composite chain, across several workflows?

    Select that stage's nodes and connections on the canvas, right-click, and choose Save Selected as Template. It is stored as a user-generated subgraph blueprint that teammates can find in search. In any other workflow, double-click an empty area of the canvas, filter the search to Blueprints, then press Enter or double-click the stage's row (or drag the row onto the canvas) and it drops in as a ready-to-tweak subgraph. When the stage changes, save the new version under a name with a version suffix and note that name in the job record.

    Which node writes a Studio stage's output so the Turbo call can use it?

    A Save node does. Save Image, Save Audio, and Save Video cover the three media types, and a workflow needs one to hand back its outputs; right-clicking it downloads the file. Saved results are written to gmi-studio-output in Inference Storage under a hosted URL. A Save Image output can go straight into an image input such as first_frame on kling-3.0-turbo-i2v, and Save Video output into a video input.

    Duplicating your first pipeline in Studio

    Once your pipeline exists as a workflow in Studio, your first versioned copy is one Duplicate away: duplicate it and run the copy on GMI's managed GPUs. To scope a dedicated cluster, role-based access, or production support, ask GMI's team about Studio Enterprise.

    Colin Mo

    Build AI Without Limits

    GMI Cloud helps you architect, deploy, optimize, and scale your AI strategies

    FAQ

    Select that stage's nodes and connections on the canvas, right-click, and choose Save Selected as Template. It is stored as a user-generated subgraph blueprint that teammates can find in search. In any other workflow, double-click an empty area of the canvas, filter the search to Blueprints, then press Enter or double-click the stage's row (or drag the row onto the canvas) and it drops in as a ready-to-tweak subgraph. When the stage changes, save the new version under a name with a version suffix and note that name in the job record.

    Ready to build?

    Explore powerful AI models and launch your project in just a few clicks.

    Get Started