Training a ChromBPNet model takes a prepared dataset, a bias stage, a GPU, and patience. Sometimes all four are in short supply, and you still have variants to score by Friday. That is what the project’s pretrained models are for. The ChromBPNet project shares models already trained for several cell types from public reference data, the ENCODE project, so you can run predictions and variant scoring for those cell types without training anything yourself. This article explains what pretrained models are, where to get them, how to put them to work, and the point at which you should stop borrowing and train your own.
What a pretrained model actually is
A pretrained ChromBPNet model is the finished product of the full training pipeline, run by the project on reference accessibility data for a particular cell type. Someone already assembled the peaks, the reference genome, and the signal for that cell type, trained the bias model, trained the bias-factorized accessibility model, and packaged the result. What you download is that trained network, ready to accept sequences and return base-resolution predicted profiles and total counts.
The word that does the heavy lifting is cell type. A pretrained model is not a generic accessibility oracle. It is a model of one cell type’s regulatory grammar, learned from that cell type’s data, and its predictions speak for that cell type alone. Everything sensible about using pretrained models follows from respecting that scope.
Where to get them
The models live with the project itself, through the official ChromBPNet repository on GitHub, kundajelab/chrombpnet. That is the source to use, for the same reason you install the package from there: the repository’s models are the ones matched to the current framework, documented alongside it, and referred to by the community when questions come up. Download the model for the cell type you need, place it where your pipeline expects it, and treat its provenance, which dataset and cell type it was trained on, as part of the model’s identity. Record that provenance in your project notes the day you fetch it; six months later, no one remembers which reference dataset a file came from, and the answer matters for every conclusion drawn from it.
What you can do with one, starting today
A pretrained model supports the framework’s lighter working modes immediately:
- Predict profiles for regions of interest in that cell type, giving you base-resolution predicted accessibility for loci you have no experimental data for.
- Score variants, comparing reference and variant sequence predictions to estimate effects on accessibility, the flagship use for borrowed models.
- Explore interpretation, running contribution scores on regions to see which sequence patterns the reference model leans on in that cell type.
These jobs are far lighter than training. Prediction and variant scoring still run faster on a GPU, and genome-scale scoring rewards one, but they are practical in a way that training your own model this afternoon is not. For many groups, a pretrained model answers the actual question, which is usually about variants in a known cell type, and training never becomes necessary.
How a working session with a pretrained model looks
The rhythm is simple. Fetch the model for your cell type from the project. Prepare the sequences you want to interrogate: the regions for prediction, or the reference and variant sequence pairs for scoring. Run the prediction or scoring stage of the pipeline with the pretrained model in place of a locally trained one. Then do the unglamorous part that separates results from noise: examine the outputs on a few regions you understand well before trusting the genome-scale batch. If predicted profiles on well-characterized loci behave the way reference data says they should, the model and your setup agree, and the rest of the run deserves confidence.
When a pretrained model is not enough
Borrowed models run out of road in recognizable places:
- Your cell type is not on the list. The shared models cover several cell types from public reference data, not the long tail of primary cells, rare subtypes, and model organisms variations that real projects involve.
- Your biology is a perturbation. A treatment, a differentiation stage, a disease state: if accessibility in your condition diverges from the reference cell type, the pretrained model describes the reference, not your condition.
- Your question is about your own dataset. Studies designed around a specific experiment eventually need a model of that experiment, trained on its peaks and signal, with your samples’ quirks learned rather than averaged away.
In each case the answer is the training pipeline, and the encouraging news is that working with pretrained models first teaches you the framework’s outputs and failure modes cheaply, so your eventual training run is not also your first encounter with its predictions.
Choosing among the available models
When several pretrained models could plausibly serve, choose by proximity to your question. The cell type closest to the tissue or system your variants and loci belong to is the right scorer, even if another model is more famous or more downloaded. If your variants come from a study of a particular tissue, score them in the model of that tissue’s cell type, because a variant can only affect accessibility where the surrounding chromatin is in play. When genuinely torn between two close cell types, run both and compare: agreement between related models strengthens a candidate, and disagreement is itself information about cell-type specificity, which is often the biology you were hunting for in the first place.
Keeping a borrowed model honest over a whole project
A pretrained model tends to enter a project quietly and then become load-bearing, which makes two bookkeeping habits worth adopting from day one. First, pin the model’s identity in your records: which cell type, trained on which public reference data, fetched from the project repository on which date. Analyses get revisited, manuscripts get revised, and the sentence “we scored variants with the project’s model for this cell type, trained on ENCODE reference data” should be writable from your notes, not reconstructed from download timestamps.
Second, revalidate when anything around the model changes. A framework update, a new environment, a move to a different machine: rerun your known-locus checks before trusting fresh outputs. Pretrained models remove the training burden, not the verification burden. The groups that use them well treat them like shared instruments in a core facility, calibrated on arrival and after every move. That small discipline is what separates a pretrained model used as a scientific instrument from one used as an oracle, and reviewers can tell the difference.
Conclusion
Pretrained ChromBPNet models are the framework’s front door: trained by the project on ENCODE reference data for several cell types, shared through the official GitHub repository, and ready for prediction, interpretation, and variant scoring the day you download them. Use the model whose cell type matches your question, record its provenance, sanity-check its predictions on loci you know, and it will carry a large share of real projects. When your cell type, condition, or dataset outgrows the shared list, graduate to training your own, with the guides below, and you will do it already fluent in what the framework’s outputs should look like.
Read next:
