Proposal: Integrating anima_lora as alternative Turbo training engine

[wochenlong]

Background

We've been evaluating sorryhyun/anima_lora (MIT License, Copyright 2026 Seunghyun Ji) as a potential alternative training engine for Anima LoRA training. Their project achieves ~1.1 s/step on RTX 5060 Ti (rank=32, 1MP) compared to our current ~5-8 s/step, primarily through:

• torch.compile + CUDAGraph (per-block and full-model compilation)
• Constant-token bucketing (static_token_count=4096, zero recompilation)
• Compile-friendly code paths (einops removal, autocast elimination)
• OrthoLoRA, T-LoRA, HydraLoRA and other advanced LoRA variants

Proposal: Dual-Engine Architecture

Rather than porting individual optimizations into our kohya sd-scripts backend (which would require deep vendor modifications), we propose a dual-engine architecture:

• Standard mode — existing kohya sd-scripts backend, unchanged. Supports gradient_checkpointing, blocks_to_swap, low-VRAM users (~12GB+).
• Turbo mode — anima_lora engine as an alternative backend. Requires more VRAM (~16-20GB) but delivers ~5x speedup.

Users would select the engine in the GUI. Parameters are independent per engine.

Why dual-engine instead of porting?

This approach resolves most migration challenges at once:

Challenge	Status with dual-engine
compile + checkpointing mutual exclusion	Resolved — each engine has its own constraints
Constant-token bucketing	Resolved — anima_lora has it built-in
einops compatibility	Resolved — anima_lora already replaced them
vendor/sd-scripts management	Resolved — no sd-scripts modifications needed
OrthoLoRA integration	Resolved — use anima_lora native implementation
GUI integration	Needs work — add engine selector + per-engine parameter panels
PyTorch version gap (2.7 vs 2.12)	Partially resolved — Turbo mode can use its own environment

License Compliance

anima_lora is MIT licensed. We have already added proper attribution in our NOTICE.md. MIT is fully compatible with our AGPL-3.0 license.

Implementation Steps

1. Add anima_lora as a git submodule under vendor/anima_lora/
2. Create a new wrapper script scripts/dev/anima_train_turbo.py with config translation
3. Add engine selection to the GUI schema (sd3-lora.ts)
4. Handle environment/dependency isolation (Python 3.13 + torch 2.12 for Turbo mode)

Open Questions

1. Should we lock to a specific anima_lora release tag (e.g. v1.4.1) or track main?
2. How to handle the Python version gap (they require 3.13, we use 3.10) — separate venv or attempt compatibility?
3. Should OrthoLoRA also be available in Standard mode (requires LoRANetwork adaptation work)?
4. Priority: should we ship Turbo mode first, or OrthoLoRA-in-Standard-mode first?

Feedback and ideas welcome.

[wochenlong]

进展同步 & 合并计划

感谢 @MikumikuDAIFans 在 anima_lora 分支上的实现（36c3e81 / 5e98c5b / fd84050）。我们已 review，整体方向与本帖提出的 双引擎（Standard + Turbo） 一致，且比原草案里的「在 sd3 页切换引擎」更保守、更适合渐进落地：

• 独立后端 mikazuki/anima_fast_backend/（安装器、独立 venv、preflight、配置适配、训练启动）
• 训练类型 anima-lora-fast，与现有 Anima LoRA（kohya）、Anima Finetune 并存，不替换标准路径
• 上游快照 pin（source_commit）+ 依赖安装重试
• LORA_ENABLE_ANIMA_FAST=1 才暴露 schema / 侧栏 / API（默认关闭）

合并节奏（维护者共识）

1. 先完成 main 上的数据集 / 标签编辑器工作区（当前 WIP，与 Fast 会碰同一批 api.py / frontend/dist 文件）
2. 再合并 anima_lora → main，作为 Experimental / 实验功能 发布
3. 合并时 以 main 的 v2.6 UI 为底（侧栏分组、Anima Finetune、i18n、版本号等），Fast 入口通过 dist patch 脚本叠加，避免硬 merge 压缩后的 app.js

小白 vs 进阶的体验分层

用户	默认行为
整合包 / 新手	看不到 Anima Fast；继续用 Anima LoRA + 全量微调，无额外安装
进阶 / 内测	设置环境变量后出现 Anima Fast LoRA 入口；页内先 安装/审计 拓展，通过后再解锁训练；文档标明高显存（约 16–20GB+）、cu130 / Python 3.13 独立环境等限制

整合包 7z 体积不因此明显增大（运行时按需安装）；Release 说明会标 Experimental，不会作为默认可用能力宣传。

对本帖 Open Questions 的当前倾向

1. 锁定上游版本？ — 是。采用 pin commit + 安装快照（分支已实践），而非跟踪 main。
2. Python 3.10 vs 3.13？ — 独立 venv（分支已实践）；主程序仍用 embed 3.10。
3. Standard 模式也上 OrthoLoRA？ — 暂缓；Turbo 侧先用 anima_lora 原生实现。
4. 优先级？ — 标签编辑器里程碑 → Turbo 实验合并；Standard 路径保持默认。

后续协作

• 在标签编辑器合进 main 之前，欢迎 occasional rebase anima_lora onto main，减少最终 PR 冲突
• 合并 PR 前会做：patch 流水线、pytest（test_anima_fast_*）、Win 冒烟（install → preflight → 短训）

如有不同意见（例如希望在同一页做 Standard/Turbo 切换，而非独立 Fast 页），欢迎在此继续讨论。