Вопросы на собеседовании: AI ресерч-инженер

Я оформлю статьи как изменения относительно одного общего checkpoint и сравню каждый метод с неизменённым continuation из него.

• При измеренном MFU 40% относительно dense BF16 peak H100 примерно 0,99 PFLOP/s один H100-час даёт около 1,42e18 FLOPs; dense-training требует примерно 6ND всего, или 6N на токен.
• Создание общего checkpoint 7B на 100B токенов стоит около 2 950 часов, затем три method-continuations и один неизменённый control по 50B токенов стоят около 5 900 часов.
• Оставшиеся примерно 3 150 часов пойдут на mechanism ablations на 1B и 3B, evaluation и retries; для статьи, требующей 300B токенов, нужен готовый checkpoint, иначе результат называется частичным воспроизведением.
• Покажу парные method-minus-control deltas при одинаковых токенах и core FLOPs и признаю claim воспроизведённым, только если preregistered effect выдержит свежую confirmation в ledger 12 000 часов.

Я потребую от каждой заявки пройти дешёвый falsification gate до получения одного из 6 target-scale slots.

• Каждая заявка объявляет один causal claim, одну primary eval, minimum useful effect +0,7 пункта, failure condition и точные controls по tokens и FLOPs.
• При измеренном MFU 40% screen на 5B токенов для 1B и 7B стоит меньше 170 H100-часов на идею, поэтому все 18 можно проверить примерно за 3 100 часов, не выдавая это за evidence 70B.
• Каждый выбранный прогон 70B на 8 000 часов ограничен примерно 27B dense-equivalent токенов до overhead, а slots ранжируются по prediction-adjusted information gain с 2 местами для high-uncertainty идей.
• Branch проходит дальше, только если fresh proxy evidence предсказывает target, результат 70B выше +0,7 со скорректированным interval выше нуля и ни один guardrail не падает больше чем на 0,3 пункта.

Я распределю compute по stages и выведу token caps из измеренной стоимости каждой context length, чтобы слабые методы не дошли до 128K.

• Потрачу 4 000 H100-часов на один baseline 7B, packing checks и точное измерение layer-shape FLOPs и MFU при 8K, 32K и 128K.
• Затем 3 метода получат по 2 000 часов на 8K и 3 000 на 32K, ровно 15 000 часов всего, а token caps задаются измеренными valid tokens на H100-час вместо предположения о равном exposure.
• Только методы с gain retrieval минимум 5 пунктов на 32K и regression 8K меньше 1 пункта разделят оставшиеся 21 000 часов на fresh-seed confirmation 128K.
• Покажу views iso-token и iso-FLOP и выберу победителя, только если его cluster-aware 95% interval положителен, а quality на H100-час выше baseline минимум на 20%.

До первого крупного запуска я preregister причинные гипотезы, план анализа и зависящие от compute правила остановки.

• Назову 2 главных результата, точные версии датасетов, настройки decoding, агрегацию и минимальный эффект 1.5 пункта.
• Для 24 сравнений объявлю иерархию или поправку Холма с family-wise alpha 0.05 вместо выборочных нескорректированных побед.
• Зафиксирую 3 seed, критерии исключения, обработку пропавших прогонов и 10% holdout, который не открывается до конца выбора архитектуры.
• Приму утверждение, только если скорректированный тест пройден, эффект выше 1.5 пункта и ни один preregistered safety-срез не потерял больше 1 пункта.

Я задам групповые последовательные проверки заранее, а не буду смотреть дашборд после каждого запуска.

• Проверки пройдут после 10%, 25%, 50%, 75% и 100% compute с alpha-spending границами вроде O'Brien-Fleming.
• Остановка по бесперспективности сработает при conditional power ниже 15% для достижения цели 0.8 пункта, а ранний успех потребует скорректированной верхней границы.
• Размеры моделей и seed поступают сбалансированными блоками, чтобы ранняя проверка не смешивала масштаб с одним удачным seed или data-shard.
• Я остановлю и заявлю успех только на скорректированной границе, закрою ветку при futility ниже 15%, иначе потрачу все 60 000 GPU-часов.

Я опубликую результат как ограниченную проверку заявленного эффекта, а не как доказательство, что идея не работает никогда.

• Выпущу конфиги, seed, хеши данных, lineage чекпоинтов и таблицу расхождений со всеми 3 исходными реализациями.
• Equivalence test проверит, можно ли исключить эффекты вне preregistered диапазона от -0.7 до +0.7, рядом с обычным доверительным интервалом.
• Добавлю sensitivity-анализ на 3 размерах модели и 2 data-mixture, чтобы показать границы переноса нулевого результата.
• Назову отрицательный результат убедительным, только если equivalence пройден и все 6 условий исключают gain больше 0.7 пункта.

Я оценю compute-optimal frontier на proxy и выберу итоговое сочетание параметров и токенов из фиксированного ledger core FLOPs.

• В dense-приближении C около 6ND полный бюджет 2,4e25 FLOPs означает около 57,1T токенов для 70B или 10,0T для 400B, а промежуточные точки считаются как D равно C, делённому на 6N.
• Аппроксимирую loss по прогонам 1B, 3B, 7B и 13B минимум с 4 отношениями токенов к параметрам, списывая FLOPs пилотов в тот же ledger, если 2,4e25 является cap всей программы.
• Точный расчёт по shapes слоёв отдельно добавит attention, embeddings и recompute, а измеренный MFU переведёт выбранные FLOPs в wall-clock, не меняя научный бюджет.
• Потрачу не больше 5% на пилоты и confirmation, затем выберу минимального кандидата внутри интервала predicted loss, если sealed downstream set не показывает gain минимум 1 пункт.

Я проведу отдельные панели iso-token и iso-FLOP, потому что одно сравнение не может одновременно зафиксировать exposure данных и активный compute.

• На 2T токенов терм 6ND для dense равен примерно 6 умножить на 180B и на 2T, то есть 2,16e24 FLOPs, а терм MoE с 50B активных параметров около 6,0e23 до architecture-specific corrections, что различается примерно в 3,6 раза.
• В iso-token панели обе модели увидят один упорядоченный корпус 2T токенов, а разница compute будет явно показана без заявления о matched arms.
• Iso-FLOP panel начинает с dense на 2T токенов и MoE примерно на 7,2T, затем корректирует token cap MoE по точному учёту shared attention, active experts и router, отдельно показывая FLOPs auxiliary loss и recompute.
• Три seed для обеих номинальных panels потребуют около 2,12e25 терма в стиле 6ND, оставив примерно 8,8e24 из cap 3e25 на точные corrections, executed overhead, evaluation и retries; при нехватке reserve token caps уменьшаются.

Я отберу нормализованные формы модели на proxy, а остаток pilot budget потрачу на прямой bridge 120B.

• При измеренном MFU 40% прогон на 10B токенов стоит около 84 H100-часов для 2B и 337 часов для 8B по 6ND; 4 формы, 3 seed и оба размера потребуют суммарно около 5 050 часов.
• Формы будут совпадать по числу параметров и training FLOPs при разных числе слоёв и hidden width, а head dimension, MLP ratio, tokenizer и порядок данных останутся фиксированными вместо невозможного требования одинакового head count.
• Около 5 100 часов отдам одному прогону выбранной формы 120B на 5B токенов и одному matched control, оставив примерно 1 850 часов на profiling, evaluation и retries.
• Выберу форму, только если paired bridge 120B подтвердит направление proxy loss, а измеренные step time, activation memory и TP traffic останутся на предсказанном Pareto frontier.

Я использую screening на proxy и короткие continuation от одного checkpoint 70B, потому что 50 000 часов не финансируют независимый long-context pretraining на всех 3 длинах.

• При измеренном MFU 40% один только dense-терм 70B стоит около 420B FLOPs на токен, поэтому 50 000 H100-часов покрывают максимум около 169B совокупных токенов до дополнительной цены attention на 64K и 256K.
• Потрачу 10 000 часов на screening вариантов RoPE и sparse attention на 7B, зарезервирую 35 000 на matched continuation двух лучших методов от одного checkpoint 70B и оставлю 5 000 на evaluation и retries.
• Для каждой длины покажу и iso-token, и iso-FLOP результат по измеренным layer-shape FLOPs, потому что квадратичный attention делает равные token counts всё менее равными по compute.
• Продвину только метод, который улучшит sealed retrieval и reasoning на 256K минимум на 8 пунктов при потере качества 8K меньше 0,5 пункта и ledger ниже 50 000 часов.

Я проверю 6 fusion arms на proxy 7B и 13B и зарезервирую target-scale compute только для одного или двух confirmation 100B.

• Шесть веток образуют early, intermediate и late fusion, пересечённые с 2 одинаковыми бюджетами параметров projector или cross-attention, на одном frozen multimodal sample stream.
• При измеренном MFU 40% по 2 seed каждой ветки 7B на 5B токенов стоят суммарно около 1 770 H100-часов, а по одному прогону каждой ветки 13B на 10B токенов около 3 290 часов до vision overhead.
• Около 8 450 часов зарезервирую для 2 лучших дизайнов 100B на 5B токенов и 2 свежих seed каждого, оставив примерно 6 500 из 20 000 часов на encoders, evaluation, profiling и failures.
• Fusion design пройдёт дальше, только если multimodal quality вырастет минимум на 2 пункта, text-only потеряет меньше 0,3, а confirmation 100B согласятся без сотен миллиардов токенов на каждую ветку.

Я ограничу routing-исследование до выделения 30 000 часов и вместе проверю специализацию, capacity и network cost.

• При измеренном MFU 40% 3 router с 2 seed на 7B и 5B токенов стоят около 885 H100-часов, а 2 лучших с 2 seed на 30B и 3B токенов около 1 520 часов.
• Pilot cap примерно 4 000 часов также покрывает replay со сдвигом доменов и profiling all-to-all, причём active FLOPs, shared attention, router FLOPs и dropped tokens показываются отдельно.
• Сравню top-8, expert-choice и auxiliary-loss-free routing на одном token stream по load CV, routing entropy, specialization, overflow и traffic отдельных links.
• Выделю 30 000 часов, только если router обгонит dense compute control на 0,7 пункта, удержит overflow ниже 0,1% и повторит load и traffic gates на свежих seed.

Я буду разрешать scale-up по парным candidate и control continuations из одинаковых checkpoints на каждом размере модели.

• Два seed-блока на 70B требуют четыре прогона по 10B токенов, суммарно около 11 800 H100-часов при измеренном MFU 40%.
• Парные deltas 70B должны попасть в prediction interval proxy, снизить loss минимум на 0,4% и улучшить sealed downstream quality минимум на 0,7 пункта.
• Только после этого потрачу около 25 300 часов на четыре прогона 300B по 5B токенов, один candidate и один control для каждого из двух seeds, оставив примерно 7 900 часов на profiling, evaluation и failures.
• Заявлю перенос, только если обе парные deltas 300B останутся положительными, а их среднее составит минимум 60% preregistered extrapolation при matched core FLOPs.

Я оценю quality-compute frontier для sampling, verification и search, а не оптимизирую один decoding-рецепт.

• Сравню best-of-N при N 1, 4, 16 и 64, verifier reranking и tree search в общем бюджете 1e9 токенов.
• Для каждого метода покажу accuracy AIME и GPQA-Diamond против generated tokens, verifier FLOPs, diversity и calibration на 5 seed.
• Зарезервирую 20% токенов для скрытого test-set, чтобы параметры search не настраивались на отчётных вопросах.
• Приму метод, только если он даст минимум 8 пунктов AIME и сохранит хотя бы 80% gain при сокращении token-budget вдвое.

Я начну с TP 8, PP 8, CP 1 и DP 64, а EP 8 будет разделять измерение DP, но не умножать world size.

• World size равен TP умножить на PP, CP и DP, поэтому 8 умножить на 8, 1 и 64 равно 4 096; EP 8 оставляет expert data parallelism 64 делить на 8, то есть 8.
• TP 8 останется внутри каждого NVLink-узла на 8 GPU, PP пройдёт по 8 группам stages, а EP all-to-all использует выбранные по topology группы из 8 соответствующих ranks между узлами.
• Sequence parallelism переиспользует TP group, но context parallelism является отдельным множителем world size; при CP 4 DP уменьшится до 16, а expert-DP до 2 на тех же 4 096 GPU.
• Приму layout только после layerwise byte accounting и пилотов на 256-1 024 GPU, предсказывающих peak ниже 72 GB, communication ниже 25% и scaling efficiency выше 80% на 4 096 GPU.

Я начну с TP 8, PP 2 и DP 128, чтобы каждый collective следовал shards, которые действительно разделяют данные.

• TP 8 занимает один NVLink-узел, PP связывает 2 узла, а произведение 8, 2 и 128 даёт все 2 048 GPU.
• TP collectives остаются внутри NVLink, pipeline sends идут между NIC-local парами ranks, а каждый DP collective объединяет соответствующий TP- и PP-shard по 128 replicas через InfiniBand.
• Я не стану сначала выполнять intra-node DP reduction, потому что 8 локальных TP ranks владеют разными tensor shards; межузловой DP reduce-scatter использует rail-aware rings или trees и измеренный overlap.
• Microbenchmarks по размеру сообщений и поэтапные прогоны на 256, 1 024 и 2 048 GPU должны удержать collectives ниже 20% шага, p99 link tails в пределах 10% медианы и full-scale efficiency выше 82%.

Я сравню полные реализуемые training paths, а не буду считать FSDP, ZeRO-3 и Megatron-LM взаимозаменяемыми features.

• Кандидаты включают composable PyTorch TP 8 с FSDP2 FULL_SHARD по DP 128, DeepSpeed ZeRO-3 с TP 8 там, где поддерживается точный graph, и Megatron Core TP 8, PP 2, DP 64 с distributed optimizer.
• Каждый path использует один token stream, global batch, precision и одинаковые математические kernels, где это возможно, а различия topology и core FLOPs показываются явно.
• Перед пилотами 175B пройдёт one-step parity suite на 22B, затем измеряются peak и transient all-gathers, MFU, overlap collectives, checkpoint resharding и loss на 2 000 шагах.
• Выберу только path с памятью ниже 72 GB на rank, loss в пределах 0,1% reference, MFU выше 45% и restore при изменённом DP size без ручной переделки checkpoint.

Я разделю global persistent bytes, local sharding, transient materialization и activations в одной исполняемой модели памяти.

• Глобально BF16 parameters занимают около 440 GB, BF16 gradients 440 GB, FP32 moments Adam 1,76 TB, а необязательная FP32 master copy 880 GB, всего 3,52 TB при наличии всех 4 категорий.
• При TP 8, PP 4 и DP 64 full state sharding делит persistent state по всем 2 048 ranks, а distributed optimizer с replicated BF16 parameters хранит около 13,75 GB parameters на model shard и шардирует по DP только подходящие состояния.
• Добавлю максимальный per-layer all-gather, reduce-scatter buckets, activations из точных shapes microbatch и sequence, attention workspaces, NCCL buffers, fragmentation и минимум 10% запаса.
• Запуск разрешён, только если инструментированный shape-faithful proxy совпадёт с predicted peaks в пределах 5%, а каждый target rank останется ниже 72 GB на первом optimizer step и checkpoint save.

Я выберу recompute по измеренным GB, сэкономленным на добавленную миллисекунду, и потребую запас для реального распределения длин 32K.

• Текущий peak равен примерно 98 GB, поэтому policy должна сэкономить минимум 26 GB до рабочего target 72 GB, а не только пересечь номинальный лимит 80 GB.
• Сравню selective attention, MLP и full-block non-reentrant checkpoint regions на одинаковых packed batches по saved tensors, extra FLOPs, step time и gradient parity.
• Если microbatch уже равен 1 и selective recompute не достигает 72 GB при цене до 20% времени, добавлю context parallelism или сокращу trained context вместо несуществующего уменьшения batch.
• Оставлю самую дешёвую policy, которая проходит 1 000 шагов ниже 72 GB на каждом rank, сохраняет gradients в допуске и выдерживает p99 sequence lengths без allocator retries.

Я использую измеренную стоимость stages и interleaved schedule, потому что обычный 1F1B не достигает target 8% bubbles при умеренном числе microbatches.

• Реализуемый world layout равен TP 8, PP 16 и DP 8, чьё произведение даёт 1 024 GPU, а 6 физических layers назначаются каждому pipeline stage по времени, а не только по числу.
• При 2 virtual chunks на stage и 128 microbatches идеальный interleaved bubble term примерно равен 15, делённым на 256, то есть 5,9%, оставляя небольшой запас под imbalance.
• Переберу 96-160 microbatches при фиксированных global tokens и включу embeddings, loss, recompute, sends, receives и activation residency в schedule model.
• Выбранный schedule должен измеренно держать bubbles ниже 8% на 2 000 шагах, каждый stage в пределах 3% median time, память ниже 72 GB и throughput минимум на 7% выше plain 1F1B.