LightSeek Foundation udgiver TokenSpeed som open source under MIT-licens i preview, målrettet agentiske kodningssystemer i IDE’er og CI/CD. Ifølge LightSeek og dækning hos MarkTechPost er målet ydeevne i nærheden af TensorRT-LLM, men med arkitekturvalg skruet til lange forløb og skiftende belastning. Det er vendor-udmeldinger. Vi markerer tydeligt, når noget ikke er uafhængigt verificeret.
Kerneideen er enkel: skub tokens per minut per GPU op, uden at en enkelt brugers tokens per sekund falder under et fast gulv. LightSeek nævner cirka 70 TPS som bund og i nogle scenarier 200+ TPS på én strøm, mens klyngen samlet jagter høj TPM. Tallet er højt, men giver mening i redigeringsnære flows, hvor korte bursts afgør, om man arbejder eller venter.
Hvorfor det rammer nu
Agentiske flows er ikke små chat-slag. Kontekster over 50.000 tokens og mange turer i træk er normale, når en kodeagent tygger sig gennem filer, dependency-træer og testlogs i ét langt stræk. Offentlige benchmarks fanger sjældent den profil, så man kan have flotte grafer og alligevel træge sessions i praksis. Det hul går TokenSpeed direkte efter.
Orkestration gør det sværere. VentureBeat beskriver Sakana AI’s RL Conductor, hvor en mindre model fordeler arbejde mellem flere LLM’er. Når fordelingen skifter over tid, bliver selve inference-motoren en flaskehals. Latency og cache-håndtering afgør, om hele orkesteret holder tempoet.
Fem byggesten i arkitekturen
LightSeek peger på fem søjler: et compiler-understøttet modelleringslag med lokal SPMD, en hurtig scheduler med adskilt kontrol og eksekvering, en typesikret politik for KV-genbrug, et pluggable kernel-lag til heterogene accelerators og en SMG-integration som lav-overhead CPU-entrypoint. De går på velkendte problemer: ejerskab af KV, udnyttelse af Tensor Cores når num_heads varierer, og færre håndrullede collectives. Vi genkender mønstrene fra kundecases, hvor netop KV-ejerskab og lange prefill-faser skabte støj i driften.
Det er ikke ét trick. Det er flere små gearhjul, der skal spille. Godt, men kræver omhu ved opsætning.
Modelleringslaget og lokal SPMD
Lokal SPMD betyder samme program, forskellige datastykker. TokenSpeed lader udviklere annotere I/O ved modulgrænser, hvorefter en let compiler ved modelkonstruktion automatisk indsætter collectives. Gevinsten er mindre boilerplate og mere stabil dataflow. Bagsiden er et compile-step, der skal ind i CI med versioner og artefakter.
Sådan kan en annotering se ud i praksis — rent illustrativt, ikke officiel syntaks:
# pseudo
with ts.module(spmd=True):
x = ts.input(place="gpu:0")
y = block(x).to(place="gpu:1") # compiler indsætter collectives
ts.output(y)
I teams ændrer det rytmen: lidt mere arbejde ved build, færre skrøbelige mønstre ved runtime. Jeg blev faktisk i tvivl om, hvor mange annotationer man ender med i en meget stor model, men pointen om færre fejl i kollektiv logik er solid.
Scheduler, typesystem og KV-sikkerhed
Scheduler-delen skiller kontrol- og eksekveringsplan. Kontrolplanet i C++ er en endelig tilstandsmaskine, der sammen med typesystemet håndhæver korrekt ressourceforvaltning ved compile time. Herunder ejerskab og tilstand for KV-cache samt overlap i timing. Eksekveringen ligger i Python for at holde udviklingshastigheden oppe.
Hvorfor betyder det noget: KV-fejl er en klassiker i lang-kontekst systemer. Når korrekthed kodes ind i typer og FSM, fanges problemer tidligere, før en enkelt racing-session vælter flere workers. Det er forskellen på en rolig nat og en Slack-tråd, der eksploderer kl. 02.17.
Kernel-lag og heterogene accelerators
Kernels behandles som moduler med offentligt API, registry og plug-in-model. Målet er portabilitet og mulighed for flere acceleratortyper. LightSeek fremhæver en hurtig MLA-kernel til NVIDIA Blackwell med grouping af q_seqlen og num_heads for bedre udnyttelse af Tensor Cores samt en fintunet softmax i prefill. De skriver også, at TokenSpeed MLA er taget i brug i vLLM. Det er vendor-rapporteret; vi har ikke set uafhængige end-to-end målinger.
Hvis plug-in-tilgangen holder, kan teams med fx AMD eller specialiserede accelerators koble på. Men uden offentlig, detaljeret dokumentation af kernel-API og liste over targets må man regne med integrationsarbejde og ekstra test.
SMG og CPU-entrypoint
LightSeek omtaler en SMG-integration som et lav-overhead CPU-entrypoint, beskrevet som PyTorch-native. Offentlig specifikation er uklar. Vi kan derfor ikke vurdere, hvor tæt integrationen er, eller hvad API’et ligner. Indtil der er docs, bør teams selv måle CPU→GPU handoff-latency — ellers kan kernelgevinster forsvinde i køen foran GPU’en.
TPM og TPS i praksis
TPM per GPU er kapacitet. TPS per bruger er oplevet hastighed. LightSeek sigter mod høj TPM med en TPS-bund omkring 70 (nogle gange 200+). Det kræver andre batching-valg end klassisk “størst mulig batch”. Korte bursts skal prioriteres i mikroplanen, og lange prefill-sekvenser udfylder hullerne. Tænk moderne webserver, bare med tokens.
Konsekvensen for platformteams: jagt stabil minimumsoplevelse før maksimal batchstørrelse, især når konteksterne er lange og varierende.
Drift og arkitektur i virkeligheden
Hvis TokenSpeed leverer som beskrevet, bør DevOps- og ML-platformteams fokusere på tre ting: batching, KV-politik og observability. Mål TPS per session, TPM per GPU, KV-hitrate og eviction-events. Vi har set hos en kunde med 60.000+ tokens i lange redigeringssessions, at en justering af KV-pinning sænkede timeouts markant. Grafen faldt, og Slack-kanalen blev stille.
Arkitektonisk skal compile-step ind i CI med versionsstyrede modelbuilds, reproducerbare artefakter og en skarp rollback-plan, hvis nye typeregler knækker throughput. Kører I hybrid, kan det give mening at splitte efter sekvenslængde: korte interaktioner på billigere GPU’er tæt på brugeren, lange prefill-kørsler på højtydende instanser. Ikke smukt, men effektivt. For ikke-NVIDIA-miljøer: planlæg tid til kernel-adaptere, CI-tests og profileringsscripts, før I åbner for trafik.
Tradeoffs og begrænsninger
Antagelserne er tydelige: lokal SPMD og compile-step kræver disciplin. Plug-in-kernels forudsætter et API/ABI, som teams skal lære, og ydeevne uden for NVIDIA er uafklaret. Preview-status betyder, at stabilitet under lange, fejlbehæftede kørsler ikke er dokumenteret offentligt. LightSeek taler om TensorRT-LLM-niveau som mål, men der findes endnu ikke uafhængige benchmarks mod TensorRT-LLM, Triton og kommercielle motorer i agentiske scenarier. Test det, før I kalder det produktklart i stor skala.
Kompatibilitet er også åben: hvordan spiller TokenSpeed sammen med eksisterende Triton-servers, ONNX-rør eller jeres egne routere. Forvent integrationsarbejde — især hvis heterogene accelerators skal med.
Kort POC-plan uden pynt
Vil I prøve det af, så gør det målbart fra dag ét:
- Hardware og workload: Vælg 1–2 kendte GPU-typer. Genskab agentiske sessions med 50–80K tokens og 20–40 ture, med både bursts og lange prefill-faser.
- Build og drift: Frys modelversioner, automatiser compile-step i CI, gem artefakter og hold en kendt engine i skygge som fallback.
- Telemetri: Mål TPS per session som førsteprioritet, derefter TPM per GPU, KV-hitrate/evictions, p50/p95/p99 token-latency og CPU→GPU handoff.
- Stabilitet og omkostning: Kør 12–24 timers soak med inducerede fejl. Sammenlign cost per 1.000 tokens før/efter på samme workload.
Hvis tallene er grønne, kan man route 5–10 procent trafik og øge gradvist. Ikke omvendt.
Cases og sammenhæng
Claude Code, Codex og Cursor er gode repræsentanter for agentiske redigeringsscenarier med eksploderende kontekst og langlivede sessions. Når værktøjet læser hele repos, genererer patches og gennemgår testfejl i flere omgange, bliver inference ikke bare et lag, men det lag, der afgør, om udviklere venter eller arbejder. I orkestrerede setups som hos Sakana, hvor en mindre model fordeler opgaver mellem større LLM’er, stiger variansen i query-mix yderligere og presser scheduler og KV-politik.
Kildekritik og hvad der mangler
Fakta om lancering, licens, preview-status og arkitektursøjler stammer fra LightSeek/MarkTechPost og LightSeeks egen udmelding. Der mangler uafhængige end-to-end benchmarks. En fair test vil køre identiske agentiske workloads med 50–80K tokens, blande bursts og lange prefill-faser, og måle TPS/TPM, p95-latency, KV-hitrate og cost per 1.000 tokens mod TensorRT-LLM, Triton og én kommerciel engine. Vi afventer også offentlig dokumentation for SMG samt kernel plug-in API og liste over understøttede accelerators.
Vores vurdering
Ideerne giver mening. Compiler-støttet SPMD, typesikret KV-håndtering og et modulært kernel-lag rammer reelle smertepunkter. Hvis målet om høj TPM med en stabil TPS-bund holder i praksis, kan teams betjene flere samtidige udvikler-agenter på færre GPU’er uden træg brugeroplevelse. Det er drift, ikke pynt.
Vi er fortsat skeptiske på to ting: plug-in-historien uden dokumenteret bred hardwarestøtte og preview uden soak-data. Begge kan løses, men kræver tid, målinger og en CI/rollback-strategi, der kan bære fejl. Vi ville starte med en POC og lade skyggetrafik bevise sagen, før kritiske flows flyttes.
Hvad gør man nu
Start småt og målbart. Sæt TPS per session som første røde lampe. Byg et realistisk agentisk workload. Kør TokenSpeed side om side med jeres nuværende engine. Lad tallene — ikke slides — afgøre næste skridt.
Kilder: LightSeek via MarkTechPost og LightSeek’s egen side for TokenSpeed. Orkestrationskontekst fra VentureBeat.
