7 PhD Students Train a 7B Model, and AI Begins to Participate in Making AI

Seven PhD students from different disciplines trained a 7-billion-parameter model from scratch in three months, and made the code, data, weights, and training logs fully public.

This happened at the Beijing Zhongguancun Academy, under a project called ZGCM-1. Compared with the birth of yet another 7B model, what is truly worth attention is the R&D approach behind it: the team introduced hundreds of Agents, breaking tasks such as information gathering, code writing, experiment configuration, log analysis, and troubleshooting into separate pieces and assigning different AI roles to complete them collaboratively.

In other words, this is not a story about “a few students manually building a model,” but a public experiment showing how a small team can use Agents to compress an R&D process that would originally require dozens of people and several months—or even longer—into three months.

Why Can Seven People Do the Work of Dozens of People in the Past?

When training a foundation model, what really consumes time is often not just running GPUs. Where does the data come from, and how should it be cleaned? How should the Tokenizer be selected? How should the model architecture be determined? How should training parameters be adjusted? When an abnormal loss appears during training, how should its cause be located? When evaluation results are unsatisfactory, should the data be changed or the architecture? These stages depend on one another, and an error at any step can waste both computing resources and time.

The traditional approach is for researchers, algorithm engineers, data engineers, and infrastructure engineers to take responsibility for different parts. It is difficult for a small team to cover so many roles at once. This is especially true for interdisciplinary teams, which often need to spend a great deal of time first filling in gaps in their engineering capabilities.

ZGCM-1’s approach is to break the R&D process into many tasks that can be described, verified, and reused, and then have Agents handle the execution. For example:

• Information and Planning Agent: searches papers, open-source implementations, and existing experiments, and organizes model architectures and training strategies;
• Data Agent: processes raw corpora and performs deduplication, filtering, quality assessment, and data bucketing;
• Code Agent: generates training scripts, data-processing scripts, and evaluation programs based on tasks;
• Experiment Agent: records experiment configurations, submits training jobs, and tracks loss curves and resource usage;
• Diagnostic Agent: proposes possible causes and fixes when training diverges, throughput drops, or GPU memory behaves abnormally;
• Evaluation Agent: organizes benchmark tests, compares the results of different experiments, and feeds conclusions back into the next round of planning.

This division of labor resembles a software company’s production line, except that the “junior engineers” of the past have been replaced by Agents. Humans no longer need to personally process every log or modify every script; instead, they define objectives, set boundaries, and review key decisions.

But there is an easily overlooked prerequisite here: Agents have not created a reliable R&D system out of thin air. Whether they can be effective depends on whether tasks are split reasonably, tool permissions are controlled, experiments are reproducible, and someone ultimately takes responsibility for the results.

What Does “Training from Scratch” Mean?

Here, “from scratch” generally means beginning pretraining from random initialization, rather than continuing to fine-tune an existing foundation model. The difficulty of the two is completely different.

Fine-tuning is more like providing specialized training to someone who already knows how to speak and code. Pretraining from scratch, by contrast, first requires laying the foundation for language ability. The team needs to prepare large-scale corpora, design data-processing workflows, determine the vocabulary and Tokenizer, choose a Transformer architecture, arrange the pretraining stages, and then conduct instruction tuning as well as safety and capability evaluations.

Seven billion parameters does not mean a model is “lightweight enough to train casually.” On consumer-grade graphics cards, a 7B model is already relatively friendly for inference. During pretraining, however, gradients, optimizer states, and intermediate activations must be stored, significantly increasing memory requirements. Training also involves multi-GPU communication, checkpoint saving, resume-from-checkpoint capabilities, and throughput optimization. The larger the model, the more likely engineering problems are to be amplified.

The value of ZGCM-1 does not primarily lie in whether it can defeat today’s leading models on general-purpose leaderboards. By 2026 standards, it is unrealistic for a newly trained 7B model to catch up with mature open-source models such as Qwen, Llama, DeepSeek, or others in overall capability. Major companies and leading laboratories possess larger datasets, longer training cycles, more mature post-training systems, and infrastructure refined over many years.

This project is more like an open “model-training laboratory”: it puts an end-to-end process on display and lets external developers see exactly how a small team goes from a blank slate to producing model weights.

Making All the Materials Public Matters More Than the Model’s Ranking

The project has made its code, training data, model weights, and training logs public. This combination of materials is more valuable than merely publishing a model download link.

If only the weights are made public, developers can know the result but cannot determine why the model produced that result. If only the code is public, they cannot confirm whether the training data and hyperparameters match. If only the data is public, reproducing the experiment is difficult. Training logs fill in the process information: at what stage the model began to converge, which round of experiments encountered anomalies, how fast training proceeded, and what changes resulted from parameter adjustments.

For developers, the most useful application may not be deploying ZGCM-1 directly, but using it to build their own training baseline. For example:

1. Download the public data or construct a small-scale corpus according to the published rules;
2. Run the basic training scripts to confirm that the environment, data format, and parallel configuration are working properly;
3. Compare against the training logs to check whether the loss curve and throughput are within a reasonable range;
4. Modify the Tokenizer, data mixture, or model architecture and observe how the experimental results change;
5. Use the same evaluation process to compare different training approaches, rather than looking only at the final score.

This is another important dimension of the value of open-source models: they provide not only a usable product, but also an engineering sample that can be taken apart. For teams learning distributed training, data engineering, or evaluation systems, complete logs are often more informative than a promotional article saying “performance improved by X.”

Hundreds of Agents Do Not Equal Hundreds of Researchers

“Hundreds of Agents participated in R&D” can easily become a highlight in publicity, but it should not be interpreted simply as the team gaining hundreds of independent researchers.

Agents excel at repetitive, structured, and tool-calling tasks: reading documents, generating scripts, executing commands, organizing logs, and comparing results. In the past, these tasks did indeed occupy a great deal of engineers’ time. The problem is that Agent outputs may still contain hallucinations, erroneous assumptions, and code that appears reasonable.

For example, an Agent can write a training script that runs, but may not realize that data leakage has occurred. It can detect an abnormal loss, but may not be able to determine whether the cause is the learning rate, data quality, mixed precision, or a communication bottleneck. It can organize the results of multiple experiments into a table, but may not understand whether the experiments are actually comparable.

Therefore, the more accurate description of AI4AI at present is not that “AI autonomously invented a model,” but that “AI has begun to take on a large amount of the intermediate labor involved in model R&D.” What truly determines the upper limit of a project is still humans’ definition of the problem, experimental design, and judgment of the results.

This is also the aspect of ZGCM-1 most worth observing: it advances the relationship between humans and Agents from “one question and one answer” to “multi-role collaboration.” In the future, a model team may no longer consist merely of a chatbot and several engineers, but rather a research network in which human leaders coordinate, multiple specialized Agents execute, and automated systems record and evaluate the work.

Can This Approach Be Replicated?

Yes, but it cannot be copied wholesale.

For developer teams with a certain level of engineering capability, what is most worth reusing is not the number of Agents, but the following four principles.

First, Standardize the Process Beforehand

If training tasks, data versions, code versions, and evaluation metrics are not recorded consistently, more Agents will only create more confusion. Every experiment should have a clearly defined configuration file, version number, and artifact path.

Second, Give Agents Clear Tool Boundaries

There is no problem with having Agents generate code and make suggestions, but granting them direct permission to delete data, modify production environments, or submit unlimited GPU jobs carries considerable risk. A more reasonable approach is to use sandboxes, approval checkpoints, and resource quotas, leaving high-risk actions for human confirmation.

Third, Put Evaluation at the Center of the Process

Without automated evaluation, Agents can only keep “trying.” Only when every change can be tied to comparable metrics does the system have a chance to accumulate experience. Evaluation must not look only at a single overall score; it should also cover dimensions such as knowledge, reasoning, coding, long-context understanding, factuality, and safety.

Fourth, Preserve Records of Failures

Many R&D teams show only successful experiments. In reality, failure logs are often more useful for helping those who come later avoid pitfalls. Which data-cleaning rules caused capabilities to decline? Which hyperparameters made training unstable? Which Agent suggestions were not adopted? This information determines whether a project can truly be reproduced.

What Does This Mean for the Open-Source Model Ecosystem?

In the past, training foundation models was the exclusive capability of a small number of large companies. The reason was not only that computing power was expensive, but also that it required a team that understood data, algorithms, systems, and evaluation simultaneously. Agents are lowering this barrier, but what they mainly reduce is the “organizational and execution cost”—not the cost of computing power or high-quality data.

This means more small-team-trained, medium- and small-scale models may emerge in the future. They may not win in overall capability, but could be more valuable in vertical domains, specific languages, industry knowledge, or local deployment. As long as the training process is transparent, the community can continue iterating on data, architectures, and post-training methods.

At the same time, an increase in open-source models will bring new problems: Are the model licenses clear? Are the training corpora compliant? Do the weights really correspond to the publicly released code? Have the evaluation results been checked for contamination? Does the model have hidden safety risks?

Therefore, “full openness” is an excellent starting point, but not the endpoint of trustworthiness. When using ZGCM-1 or similar projects, developers should still independently check the data sources, licenses, weight hashes, evaluation scripts, and actual outputs. They should not assume that a project is production-ready simply because it has disclosed its training logs.

What Can OpenAI Hub Provide?

For developers who want to quickly compare different open-source models, model training is only the first step. Subsequent steps also include inference services, interface adaptation, cost control, and performance evaluation. OpenAI Hub provides a unified API entry point compatible with the OpenAI format, allowing models such as GPT, Claude, Gemini, and DeepSeek to be compared using the same calling method.

Such an aggregation entry point cannot replace local deployment of ZGCM-1, but it is suitable for benchmarking: give the same batch of questions and the same set of business prompts to different models, then compare their accuracy, latency, and cost. For small teams, it is generally more prudent to first validate requirements through a unified interface and then decide whether to invest computing resources in training or deploying their own model, rather than building a complete infrastructure from the outset.

Conclusion: Models Are Increasingly Like Results; the Process Is the Asset

Seven PhD students completing the training of a 7B model within three months naturally depended on specific conditions such as the project schedule, team background, and infrastructure. It should not be packaged as “anyone can train a large model.” But it does send a clear signal: model R&D is shifting from being manually driven by a small number of experts toward a collaborative model in which humans design the process, Agents execute at scale, and systems record everything automatically.

Whether ZGCM-1’s final capabilities are sufficient for deployment in real production environments still requires further independent evaluation and community reproduction to determine. By comparison, its public training process is more likely to leave a lasting impact.

When the code, data, weights, and logs can all be taken, run, modified, and questioned by those who come later, a 7B model is no longer merely a published result, but a piece of R&D infrastructure that can continue to be forked. What the next generation of small teams may need to do is not train an “even larger model,” but make this AI-assisted R&D process more reliable, transparent, and affordable.

References

• GitHub: Search for publicly available code and repositories related to ZGCM-1—for locating project code, training scripts, and public repositories.
• Hugging Face: Search for models and datasets related to ZGCM-1—for locating model weights, datasets, and community reproduction information.

Note: This article was compiled from publicly available information as of September 15, 2026. The model size, training period, number of Agents, and scope of publicly released materials are ultimately subject to the disclosures on the project’s official repository and model page.