EmoLLM: A Fine-Tuning Recipe Collection for Chinese Mental Health Chat Models

The gap EmoLLM fills: fine-tuning configs, not another chatbot

Most mental health chat projects ship either a demo or a paper. EmoLLM ships the middle layer that is usually missing: a set of XTuner configuration files, one per base model and training regime, plus pointers to datasets and evaluation material. The README frames the goal as a chain of understanding the user, supporting the user, and helping the user, and the repository's job is to produce models that can do that from open-weight backbones. The audience is therefore narrow and specific. It is for engineers who already know how to launch an XTuner job and want a mental health corpus and a reference config instead of assembling both from scratch. It is not aimed at clinicians, product managers, or anyone who wants to type a question into a box. The homepage link points to an OpenXLab application for EmoLLM V3.0, so a hosted demo does exist, but the repository itself is a training workbench. The distinction matters because the maintenance burden, the failure modes and the licence questions are all training-side questions.

What the config table actually gives you

The core artifact is a table mapping base models to training type and config file. It covers sixteen rows spanning InternLM2_5_7B_chat, InternLM2_7B_chat, InternLM2_7B_base, InternLM2_1_8B_chat, InternLM2_20B_chat, Qwen_7b_chat, Qwen1_5-0_5B-Chat, Baichuan2_13B_chat, ChatGLM3_6B, DeepSeek MoE_16B_chat, Mixtral 8x7B_instruct, LLaMA3_8B_instruct (twice, with different configs), Qwen2-7B-Instruct, and a Deepseek-R1_14b_int4 entry trained with unsloth. Training types split across full fine-tuning, LoRA and QLoRA. The naming convention in the config filenames encodes the regime: internlm2_5_chat_7b_full.py is a full fine-tune, internlm2_5_chat_7b_qlora_oasst1_e3.py is QLoRA for three epochs, and internlm2_7b_base_qlora_e10_M_1e4_32_64.py appears to encode ten epochs with a learning rate of 1e-4 and LoRA dimensions of 32 and 64. That filename-as-metadata habit is useful when you are scanning for a config that fits your GPU budget, but it also means the authoritative hyperparameters live in the file, not in the README. Read the file.

How training and data flow through the repository

The mechanism is XTuner's standard pipeline. A config file names a base model, a dataset, a training schedule and an output directory; XTuner loads the base weights, applies the adapter or full-weight update, and writes a checkpoint. EmoLLM's contribution is the pairing of that machinery with mental health dialogue data and with published checkpoints. Several rows link to ModelScope or OpenXLab model pages, which means you can either reproduce a fine-tune or download a finished adapter. The dataset side is less visible in the material supplied: the README references datasets and evaluation as part of the project scope, and the topic list includes dataset and evaluation, but the excerpt does not enumerate dataset files or their licences. That is a gap worth checking before you build a pipeline around it, because dialogue data collected for mental health use carries consent and redistribution questions that a code licence does not answer. On the inference side, the description mentions RAG and deployment, and the homepage points at an OpenXLab app, so the intended flow is fine-tune, then serve with retrieval, though the excerpt does not show the retrieval code or index format.

Getting a run started

The README gives config paths rather than a full shell transcript, so the commands below follow XTuner's documented interface and the file names in this repository. Install XTuner and its dependencies first, then point the trainer at a config. For a QLoRA run on InternLM2_5_7B_chat, the config is xtuner_config/internlm2_5_chat_7b_qlora_oasst1_e3.py, and the invocation is typically xtuner train followed by that path. For the full fine-tune variant, swap in xtuner_config/internlm2_5_chat_7b_full.py. The 1.8B full fine-tune uses xtuner_config/internlm2_1_8b_full_alpaca_e3.py, which is the smallest full-weight option in the table and the one most likely to fit on a single consumer GPU. For a non-InternLM base, the pattern holds: xtuner_config/qwen_7b_chat_qlora_e3.py, xtuner_config/baichuan2_13b_chat_qlora_alpaca_e3.py, xtuner_config/chatglm3_6b_lora_alpaca_e3.py, xtuner_config/mixtral_8x7b_instruct_qlora_oasst1_e3.py. Before launching anything, open the config and check the pretrained model path, the dataset path and the batch size, since those are the three values most likely to need editing for your hardware. The README does not publish a dependency pin or a requirements file in the excerpt, so treat version drift between XTuner releases and these configs as a real risk.

Where EmoLLM is the wrong choice

The repository is a collection of training recipes, and that shape imposes limits. There is no published evaluation result in the material supplied: the description lists evaluation as a project area, but no benchmark table, no safety metric and no comparison against a base model appears in the excerpt. For a mental health application that is a serious omission, because the interesting question is not whether the model produces fluent supportive text but whether it refuses appropriately, avoids diagnostic claims and routes crisis language to human help. Nothing in the supplied material shows those behaviours being measured. A second limitation is the breadth of the model table. Sixteen configs across eight model families means each individual path is likely to be maintained at the level of a contributed config rather than a tested release. The release cadence (v0.4 in October 2024, v0.5 in March 2025, v0.6 in May 2025) suggests active work, but a config that trains is not the same as a config that has been validated end to end. Third, the project is Chinese-first: the README is in Simplified Chinese with English and Japanese translations, and the datasets referenced by names like oasst1 and alpaca are general instruction corpora, so the mental health specificity comes from whatever additional data the project supplies. If your users write in English, verify the data mix before assuming transfer.

Alternatives and the difference in approach

The closest comparison is not another mental health model but the underlying toolchain used without EmoLLM. XTuner, which this repository depends on, already ships example configs for QLoRA and full fine-tuning on InternLM and Qwen bases. The difference is data and framing: XTuner gives you the training loop and generic instruction data, while EmoLLM gives you mental health-oriented dialogue data plus configs already pointed at that data, at the cost of inheriting this project's dataset choices and its maintenance pace. A second alternative is to start from a general-purpose instruct model and handle the mental health behaviour in the prompt and retrieval layer rather than in the weights. That approach avoids fine-tuning entirely, keeps the base model's safety training intact, and lets you update behaviour without a GPU run. It fails when you need a consistent tone or domain vocabulary that the base model will not adopt from prompting alone. EmoLLM sits between those poles: more domain adaptation than prompting, less infrastructure than building your own corpus and training script. The trade you are making is convenience for control over data provenance.

Licence, maintenance and what to verify before you commit

The repository is MIT-licensed, which is permissive for the code and configs. That licence does not extend to the base models, and it does not cover the training data. InternLM, Qwen, Baichuan, ChatGLM, LLaMA and Mixtral each carry their own licence terms, and several of them restrict commercial use or require separate agreements. Downloading a checkpoint from ModelScope or OpenXLab does not change those terms. The dataset question is the one to resolve first: the excerpt does not state the licence or provenance of the mental health dialogue data, and for this domain that is the constraint most likely to block a product. On maintenance, the version history shows three releases in roughly eight months and a last push in June 2026, so the project is not dormant, but the sixteen-config surface means any single config can lag behind the current XTuner API. The practical check is to pick one config, confirm its dataset path resolves, run a short training step, and only then scale up. If the config you want is one of the rows with an empty model link column, expect to produce the checkpoint yourself. None of this is legal advice; the licence terms of each base model are the ones that govern your use.

Editorial conclusion

Adopt EmoLLM if you already have XTuner experience and want a starting corpus of mental health dialogue plus per-base config files to compare full fine-tuning against QLoRA on one of the listed backbones. Do not adopt it if you need a hosted clinical service or a model with published safety evaluation results, because the README describes neither. Before committing GPU time, open xtuner_config/internlm2_5_chat_7b_full.py and the matching qlora file side by side, check the dataset path each one points at, and confirm the target base model is actually downloadable from the ModelScope or OpenXLab link in the table.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SmartFlowAI/EmoLLM on GitHub