bailian-train-deploy

Bailian Model Training → Deployment Loop (

bl

)

Deploy models into callable exclusive inference services using Bailian CLI

bl

— you can fine-tune first then deploy, or deploy base models directly skipping training. Supports three modalities: text, audio TTS, and image generation. The two "waiting" steps use Monitor for asynchronous polling without blocking the main process.

Pipeline A (Train first then deploy):
Dataset → finetune <modal> create → Wait for SUCCEEDED → Export model (usually automatic) → deploy <modal> create → Wait for RUNNING → Inference

Pipeline B (Deploy base model directly, skip training):
Select base model → deploy <modal> create → Wait for RUNNING → Inference

Pipeline B applies to scenarios where you "just want to run a certain base model as your own deployment service" — there's no essential difference from directly calling the API for inference, but you get an independent deployment instance, adjustable rate/billing method, and can integrate it into your own O&M. Only use this pipeline when users explicitly state they don't want to train / skip training / deploy base models directly; when users only don't mention training details, guide them using Pipeline A by default, do not skip training without permission.

Modality Distribution: The general process of this skill applies to all modalities, but data formats, hyperparameters, and inference commands vary by modality. After confirming the user's intent, refer to the corresponding reference file by modality:

Text Models (dialogue/inference) →
```
references/text.md
```
Audio TTS Models (speech synthesis/CosyVoice) →
```
references/audio.md
```
Image Generation Models (text-to-image/image-to-image/Wan2.7) →
```
references/image.md
```
Future new modalities = add corresponding reference files, the skeleton of this process remains unchanged

This skill assumes
bl
(bailian-cli) is already installed. For details on commands/flags, refer to
bl <cmd> --help
; this skill focuses on process orchestration and pitfall avoidance.

Write Operation Guardrails (Read Before Creation)

bl finetune <modal> create

and

bl deploy <modal> create

are real write operations that will generate billed resources (fine-tuning training + inference deployment).

bl

does not have
--dry-run
, so use pre-check commands instead of dry runs and billing confirmation to gate reserved resources. Any write operation must pass these three gates first:

Pre-check instead of dry-run (must run before creation, confirm feasibility before writing). These pre-check commands require authentication via the Pre-checks below — if not authenticated, run
```
bl auth login
```
first then perform pre-checks:
- Before training:
```
bl finetune capability --model <base-model>
```
  — confirm that the base model supports the training-type you selected (if not supported, it will fail quickly without consuming quotas; the
```
create
```
  submission will also validate this again).
- Before deployment:
```
bl deploy models --source custom
```
  (fine-tuned output for Pipeline A) or
```
--source base
```
  (base model for Pipeline B) — confirm that the target model can be deployed, check available plans, then decide on
```
--plan
```
  .
- Reuse detection:
```
bl deploy list --status RUNNING
```
  — if there is already a running deployment referencing the same
```
finetuned_output
```
  , directly reuse its
```
deployed_model
```
  , do not create a second billed instance.
Billing Confirmation Hard Gate (mu/ptu):
- ```
lora
```
  (default, billed by token, generally no charge when idle) — safe default, can be created directly.
- ```
mu
```
  /
```
ptu
```
  are reserved/exclusive resources, billed even when idle — before creation, must explicitly explain the billing method to the user and obtain confirmation. In non-interactive environments such as agents / CI, do not automatically enable reserved resources. When mu/ptu is involved, hand over the command along with "this will incur idle charges" to a human for confirmation in the terminal (currently
```
bl
```
  does not provide a
```
--yes
```
  flag to skip confirmation, and confirmation is fully controlled by humans).
Account Readiness Check:
```
bl auth status
```
— stop if
```
authenticated: false
```
, provide
```
bl auth login --api-key sk-...
```
. Bailian uses API key / access token for authentication, there is no separate real-name verification gate,
```
auth status
```
serves as the account readiness check.

Anti-Trigger List (Intents Not Covered by This Skill, with Complete Commands)

User Intent	Route to	Complete Example Command
Just want to test model performance / one-time dialogue	`bailian-cli`	`bl text chat --model qwen3-8b --message "..."`
Model is confirmed, only need inference methods	`bailian-cli`	`bl text chat --model <model> --message "..."`
Don't know which base model to choose / model selection	`bailian-model-recommend`	(Let that skill recommend based on scenarios)
Purely check model parameters / price / context window	`bailian-docs-llm-wiki`	(Check model data directory)
Deployment already exists, only need to generate inference examples	`bailian-cli`	`bl text chat --model <deployed_model> --message "..."` or `bl speech synthesize --model <deployed_model> --voice default --text "..."` or asynchronous API + trigger words (image generation, see image.md)
Query/delete existing training tasks / deployments (lifecycle management)	Directly use `bl`	`bl finetune list` / `bl deploy list` / `bl deploy delete --deployed-model <id>`

This skill only handles the closed loop of "create new training task + create new deployment + deliver inference". Full lifecycle management of training tasks and deployments (list / stop / delete historical tasks, delete deployments, etc.) is not within the scope of this skill; use
bl finetune list
/
bl deploy list
/
bl deploy delete
for direct operations.

Anti-Hallucination Checklist

--model
has different meanings in different commands, do not reuse it:
- ```
bl finetune <modal> create --model
```
  → Base model name (text
```
qwen3-8b
```
  , audio
```
cosyvoice-v3-flash
```
  , image
```
wan2.7-image-pro
```
  ).
- ```
bl deploy <modal> create --model
```
  → Exported model name (Pipeline A:
```
qwen3-8b-ft-...
```
  /
```
cosyvoice-v3-flash-ft-...
```
  /
```
wan2.7-image-pro-ft-...
```
  ; Pipeline B: base model name).
- Inference command
```
--model
```
  → Must use
```
deployed_model
```
  from the response of
```
deploy <modal> create
```
  , not the name you passed to deploy <modal> create.
--training-type
values are exhaustive:
```
sft
```
/
```
sft-lora
```
(default) /
```
dpo
```
/
```
dpo-lora
```
/
```
cpt
```
. Mapping is completed at the CLI boundary (
```
sft-lora
```
→
```
efficient_sft
```
), always pass CLI values, do not pass server-side strings.
```
cpt
```
has no
```
-lora
```
variant. Audio TTS and image generation only use
```
sft-lora
```
—
```
finetune audio create
```
/
```
finetune image create
```
do not expose this flag, only
```
finetune text create
```
accepts it.
--plan
values are exhaustive:
```
lora
```
(default, billed by token) /
```
ptu
```
(requires
```
--input-tpm
```
/
```
--output-tpm
```
) /
```
mu
```
(requires
```
--deploy-spec
```
/
```
--capacity
```
). Base models in Pipeline B usually do not support
lora
. Audio TTS fine-tuned models only support
mu
. Image generation fine-tuned models only support
lora
.
--deploy-spec
(not ~~template-id~~): Deployment specification flag for mu plan. The CLI reads
```
template_id
```
from the catalog and sends it as
```
deploy_spec
```
in the request body.
--source
values are exhaustive (
```
bl deploy models
```
):
```
custom
```
(fine-tuned output) /
```
base
```
(base model) /
```
public
```
.
--learning-rate
must be a string: Pass
```
"3e-4"
```
, do not pass the number
```
3e-4
```
to avoid JSON precision loss (applies to text models, not required for audio/image).
Inference commands vary by modality: Use
```
bl text chat
```
for text models,
```
bl speech synthesize --voice default
```
for audio TTS models, and asynchronous API + trigger words for image generation (see
```
references/image.md
```
).
These flags/subcommands do not exist:
```
bl
```
has no
```
--dry-run
```
, no bare
```
finetune create
```
/
```
deploy create
```
(must include modality segment:
```
finetune text|audio|image create
```
,
```
deploy text|audio|image create
```
), no
```
finetune start
```
, no
```
deploy stop
```
(CLI has no stop command yet, running mu/ptu instances need to be disabled in the console).

Required parameters:

--model

--datasets

for

finetune <modal> create

;

--model

--name

for

deploy <modal> create

Pre-checks (Start of Action Flow)

Authentication:

bl auth status

, confirm API key is configured (

DASHSCOPE_API_KEY

bl auth login --api-key sk-...

Base model selection: Query training capabilities with
```
bl finetune capability
```
(queries listFoundationModels, uses API key, no console login required):
- ```
bl finetune capability --model <base-model>
```
  — which training types are supported by this model.
- ```
bl finetune capability --training-type sft-lora
```
  — reverse query: which models support this training type (returns
```
models
```
  list with Chinese names).
- After selecting a base model, you can directly proceed to Step 2;
```
bl finetune <modal> create
```
  will also validate with listFoundationModels before submission, and will fail quickly if not supported.
- Recommended text inference models are Qwen3 series (
```
qwen3-8b
```
  /
```
qwen3-14b
```
  /
```
qwen3.6-flash
```
  ); use
```
cosyvoice-v3-flash
```
  for audio TTS; use
```
wan2.7-image-pro
```
  /
```
wan2.7-image
```
  for image generation.

Step 1: Prepare Dataset

Supports three data sources, you (Agent) can flexibly choose based on user intent, do not hardcode the interaction process — you have the ability to ask questions proactively, so naturally confirm with users after knowing the options:

Local Dataset — User provides local file path, use directly.
Uploaded Dataset — Select from existing datasets on Bailian (
```
bl dataset list
```
).
Generate Sample Data — With user consent, generate a small-scale sample data only for running through the process (limited effect, need to inform users truthfully).

Data format varies by modality, see corresponding reference files:

Text Models:
```
.jsonl
```
files (ChatML/DPO/CPT schema), see
```
references/text.md
```
.

Audio TTS:

.zip

package (contains

data.jsonl

train/*.wav

), see

references/audio.md

Image Generation:
```
.zip
```
package (contains
```
data.jsonl
```
+ flat image files), see
```
references/image.md
```
.

Before submitting training, run

bl dataset validate --file <path>

to pass validation before proceeding (CLI automatically detects schema, you can also explicitly specify with

--schema tts

--schema image

--schema chatml

Step 2: Create Fine-tuning Task

bash

bl finetune <modal> create \
  --model <base-model> \
  --datasets <path-or-file-id> \
  --output json

training-type values and mapping see

references/finetune.md

. Modality-specific hyperparameters see corresponding reference files:

Text models (

finetune text create

): Accept

--training-type

--n-epochs

--learning-rate

, etc., see

references/text.md

Audio TTS (
```
finetune audio create
```
): Does not expose
--training-type
(internally fixed to
```
sft-lora
```
), hyperparameters are automatically injected by CLI, see
```
references/audio.md
```
.
Image generation (
```
finetune image create
```
): Does not expose
--training-type
(internally fixed to
```
sft-lora
```
), hyperparameters are automatically injected by CLI, see
```
references/image.md
```
.

Record from the response:

output.job_id

output.finetuned_output

(exported model name, in the format

<base>-ft-<ts>-<id>

Step 3: Wait for Training Completion (Asynchronous)

Use the Monitor tool to run the built-in waiting script of this skill — it will notify when status changes and exit when reaching terminal state:

Monitor command: bash <skill-directory>/scripts/wait.sh finetune <JOB_ID>

<skill-directory>

is the base directory of this skill (provided when the skill is loaded, contains

scripts/wait.sh

), replace with the actual path. The script polls every 30s, terminal states are

SUCCEEDED

FAILED

CANCELED

PARTIALLY_SUCCEEDED

⚠️ Pitfall Avoidance: Do not write a manual
status=...
polling loop in zsh.

status

is a read-only built-in variable in zsh, assigning it will report

read-only variable

and exit the script with code 1. Use the bash script of this skill (

#!/usr/bin/env bash

) to avoid this, or use variable names like

st

when writing your own.

Step 4: Export Best Model (Usually Skippable)

After the task is SUCCEEDED, the platform will automatically export the best checkpoint as a deployable model — you can directly proceed to Step 5 without manual export.

Only explicitly export when you need to deploy a non-best checkpoint:

bash

bl finetune checkpoints --job-id <JOB_ID>          # List available checkpoints
bl finetune export --job-id <JOB_ID> --checkpoint <name> --model-name <custom-name>

Step 5: Create Deployment

Before creation, pass the Write Operation Guardrails:
bl deploy list --status RUNNING
to check if there is an existing deployment of the same model that can be reused;
bl deploy models --source custom|base
to confirm available plans;
mu
/
ptu
must obtain user billing confirmation first.

⚠️ Critical Pitfall: Fine-tuned models cannot be directly called using the fine-tuned output name, it will return 404
Model not exist
. You must create a deployment first. (Same for deploying base models in Pipeline B — direct calling uses public inference and does not go through your deployment instance.)

bash

bl deploy <modal> create \
  --model <model-name> \              # Fine-tuned output name (Pipeline A) or base model name (Pipeline B)
  --name <display-name> \
  --plan <lora|ptu|mu> \              # See explanation below
  --output json

Modality segment (
```
text
```
/
```
audio
```
/
```
image
```
) must match the modality of the deployed model; the flags of the three modality subcommands are identical.
```
--model
```
: Pass
```
finetuned_output
```
from Step 2 for Pipeline A; directly pass the base model name for Pipeline B.
```
--plan
```
:
- Default
```
lora
```
  (billed by token) for text fine-tuned models,
```
mu
```
  is also available.
- Audio TTS fine-tuned models only support
  mu
  (do not support
```
lora
```
  /
```
ptu
```
  ), require
```
--deploy-spec
```
  +
```
--capacity
```
  .
- Image generation fine-tuned models only support
  lora
  (do not support
```
mu
```
  /
```
ptu
```
  ).
- Base models in Pipeline B usually only support
```
ptu
```
  /
```
mu
```
  , do not support
  lora
  .
- Required parameters and billing details for each plan see
  references/deploy.md
  .
```
--deploy-spec
```
: Deployment specification for mu plan (e.g.,
```
dps-20260521172224-1vabse
```
), automatically matched from the catalog if omitted.
Unsure which plans are supported: Use
```
bl deploy models --source custom
```
for Pipeline A,
```
bl deploy models --source base
```
for Pipeline B, select from the returned
```
plans
```
.

⚠️ Top-Frequency Error Pitfall:
--model
has different meanings in
deploy <modal> create
and inference commands —

deploy <modal> create --model

passes the exported model name,

output.deployed_model

returned in the response is the deployment instance ID, and the inference command

--model

must use

deployed_model

, do not reuse the exported model name. See

references/deploy.md

Record from the response:

output.deployed_model

Step 6: Wait for Deployment Readiness (Asynchronous)

Monitor command: bash <skill-directory>/scripts/wait.sh deploy <DEPLOYED_MODEL>

<skill-directory>

is the same as in Step 3. Polls every 15s,

RUNNING

means ready (terminate if

FAILED

STOPPED

⚠️ Pitfall Avoidance: Status Propagation Delay. Immediately calling the model when deployment just reaches

RUNNING

may briefly return 404

Model not exist

— this is server-side status propagation delay, not an incorrect model name.

bl deploy get

may also still show

PENDING

. It will stabilize within about 1 minute; if you encounter 404, wait ten seconds and retry; if it persists, first check if you are using

deployed_model

instead of the fine-tuned output name.

Step 7: Inference and Delivery

Inference commands vary by modality:

Text models:

bash

bl text chat --model <DEPLOYED_MODEL> --message "Your question"

Audio TTS models:

bash

bl speech synthesize --model <DEPLOYED_MODEL> --voice default --text "Text you want to synthesize" --out result.mp3

Image generation models (asynchronous API, requires trigger words):

bash

# See references/image.md — requires X-DashScope-Async header + prompt containing trigger words

--model
must use
deployed_model
from the response of
deploy <modal> create
, not the fine-tuned output name.
--voice
for audio TTS is fixed to
default
. Image generation requires asynchronous calling and prompts containing trigger words. See corresponding modality reference files.

When delivering to users, provide:

Deployment instance ID (
```
deployed_model
```
) — use this for inference, not the fine-tuned output name
One directly executable inference example command

Common O&M commands:

bl deploy get --deployed-model <id>

to check status;

bl deploy delete --deployed-model <id>

to delete deployment;

bl finetune list

to check historical tasks.

Closing Tips

Idle Charges and Deletion:
```
lora
```
generally has no charge when idle;
```
mu
```
/
```
ptu
```
are charged even when idle, clean them up when not in use, and
```
bl deploy delete
```
has status constraints (CLI has no stop command). Details see
```
references/deploy.md
```
.
Reuse Datasets: When training with the same data multiple times, first run
```
bl dataset upload
```
to get a file-id, then use
```
--datasets <file-id>
```
to avoid repeated uploads.
Poor Performance: Prioritize adding data (quantity and quality), then adjust
```
n-epochs
```
/
```
learning-rate
```
, and finally consider full-parameter
```
sft
```
. Small datasets (<100 entries) have limited performance upper limits, manage expectations accordingly.

bailian-train-deploy

NPX Install

Tags

SKILL.md Content (Chinese)

Bailian Model Training → Deployment Loop (
`bl`
)

Write Operation Guardrails (Read Before Creation)

Anti-Trigger List (Intents Not Covered by This Skill, with Complete Commands)

Anti-Hallucination Checklist

Pre-checks (Start of Action Flow)

Step 1: Prepare Dataset

Step 2: Create Fine-tuning Task

Step 3: Wait for Training Completion (Asynchronous)

Step 4: Export Best Model (Usually Skippable)

Step 5: Create Deployment

Step 6: Wait for Deployment Readiness (Asynchronous)

Step 7: Inference and Delivery

Closing Tips

bailian-train-deploy

NPX Install

Tags

SKILL.md Content (Chinese)

Bailian Model Training → Deployment Loop (bl)

Write Operation Guardrails (Read Before Creation)

Anti-Trigger List (Intents Not Covered by This Skill, with Complete Commands)

Anti-Hallucination Checklist

Pre-checks (Start of Action Flow)

Step 1: Prepare Dataset

Step 2: Create Fine-tuning Task

Step 3: Wait for Training Completion (Asynchronous)

Step 4: Export Best Model (Usually Skippable)

Step 5: Create Deployment

Step 6: Wait for Deployment Readiness (Asynchronous)

Step 7: Inference and Delivery

Closing Tips

Bailian Model Training → Deployment Loop (
`bl`
)