Чтобы получить чистое Markdown-содержимое этой страницы, добавьте .md к этому URL. Полный индекс документации см. на https://docs.nvidia.com/dynamo/llms.txt. Полное содержимое, включая справочник API и примеры SDK, см. на https://docs.nvidia.com/dynamo/llms-full.txt.

Живая симуляция с Mocker

Mocker - это живой симулируемый движок в DynoSim. Он работает как backend Dynamo, регистрирует workers, публикует KV-события и задействует реальный путь frontend/router/planner без необходимости в GPU.

Ядро mocker реализовано на Rust и моделирует планирование, управление памятью и временное поведение production-движков. Оно может использовать полиномиальную модель времени, модель времени на основе профилей или модель времени на базе AIC. AIC предсказывает длительность prefill/decode; Mocker при этом по-прежнему отвечает за scheduler, жизненный цикл KV cache, поведение prefix-cache и модель выполнения запросов.

Обзор

Mocker симулирует:

• Управление KV cache на основе блоков с вытеснением LRU
• Планировщики continuous batching, специфичные для engine для vLLM и SGLang
• Prefix caching с дедупликацией блоков на основе hash
• Chunked prefill для повышения эффективности batching
• Реалистичные временные модели для фаз prefill и decode
• Дезагрегированное обслуживание (разделение prefill/decode)
• Публикацию KV-событий для интеграции с router
• Параллелизм данных (несколько DP ranks на engine)

Примечание: Хотя mocker использует vLLM как основную эталонную реализацию, эти ключевые компоненты - управление KV cache на основе блоков, планировщики continuous batching, LRU evictors и prefix caching - являются фундаментальными для всех современных LLM inference engines, включая SGLang и TensorRT-LLM. Симулируемые здесь архитектурные шаблоны не зависят от конкретного engine и широко применимы во всей inference-экосистеме.

Быстрый старт

Базовое использование

# Launch a single mocker worker
python -m dynamo.mocker --model-path Qwen/Qwen3-0.6B

# Launch with custom KV cache configuration
python -m dynamo.mocker \
    --model-path Qwen/Qwen3-0.6B \
    --num-gpu-blocks-override 8192 \
    --block-size 64 \
    --max-num-seqs 256

# Launch with timing speedup for faster testing
python -m dynamo.mocker \
    --model-path Qwen/Qwen3-0.6B \
    --speedup-ratio 10.0

Дезагрегированное обслуживание

# Launch prefill worker
python -m dynamo.mocker \
    --model-path Qwen/Qwen3-0.6B \
    --disaggregation-mode prefill \
    --bootstrap-ports 50100

# Launch decode worker (in another terminal)
python -m dynamo.mocker \
    --model-path Qwen/Qwen3-0.6B \
    --disaggregation-mode decode

Несколько workers в одном процессе

# Launch 4 mocker workers sharing the same tokio runtime
python -m dynamo.mocker \
    --model-path Qwen/Qwen3-0.6B \
    --num-workers 4

Аргументы CLI

Аргумент	По умолчанию	Описание
--model-path	Обязательный	ID модели HuggingFace или локальный путь к tokenizer
--endpoint	Выводится автоматически	Строка endpoint Dynamo. Значения по умолчанию зависят от namespace, а prefill workers используют другой endpoint по умолчанию, чем aggregated/decode workers
--model-name	Выводится из model-path	Имя модели для ответов API
--num-gpu-blocks-override	16384	Количество блоков KV cache
--block-size	64 (vllm) / зависит от engine	Tokens на блок KV cache. Для sglang, если аргумент опущен, эффективный page/block size по умолчанию равен 1 или --sglang-page-size, если он задан
--max-num-seqs	256	Максимальное количество concurrent sequences
--max-num-batched-tokens	8192	Максимальное количество tokens на batch
--enable-prefix-caching	True	Включить prefix caching
--no-enable-prefix-caching	-	Отключить prefix caching
--enable-chunked-prefill	True	Включить chunked prefill
--no-enable-chunked-prefill	-	Отключить chunked prefill
--preemption-mode	lifo	Политика вытеснения decode при нехватке памяти: lifo (в стиле vLLM v1) или fifo
--speedup-ratio	1.0	Коэффициент ускорения timing
--decode-speedup-ratio	1.0	Множитель ускорения только для decode (например, для Eagle speculation)
--data-parallel-size	1	Количество DP replicas
--startup-time	None	Симулируемая задержка запуска (секунды)
--planner-profile-data	None	Путь либо к .npz-файлу в формате mocker, либо к каталогу результатов profiler
--num-workers	1	Workers на процесс
--reasoning	None	JSON-конфигурация для эмиссии spans reasoning tokens, с start_thinking_token_id, end_thinking_token_id и thinking_ratio
--engine-type	vllm	Тип симуляции engine: vllm или sglang
--sglang-schedule-policy	fifo / fcfs	Политика планирования SGLang: fifo/fcfs (по умолчанию) или lpm (longest prefix match)
--sglang-page-size	1	Размер page в radix-cache SGLang в tokens. Также становится эффективным block size, когда --engine-type sglang, а --block-size опущен
--sglang-max-prefill-tokens	16384	Максимальный бюджет prefill tokens SGLang на batch
--sglang-chunked-prefill-size	8192	Размер chunk для SGLang chunked-prefill
--sglang-clip-max-new-tokens	4096	Ограничение admission budget SGLang для max new tokens
--sglang-schedule-conservativeness	1.0	Коэффициент консервативности schedule SGLang
--aic-perf-model	False	Использовать AIC SDK для предсказания latency вместо интерполированных/полиномиальных моделей. Только opt-in: стандартные пути запуска mocker и DynoSim не используют AIC. Требует установленный aiconfigurator и пригодные AIC systems/perf data для запрошенного кортежа system/backend/version
--aic-system	h200_sxm	Имя AIC system (например, h200_sxm). Используется с --aic-perf-model
--aic-backend-version	Auto	Версия backend engine AIC (например, 0.12.0 для vLLM). Если не задана, используется версия по умолчанию для backend
--aic-tp-size	1	Tensor parallel size для предсказания AIC latency. Влияет только на lookups модели производительности AIC, а не на планирование mocker
--aic-moe-tp-size	None	MoE tensor parallel size для предсказания AIC latency. Требуется некоторыми MoE models
--aic-moe-ep-size	None	MoE expert parallel size для предсказания AIC latency. Требуется некоторыми MoE models
--aic-attention-dp-size	None	Attention data parallel size для предсказания AIC latency. Требуется некоторыми MoE models
--extra-engine-args	None	Путь к JSON-файлу с конфигурацией mocker; переопределяет отдельные CLI arguments
--stagger-delay	-1 (auto)	Задержка между запусками workers (секунды). 0 отключает, -1 включает auto mode
--disaggregation-mode	agg	Режим worker: agg (aggregated), prefill или decode
--durable-kv-events	False	Устаревший режим JetStream KV-event; предпочитайте путь local indexer / event-plane subscriber
--zmq-kv-events-ports	None	Разделенные запятыми ZMQ PUB base ports для публикации KV event, по одному на worker
--zmq-replay-ports	None	Разделенные запятыми ZMQ ROUTER base ports для gap recovery, по одному на worker
--bootstrap-ports	None	Разделенные запятыми rendezvous base ports, по одному на worker в disaggregated mode
--kv-transfer-bandwidth	64.0	Пропускная способность передачи KV cache в GB/s. Установите 0, чтобы отключить
--kv-cache-dtype	auto	KV cache dtype для вычисления bytes-per-token
--kv-bytes-per-token	Вычисляется автоматически	Bytes KV cache на token (переопределяет автоматическое вычисление)
--discovery-backend	Из переменных окружения (etcd)	Discovery backend: kubernetes, etcd, file или mem
--request-plane	Из переменных окружения (tcp)	Request transport: nats, tcp
--event-plane	Из переменных окружения (nats)	Event transport: nats или zmq

Переменные окружения

Переменная	По умолчанию	Описание
DYN_MOCKER_KV_CACHE_TRACE	off	Установите 1 или true, чтобы логировать структурированные трассы выделения и вытеснения KV cache

Примечание: Для локальных scale tests и router benchmarks предпочитайте --num-workers запуску множества отдельных процессов mocker. Все workers разделяют один tokio runtime и thread pool; это легче по ресурсам и ближе к тому, как test harnesses задействуют mocker.

Запуски DynoSim

Mocker также обеспечивает запуски DynoSim через выделенный CLI python -m dynamo.replay, который напрямую предоставляет offline|online, round_robin|kv_router, arrival_speedup_ratio, admission с closed-loop concurrency, генерацию synthetic workload и offline-симуляцию disaggregated prefill/decode:

CLI DynoSim по умолчанию использует --replay-mode offline и --router-mode round_robin. Aggregated runs используют --extra-engine-args. Offline disaggregated runs вместо этого используют --prefill-engine-args плюс --decode-engine-args, вместе с --num-prefill-workers и --num-decode-workers.

python -m dynamo.replay /path/to/mooncake_trace.jsonl \
    --num-workers 4 \
    --replay-mode offline \
    --router-mode kv_router \
    --arrival-speedup-ratio 5 \
    --trace-block-size 512 \
    --extra-engine-args '{"block_size":64}' \
    --router-config '{"router_queue_policy":"fcfs"}' \
    --report-json /tmp/dynosim-report.json

Тот же CLI также поддерживает synthetic workloads без trace file:

python -m dynamo.replay \
    --input-tokens 5000 \
    --output-tokens 500 \
    --request-count 1000 \
    --arrival-interval-ms 1.0 \
    --num-workers 1 \
    --replay-mode offline \
    --replay-concurrency 100 \
    --extra-engine-args '{"block_size":512}' \
    --report-json /tmp/dynosim-report.json

Synthetic workloads также поддерживают shared-prefix и multi-turn tests:

python -m dynamo.replay \
    --input-tokens 5000 \
    --output-tokens 500 \
    --request-count 200 \
    --turns-per-session 3 \
    --shared-prefix-ratio 0.5 \
    --num-prefix-groups 8 \
    --inter-turn-delay-ms 250 \
    --replay-mode offline \
    --replay-concurrency 32 \
    --extra-engine-args '{"block_size":512}' \
    --report-json /tmp/dynosim-report.json

Для trace files DynoSim также понимает multi-turn sessions, когда записи разделяют session_id. Первый turn использует timestamp/created_time; последующие turns могут использовать delay или delay_ms:

{"session_id":"session-a","timestamp":1000,"input_length":2048,"output_length":128,"hash_ids":[1,2,3,4]}
{"session_id":"session-a","delay":250,"input_length":2560,"output_length":128,"hash_ids":[1,2,3,4,5]}

Для запусков по trace file --trace-block-size управляет тем, сколько tokens представляет каждый hash_id в dataset, тогда как engine block_size по-прежнему управляет симулируемым engine и router hashing. Публичные трассы Mooncake/toolagent используют --trace-block-size 512; engine block_size может оставаться 64, чтобы соответствовать конфигурации live runtime.

Автономный CLI DynoSim печатает summary table в стиле AIPerf в stdout и записывает полный report JSON на диск.

Семантика timing:

• trace mode учитывает timestamps первого turn и inter-turn delays
• concurrency mode игнорирует timestamps первого turn, но по-прежнему применяет inter-turn delays
• в concurrency mode TTFT измеряется от фактической dispatch под in-flight cap

Полное описание использования, ограничений и рекомендаций по benchmarking см. в запусках DynoSim.

DynoSim runs поддерживают aggregated-конфигурации engines vllm и sglang. Внутри simulator использует канонический block_size; для sglang sglang.page_size по-прежнему принимается как compatibility alias, если он совпадает с block_size, когда указаны оба значения.

Offline DynoSim runs также поддерживают disaggregated-режим kv_router. В этом режиме:

• --prefill-engine-args должен описывать prefill worker
• --decode-engine-args должен описывать decode worker
• --router-mode должен быть kv_router
• поддерживается только offline mode

Пример:

python -m dynamo.replay \
    --input-tokens 4096 \
    --output-tokens 256 \
    --request-count 100 \
    --replay-mode offline \
    --router-mode kv_router \
    --replay-concurrency 32 \
    --num-prefill-workers 2 \
    --num-decode-workers 6 \
    --prefill-engine-args '{"worker_type":"prefill","block_size":512}' \
    --decode-engine-args '{"worker_type":"decode","block_size":512}' \
    --router-config '{"router_queue_policy":"wspt"}' \
    --report-json /tmp/dynosim-report.json

Настройка моделирования производительности

По умолчанию mocker использует hardcoded polynomial formulas для оценки времени prefill и decode. Для более реалистичных симуляций передайте --planner-profile-data с одним из вариантов:

• .npz-файл в формате mocker, или
• каталог output profiler

Mocker автоматически принимает каталоги результатов в стиле profiler и преобразует их внутри.

Он также принимает более старые каталоги raw-data, содержащие:

• prefill_raw_data.json
• decode_raw_data.json

python -m dynamo.mocker \
    --model-path nvidia/Llama-3.1-8B-Instruct-FP8 \
    --planner-profile-data components/src/dynamo/planner/tests/data/profiling_results/H200_TP1P_TP1D \
    --speedup-ratio 1.0

Модель производительности AIC

Чтобы использовать AIC SDK для предсказания latency:

uv pip install '.[mocker]'

python -m dynamo.mocker \
    --model-path nvidia/Llama-3.1-8B-Instruct-FP8 \
    --engine-type vllm \
    --aic-perf-model \
    --aic-system h200_sxm

Модель AIC автоматически использует --model-path и --engine-type, чтобы выбрать соответствующие performance data. Доступные systems включают h200_sxm, h100_sxm и т. д. (полный список см. в документации AIC SDK).

Важные замечания:

• AIC является opt-in. Если вы не передаете --aic-perf-model, python -m dynamo.mocker не использует AIC.
• У python -m dynamo.replay есть две отдельные поверхности AIC:
  • engine timing AIC через --extra-engine-args / staged engine JSON
  • router-side prefill-load AIC через top-level флаги --aic-* плюс router_prefill_load_model="aic" в --router-config
• Python AIC session bridge теперь разделяется с live KV router path через внутренний модуль dynamo._internal.aic. Поведение Mocker CLI не изменилось; это только устраняет дублирование кода AIC session.
• aiconfigurator должен быть способен загрузить запрошенную performance database для выбранного system/backend/version. Если SDK установлен, но backing systems data отсутствуют или недоступны для чтения, mocker теперь быстро завершается при запуске с понятной ошибкой вместо отказа позже на первом запросе.
• В development environments для этого может потребоваться указать Python на source checkout aiconfigurator с материализованными реальными Git LFS payloads в его каталоге systems/.

Этот путь AIC в mocker отделен от router-side prefill-load estimator. Live router, frontend и DynoSim runs все используют router_prefill_load_model="aic" плюс top-level флаги --aic-* для затухания prompt-load у oldest-prefill. DynoSim по-прежнему отдельно использует AIC через engine-args, когда вы хотите, чтобы сама модель времени mocked worker бралась из AIC.

Для aggregated DynoSim runs engine timing AIC по-прежнему задается через --extra-engine-args:

python -m dynamo.replay /path/to/trace.jsonl \
    --extra-engine-args '{"aic_backend":"vllm","aic_system":"h200_sxm","aic_model_path":"nvidia/Llama-3.1-8B-Instruct-FP8","aic_tp_size":1}'

Для offline disaggregated DynoSim runs вместо этого передайте staged engine configs:

python -m dynamo.replay /path/to/trace.jsonl \
    --replay-mode offline \
    --router-mode kv_router \
    --prefill-engine-args '{"worker_type":"prefill","aic_backend":"vllm","aic_system":"h200_sxm","aic_model_path":"nvidia/Llama-3.1-8B-Instruct-FP8","aic_tp_size":1,"block_size":512}' \
    --decode-engine-args '{"worker_type":"decode","aic_backend":"vllm","aic_system":"h200_sxm","aic_model_path":"nvidia/Llama-3.1-8B-Instruct-FP8","aic_tp_size":1,"block_size":512}' \
    --num-prefill-workers 2 \
    --num-decode-workers 6

Поле aic_backend включает AIC perf model и должно совпадать с engine_type ("vllm" или "sglang"). Поле aic_model_path является эквивалентом --model-path в dynamo.mocker.

DynoSim router-side AIC prompt-load modeling настраивается отдельно через top-level флаги:

python -m dynamo.replay /path/to/trace.jsonl \
    --replay-mode offline \
    --router-mode kv_router \
    --num-workers 4 \
    --trace-block-size 512 \
    --extra-engine-args '{"block_size":64}' \
    --router-config '{"router_track_prefill_tokens":true,"router_prefill_load_model":"aic"}' \
    --aic-backend vllm \
    --aic-system h200_sxm \
    --aic-model-path nvidia/Llama-3.1-8B-Instruct-FP8 \
    --aic-tp-size 1

Для MoE models, которым требуется AIC MoE parallelism, передайте те же поля на router-side AIC surface. Для Kimi-style TP-only MoE simulation используйте --aic-moe-tp-size, равный --aic-tp-size, --aic-moe-ep-size 1 и --aic-attention-dp-size 1.

Для offline disaggregated DynoSim runs те же top-level флаги --aic-* управляют только prefill-stage router; decode-stage router оставляет prompt tracking отключенным.

Пример конфигурации --reasoning:

python -m dynamo.mocker \
    --model-path Qwen/Qwen3-0.6B \
    --reasoning '{"start_thinking_token_id":123,"end_thinking_token_id":456,"thinking_ratio":0.6}'

Каталог результатов profile должен содержать:

• selected_prefill_interpolation/raw_data.npz
• selected_decode_interpolation/raw_data.npz

Чтобы сгенерировать profile data для собственной модели и hardware, запустите profiler, а затем укажите --planner-profile-data на полученный output directory.

Event Transport и тестирование Router

Путь event по умолчанию использует поток local indexer / event-plane subscriber. Более старый durable KV-events mode все еще доступен через --durable-kv-events, но он устарел и не должен быть предпочтительной настройкой для новых tests.

Для экспериментов с router и indexer, которым нужна нативная пересылка событий в wire-format, mocker также поддерживает путь ZMQ:

• --event-plane zmq
• --zmq-kv-events-ports для per-worker PUB base ports
• --zmq-replay-ports для необязательных ROUTER base ports replay/gap-recovery

Когда это задано, каждый worker привязывается к своему base port плюс dp_rank, поэтому количество разделенных запятыми base ports должно совпадать с --num-workers.

Схема портов дезагрегации

--bootstrap-ports принимает разделенный запятыми список base ports, по одному на worker. В multi-worker mode количество указанных ports должно точно совпадать с --num-workers.

Prefill workers слушают эти ports и публикуют bootstrap endpoint через discovery. Decode workers используют соответствующие ports для rendezvous перед началом decode.

Развертывание в Kubernetes

Mocker можно развернуть через примерные манифесты DynamoGraphDeployment как для aggregated, так и для disaggregated setups:

kubectl apply -f examples/backends/mocker/deploy/agg.yaml
kubectl apply -f examples/backends/mocker/deploy/disagg.yaml

Архитектура

Mocker организован как несколько взаимодействующих компонентов, которые отражают внутреннюю архитектуру production LLM inference engines. Scheduler (варианты в стиле vLLM и SGLang) и KV block manager находятся внутри ядра engine. Multi-engine behavior - симуляция KV transfer/offloading, KV router simulation, planner simulation - добавляется run harness DynoSim поверх нескольких engine cores; component-level diagram и offline internals см. в Запуски DynoSim в разделе lib/mocker/src/replay/offline/.

Планировщик

Теперь у mocker две формы scheduler, а не одна универсальная модель очереди:

• vLLM mocker использует scheduler в upstream-style waiting + running. Каждый request отслеживает computed tokens, scheduler сначала расходует единый token budget по running set, а decode pressure запускает inline preemption running requests.
• SGLang mocker использует cache-aware waiting/running scheduler вокруг radix-style prefix cache. Он batch-ит prefill work с учетом decode-state и обрабатывает pressure в основном через decode retraction, сохраняя cached prefixes.

Оба schedulers симулируют continuous batching, повторное использование prefix, chunked prefill, memory pressure и эмиссию decode tokens, одновременно публикуя metrics о текущем использовании resources.

Когда resources становятся ограниченными, mocker симулирует реальный путь восстановления engine:

• preemption и recompute decode в стиле vLLM
• retraction decode в стиле SGLang плюс обновления cache с сохранением prefix

KV Block Manager

KV block manager mocker теперь построен на kvbm-logical::BlockManager<G1>, том же logical block manager, который использует реальный runtime Dynamo. Mocker оборачивает его в lib/mocker/src/kv_manager/kvbm_backend.rs и транслирует собственный протокол MoveBlock в RAII lifecycle kvbm-logical (allocate → stage → register → drop).

Концептуально blocks по-прежнему находятся в одном из двух pools:

• Active - blocks, которые сейчас удерживает хотя бы одна sequence. Partial (еще заполняемые) blocks удерживаются как MutableBlock<G1>; full blocks удерживаются как clones ImmutableBlock<G1> (длина clone vec - это refcount mocker, по одному на Use).
• Inactive - blocks, на которые больше не ссылается ни одна sequence, но которые сохраняются для повторного использования prefix-cache. Полностью обрабатываются inactive pool в kvbm-logical; mocker никогда не отслеживает их вручную.

Lifecycle основан на RAII: удаление последнего clone ImmutableBlock переводит block из active в inactive (pool reset в kvbm-logical), без явного учета deref/evict на стороне mocker. Когда sequence завершается или preempted, mocker просто удаляет свои handles; kvbm-logical восстанавливает capacity.

stateDiagram-v2
    [*] --> Active : allocate + stage + register
    Active --> Inactive : last handle dropped (RAII)
    Inactive --> Active : match_blocks(PLH) reuse
    Inactive --> Freed : evicted by backend
    Active --> Freed : explicit Removed (Destroy)
    Freed --> [*]

    state Active {
        [*] --> Partial : MutableBlock<G1>
        Partial --> Full : promote (PLH / SequenceHash)
        [*] --> Full : ImmutableBlock<G1> clones
    }

Для эмиссии KV-event отслеживаются три результата Use: ActiveHit (увеличение refcount уже закрепленного block), InactiveHit (реактивация через match_blocks(plh)) и NewStore (новое выделение). Только NewStore генерирует KV event Stored - radix tree router уже знает о двух других и забывает только при явном Removed.

Backends вытеснения

Inactive pool kvbm-logical выбирает жертвы вытеснения через один из трех backends, раскрытых как MockerEvictionBackend в lib/mocker/src/common/protocols.rs:

• Lineage (по умолчанию) - учитывает parent-chain: сначала вытесняет leaf blocks, сохраняя shared prefix chains. Замещает поведение preemption-priority, которое раньше обеспечивал hand-rolled LRUEvictor::push_front.
• Lru - обычный LRU на основе recency.
• MultiLru - 4-tier frequency-aware LRU, построенный на TinyLFU tracker.

Все три дают один и тот же результат "suffix blocks вытесняются раньше shared prefixes", для которого был создан старый evictor; Lineage делает это структурно (через parent chain block), а не через monotonic counters.

Отслеживание Sequence

Каждый active request отслеживается как sequence, управляющая своими token blocks и состоянием generation. По мере генерации tokens sequence отслеживает, какие blocks являются partial (MutableBlock<G1>, все еще заполняются), а какие full (ImmutableBlock<G1>, завершены и hashable для prefix caching). Когда partial block заполняется, он "promoted" до full block с content-based SequenceHash (или схлопывается на существующий registered handle, если PLH уже присутствует), что обеспечивает будущие cache hits для requests с совпадающими prefixes.

Модель производительности

Mocker поддерживает три режима предсказания timing:

Полиномиальная модель (по умолчанию): Использует hardcoded polynomial formulas, приближенно описывающие типичное поведение GPU. Время prefill растет квадратично с количеством tokens, а время decode зависит от общего размера active KV cache.

Интерполированная модель: Загружает реальные profiling data из NPZ-файла с измеренными prefill и decode latencies. Mocker интерполирует между data points, чтобы предсказывать timing для любого input size. Это дает high-fidelity simulation, соответствующую конкретной hardware configuration.

Модель AIC (--aic-perf-model): Использует SDK NVIDIA AI Configurator (AIC) для предсказания latency. AIC предоставляет калиброванные performance models для конкретных комбинаций GPU/model/engine, предсказывая latency prefill и decode как функцию batch size, sequence length и prefix cache hits. Model path автоматически выводится из --model-path, а engine type - из --engine-type. Этот режим является opt-in и требует как SDK aiconfigurator, так и загружаемые systems/perf data для запрошенного кортежа.

Bootstrap Rendezvous (дезагрегированное обслуживание)

Для disaggregated prefill/decode deployments prefill и decode workers координируются через простой rendezvous protocol на основе TCP. Decode worker подключается к bootstrap port prefill worker и ждет, пока фаза prefill завершится и KV cache будет готов. Любая сторона может прийти первой - rendezvous завершается, когда готовы обе.

Симуляция задержки KV Transfer

Mocker симулирует время передачи KV cache между prefill и decode workers. Прежде чем prefill worker выпустит первый (и единственный) token, он засыпает на длительность, рассчитанную на основе:

• kv_bytes_per_token (автоматически вычисляется из model config): num_layers * 2 * num_kv_heads * head_dim * dtype_bytes. dtype_bytes определяется --kv-cache-dtype: когда задано auto (по умолчанию), используется dtype модели из config; когда задано явно (например, fp8), используется указанный dtype. Также можно напрямую переопределить через --kv-bytes-per-token.
• kv_transfer_bandwidth (по умолчанию: 64.0 GB/s, inter-node InfiniBand)
• Время передачи: num_input_tokens * kv_bytes_per_token / bandwidth

Эта задержка внедряется после завершения compute simulation prefill в scheduler, моделируя последовательный поток: prefill computation → KV transfer → decode begins. Установите --kv-transfer-bandwidth 0, чтобы отключить.

Интеграция с Dynamo

Публикация KV-событий

Когда prefix caching включен, mocker публикует события KV cache в distributed runtime. Эти события уведомляют систему, когда blocks сохраняются (новое содержимое закешировано) или удаляются (вытеснены). Это позволяет KV-aware router принимать разумные решения маршрутизации на основе того, у каких workers какие prefixes находятся в cache.

Публикация Metrics

Каждый scheduler публикует metrics о своем текущем состоянии, включая количество active decode blocks на DP rank. Router использует эти metrics для load-aware routing decisions.

Сценарии тестирования

Mocker особенно полезен для:

1. Тестирование Router - проверка KV-aware routing без GPU
2. Тестирование Planner - тестирование SLA-based planners с реалистичным timing
3. Fault Tolerance - тестирование request migration, graceful shutdown
4. Disaggregation - тестирование P/D separation и координации KV transfer
5. Performance Modeling - прототипирование scheduling policies
6. CI/CD - быстрые integration tests без hardware dependencies

Сравнение с реальными engines

Возможность	Реальный engine	Mocker
Требуется GPU	Да	Нет
Block Manager	Paged KV cache	Симулируемые blocks
Scheduler	Continuous batching	Continuous batching
Prefix Caching	Hash-based	Hash-based
Chunked Prefill	Поддерживается	Поддерживается
Preemption	Recompute/swap	Recompute (симулируется)
Timing	Реальное выполнение	На основе модели
KV Events	Нативные	Совместимые
Data Parallelism	Multi-GPU	Симулируется

Следующие шаги

Документ	Описание
Бенчмаркинг развертываний Dynamo	Запустите AIPerf для deployment на базе mocker, чтобы измерить latency, TTFT, throughput и scaling behavior
Пример aggregated-развертывания Mocker	Разверните aggregated DynamoGraphDeployment на базе mocker в Kubernetes
Пример disaggregated-развертывания Mocker	Разверните отдельные prefill и decode mocker workers для disaggregated-serving benchmarks
Пример Mocker для Global Planner	Расширенная multi-pool настройка mocker для экспериментов с planner и global-router

Пробелы в возможностях (WIP)

Более широкую roadmap улучшений mocker см. в #6383.

Следующие возможности пока не поддерживаются mocker:

• Multi-tier memory - нет поддержки offloading KV cache на CPU/disk или onboarding обратно на GPU; возможна будущая интеграция с KVBM
• Multimodal support - сейчас симулируется только обработка text tokens; без симуляции vision encoder или cross-attention
• Native Rust reference counting - работа по использованию нативных Rc/Arc для подсчета ссылок block продолжается, что позволит применять естественные RAII patterns для более простого tracking