개요
RLM은 재귀적 프로그래밍 방식으로 표준 LLM 호출을 대체하여 거의 무한한 컨텍스트를 처리할 수 있습니다. 이 라이브러리는 확장 가능한 추론 엔진과 훈련 환경을 제공하고 API 및 로컬 LLM을 지원하며, Docker, Modal 등 다양한 샌드박스 환경을 통합하여 격리된 실행을 구현합니다.
README 미리보기
\n---\n\n\nRecursive Language Models (RLMs)\n\n\n\n Full Paper •\n Blogpost •\n Documentation •\n RLM Minimal\n\n\n\n \n \n \n \n \n \n\n\n\n \n \n \n\n\n## Overview\nRecursive Language Models (RLMs) are a task-agnostic inference paradigm for language models (LMs) to handle near-infinite length contexts by enabling the LM to *programmatically* examine, decompose, and recursively call itself over its input. RLMs replace the canonical `llm.completion(prompt, model)` call with a `rlm.completion(prompt, model)` call, acting as a "language model". RLMs offload the context as a variable in a REPL environment that the LM can interact with and launch sub-LM calls inside of.\n\nRLMs are a bet on future "language model" design choices. We argue for a [CodeAct](https://arxiv.org/abs/2402.01030)-style harness (i.e. all language models should have access to a code environment) with sub-(R)LM calls as functions in code, and context / prompts as objects in code. RLMs explicitly defer code execution with sub-calls as functions to the language model itself, which is incredibly flexible and lends itself well to scale if trained correctly. We want to move away from the JSON tool-calling standard for both sub-agents and generic tool calls. The naming comes from the fact that such a system is itself a "language model" (a probabilistic mapping from text to text) that builds around and relies on recursive sub-LLM calls.\n\nThis repository provides both an extensible inference engine and training environment for using RLMs around standard API-based and local LLMs. The initial experiments and idea were proposed in a [blogpost](https://alexzhang13.github.io/blog/2025/rlm/) in 2025, with expanded results in an [arXiv preprint](https://arxiv.org/abs/2512.24601).\n\nWe now also include a [verifiers](https://github.com/PrimeIntellect-ai/verifiers) training environment based on Prime Intellect's [prime-rl](https://github.com/PrimeIntellect-ai/prime-rl) in the `training/` folder
FAQ (2)
문제 해결Python 3.10에서 `pip install rlms`를 실행하면 왜 v0.0.1a1이 설치되고 `ModuleNotFoundError: No module named 'rlm'` 오류와 함께 실패하나요?
문제 해결
Python 3.10에서 `pip install rlms`를 실행하면 왜 v0.0.1a1이 설치되고 `ModuleNotFoundError: No module named 'rlm'` 오류와 함께 실패하나요?rlms 0.1.0은 Python >= 3.11이 필요하지만, 이전 0.0.1a1 스텁에는 Python 버전 제약이 없습니다. 따라서 Python 3.10에서는 pip이 호환되지 않는 스텁으로 폴백하면서 성공으로 보고합니다. Python 3.11 이상을 사용하여 설치하세요:
python3.11 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip uninstall -y rlms
pip install rlms
pip show rlms # Version: 0.1.0이 표시되어야 합니다
python -c "from rlm import RLM"Python 3.10에서는 pip install rlms==0.1.0이 No matching distribution found 오류와 함께 실패합니다. 0.0.1a1은 버전 문자열만 포함하고 있으므로 사용해서는 안 됩니다. 패키지 관리자는 0.0.1a1을 yank하거나 Python 3.10 호환 버전을 릴리스하여 이러한 조용한 폴백 문제를 해결할 수 있습니다.
문제 해결I don't have the actual source or docs for `rlm_query_batched`, so I can't tell you its exact behavior — but here's how this is typically handled, plus what to check in your implementation.
**1. Check for a built-in concurrency knob**
Many batching helpers default to sequential execution for simplicity. Look at the function signature for parameters like `max_workers`, `concurrency`, `num_threads`, or an async variant (e.g., an `rlm_query_batched_async` or an underlying async client). If one exists, that's the intended path.
**2. Parallelize at the caller level if it doesn't**
Since your subqueries are independent, you can skip `rlm_query_batched` entirely and run `rlm_query` yourself in parallel. Because LM API calls are I/O-bound, threads work fine despite the GIL:
```python
from concurrent.futures import ThreadPoolExecutor
subqueries = [...] # your independent subqueries
def run_one(q):
return rlm_query(q, context=...) # fresh context/state per call
with ThreadPoolExecutor(max_workers=8) as pool:
results = list(pool.map(run_one, subqueries))
```
If the library exposes an async client, `asyncio.gather` with a semaphore to cap concurrency is usually more efficient:
```python
import asyncio
sem = asyncio.Semaphore(8)
async def run_one(q):
async with sem:
return await rlm_query_async(q)
results = await asyncio.gather(*(run_one(q) for q in subqueries))
```
**3. Gotchas specific to recursive subcalls**
- **State isolation**: each subquery needs its own environment (REPL state, context buffer, message history). If the batched helper shares a single environment across subcalls, running them in parallel will corrupt state — that's often *why* the default is sequential.
- **Rate limits**: parallel subqueries multiply request volume, and each RLM subquery may itself fan out into multiple LM calls. Add retries with backoff and cap `max_workers` to stay under your provider's limits.
- **Client thread-safety**: verify the underlying LM client (OpenAI, Anthropic, etc.) is safe to share across threads, or create one client per worker.
If you can paste the signature or source of `rlm_query_batched` from the repo you're using, I can tell you exactly where parallelism breaks down or how to enable it.
문제 해결
I don't have the actual source or docs for `rlm_query_batched`, so I can't tell you its exact behavior — but here's how this is typically handled, plus what to check in your implementation.
**1. Check for a built-in concurrency knob**
Many batching helpers default to sequential execution for simplicity. Look at the function signature for parameters like `max_workers`, `concurrency`, `num_threads`, or an async variant (e.g., an `rlm_query_batched_async` or an underlying async client). If one exists, that's the intended path.
**2. Parallelize at the caller level if it doesn't**
Since your subqueries are independent, you can skip `rlm_query_batched` entirely and run `rlm_query` yourself in parallel. Because LM API calls are I/O-bound, threads work fine despite the GIL:
```python
from concurrent.futures import ThreadPoolExecutor
subqueries = [...] # your independent subqueries
def run_one(q):
return rlm_query(q, context=...) # fresh context/state per call
with ThreadPoolExecutor(max_workers=8) as pool:
results = list(pool.map(run_one, subqueries))
```
If the library exposes an async client, `asyncio.gather` with a semaphore to cap concurrency is usually more efficient:
```python
import asyncio
sem = asyncio.Semaphore(8)
async def run_one(q):
async with sem:
return await rlm_query_async(q)
results = await asyncio.gather(*(run_one(q) for q in subqueries))
```
**3. Gotchas specific to recursive subcalls**
- **State isolation**: each subquery needs its own environment (REPL state, context buffer, message history). If the batched helper shares a single environment across subcalls, running them in parallel will corrupt state — that's often *why* the default is sequential.
- **Rate limits**: parallel subqueries multiply request volume, and each RLM subquery may itself fan out into multiple LM calls. Add retries with backoff and cap `max_workers` to stay under your provider's limits.
- **Client thread-safety**: verify the underlying LM client (OpenAI, Anthropic, etc.) is safe to share across threads, or create one client per worker.
If you can paste the signature or source of `rlm_query_batched` from the repo you're using, I can tell you exactly where parallelism breaks down or how to enable it.PR #136이 포함된 릴리스로 업그레이드하십시오. 해당 버전에서는 rlm_query_batched가 제한된 ThreadPoolExecutor를 사용하여 2개 이상의 독립적인 하위 RLM 호출을 자동으로 동시에 실행하고 결과를 원래 제출 순서대로 반환합니다. 이를 통해 N개의 I/O 바운드 하위 호출에 대한 wall time이 약 N × T에서 약 T로 감소하며, 이는 구성된 동시성 제한에 따릅니다. 여러 프롬프트로 rlm_query_batched를 호출하는 것 외에는 코드 변경이 필요하지 않습니다.