Зустрічайте Beam: відкрита модель на 501 млрд параметрів, якою ви можете володіти, налаштовувати та масштабувати

Оновити на GitHub

Beam від Reflection уже доступна на Hugging Face! Це перша модель нової американської лабораторії Reflection — і вона відкрита! Це модель із сумішшю експертів (MoE) із 501 млрд параметрів (23 млрд активних для кожного токена), яка підтримує текст як вхідні дані, має контекстне вікно на 1 млн токенів і випущена за ліцензією Apache 2.0.

Beam орієнтована на випадки використання, пов’язані з програмуванням і агентами. Вона призначена для команд, які хочуть мати модель фронтирного масштабу на власному обладнанні, у власній інфраструктурі чи хмарі та налаштовувати її під свої потреби. Beam постачається з власним спеціалізованим опенсорсним рушієм на Rust, який забезпечує найкращу продуктивність моделі.

Beam має нативну реалізацію в transformers, а також підтримується такими бібліотеками, як vLLM і SGLang. Ми працювали з командою Reflection, щоб підготувати для вас рецепти інференсу, SFT (керованого донавчання) і RL (навчання з підкріпленням), які допоможуть створювати рішення на основі цієї моделі. Окрім підтримки в transformers, SGLang і vLLM від першого дня, у цій публікації ми покажемо, як запускати та донавчати модель і що ми з нею створили.

Коротко

• LLM MoE із 501 млрд параметрів і 23 млрд активних параметрів на токен. 52 шари, 256 експертів на шарі MoE, 8 експертів обираються для кожного токена.
• Текст на вході, текст на виході з контекстним вікном на 1 млн токенів.
• Формати контрольних точок: BF16, FP8, і NVFP4
• Міркування, які можуть зберігатися в контексті між ходами (preserve_thinking), виклик інструментів зі спеціальною граматикою. Модель підтримує п’ять значень рівня міркувань: "low", "medium" (за замовчуванням), "high", "xhigh" і "max".
• Шаблон відповіді в токенізаторі.
• Модель для спекулятивного декодування за допомогою DFlash2
• Бібліотеки, доступні від першого дня: transformers, SGLang, vLLM. RL із повним набором параметрів за допомогою Miles.
• Постачається з власним рушієм на Rust.
• Apache 2.0.

Створюйте з Beam

Reflection надасть кредити Hub на суму 10 000 доларів за найкращі проєкти, що використовують Beam. Вам лише потрібно щось створити й опублікувати це на Hub:

• Можна створити демо з використанням моделі Beam у Spaces
• Можна квантувати її для улюбленого обладнання
• Можна згенерувати синтетичний набір даних для улюбленої задачі
• Можна створити середовище RL із Beam або для Beam
• Можна протестувати Beam і поділитися результатами.
• Можна нас здивувати!

Якщо ви щось створите з Beam, опублікуйте це на Hub, щоб отримати шанс виграти 10 000 доларів. Вам потрібно лише створити репозиторій простору, моделі або набору даних і поділитися ним на сторінці репозиторію моделі. Ми зберемо всі посилання, оберемо найкращі та надішлемо кредити на ваші облікові записи Hub.

Що таке Beam?

Beam — це текстова модель, створена для міркувань у довгому контексті (довжина контексту 1 млн токенів) і роботи агентів. Це розріджена модель MoE, у якій кожен токен обчислюється лише невеликою частиною мережі, тож вона працює зі швидкістю значно меншої моделі, зберігаючи місткість великої.

Механізм уваги

Декодер має 52 шари з розміром прихованого стану 5120. У більшості шарів використовується увага зі ковзним вікном для попередніх 512 токенів; кожен шостий шар і останній шар звертаються до всього контексту. Таким чином, є 43 шари зі ковзним вікном і 9 глобальних шарів.

Усередині блока уваги (обидва типи шарів)

Два типи шарів по-різному працюють із позицією. Шари зі ковзним вікном використовують RoPE, оскільки відносна позиція найважливіша в межах короткого вікна. Глобальні шари не використовують позиційне кодування. Натомість кожен запит множиться на масштабувальний коефіцієнт, який повільно зростає зі збільшенням кількості видимих токенів: (1 + (pos + 1) / 2048) ** 0.1. Він діє як температура: softmax зберігає точність зі збільшенням довжини контексту, а не вирівнюється. Реалізація називає це масштабуванням запитів scalable-softmax.

У механізмі уваги використовується згрупована увага запитів із 48 головами запитів і 8 головами ключів-значень, а також RMSNorm для запитів і ключів. Навчуваний сигмоїдний вентиль, обчислений із входу шару, масштабує кожен канал кожної голови перед вихідною проєкцією.

Суміш експертів

Перші 3 шари використовують щільний MLP SwiGLU. В інших 49 шарах його замінено блоком суміші експертів із 256 експертами, кожен із яких є MLP SwiGLU з проміжним розміром 2560, або приблизно 39 млн параметрів. На експертів припадає 98,4% параметрів моделі.

Маршрутизатор дотримується схеми DeepSeek-V3 з обмеженням за групами. Він оцінює всі 256 експертів за допомогою сигмоїди, розподіляє їх на 8 груп по 32, залишає 4 найкращі групи (ранжовані за сумою двох найвищих оцінок кожної групи), а потім обирає 8 найкращих експертів у них. Beam використовує такі самі розміри груп, як DeepSeek-V3, але без спільного експерта. Виходи експертів об’єднуються з нормалізованими вагами маршрутизатора та масштабуються на 2,5.

Для кожного токена запускаються лише 8 експертів, тому модель обчислює кожен токен приблизно 23 млрд параметрів. Усі 256 експертів залишаються в пам’яті, тому для розгортання потрібна пам’ять для моделі на 501 млрд параметрів, але працює вона зі швидкістю моделі на 23 млрд. Контрольна точка BF16 займає приблизно 1 ТБ у форматі safetensors. Контрольна точка NVFP4 зберігає більшість параметрів у 4-бітній точності для графічних процесорів NVIDIA Blackwell, а деякі параметри залишаються у BF16 для точності. На Hub також доступні контрольні точки FP8, які ідеально підходять для чипів серій Hopper і Ampere.

Якщо ви хочете самостійно розгорнути Beam, перегляньте наведені нижче рецепти для vLLM або SGLang.

Залишковий потік

Залишкові зв’язки — найхарактерніша частина моделі. Стандартний трансформер додає вихід кожного підшару до потоку з вагою 1, тому потік зростає разом із глибиною.

Beam вважає вбудовування входу кроком 1. На кроці k вона додає вихід підшару з вагою 1/sqrt(k) і зберігає наявний потік із вагою sqrt((k-1)/k). Квадрати двох ваг у сумі дорівнюють одиниці, тому потік зберігає сталий масштаб від першого до останнього шару. Після всіх 104 додавань кожен вихід підшару та вбудовування входу мають однакову вагу у фінальному прихованому стані.

Кожен підшар також нормалізується до і після, а фінальні логіти проходять через tanh softcap на рівні ±30, обчислений у FP32. Реалізація чітко визначає, що обчислюється у FP32: маршрутизатор, добуток SwiGLU, норми, RoPE, масштабування запитів і softcap.

Довгий контекст

Гібридна увага добре працює з довгими контекстами. Кожен шар кешує 2 x 8 KV-голів x 128 вимірів = 2048 значень на токен. Якби всі 52 шари зберігали кожен токен, кеш зростав би на 208 КіБ на токен. Лише 9 глобальних шарів зберігають усю послідовність. 43 шари зі ковзним вікном утримують фіксоване вікно на 512 токенів кожен і перестають зростати. Отже, кеш зростає на 36 КіБ на токен — приблизно на шосту частину наївного показника.

Ці числа наведено для однієї послідовності, у BF16, із динамічним кешем transformers.

Результати тестування

Ось результати тестування для різних рівнів точності, надані командою Reflection.

Вимоги до обладнання

Найпрактичніший спосіб обслуговувати модель — використовувати контрольну точку NVFP4, яка зберігає більшість якості контрольної точки bf16. NVFP4 зберігає деякі ваги в 4 бітах і таким чином зменшує розмір 501 млрд параметрів у BF16 з 1 ТБ до приблизно 280 ГБ. Графічні процесори Blackwell нативно запускають NVFP4, але старіші за Blackwell GPU, наприклад H200, цього не можуть. Контрольні точки FP8 підходять для GPU старіших за Blackwell.

B200 має 180 ГБ HBM3e, тому два таких GPU (360 ГБ) можуть вмістити ваги Beam, залишивши мало місця для активацій і KV-кешу. Плануйте чотири B200 (720 ГБ), що залишить достатньо місця для довгих контекстів і паралельних запитів. Також можна обслуговувати модель на повному вузлі 8xB200, на двох B300 по 288 ГБ кожен або навіть на 8xRTX Pro 6000. Якщо у вас немає обладнання Blackwell, скористайтеся Inference Providers (безсерверними), щоб протестувати Reflection.

Підтримка інференсу

Beam має підтримку в transformers, SGLang і vLLM від першого дня.

Transformers

Встановіть останню версію transformers.

pip install -U "transformers>=5.20.1"

Найпростіший спосіб запустити Beam — конвеєр text-generation:

from transformers import pipeline

pipe = pipeline(
    "text-generation", model="reflectionai/Beam-1.0-501B-A23B", device_map="auto"
)

messages = [
    {"role": "user", "content": "Write a limerick about Python exceptions."}
]
output = pipe(messages, max_new_tokens=2000)
output[0]["generated_text"][-1]

Конвеєр повертає весь чат. Останнє повідомлення — відповідь Beam, уже розібрана за шаблоном відповіді.

Якщо перейти на нижчий рівень, використовуйте AutoModelForCausalLM і AutoTokenizer.

from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "reflectionai/Beam-1.0-501B-A23B"
tokenizer = AutoTokenizer.from_pretrained(model_id)

model = AutoModelForCausalLM.from_pretrained(
    model_id, dtype="auto", device_map="auto"
)

Чат

messages = [
    {"role": "system", "content": "You should only answer with a number."},
    {"role": "user", "content": "What is 17 * 23?"},
]

inputs = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    tokenize=True,
    return_dict=True,
    return_tensors="pt",
    reasoning_effort="medium" 
).to(model.device)

input_len = inputs["input_ids"].shape[-1]

outputs = model.generate(**inputs, max_new_tokens=2000)

tokenizer.parse_response(
    outputs[0][input_len:], prefix=inputs["input_ids"][0]
)

Токенізатор Beam містить шаблон відповіді. parse_response читає його та перетворює необроблений вихід на словник повідомлення з окремими полями для міркувань, відповіді та викликів інструментів. Це усуває потребу у звичайному регулярному виразі для розділення міркувань, відповідей і викликів інструментів. Правила постачаються разом із токенізатором, тому розібрана структура відповідає формату, для якого навчали Beam. Шаблон чату може заздалегідь записувати частину ходу асистента, яку парсеру потрібно бачити.

Виклик інструментів

Повний приклад виклику інструментів

def get_weather(city: str, unit: str = "celsius"):
    """
    Get the current weather for a city.

    Args:
        city: The city to look up.
        unit: Temperature unit, "celsius" or "fahrenheit".
    """
    ...

tools = [get_weather]
messages = [
    {"role": "user", "content": "I land in Paris tonight. Do I need a coat?"}
]

inputs = tokenizer.apply_chat_template(
    messages,
    tools=tools,
    add_generation_prompt=True,
    tokenize=True,
    return_dict=True,
    return_tensors="pt",
).to(model.device)

input_len = inputs["input_ids"].shape[-1]
outputs = model.generate(**inputs, max_new_tokens=1000)

message = tokenizer.parse_response(
    outputs[0][input_len:], prefix=inputs["input_ids"][0], tools=tools
)
message.get("tool_calls")

Також передайте tools у parse_response. Beam записує аргументи виклику інструментів безпосередньо у власній граматиці в стилі XML, тому окреме 7 може бути числом або рядком. Завдяки схемам інструментів парсер перетворює кожен аргумент на оголошений для нього тип.

Кілька GPU та вузлів

Конфігурація Beam визначає план паралелізму експертів. За паралелізму експертів кожен експерт розміщується на окремому пристрої. Механізм уваги, щільні шари, вбудовування та LM-голова реплікуються на кожному пристрої. Це 8 млрд параметрів, або 16 ГБ у BF16. Завантажте модель із DistributedConfig:

import os

from transformers import AutoModelForCausalLM
from transformers.distributed import DistributedConfig

model = AutoModelForCausalLM.from_pretrained(
    "reflection/Beam-1.0-501B-A23B",
    distributed_config=DistributedConfig(
        tp_size=int(os.environ["WORLD_SIZE"]), enable_expert_parallel=True
    ),
)

Запустіть скрипт за допомогою torchrun на 16 GPU H200. Тоді кожен пристрій зберігатиме 78 ГБ ваг. За 8 GPU кожен зберігатиме 139 ГБ, що не залишає місця на H200 обсягом 141 ГБ. Кількість пристроїв має бути дільником кількості експертів — 256.

vLLM

Beam має підтримку у vLLM від першого дня. Наведена нижче команда обслуговує контрольну точку BF16 із тензорним паралелізмом на 16 GPU (два вузли 8x H200) і відкриває API, сумісний з OpenAI:

vllm serve reflection/Beam-1.0-501B-A23B --tensor-parallel-size 16 --served-model-name beam

Для швидшої генерації додайте спекулятивне декодування DFlash2. Невелика модель-чернетка пропонує до 15 наступних токенів, а Beam перевіряє їх усі за один прямий прохід, тому на кожному кроці можна прийняти кілька токенів. Ціна — трохи додаткової пам’яті для моделі-чернетки:

vllm serve reflection/Beam-1.0-501B-A23B \
  --tensor-parallel-size 16 \
  --speculative-config '{ "method": "dflash", "model": "reflection/dflash2-drafter-preview", "num_speculative_tokens": 15 }'

Обидві команди запускають OpenAI-сумісний сервер, тому ви можете спрямувати будь-який клієнт OpenAI на http://localhost:8000/v1. Інші конфігурації обслуговування дивіться в запропонованому рецепті Beam для vLLM.

SGLang

Beam також має підтримку в SGLang від першого дня. Ми рекомендуємо обслуговувати її зі спекулятивним декодуванням DFlash2, яке вмикають обидві наведені нижче команди. На Blackwell контрольна точка NVFP4 поміщається на 4 B300:

python -m sglang.launch_server \
--model-path reflection/Beam-1.0-501B-A23B-NVFP4 \
--served-model-name beam \
--tp 4 \
--attention-backend trtllm_mha \
--page-size 64 \
--context-length 1048576 \
--mem-fraction-static 0.85 \
--enable-unified-memory \
--speculative-algorithm DFLASH \
--speculative-draft-model-path reflection/Beam-1.0-501B-A23B-DFlash2 \
--speculative-dflash-block-size 8 \
--tool-call-parser beam --reasoning-parser beam \
--host 0.0.0.0 --port 30000

На GPU Hopper натомість використовуйте контрольну точку FP8 на 8 H200. Змінюються лише три прапорці: контрольна точка, розмір тензорного паралелізму (8 замість 4) і бекенд уваги (fa3 замість trtllm_mha, якому потрібен Blackwell):

python -m sglang.launch_server \
--model-path reflection/Beam-1.0-501B-A23B-FP8 \
--served-model-name beam \
--tp 8 \
--attention-backend fa3 \
--page-size 64 \
--context-length 1048576 \
--mem-fraction-static 0.85 \
--enable-unified-memory \
--speculative-algorithm DFLASH \
--speculative-draft-model-path reflection/Beam-1.0-501B-A23B-DFlash2 \
--speculative-dflash-block-size 8 \
--tool-call-parser beam --reasoning-parser beam \
--host 0.0.0.0 --port 30000

Провайдери інференсу

Beam доступна через Inference Providers на Hugging Face за підтримки Baseten, Fireworks і Together; незабаром долучаться й інші.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://router.huggingface.co/v1",
    api_key=os.environ["HF_TOKEN"],
)

completion = client.chat.completions.create(
    model="reflection/Beam-1.0-501B-A23B:auto",
    messages=[{"role": "user", "content": "What is the capital of France?"}],
)

print(completion.choices[0].message)

Кінцеві точки інференсу

Ми підготували рецепт Beam для розгортання одним клацанням у Inference Endpoints із каталогу у форматі FP8 або NVFP4, або встановіть його за допомогою CLI hf так:

hf endpoints catalog deploy --repo reflection/Beam-1.0-501B-A23B --name beam

Що ми тестували

Ми ділимося результатами кількох практичних оцінювань Reflection Beam-501B-A23B на п’яти завданнях: по одному разу з низьким і високим рівнями міркувань через платформу Reflection. Це практичні оцінювання, а не бенчмарки. Якщо ви плануєте використовувати Beam, це чудовий спосіб випробувати її та побачити, як вона поводиться в конкретних випадках використання, а головне — де вона перемагає, а де програє.

Нижче наведено огляд використаних запитів і трас виходів із Hub. Повні вхідні та вихідні дані, використання API, фікстури завдань, оцінювачі й траси діалогів містяться в цьому публічному бакеті Hugging Face.

* Відповідь із низьким рівнем міркувань на завдання з довгим контекстом правильно відтворила всю поведінку коду та всі шість посилань на вихідні файли. Однак відповідь не відповідала формату парсера, тож це частково пов’язано з неоднозначністю запиту.

† Відповідь із низьким рівнем містила правильний результат, але не містила запитаного обґрунтування. Високий рівень надав правильний доказ через корені з одиниці, який було перевірено незалежно.

Не вірте нам на слово. Перегляньте бакет, переробіть рішення під власний випадок використання чи проєкт і випробуйте Beam на максимум.

Післянавчання Beam

Ви можете донавчити Beam для власних випадків використання. Тут ми ділимося прикладами в TRL і Miles, щоб допомогти вам розпочати кероване донавчання та навчання з підкріпленням.

SFT із TRL

Найшвидший спосіб адаптувати Beam до власних даних — кероване донавчання за допомогою SFTTrainer із TRL. Щоб зберегти керований обсяг пам’яті, ми навчаємо адаптери LoRA за допомогою PEFT, а не оновлюємо всі 501 млрд параметрів: Ми використали SFTTrainer із TRL, щоб адаптувати Beam до простої мети: зберігати міркування мовою, яку запитав користувач. Ми донавчили модель на наборі Multilingual-Thinking за допомогою LoRA, яка навчає невеликий набір ваг адаптера, залишаючи базову модель замороженою.

Конфігурація поєднує шардинг моделі під час завантаження, паралелізм експертів, FlashAttention 4 і пакування послідовностей. SFT LoRA працює на одному вузлі з 8 GPU B300, досягаючи приблизно 19 000 токенів на секунду. Відповідна конфігурація H100 використовує чотири вузли.

Після однієї епохи Multilingual-Thinking Beam виконала міркування запитаною мовою у 16 із 16 відкладених запитів, тоді як базова модель — у 3 із 16. Це невелике оцінювання вимірює дотримання мови, а не правильність самих міркувань.

Втрата під час навчання (ліворуч) і середня точність токенів (праворуч) під час окремого запуску на 500 кроків на підмножині міркувань open-r1/Mixture-of-Thought із використанням одного вузла B300 із 8 GPU. Ці метрики навчання взято з офіційного прикладу PR для TRL.

GRPO з Miles

Reflection і RadixArk створили рецепт навчання моделі за допомогою GRPO у Miles, у BF16. Ви можете оновлювати всю модель або використовувати LoRA для навчання адаптерів, залишаючи базові ваги замороженими. Megatron навчає, SGLang генерує розгортання, а Miles публікує нові ваги для рушіїв розгортання після кожного оновлення. Ми перевірили цей рецепт.

Рецепт запускає GRPO на DAPO-Math-17K і оцінює модель на AIME25. Створіть образ, завантажте дані та надішліть завдання до кластера Ray із дванадцяти вузлів 8x H200:

docker build -f docker/Dockerfile.beam -t miles-beam .

python scripts/run_beam.py prepare \
  --model-id reflection/Beam-1.0-501B-A23B \
  --model-dir /root/models/Beam \
  --data-dir /data/datasets

export MASTER_ADDR=10.0.0.1
export RAY_ADDRESS=http://${MASTER_ADDR}:8265

python scripts/run_beam.py execute \
  --model-dir /root/models/Beam \
  --data-dir /data/datasets \
  --output-dir /root/shared_data/beam-run \
  --num-rollout 100

Що відбувається під час розгортання:

Вибірка: 32 запити передаються моделі з 8 відповідями кожен. Два рушії SGLang обслуговують розгортання на 16 GPU кожен.

Оцінювання: відповідь у рамці порівнюється з міткою, а для відповідей, близьких до обмеження довжини, застосовується м’який штраф.

Оновлення: один крок оптимізатора для всіх 256 зразків. Переваги, відносні до групи, з усіченою вибіркою важливості, без штрафу KL або ентропії.

Паралельне навчання: тензорний паралелізм 8, паралелізм експертів 8, паралелізм даних 8, із паралелізмом послідовностей і повним перерахунком.

Оптимізатор: Adam із постійним значенням 1e-6. Градієнти у BF16, основні ваги у FP32, моменти у BF16. Стан оптимізатора передається через локальний NVMe вузла, тому кожному вузлу тренування потрібно 2 ТБ тимчасового сховища.

Оцінювання: AIME25 після кожних п’яти розгортань, по вісім зразків на задачу. Контрольна точка зберігається після кожних двадцяти.

Наступне розгортання генерується, поки поточне навчається, тому відповіді відстають на одне оновлення. Додайте --resume, щоб продовжити з останньої контрольної точки. execute-colocate запускає той самий рецепт на восьми вузлах, де кожен GPU по черзі навчає та обслуговує модель.

Навчання з LoRA

Ви також можете запускати GRPO із LoRA на чотирьох вузлах 8× H200: 16 GPU для навчання і 16 для розгортання. Рецепт навчає адаптери рангу 16 на шарах уваги, щільному MLP та експертних шарах Beam, залишаючи базові ваги замороженими. Із SGLang синхронізуються лише ваги адаптерів, а стан оптимізатора залишається в пам’яті GPU, що усуває потребу у вивантаженні оптимізатора на NVMe.

python scripts/run_beam_lora.py execute \
  --model-dir /root/models/Beam \
  --data-dir /data/datasets \
  --output-dir /root/shared_data/beam-run \
  --num-rollout 100

Створюйте з Beam: демо

Якщо ви щось створите з Beam, опублікуйте це на Hub, щоб отримати шанс виграти 10 000 доларів. Вам потрібно лише створити репозиторій простору, моделі або набору даних і поділитися ним на сторінці репозиторію моделі. Для натхнення наведемо кілька створених нами прикладів.

Гей, Beam, створи нативну локальну програму для MacOS!

У Hugging Face ми любимо відкриті локальні моделі, які працюють нативно на своєму обладнанні, але створювати нативні програми для Mac може бути складно! Подивімося, чи зможе Beam нам допомогти.

Ми попросили Beam створити нативну програму для MacOS, яка перетворює мовлення на текст і зручно вставляє його в позицію курсора. Ми хотіли використати MLX, щоб максимально задіяти Mac Metal, і модель Parakeet для якісного перетворення мовлення на текст.

Build BeamSpeak, a native macOS menu bar dictation app with a compact recording pill and no main window or account.

Use ⌘⇧Space to start and stop microphone recording, showing elapsed time, microphone level, and transcription status. Run speech recognition entirely locally using a Hugging Face model, preferably Parakeet v3 through MLX, and keep the model loaded between recordings. Paste the transcript into the original app if it remains focused and Accessibility permission is granted; otherwise copy it to the clipboard, preserving newer clipboard changes and never pressing Enter. Handle permissions, cancellation, silence, errors, a two-minute recording limit, and temporary audio cleanup. Deliver source code, a runnable BeamSpeak.app, setup instructions, and verification of offline transcription, the physical shortcut, microphone capture, and text delivery.

Ми використали Beam із кодувальним рушієм Pi, щоб створити початкову нативну програму для панелі меню macOS, яка запускає Parakeet за допомогою MLX. Збережений запуск містить додаткові запити; фінальний початковий код також містить подальші виправлення Codex. Наведений вище запит — скорочена версія вимог до створення.

Переглянути трасу агента, який створював це за допомогою pi, можна в цій трасі. Якщо хочете випробувати демо, завантажте початковий код або прочитайте інструкції зі встановлення.

Гей, Beam, як ти масштабуєшся на кількох агентах?

Ми хотіли перевірити, чи зможе Beam швидше просуватися, розділивши програмувальне завдання між агентами. Ми поєднали Beam із відкритим кодувальним агентом Pi та порівняли три конфігурації: 1. один агент працює сам, 2. п’ять постійних колег співпрацюють через спільний Git-репозиторій, 3. головний агент делегує роботу асинхронним підлеглим агентам. Рушій працював у jobs Hugging Face, а інференс відбувався через API платформи Reflection.

Для завдань ми використали ProgramBench: агенти мають відтворити програму за її скомпільованим виконуваним файлом і документацією, не бачачи початкового коду або тестів оцінювача. Кожна конфігурація мала однакове обмеження у 8 млн токенів API і двогодинний ліміт розв’язання на завдання, спільний для всіх її агентів. Ми зберігали знімки реалізації та оцінювали їх на фіксованих наборах прихованих тестів із набору даних ProgramBench-Tests.

На нашому графіку залежності оцінки від затримки показано середню частку пройдених тестів. Вісь часу використовує фіксовані еталонні швидкості для токенів моделі плюс виміряний час роботи інструментів, а не фактичний час. Спочатку ми запустили п’ять завдань. Поточний рисунок показує підмножину jq, xsv, FIGlet і hexyl, сформовану постфактум; ripgrep було виключено в усіх трьох конфігураціях, оскільки перевірка збережених артефактів була надто повільною. Опубліковані результати містять усі 15 початкових епізодів.

Ви можете переглянути запуски на панелі Trackio, дослідити опубліковані дані результатів і повторно використати рушій дослідження.

Гей, Beam, донавчи модель прийняття рішень для моєї кодової бази!

Моделі прийняття рішень нині дуже популярні, оскільки вони надзвичайно швидкі та практичні для багатьох випадків використання. Ми почали з Beam, а після вичерпання її квоти продовжили з GLM-5.3 у Pi, щоб навчити й оцінити власну модель прийняття рішень для сортування інцидентів розробників.

Ми хотіли перевірити, чи зможе кодувальний агент перетворити політику сортування інцидентів на малу швидку модель прийняття рішень. Завдання полягало в тому, щоб прочитати інцидент розробника й обрати відповідальну команду, його критичність і те, чи потрібно негайно когось сповістити. За допомогою Unsloth ми донавчили Qwen3.5-0.8B, щоб вона безпосередньо оцінювала ці варіанти.

Спочатку робочий процес створив синтетичний набір даних із 2,3 тис. інцидентів, розділених за кластерами інцидентів для навчання, калібрування і тестування. Ми навчали адаптер LoRA та голову прийняття рішень протягом трьох епох із 4-бітною базовою моделлю на одному H100 80GB у кластері Science Slurm.

Для базового порівняння ми подали неналаштованій моделі повну політику сорт�