Skip to main content

Skotergy: latency-first LLM inference with single-GPU closure and request-level multi-GPU routing.

Project description

Skotergy — Latency-First LLM Inference Engine

Single-device decode closure · Request-level multi-GPU routing · Triton-accelerated kernels · Model-agnostic packaging


Abstract

Skotergy is an inference engine engineered to minimize end-to-end latency without sacrificing scale-out throughput. A request executes entirely on a single device across prefill and decode—KV cache, logits, and fused ops are colocated—so step-internal collectives are removed from the critical path. Throughput scales by dispatching independent requests to per-device replicas (request-level multi-GPU), which preserves the single-request latency envelope. Kernel patches in Triton fuse normalization and strictly enforce device-resident, contiguous tensors. The system ships without model weights and remains agnostic to the user’s model distribution and tooling.


Measured Outcomes (same host · same model · same dtype)

Scenario Metric Baseline (CUDA/Transformers) Skotergy Delta
Single GPU · Llama-3.1-8B-Instruct (bf16) p50 latency 6093.2 ms 4689.4 ms −23.04%
p95 latency 11218.1 ms 8580.4 ms −23.51%
Two GPUs · request-level parallel 16 × 64 new tokens TOTAL ≈ 3.02–3.12 s
Aggregate throughput ≈ 330–340 tok/s
Errors 0 0

Interpretation: single-device closure lowers median and tail; routing across replicas lifts tokens/s while keeping single-request latency single-GPU-like.


System Architecture

Decode Closure (single device)

• Prefill and token-by-token decode remain on one accelerator; KV cache is persistent and local.
• The engine avoids per-step cross-device collectives (e.g., attention/MLP all-reduce), eliminating synchronization spikes and allocator churn.
• Generation enforces use_cache=True; attention is explicit with left-padding and a guaranteed pad_token_id to stabilize shapes.
• Model loading prefers the modern dtype keyword and automatically falls back to torch_dtype on older stacks.
• Embeddings are resized only when a pad token must be introduced, maintaining tokenizer-model consistency.

Request-Level Multi-GPU Routing

• One replica per visible device; each replica holds its own queue and inflight cap.
• Length-aware dispatch chooses the replica whose recent average prompt length is closest to the incoming request, reducing over-padding and graph churn.
• An optional micro-batch window consolidates arrivals into denser launches; default is disabled to keep p50 tight.
• Per-replica concurrency defaults to 1 to avoid stream contention that inflates tail latency.

Triton Kernel Patches (CUDA path)

• Fused RMSNorm implemented in Triton; launches require contiguous, device-resident pointers and reject CPU tensors at dispatch.
• Grid/block sizing derives from hidden dimension to avoid under- or over-occupancy; mixed precision is explicit at the API boundary.
• Patches auto-disable on non-CUDA backends; framework ops are used as safe fallbacks with identical semantics.

Stability & Determinism Choices

• TF32 is enabled for residual FP32 matmuls to free headroom without observable decode-path accuracy loss in typical use.
• cuDNN autotune is disabled to keep latency stable under variable shapes.
• Float32 matmul precision is pinned to “high” to avoid unintentional regression on some builds.


Why It Beats the Baseline

• Eliminates step-internal communication: the token loop does not cross devices, so there are no per-step collectives; queues, caches, and fused ops remain local, shrinking p50 and calming p95.
• Scales by isolation, not synchronization: independent replicas absorb concurrency, so aggregate tokens/s rise while single-request latency stays bounded by one device.
• Makes shapes predictable: left-padding, explicit masks, and optional length-bucket warmup cut graph thrash and allocator noise.
• Protects the kernel boundary: Triton launches operate only on well-formed, contiguous, device pointers; dtype transitions are explicit, preventing silent slow paths.


Compatibility Model

• Accelerators: CUDA first-class; MPS/XPU/CPU supported with graceful feature fallbacks.
• Models: decoder-style causal LMs compatible with the framework stack; weights are never bundled.
• Ecosystem: PyTorch is user-supplied to match drivers/runtimes; version constraints are intentionally minimal to maximize interoperability with external tooling.


Public Interface Surface

CLI Entrypoints

skote.runtime.generate:main — single-device, latency-first text generation.
skote.runtime.router:main — multi-device request router with length-aware policy.
skote.eval.runner:main — optional benchmark harness used to obtain the measurements above.

Python Signatures (illustrative)

def generate(local_dir: str, prompt: str, *, max_new_tokens: int, greedy: bool) -> str: ...
class Router:
    def __init__(self, local_dir: str, devices: list[str] | None = None,
                 dtype: str | None = None, policy: str | None = None,
                 max_concurrency_per_device: int | None = None): ...
    def submit(self, text: str, *, max_new_tokens: int, greedy: bool) -> str: ...
    def submit_many(self, texts: list[str], *, max_new_tokens: int, greedy: bool) -> list[str]: ...

Guarantees & Scope

• Focused on inference for decoder-style LLMs; not a training framework; no model distribution.
• Performance wins were observed under the reported configuration; results may vary with sequence length, driver/runtime stacks, and kernel availability; users should reproduce on their own systems.
• Router defaults target latency stability; knobs exist to trade a small wait window for higher packing when desired.


Roadmap

• Optional remote service entry (HTTP/gRPC) behind an extras flag, leaving local CLI untouched.
• Opt-in decode tensor parallel with captured communication graphs for scenarios willing to trade per-request latency for device utilization.
• Extended fused kernels (paged KV, attention variants) with strict fallbacks on non-CUDA backends.


License

• Code under Apache-2.0.
• Models and weights remain external; users are responsible for their model licenses and distribution policies.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

skotergy-1.0.1.tar.gz (128.2 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

skotergy-1.0.1-py3-none-any.whl (138.2 kB view details)

Uploaded Python 3

File details

Details for the file skotergy-1.0.1.tar.gz.

File metadata

  • Download URL: skotergy-1.0.1.tar.gz
  • Upload date:
  • Size: 128.2 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.10.11

File hashes

Hashes for skotergy-1.0.1.tar.gz
Algorithm Hash digest
SHA256 49aa935317c4ad2104a537c7d27a689c847f65e883a566ca0729169074740f6c
MD5 81e90e0428954137b19485724723d254
BLAKE2b-256 a7f9e7ebb4af6053cd0de99e221e3569ce2a2b3ac654743bda9b96e9cb335eed

See more details on using hashes here.

File details

Details for the file skotergy-1.0.1-py3-none-any.whl.

File metadata

  • Download URL: skotergy-1.0.1-py3-none-any.whl
  • Upload date:
  • Size: 138.2 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.10.11

File hashes

Hashes for skotergy-1.0.1-py3-none-any.whl
Algorithm Hash digest
SHA256 7b3aad12d973e98f9ebec8b506980fadd70489dca85313595e82b616d039b68a
MD5 3c52488260af715ceab42d75a68a26f4
BLAKE2b-256 52ff6249d1c2fce6c4e3cee67f7698c9200c7acae6f00726da3f42b34086927b

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page