ModelArts-Lab: the sample notebook library behind Huawei Cloud's AI platform

What the repository is for

`huaweicloud/ModelArts-Lab` is the example code repository for ModelArts, Huawei Cloud's AI development platform. GitHub records the primary language as Jupyter Notebook, which is the honest description of what most of the content is. The project has around 1,045 stars and 848 forks, sits under the Apache-2.0 licence, and had 5 open issues at last count. The default branch is `master`, and the last push was 2026-09-20.

The README is short and does three things. It points at the Huawei Cloud AI developer community as the place for newer material, it offers a Gitee mirror at `gitee.com/ModelArts/ModelArts-Lab` for readers who find GitHub slow, and it states the intended use of everything inside. That last part deserves attention before anything else: the cases and datasets are declared usable for learning and exchange only, the datasets originate from open source communities, and commercial use beyond learning is excluded, with legal responsibility placed on the user.

The repository description is one sentence and points to the same community site, so the intent is clear. This is a showcase of platform capability, maintained by the vendor, not an open source project that happens to touch a Huawei service.

One release exists, tagged `1.0.0` and titled Release ModelArts-Lab-1.0.0, published on 2020-11-24 with a body describing an archival of the cases under that version number. There have been no releases since, while commits have continued. For a repository of notebooks that is a reasonable pattern, since there is nothing to version in the way a library would need to be versioned.

Three kinds of case, aimed at three skill levels

The README organises everything into three groups, and the split is really a progression in how much you are expected to know.

The first is ExeML, short for automated machine learning. The argument the README makes is about a skills gap: only a small number of algorithm engineers and researchers have both prototype development and the engineering work that turns a prototype into a product, while most business developers have neither the algorithm knowledge nor the tuning experience. ExeML is the answer to that gap. You supply annotated data and pick a scenario, and the platform trains and deploys a model meeting your accuracy requirement without you writing code. Four scenario types are listed: image classification, object detection, predictive analysis and sound classification. The model is tuned against the inference speed your deployment environment and your own requirements imply.

The second group is notebooks. ModelArts integrates Jupyter Notebook and the README frames this as a browser-based interactive development and debugging environment. You create a development environment, write and run training code yourself, and train on top of it. The README goes further and recommends this path for teaching AI, noting that several well-known educational institutions run AI courses on ModelArts. For a learner that is the cheapest entry point in the repository, since notebook output tells you what happened without needing to interpret platform logs.

The third group is the end-to-end train-and-inference cases, which cover the full path from data preparation through model development, training, deployment, release and sharing through the AI market. This is where you see how the pieces are meant to fit, and where the MoXing API earns its keep, since the training code in these cases drives the platform rather than a local runtime.

Reading the directory tree

The top-level listing is short and maps cleanly onto the three case groups, with a few directories the README does not explain:

ExeML/
HiLens/
benchmark/
contrib/
notebook/
official_examples/
tools/
train_inference/
cases_list.md

`ExeML/`, `notebook/` and `train_inference/` are the three groups from the README. `official_examples/` is the one to look at first if you want vendor-endorsed code, since the name distinguishes it from contributed work. `contrib/` is the natural counterpart for community additions. `tools/` holds helper scripts, and `benchmark/` is the only top-level directory whose purpose the README does not describe, which makes it worth opening before assuming what it contains.

`HiLens/` is the one to note if you work on edge deployment. The README never mentions it, so treat the directory name as a hint rather than a description. Huawei's HiLens line is associated with on-device inference, and its presence alongside the cloud cases suggests the repository covers at least part of the path from a trained model out to hardware.

`docs/` holds the three documents linked from the README: a ModelArts preparation guide, the MoXing API reference, and a FAQ file. Of the three, the MoXing reference is the one you cannot work without if you are writing training code, since MoXing is the interface those examples call. `cases_list.md` at the root is an index of the cases, which is the fastest way to see how many exist per category.

One curiosity in the listing is `FETCH_HEAD`, a file git writes during a fetch. Its presence means it was committed by accident. It is harmless and it does not affect the notebooks, but it is the kind of small untidiness worth noticing when you are deciding how closely the repository tracks upstream.

What the MoXing API implies about the training code

MoXing is the piece most worth understanding before reading any notebook here, because it explains why the training code looks unlike a PyTorch script.

A notebook in this repository is not self-contained in the sense that you could pip install its imports and run it on a laptop. Training runs on a ModelArts development environment, and the code is expressed in terms of the platform's data and model abstractions rather than raw file paths and local processes. The practical consequences show up in the notebooks themselves: dataset references are dataset identifiers rather than paths on disk, the number of training steps or the resource configuration is set through framework parameters instead of local flags, and the resulting model is registered with the platform rather than written out as a checkpoint file.

That design has real advantages once you are on the platform. Moving from a development environment to a distributed training job, or from a trained model to a deployed inference endpoint, stays inside the same vocabulary, and the end-to-end cases exist precisely to demonstrate those transitions. It also means the notebooks teach you ModelArts, not only PyTorch or TensorFlow.

The README's own emphasis on the ExeML path is telling in the same direction. For a business developer with no algorithm background, the platform's recommended experience is to never touch this code at all. The notebooks exist for the other audience, the one who does want to write the training loop and needs to know how to shape it so the platform can schedule it.

Licensing, data rights and the community boundary

Two restrictions stack on top of the Apache-2.0 licence, and both matter if you are planning to reuse anything here.

The licence itself is permissive. Apache-2.0 covers the code and documentation in the repository, including the notebooks, and it is a reasonable choice for a vendor publishing reference material. The grant covers use, modification and redistribution with attribution and patent terms, and it does not obligate you to open-source work built on top of it.

The data is different. The README is explicit that the sample datasets come from open source communities and that the cases and datasets are for learning and exchange only, with commercial use excluded and liability disclaimed. A permissive code licence does not extend to the data that the code demonstrates on, so if your plan involves a dataset from these cases in anything resembling a product, you need to trace that dataset back to its original community source and its own terms. The upstream community licence, not the licence on this repository, is the one that governs it.

The same paragraph sets a geographic and promotional boundary. The README asks that the project not be advertised on domestic media platforms, which is a distribution preference rather than a legal restriction, but it is a clear signal about where the maintainer wants the project's reach to sit. Anything further is hosted on the Huawei Cloud AI developer community, and the README frames newer AI development and learning material as living there rather than in this repository.

The Gitee mirror exists for reach rather than governance, and the README states its content is identical to GitHub. Both point to a single maintainer rather than a foundation, which is worth keeping in mind for anything you build on top of it.

Editorial conclusion

ModelArts-Lab is best approached as a platform reference rather than as a library to depend on. Nothing here is installable as a package, the code assumes a ModelArts environment with a development instance and credentials, and the datasets carry a use restriction that the README states plainly: the cases and their data are for study and exchange only, and the datasets come from open source communities. What the repository does give you is an accurate picture of how the platform expects work to be structured, from annotated data through training to a deployed inference endpoint. Read the three documentation links in the README first, particularly the MoXing API reference, because the training code depends on that interface. If your goal is portable model code with no Huawei dependency, the notebooks will need rewriting; if your goal is a working ModelArts pipeline, this is where the working examples live.

Frequently asked questions

Official sources

1. huaweicloud/ModelArts-Lab on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases