Представьте: вы построили кластер из восьми NVIDIA H100, настроили prefill-decode disaggregation, экспертный параллелизм через несколько нод — и GPU простаивают, потому что Python не может быстро enough токенизировать входные промпты. Звучит как абсурд, но это реальность production inference в масштабе. Команда LightSeek Foundation столкнулась с этим при построении Shepherd Model Gateway и обнаружила, что узким местом становится не CUDA-ядро и не пропускная способность памяти GPU, а Global Interpreter Lock в Python-процессе, через который проходит каждый запрос.

В статье на PyTorch Blog команда SMG детально разбирает, почему токенизация и детокенизация в SGLang и vLLM превращаются в bottleneck, как Rust-шлюз решает проблему через полное разделение CPU и GPU workload, и какие конкретные цифры получаются в production-бенчмарках на H100. Результат: до 3.5-кратного роста output throughput на длинных контекстах и 28% снижения p99 TTFT при кэш-ориентированной маршрутизации.

Почему Python GIL становится bottleneck при масштабировании

На первый взгляд токенизация — тривиальная задача. Библиотеки вроде tiktoken или sentencepiece написаны на Rust или C++, работают быстро, и в небольших deployment'ах их производительности хватает с запасом. Но при large-scale prefill-decode disaggregated serving картина меняется кардинально. GPU настолько быстры, что CPU-часть pipeline — вызов токенизатора через Python, сериализация в JSON, десериализация ответа — начинает доминировать в общей задержке.

Проблема архитектурная. SGLang и vLLM используют нативные токенизаторы, но вызывают их из Python. Это означает GIL — Global Interpreter Lock, который позволяет выполнять только один поток Python-кода одновременно. При высоком concurrency это создаёт жёсткий потолок: каждый микросекундный вызов токенизатора блокирует все остальные запросы. GPU стоят простоем, ожидая, пока Python освободит lock и передаст им подготовленные токены.

Команда SMG измерила это в production. На кластерах с expert parallelism и disaggregated serving GPU настолько быстры, что CPU-bound работа — токенизация, детокенизация, парсинг reasoning-выходов, извлечение function calls, MCP-оркестрация, мультимодальная предобработка, управление историей чата, валидация structured output, детекция stop-последовательностей — каждый из этих этапов проходит через Python и добавляет задержку в критический путь.

Архитектура SMG: GPU делает тензорную математику, всё остальное — в Rust

Shepherd Model Gateway построен на одном принципе: GPU должны заниматься только tensor math. Всё остальное — токенизация, routing, протокольная трансляция, tool orchestration, мультимодальная обработка — выносится в отдельный serving layer на Rust. SMG коммуницирует с inference engines через gRPC по минимальному контракту: предобработанные токены на вход, сгенерированные токены на выход. Всё промежуточное — зона ответственности шлюза.

Это принципиально отличается от подхода проектов вроде NVIDIA Dynamo или llm-d, которые оптимизируют engine layer и кластерную оркестрацию. SMG работает на другой границе: между клиентом и GPU. Вместо того чтобы делать engine умнее, команда сделала gateway умнее — перенеся всё, что не требует GPU, в purpose-built Rust layer, который масштабируется независимо, эволюционирует независимо и работает с нулевой GIL-контенцией.

Ключевое архитектурное решение — native Rust gRPC data plane. SMG полностью переписала serving pipeline вокруг gRPC: бинарная сериализация protobuf вместо JSON, HTTP/2 multiplexing вместо HTTP/1.1, и нулевой Python в критическом пути. Inference engine получает предтокенизированный ввод и никогда не касается токенизатора. Детокенизация происходит в streaming pipeline шлюза по мере поступления токенов.

Что именно переехало в шлюз

SMG провела инвентаризацию всего CPU-bound workload, который традиционно соседствует с GPU inference, и перенесла каждый компонент в Rust.

Токенизация работает нативно в Rust с двухуровневым кэшем: L0 exact-match для повторяющихся промптов, L1 prefix-aware на границах специальных токенов. Это означает, что частые запросы вообще не проходят через токенизатор — они извлекаются из кэша за константное время. Для длинных промптов с общим префиксом L1-кэш извлекает уже готовую часть токенов, ускоряя обработку.

Парсинг reasoning и tool calls работает в streaming pipeline. По мере поступления токенов через gRPC SMG извлекает reasoning blocks, function calls и structured output в реальном времени — поддерживаются пятнадцать семейств моделей включая DeepSeek-R1, Qwen3, GLM-4, Kimi, Llama-4, Cohere Command. Нет post-processing шага на стороне engine.

Мультимодальная обработка стала самым амбициозным компонентом. Команда переписала major components image processor'а Hugging Face из Python в Rust — vision preprocessing pipelines, tensor operations, model-specific transformations. Результат: предобработанные тензоры напрямую передаются в engine через gRPC с нулевым Python overhead. Поддерживаются восемь семейств vision-моделей: Kimi K2.5, Llama-4 Vision, LLaVA, Phi-3/4 Vision, Pixtral, Qwen-VL, Qwen2-VL, Qwen3-VL. По заявлению авторов, это industry first.

MCP tool orchestration работает полностью в шлюзе: auth-aware connection pooling, concurrent batch execution, approval workflows, automatic reconnection, четыре транспорта (STDIO, HTTP, SSE, Streamable). Inference engine не знает о существовании MCP. SMG также предоставляет built-in tool routing — любой MCP-сервер превращается в native capabilities (FileSearch, WebSearch, CodeInterpreter) для любой модели. Можно развернуть Llama или Qwen с теми же встроенными инструментами, что и GPT-4.

WASM middleware даёт программируемую расширяемость без форка кодовой базы: custom authentication, compliance logging, PII redaction, cost tracking, compression — всё через WebAssembly-плагины с sandboxed isolation. Построено на Wasmtime с Component Model и async support.

Бенчмарки: цифры из production

Все бенчмарки запускались на NVIDIA H100 через NVIDIA GenAI-Perf в рамках SMG nightly benchmark suite. Тестировались восемь моделей (GPT-OSS-20B, Llama-3.1-8B, Llama-3.3-70B, Llama-3.3-70B-FP8, Llama-4-Maverick, Llama-4-Scout, Qwen2.5-7B, Qwen3-30B-MoE), два runtime (SGLang, vLLM), пять traffic scenarios, девять уровней concurrency от 1 до 256. Всего 1082 сопоставимых точки сравнения gRPC против HTTP.

На concurrency 1 gRPC и HTTP работают примерно одинаково — разница в пределах шума. Но по мере роста нагрузки преимущество gRPC накапливается. На concurrency 256 gRPC даёт примерно 8% больше throughput. Бинарная сериализация и HTTP/2 multiplexing дают compound effect именно там, где это важно — под высокой нагрузкой.

Самый впечатляющий результат — на длинных контекстах. HTTP/JSON сериализация растёт линейно с длиной промпта, а gRPC/protobuf использует компактную бинарную кодировку, которая не платит этот налог. На 7800 input tokens преимущество gRPC достигает 12.2% throughput across all models. Но настоящий прорыв происходит с Llama-3.3-70B-FP8: эта модель настолько быстрая в FP8, что HTTP сериализация становится доминирующим bottleneck. gRPC показывает до 3.5x higher output throughput: 1150 tok/s против 327 tok/s.

На production concurrency 32–256 преимущество gRPC варьируется по архитектуре модели. Llama-3.3-70B-FP8 показывает наибольший прирост: +15.8% E2E p99 latency и +44.6% output throughput. Меньшие dense модели (Llama-3.1-8B, Qwen2.5-7B) дают скромные улучшения. Паттерн очевиден: чем быстрее GPU, тем больше выигрыш от gRPC, потому что CPU overhead становится большей долей общей задержки.

Кэш-ориентированный routing и prefill-decode disaggregation

Помимо gRPC data plane, SMG включает интеллектуальный routing layer с восемью политиками балансировки: cache-aware, round robin, random, power-of-two, consistent hashing, prefix hash, manual sticky sessions и bucket-based. Cache-aware routing был переписан с нуля: вставки ускорились в 10–12 раз (216 000 insertions/sec), память сократилась на 99% (с 1.8 GB до 14 MB на 10 000 cached prefixes).

Event-driven KV cache routing транслирует реальное состояние кэша со всех бэкендов через SubscribeKvEvents RPC с автообучаемыми размерами блоков. Production результаты на восьми репликах Llama: средний TTFT снизился на 23%, p99 TTFT — на 28%. Prefill-decode disaggregation направляет prefill и decode фазы в отдельные пулы worker'ов с независимыми политиками — улучшение TTFT на 20–30% в PD-конфигурациях.

Экосистема и production adoption

SMG поддерживает пять native agentic API: Chat Completions (OpenAI), Responses API (OpenAI), Messages API (Anthropic), Interactions API (Gemini) и Realtime API (WebSocket/WebRTC). Это не translation layers — каждый API является first-class implementation. Messages API сохраняет thinking blocks end-to-end с ThinkingConfig и thinking_delta streaming events. Responses API — единственная open-source реализация для Llama, DeepSeek, Qwen и других open-source моделей.

Протокол smg-grpc-proto опубликован на PyPI и принят upstream в vLLM (PR #36169) и NVIDIA TensorRT-LLM (пять merged PRs). Это означает, что SMG может работать с этими engine'ами без форков или патчей.

В production SMG используется в Google Cloud Platform (multi-tenant AI infrastructure), Oracle Cloud Infrastructure (enterprise GenAI services), Alibaba Cloud (cloud-native AI workloads) и TogetherAI (distributed inference infrastructure). От стартапов до hyperscalers.

Часто задаваемые вопросы

Можно ли использовать SMG с существующим vLLM или SGLang deployment?

Да. SMG работает как drop-in proxy перед существующими inference engines. Поддерживаются SGLang, vLLM, TensorRT-LLM и MLX backends. Установка через pip install smg, конфигурация через CLI или Python SDK. Engine'ы принимают smg-grpc-proto, так что не требуется модификация кода engine'а для базовой интеграции.

Требуется ли Rust-экспертиза для развёртывания SMG?

Нет. SMG распространяется как Python wheel (pip install smg) с предкомпилированными Rust-расширениями. Пользователь взаимодействует с SMG через Python API или OpenAI-compatible REST endpoint. Rust нужен только если вы хотите внести изменения в сам шлюз или написать WASM plugin.

Как SMG сочетается с другими инфраструктурными проектами?

SMG комплементарен NVIDIA Dynamo и llm-d. Dynamo оптимизирует GPU-оркестрацию и hardware integration, llm-d занимается Kubernetes-native scheduling distributed inference. SMG работает на serving layer — между клиентом и GPU. Можно запускать SMG перед vLLM, который управляется llm-d, или перед TensorRT-LLM с Dynamo на уровне GPU-оркестрации. Границы ответственности чёткие: SMG владеет всем между клиентом и GPU, другие проекты — тем, что происходит на и под GPU.

Итог

Shepherd Model Gateway демонстрирует, что при масштабировании LLM inference узким местом может стать не GPU, а Python GIL в токенизации и сериализации. SMG решает это через полное разделение CPU и GPU workload: весь CPU-bound processing — токенизация, routing, tool orchestration, мультимодальная предобработка, chat history — переезжает в Rust-шлюз, а GPU получают минимальный контракт через gRPC. Результат: до 3.5x роста throughput на длинных контекстах, 28% снижение p99 TTFT, и архитектура, которая масштабируется независимо по CPU и GPU. Для команд, которые выходят за пределы небольших deployment'ов и сталкиваются с Python bottleneck в production, SMG предлагает проверенный путь — открытый, production-ready и принятый upstream ведущими inference engines.