HuggingLLM: a Chinese-language course for building on ChatGPT APIs
HuggingLLM, Hugging Future.
At a glance
- What is it?
- Datawhale's HuggingLLM is a Jupyter Notebook curriculum that teaches API-level LLM application work to programmers without an NLP background. It is a teaching resource, not a library, and the repository's own audience statement rules out anyone looking for training or inference internals.
- Who is it for?
- Adopt HuggingLLM if you are a developer with some programming background who needs to move from prompting in a chat window to calling chat and embedding endpoints from code, and who reads Chinese or is willing to work through Chinese notebooks. Do not adopt it if you need training internals such as PPO implementation details, or if you want a maintained software dependency rather than a book with notebooks attached.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 91 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap HuggingLLM is aimed at, and the readers it turns away
The README states the project's purpose directly: introduce the principles, usage and applications of ChatGPT so that people outside NLP or algorithm roles can use LLMs without a barrier. The stated audience is anyone interested in ChatGPT who wants to build a new service or solve an existing problem with it, and who has some programming foundation. The repository is written in Chinese, and the entry point is a book (the README calls it ButterflyBook) with a companion video series on Bilibili and a course on the Momodel platform.
The same README lists who should not read it, and that list is unusually blunt for a project page. It is not for readers who want to study low-level algorithm details such as how PPO is implemented or whether it could be swapped for NLPO or ILQL. It is not for anyone who wants to build a ChatGPT from scratch. It is not for readers interested in other technical details. The author also notes the material is not specifically designed for algorithm or NLP engineers, though they may still get something from it.
That framing sets the expectation correctly. If you arrive wanting a training framework, you are in the wrong repository. If you arrive as a backend or product developer who has used the OpenAI chat UI and now needs to call an endpoint from Python, the scope matches.
What the curriculum actually covers, chapter by chapter
The README publishes a content outline, and it is worth reading as a scope statement rather than a table of contents. Chapter 1 is background: language models, Transformer, GPT, RLHF. Chapters 2 through 5 are the four usage guides, and they map onto task families rather than model families. Similarity matching covers embeddings, API usage, question answering, clustering and recommendation. Sentence and word classification covers NLU basics, API usage, document QA, fine-tuning for classification and entity recognition, and a dialogue application. Text generation covers summarization, error correction and machine translation. Text reasoning covers what reasoning means, importing ChatGPT, testing its reasoning ability, calling it for reasoning, and a comparison between ChatGPT and GPT-4.
Later chapters move to engineering and context. One covers evaluation, safety and networking. Chapter 7 is titled, roughly, that the tool is not all-powerful, and its subsections are factual errors, real-time updates and resource consumption. Chapter 8 surveys commercial applications across tools (search, office, education) and industries (games, music, retail and e-commerce, advertising, media, finance, healthcare, design, film and television, industrial).
The README notes the chapters are relatively independent, so you can read one or work through the whole set. The stated time budget is 2 to 3 days per usage guide chapter and 6 to 8 hours of work each, except for the text reasoning chapter.
Two directories, one book, and a version question you have to resolve yourself
The repository splits its material in a way that matters for anyone cloning it. The docs directory holds the ebook version, and the content directory holds the Jupyter Notebook originals and their iterations. The README is explicit that docs is not the final version and that editors may have made small changes, and it gives a rule of thumb: use content for practice, use docs for reading.
That is a practical arrangement for a book project and an awkward one for a code project. If you are following along in a notebook, you are working against one text. If you are reading the published ebook at the project's GitHub Pages site, you may be working against a lightly edited version of the same text. The README does not describe a synchronization process between the two, and there are no releases listed for the repository, so there is no version tag to pin against. The default branch is main and the last push recorded is 2026-06-16.
The practical consequence: if you cite a chapter or copy a snippet into your own notes, record which directory it came from. A discrepancy between a notebook cell and the corresponding book paragraph is expected behavior here, not a bug report.
Running the API examples: zhipuai for GLM, dashscope for Qwen
The README's setup section is short and concrete, and it is built around domestic Chinese model APIs rather than OpenAI alone. The learning guide says you need working access to OpenAI's API and the gpt-3.5-turbo model, or a domestic large model API, or an open source model. For GLM, the install is pip install zhipuai, and the example imports ZhipuAI, constructs a client with an api_key argument, builds a messages list with system and user roles, and calls client.chat.completions.create with model set to glm-4, the messages list, and stream=True. The example then concatenates chunk.choices[0].delta.content across the stream into a single string.
For Qwen, the install is pip install dashscope, and the example calls dashscope.Generation.call with dashscope.Generation.Models.qwen_max, an api_key, the same messages shape, result_format='message', stream=True and incremental_output=True. The loop checks response.status_code against HTTPStatus.OK before appending response.output.choices[0]['message']['content'], and prints request_id, status_code, code and message on failure.
The two examples differ in a way worth noticing. The GLM snippet assumes every chunk carries content. The Qwen snippet checks the status code inside the loop and prints diagnostic fields when it is not OK. If you are adapting either, the Qwen pattern is the safer starting point for error handling, and the README shows it that way rather than as an afterthought.
Where this is the wrong tool
The clearest limitation is stated by the authors themselves: this is not a source for algorithm-level study. If your question is how RLHF is implemented, or how to replace PPO with another optimization method, chapter 1 will give you the vocabulary and stop there. The README says as much in its audience section.
A second limitation follows from the format. The material is a book and a set of notebooks, not a library with an API surface you import. There is no package to add to requirements.txt, no semantic version to pin, and no changelog in the material provided. Upgrading means pulling the repository again and re-reading the chapters that changed, and the docs/content split means you may need to compare two copies to find out what changed.
A third limitation is language. The README, the chapter titles and the outline are in Chinese. The API examples use English role labels and English model names, but the surrounding explanation is Chinese. A team without Chinese readers will get the code and lose the reasoning, which is most of the value here.
Finally, the API examples are written against model names that the README itself tells you to verify: the GLM comment says to consult the official documentation and fill in the model name you need to call, and the Qwen comment says the same. Treat glm-4 and qwen_max as illustrations of the call shape, not as pinned versions.
How this differs from LangChain-style frameworks
The obvious comparison is a framework such as LangChain. The difference is in what each one hands you. LangChain gives you abstractions to build with: chains, retrievers, memory objects, and a dependency you upgrade over time. HuggingLLM gives you worked examples and the reasoning behind them, and nothing to import. When you finish a HuggingLLM chapter you have a notebook that calls an endpoint and a paragraph explaining why the task was framed that way. When you finish wiring a LangChain chain you have code that runs, plus a framework whose abstractions you now depend on.
That makes the two complementary rather than competing, but it also clarifies the trade-off. A framework hides the request shape; this course shows it. If you want to understand what a retrieval step actually sends to the model before you let a framework manage it for you, the chapter on similarity matching and embeddings is the kind of material that makes the framework legible. If you already understand the request shape and need to ship, the course adds reading time without adding a dependency.
There is also a scope difference in the other direction. LangChain is model-agnostic in its integrations and English-first in its documentation. HuggingLLM is explicitly written for readers who may be using a domestic Chinese API, and it ships first-class examples for GLM and Qwen alongside the OpenAI path.
Licence, maintenance and what the repository does not tell you
The repository's licence is recorded as NOASSERTION, which means the licence could not be automatically identified from the repository metadata. The README has a LICENSE section in its table of contents, but the cleaned text provided does not include the licence body. Before reusing chapters, notebook code or images in your own material, read the LICENSE file in the repository directly and, if the terms matter to your organization, have someone qualified read it too. Nothing here is legal advice.
On maintenance, the material supports only a narrow statement: there are no releases listed, the default branch is main, and the last push recorded is 2026-06-16. The project is not archived. There is no deprecation notice in the README and no migration guide, so the upgrade cost is whatever it takes to re-read the chapters that changed between the copy you have and the copy on main.
The thing to verify first is coverage. Open the outline and check whether the four usage guides (similarity matching, sentence and word classification, text generation, text reasoning) match the task you actually have. If your task is none of those four, the engineering, limitations and commercial-application chapters may still be useful reading, but they will not give you a worked implementation to adapt. That check takes a few minutes and settles whether the rest of the repository is worth your time.
Editorial conclusion
Adopt HuggingLLM if you are a developer with some programming background who needs to move from prompting in a chat window to calling chat and embedding endpoints from code, and who reads Chinese or is willing to work through Chinese notebooks. Do not adopt it if you need training internals such as PPO implementation details, or if you want a maintained software dependency rather than a book with notebooks attached. Before committing, open the chapter list and confirm the four usage guides cover your task, then check the docs directory against the content directory to see which version of a chapter is newer, since the README states the two are not identical.
Community notes