marin
Frameworkmarin-community/marin
Open-source framework for research and development of foundation models.
Overview
Marin is a research program, software platform, and community for the research and development of foundation models. It focuses on training large language models, covering data curation, tokenization, pretraining, posttraining, and evaluation. It emphasizes open development and has been used for audio-text, DNA, and protein models.
README Preview
# Marin\n\n\n \n\n\n \n\n\n\n\n> "*I am not afraid of storms, for I am learning how to sail my ship.*"\n> – Louisa May Alcott\n\n[Marin](https://marin.community) is a research program, software platform, and community for the research and development of [foundation models](https://en.wikipedia.org/wiki/Foundation_model).\n\nMarin's concern is training large language models. This includes data curation, transformation, filtering, tokenization, pretraining, posttraining, and evaluation. Beyond the artifacts, software, and infrastructure, behind these models, Marin is committed to openly sharing *all* of the process knowledge required to build these models.\n\nMarin's core value is **[open development](https://openathena.ai/blog/open-development-of-frontier-ai/)**. We document our processes, experiments, and decisions as they happen. Every step, from raw data to the final model, is recorded. Failed experiments are part of that record.\n\nMarin has also been used for building [audio-text models](https://github.com/marin-community/marin/issues/1699), [DNA](https://github.com/Open-Athena/marin-dna), and [protein models](https://github.com/Open-Athena/MarinFold). We encourage this work through the use of Marin as a library, in [marin/experiments](https://github.com/marin-community/marin-experiments).\n\n## Current work\n\n### Frontier mixture-of-experts\n\nOur current focus is pretraining, from scratch, and posttraining a large (5e24 model-FLOPs, 500 billion+ total parameters) mixture-of-experts model to succeed on tasks of importance to scientists and researchers.\n\n### Scaling suite\n\nDelphi is Marin's open scaling suite scaling a LLM recipe from 3e18 to 1e23 FLOPs, inspired by Pythia. It has three parts: a scaling recipe that maps compute budgets to model configurations, a scaling suite trained from that recipe on the Google TPU Research Cloud, and a scaling law that uses the smaller Delphi models to predict the larger ones.\n\nWe released:\n\n- **Checkpoints**
FAQ (5)
TroubleshootingWhy does SWE-rebench score a passing Elixir oracle as 0 even though ExUnit reports 0 failures?
The archived parse_log_elixir parser expects lines beginning with test name (...), but ExUnit emits lines such as * test handles arbitrary properties (0.1ms) [L#528]. Because of the leading *, the parser returns {} for named test statuses, so FAIL_TO_PASS lookup fails and the oracle scores 0.
Fix the trace by normalizing ExUnit's bullet marker before the archived parser runs, for example in experiments/post_training/task_curation/datasets/tasktrove/swe_rebench.py:
import re
def normalize_exunit_line(line: str) -> str:
return re.sub(r"^\s*\*\s+", "", line)
Apply this to each log line before invoking parse_log_elixir. The example becomes test handles arbitrary properties (0.1ms) [L#528], allowing named passing and failing records to be detected. Regenerate or rebuild the verifier, then rerun test_state.py::test_patch_resolved; the passing oracle should score 1. Add regression tests for both passing and failing ExUnit traces. The fix is implemented in PR #10008.
TroubleshootingHow do I fix the uv lock failure "No solution found ... marin-rigging[secrets]>=0.2.123.dev35633925924" for MarinSkyRL?
The failure occurs because uv selects marin-rigging 0.2.0 from the pinned Marin Git workspace, even though PyPI has compatible releases. Force uv to use the published package by adding an override to config/external/MarinSkyRL/pyproject.toml:
[tool.uv]
override-dependencies = ["marin-rigging[secrets]>=0.2.139.dev37117265303"]
Use the higher version floor required by the pinned MarinSkyRL/TaskCompendium revision; the originally reported MarinSkyRL floor was >=0.2.123.dev35633925924. Then rerun:
uv lock --project config/external/MarinSkyRL --upgrade-package marinskyrl
Verify with uv lock -v that marin-rigging is resolved from PyPI rather than the Marin Git workspace. In testing, the reported revision resolved 198 packages with a published rigging release. This fix was implemented in PR #9931.
TroubleshootingWhy do correct ARC AGI and ReArc answers score 0.05 instead of 1.0 after JSON transport in reasoning-gym 0.1.25?
This happens because parse_board represents grids as tuples, but json.loads() restores metadata['output'] as lists. The arc_agi and rearc scorers compare these structures directly, so an otherwise correct grid receives the partial score 0.05.
Fix it by normalizing the JSON-decoded gold grid to tuples before calling score_answer():
metadata = entry["metadata"]
metadata["output"] = tuple(
tuple(row) for row in metadata["output"]
)
For example:
entry = json.loads(json.dumps(entry))
entry["metadata"]["output"] = tuple(
tuple(row) for row in entry["metadata"]["output"]
)
answer = format_board(entry["metadata"]["output"], dataset.board_format_opts)
print(dataset.score_answer(answer, entry)) # 1.0
Apply this normalization in Verifyit's JSON-loading/scoring boundary for both arc_agi and rearc. After the fix, correct grids score 1.0, wrong grids score 0.05, and malformed answers score 0.0. The TaskTrove ARC exclusion can then be removed, but previously staged rows must be reconverted separately for them to be admitted.
TroubleshootingHow to fix the missing `job_id` in `verified_identity` when running Iris native proxy tests?
The failure is caused by the locked marin-iris-native==0.1.6.dev31131847556 wheel, which does not include the native proxy task-identity changes. Update and lock the native wheel to marin-iris-native==0.1.11.dev37977873285 or newer, as done in PR #9994/#10002. Update the dependency in lib/iris/pyproject.toml, refresh the lockfile (for example with uv lock), then reinstall with uv sync and rerun:
uv run pytest lib/iris/tests/cluster/controller/test_native_proxy.py -k test_native_listener_stamps_controller_identity_and_strips_caller_credentials
The updated wheel should include {'job_id': '/alice/train'} in the decoded verified_identity.
TroubleshootingHow to fix the rolloutengine ImportError on macOS caused by the Linux-only bubblewrap_bin dependency?
Upgrade RolloutEngine to a version containing PR #9980. The fix removes eager imports of shellbox.backends.local.machine (and the local TaskCompendium runtime) from lowering.py and machines.py, importing them only inside the lock-only grading path. It also replaces isinstance(factory, LocalMachineFactory) checks with factory.backend == Backend.LOCAL, allowing delegating factory wrappers.
If you are patching the code yourself:
1. Remove the top-level local backend imports.
2. Import the local backend lazily inside _acquire_machine and validate_lowered_task, only when the lock-only path is selected.
3. Guard the bubblewrap_bin import so macOS can import the package; raise a clear platform error only when a lock-only grader actually requires the local backend.
4. Dispatch on factory.backend == Backend.LOCAL instead of the concrete class.
Then update/reinstall the package and rerun tests, for example:
git pull
pip install -e lib/rolloutengine
pytestTemporary workaround before upgrading: run the tests or type checks inside a Linux container.