LAM: a one-shot animatable Gaussian head from a single photo

One photograph in, an animatable Gaussian head out

LAM is the official PyTorch implementation from Tongyi Lab at Alibaba Group, presented at SIGGRAPH 2025. The scope is narrow and specific: given a single image of a person, produce a 3D head that can be animated and rendered in real time, with no scanning rig, no manual rigging, and no artist in the loop. The project states its goal as building a "3D Interactive Chatting Avatar with One Image in Seconds!"

The unit of output is a Gaussian head, that is, a set of 3D Gaussians rather than a triangle mesh, which is what allows the avatar to be animated and rendered in a browser or on a phone without a heavy mesh pipeline. The published figures put reconstruction at 1.4 s, animation and rendering at 562.9 FPS on an A100, and 110+ FPS on a Xiaomi 14 phone. The phone number is the point of the whole design: a talking avatar that can run on a handheld device rather than only on a server.

The shipped checkpoint is LAM-20K, trained on VFHQ and NeRSemble. So this is a research model released for use, not a product with a versioned public API, and the practical question for an engineer is what the released artifacts actually cover.

What the repository layout shows about the pipeline

The top level of the repository lists .gitignore, LICENSE, LICENSE_WEIGHT, README.md, README_CN.md, app_hf_space.py, app_lam.py, assets/, configs/, external/, lam/, requirements.txt, scripts/, tools/ and vhap/.

Several entries map directly to a workflow. Two Python entry scripts sit at the root, app_lam.py for local use and app_hf_space.py for the hosted space. The configs/ directory holds the run configurations referenced by the ${CONFIG} placeholder in the inference command. The scripts/ directory carries both the install shell scripts and the inference entry point. The tools/ directory contains AVATAR_EXPORT_GUIDE.md, the document that explains how to package a generated avatar for chat.

Two details in that listing deserve attention. A separate LICENSE_WEIGHT file sits next to the main LICENSE, so the terms for the model weights and the terms for the code are handled as distinct artefacts and should be read separately. A directory named vhap/ is present alongside lam/, and the README does not explain what it holds, so treat it as an opaque dependency rather than a documented feature.

Two CUDA install scripts and one Windows package

Installation is handled by shell scripts rather than a pip recipe. The Linux path is a clone followed by one of two scripts, each named for the CUDA version it targets:

git clone https://github.com/aigc3d/LAM.git
cd LAM
# Install with Cuda 12.1
sh ./scripts/install/install_cu121.sh
# Or Install with Cuda 11.8
sh ./scripts/install/install_cu118.sh

The scripts are what handle the CUDA toolkit and graphics extensions, which is why the requirements file on its own is not the install story. Windows is a different path: the project provides a one-click installation package built for Cuda 12.8, and a Windows Install Guide at scripts/install/WINDOWS_INSTALL.md.

Note what is not pinned anywhere in the text. No Python version, no minimum driver version, and no disk or RAM requirement appear. The choice of 12.1 versus 11.8 is the only environment decision the README puts in front of you, and it makes a real difference on older workstation images, so pick the script that matches the CUDA already on the machine rather than the newest one.

Weights and assets come from two mirrors

Model files are distributed through Hugging Face and ModelScope, and the download steps for each extract archives as well as the checkpoint. On Hugging Face:

# Download Assets
huggingface-cli download 3DAIGC/LAM-assets --local-dir ./tmp
tar -xf ./tmp/LAM_assets.tar && rm ./tmp/LAM_assets.tar
tar -xf ./tmp/thirdparty_models.tar && rm -r ./tmp/
# Download Model Weights
huggingface-cli download 3DAIGC/LAM-20K --local-dir ./model_zoo/lam_models/releases/lam/lam-20k/step_045500/

The ModelScope route uses the same layout with a different tool:

pip3 install modelscope
# Download Assets
modelscope download --model "Damo_XR_Lab/LAM-assets" --local_dir "./tmp/"
tar -xf ./tmp/LAM_assets.tar && rm ./tmp/LAM_assets.tar
tar -xf ./tmp/thirdparty_models.tar && rm -r ./tmp/
# Download Model Weights
modelscope download "Damo_XR_Lab/LAM-20K" --local_dir "./model_zoo/lam_models/releases/lam/lam-20k/step_045500/"

Two assets archives are needed, one for LAM assets and one for third-party models. The target directory for weights is spelled out exactly, step_045500 under lam/lam-20k, so a training-step path is baked into the release rather than resolved at runtime.

A Gradio app, a Blender path, and an export guide

The quickest way to see the model work is the local Gradio app:

python app_lam.py

An extra flag appears when you need Blender on the machine:

python app_lam.py --blender_path /path/blender

The export path is the part that turns a demo into a product. The Avatar Export Feature, released in April 2025, packages a LAM-generated avatar into the files that OpenAvatarChat expects, and the guide lives at tools/AVATAR_EXPORT_GUIDE.md. Around that core, the project has been assembled piece by piece: the Audio2Expression model for driving the avatar from audio on April 19, 2025, the WebGL Interactive Chatting Avatar SDK on OpenAvatarChat on April 21, 2025, and a separate WebGL-Render repository on May 20, 2025 for cross-platform animation and rendering. A separate WebGL renderer is what makes phone-rate rendering plausible at all.

For batch work outside the app, the inference entry point takes four positional arguments:

sh ./scripts/inference.sh ${CONFIG} ${MODEL_NAME} ${IMAGE_PATH_OR_FOLDER} ${MOTION_SEQ}

The image argument accepts a folder as well as a single file, so a directory of portraits can be processed in one call. The motion sequence argument is where you point at the animation driving the head, and a wrong path here fails silently in the sense that you get an avatar with no motion.

The performance table repeats itself

The model weights table lists three LAM-20K rows: trained on VFHQ, trained on VFHQ plus NeRSemble, and trained on a large dataset built by the authors. Every row carries the same 1.4 s reconstruction time, the same 562.9 FPS on an A100, and the same 110+ FPS on a Xiaomi 14. The rows differ only in where the weights can be fetched: the VFHQ plus NeRSemble row has Hugging Face and ModelScope links, while the other two show TBD in both columns.

That is worth being blunt about. The headline performance numbers are not measured per checkpoint, they are stated once and repeated, and the phone figure is written as a lower bound rather than a specific frame rate. These are also the authors' own numbers, reported in the project's own table, with no independent measurement attached.

What the table does support is a real comparison between the two reference devices, a datacenter A100 and a consumer handset. A pipeline that holds frame rate on a Xiaomi 14 leaves no room for an expensive renderer in the loop, which points to the WebGL path being the intended runtime rather than an optional extra.

The unreleased checkpoint and the pinned graphics stack

The to-do list shows LAM-small on VFHQ and NeRSemble, the Hugging Face space, the ModelScope space, the WebGL renderer, the audio-driven model, and the chatting avatar SDK all checked off. One box remains open: releasing LAM-large trained on the self-constructed large dataset. The project has also since published MeshLAM at CVPR 2026 and a PanoLAM technical report, so the effort is continuing even though the large checkpoint has not landed.

The dependency list is where the real installation friction sits. requirements.txt mixes exact pins such as pymcubes==0.1.6, numpy==1.23.0, tensorflow==2.12.0, transformers==4.41.2 and scikit-image==0.20.0 with direct Git installs of pytorch3d, diff-gaussian-rasterization, a nvdiffrast fork with backface culling, and simple-knn. The last four are the graphics stack that makes Gaussian rasterization and mesh operations work, and they are installed from source rather than from a wheel index, so a build failure on a new machine usually comes from CUDA and compiler mismatches rather than from the Python packages. face-detection-tflite and the TFLite runtime in the list also indicate that a face detection step sits in front of reconstruction.

Maintenance status and what the release history does and does not say

The repository is not archived, and the last push was on 2026-06-10, which puts recent work within a few months of this review. The project has no GitHub releases at all, so there is no version history to pin against, no changelog, and no upgrade notes. Every artifact is fetched by an explicit step directory, which means you have no package version to reason about: you either take the published checkpoint as it stands or you are out of sync with the repository state.

There is also no documented rollback, no migration guide, and no stated compatibility matrix for the CUDA 12.1 and 11.8 paths. If the repository moves forward and changes a checkpoint path, the download instructions in the README are the only contract you have. The dated news entries give a picture of steady additions across 2025 and 2026, mostly in the surrounding ecosystem of renderers, chat SDKs and export tooling, rather than in the core model itself.

Editorial conclusion

LAM is worth adopting for anyone who needs a real-time 3D talking head from a single photo and can afford a CUDA box plus the pinned graphics stack; skip it if you need the large checkpoint, a documented rollback path, or a project with a formal release cadence, and first verify that the LAM-20K weights on Hugging Face or ModelScope match your own scenes, since the published frame rates are the authors' own numbers on an A100 and a Xiaomi 14 rather than independent measurements.

Frequently asked questions

Official sources

1. aigc3d/LAM on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README