What is MinT

MinT (Mind Lab Trainer) is Mind Lab's reinforcement-learning training infrastructure for large language models — a training platform accessed through a client SDK. On your own CPU machine you write a simple Python script that defines the data, the loss function, and the RL environment; MinT manages the remote GPU cluster, object storage, and databases, and schedules model loading, forward/backward passes, optimizer updates, and sampling on demand. MinT does not try to turn "fine-tuning" into a black-box button. Instead, it hides the complexity of distributed training while keeping you in full control of the training loop and the algorithm details — switching the base model takes just one string change.

Design philosophy

MinT's design philosophy comes down to three points:

• Free you from distributed engineering. You only care about the data, the loss function, and the RL environment; the platform handles the rest.
• No black box. The training loop is visible, editable, and tunable; every step of the algorithm can be inspected and replaced.
• Switch the base model in one line. Going from Qwen3-0.6B to Qwen3-235B takes just one string change.

Core value

MinT is a good fit for enterprise LLM post-training thanks to the following capabilities:

• Low-barrier reinforcement learning. RL algorithms such as GRPO and PPO are wrapped in APIs that look just like SFT, cutting the cost of building your own.
• LoRA training at the core. A built-in LoRA Manager gives you a lightweight incremental weight right after training, ready for immediate sampling and validation.
• Remote asynchronous execution. The client only blocks when you call .result; training and sampling proceed asynchronously as futures.
• Built-in trustworthy evaluation. Multi-round evaluation, automatic judging, checkpoint recovery, and structured logging that fit a controlled research workflow.
• Enterprise-grade compliance. Support for dedicated capacity, private deployment, audit logging, and custom SLAs.

System architecture

MinT's overall architecture has four layers:

• Client layer. You write training scripts locally with the mint Python SDK — no GPU needed.
• API Gateway. A single entry point for authentication, routing, and traffic control.
• Core service layer. Includes the Model Router, the Task Manager, and the LoRA Manager (LoRA weight management).
• Backend resource layer. GPU cluster (training and sampling), object storage (datasets and weight snapshots), and databases (task metadata and audit logs).

All interaction between you and the platform goes through the SDK; the complex engineering details — cluster scheduling, memory management, batch splitting — stay transparent to you.

Community vs. Enterprise

MinT comes in two forms: Community Edition (mint.macaron.xin) and Enterprise Edition. The two share the same SDK and API, so code migrates at zero cost; the differences are mainly in capacity, isolation, SLA, and compliance:

Shortest working example

Below is the complete, shortest path from "writing a script" to "getting an inference endpoint":

import mint
from mint import types

service_client  = mint.ServiceClient
training_client = service_client.create_lora_training_client(
    base_model='Qwen/Qwen3-0.6B',
    rank=16, train_mlp=True, train_attn=True, train_unembed=True,
)
adam_params = types.AdamParams(learning_rate=5e-5)
for step, batch in enumerate(batches_of(data, batch_size=8)):
    fb  = training_client.forward_backward(batch, loss_fn='cross_entropy')
    opt = training_client.optim_step(adam_params)
    print(f'step={step} metrics={fb.result.metrics}')
    opt.result

sampling_client = training_client.save_weights_and_get_sampling_client(name='my-run-v1')

Enterprise value-add capabilities

The four categories of value-add capabilities, listed in full:

• Dedicated capacity pool (§4.1): reserved capacity + elastic capacity, with usage tracked across team / project / recipe.
• Deployment form and isolation (§4.2): multi-tenant dedicated or single-tenant dedicated, both offering full isolation from networking down to the scheduling layer.
• SLA and audit (§4.3): uptime SLA typically starting at 99.9%; first response to critical incidents within 30 minutes at minimum; audit logs with configurable retention, up to 1 year; workspace-based RBAC.
• Private deployment and compliance (§4.4): dependency images and offline install packages, console and SDK from the same source, optional SM-crypto / SSO / AD integration and log forwarding, private model hosting (LoRA and merged weights can be deployed offline).