개요
Marin은 기반 모델 연구 및 개발을 위한 연구 프로젝트이자 소프트웨어 플랫폼, 커뮤니티입니다. 대규모 언어 모델 훈련에 중점을 두고 있으며, 데이터 큐레이션, 토큰화, 사전 훈련, 사후 훈련 및 평가를 포괄합니다. 오픈 개발을 강조하며, 음성, DNA 및 단백질 모델에도 활용된 바 있습니다.
README 미리보기
# 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)
문제 해결ExUnit이 0 failures를 보고하는데도 SWE-rebench가 통과한 Elixir 오라클을 0점으로 채점하는 이유는 무엇인가요?
아카이브된 parse_log_elixir 파서는 test name (...)으로 시작하는 라인을 기대하지만, ExUnit은 * test handles arbitrary properties (0.1ms) [L#528]과 같은 라인을 출력합니다. 앞에 붙은 * 때문에 파서는 이름이 지정된 테스트 상태에 대해 {}를 반환하므로, FAIL_TO_PASS 조회가 실패하고 오라클 점수가 0이 됩니다.
아카이브된 파서가 실행되기 전에 ExUnit의 불릿 마커를 정규화하여 트레이스를 수정하세요. 예를 들어 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)parse_log_elixir를 호출하기 전에 각 로그 라인에 이를 적용하세요. 그러면 예시가 test handles arbitrary properties (0.1ms) [L#528]로 변환되어, 이름이 지정된 통과 및 실패 레코드를 감지할 수 있습니다. 베리파이어를 재생성하거나 다시 빌드한 후 test_state.py::test_patch_resolved를 재실행하세요. 통과 오라클은 1점이 되어야 합니다. 통과 및 실패 ExUnit 트레이스 모두에 대한 회귀 테스트를 추가하세요. 이 수정은 PR #10008에 구현되어 있습니다.
문제 해결MarinSkyRL에서 uv lock 실패 "No solution found ... marin-rigging[secrets]>=0.2.123.dev35633925924"를 어떻게 해결하나요?
이 실패는 PyPI에 호환되는 릴리스가 있음에도 불구하고 uv가 고정된 Marin Git 워크스페이스에서 marin-rigging 0.2.0을 선택하기 때문에 발생합니다. config/external/MarinSkyRL/pyproject.toml에 오버라이드를 추가하여 uv가 게시된 패키지를 사용하도록 강제하세요:
[tool.uv]
override-dependencies = ["marin-rigging[secrets]>=0.2.139.dev37117265303"]고정된 MarinSkyRL/TaskCompendium 리비전이 요구하는 더 높은 버전 하한을 사용하세요. 원래 보고된 MarinSkyRL 하한은 >=0.2.123.dev35633925924였습니다. 그런 다음 다시 실행하세요:
uv lock --project config/external/MarinSkyRL --upgrade-package marinskyrluv lock -v로 marin-rigging이 Marin Git 워크스페이스가 아닌 PyPI에서 해석되는지 확인하세요. 테스트에서 보고된 리비전은 게시된 rigging 릴리스로 198개의 패키지를 해석했습니다. 이 수정은 PR #9931에서 구현되었습니다.
문제 해결reasoning-gym 0.1.25에서 JSON 전송 후 올바른 ARC AGI 및 ReArc 답변이 1.0 대신 0.05로 채점되는 이유는 무엇인가요?
이 문제는 parse_board가 그리드를 튜플로 표현하지만, json.loads()가 metadata['output']을 리스트로 복원하기 때문에 발생합니다. arc_agi와 rearc 스코어러는 이 구조를 직접 비교하므로, 정답인 그리드도 부분 점수 0.05를 받게 됩니다.
score_answer()를 호출하기 전에 JSON으로 디코딩된 정답 그리드를 튜플로 정규화하여 이 문제를 해결하세요:
metadata = entry["metadata"]
metadata["output"] = tuple(
tuple(row) for row in metadata["output"]
)예를 들어:
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이 정규화를 arc_agi와 rearc 모두에 대해 Verifyit의 JSON 로딩/채점 경계에 적용하세요. 수정 후에는 정답 그리드는 1.0, 오답 그리드는 0.05, 잘못된 형식의 답변은 0.0 점수를 받습니다. 그러면 TaskTrove ARC 제외를 제거할 수 있지만, 이전에 스테이징된 행은 승인되려면 별도로 재변환해야 합니다.
문제 해결Iris native proxy 테스트를 실행할 때 `verified_identity`에서 누락된 `job_id`를 수정하는 방법은 무엇인가요?
이 오류는 네이티브 프록시 태스크 아이덴티티 변경 사항이 포함되지 않은, 락파일에 고정된 marin-iris-native==0.1.6.dev31131847556 휠로 인해 발생합니다. PR #9994/#10002에서와 같이 네이티브 휠을 marin-iris-native==0.1.11.dev37977873285 이상으로 업데이트하고 고정하세요. lib/iris/pyproject.toml의 의존성을 업데이트하고, 락파일을 갱신한 다음(예: uv lock 사용), uv sync로 재설치하고 다시 실행하세요:
uv run pytest lib/iris/tests/cluster/controller/test_native_proxy.py -k test_native_listener_stamps_controller_identity_and_strips_caller_credentials
업데이트된 휠에서는 디코딩된 verified_identity에 {'job_id': '/alice/train'}이 포함되어야 합니다.
문제 해결Linux 전용 bubblewrap_bin 의존성으로 인해 macOS에서 발생하는 rolloutengine ImportError를 해결하는 방법
PR #9980이 포함된 버전으로 RolloutEngine을 업그레이드하세요. 이 수정은 lowering.py와 machines.py에서 shellbox.backends.local.machine(및 로컬 TaskCompendium 런타임)의 즉시 임포트를 제거하고, lock-only 채점 경로 내부에서만 임포트하도록 합니다. 또한 isinstance(factory, LocalMachineFactory) 검사를 factory.backend == Backend.LOCAL로 대체하여 위임하는 팩토리 래퍼를 사용할 수 있게 합니다.
코드를 직접 패치하는 경우:
1. 최상위 로컬 백엔드 임포트를 제거합니다.
2. lock-only 경로가 선택된 경우에만 _acquire_machine과 validate_lowered_task 내부에서 로컬 백엔드를 지연 임포트합니다.
3. macOS에서 패키지를 임포트할 수 있도록 bubblewrap_bin 임포트를 가드하고, lock-only 채점기가 실제로 로컬 백엔드를 필요로 할 때만 명확한 플랫폼 오류를 발생시킵니다.
4. 구체 클래스 대신 factory.backend == Backend.LOCAL로 디스패치합니다.
그런 다음 패키지를 업데이트/재설치하고 테스트를 다시 실행합니다. 예:
git pull
pip install -e lib/rolloutengine
pytest
업그레이드 전 임시 해결 방법: Linux 컨테이너 내에서 테스트 또는 타입 검사를 실행하세요.