LocalAI erstattet 9,1 GiB vLLM med en binærfil på 66 MiB, uten å tape fart

LocalAI skriver i en gjennomgang av eget arbeid at en vLLM-installasjon lander på 9,1 GiB som virtualenv, og at avhengighetstreet må løses opp på målmaskinen mot den CUDA-versjonen og den glibc-en som tilfeldigvis står der. Prosjektets egen C++20-port av samme serverarkitektur, vllm.cpp, er ett binærprogram på 66 MiB pluss en GGUF-fil. Den implementerer de samme delene: paged KV-cache, continuous batching, prefix caching, planleggeren og sampleren.

De fleste LocalAI-backender pakker inn llama.cpp eller vLLM, og prosjektet skriver selv at det er riktig standardvalg. 18 av dem er likevel egne porter, skrevet når innpakking ville betydd å sende med en Python-installasjon tyngre enn modellen, en stakk som bare virker på CUDA, eller en modell uten C++-implementasjon i det hele tatt.

Målingene er uvanlig ærlige for et prosjekt som presenterer sitt eget arbeid. På en NVIDIA GB10 med Qwen3.6-27B i NVFP4 ligger vllm.cpp foran på alle seks samtidighetsnivåer, men prosjektet påpeker at fem av seks er uavgjort: støyen mellom kjøringer er 0,5 prosent, og nivåene fra 2 til 32 lander mellom 0,7 og 1,7. Bare enkeltstrøm-tilfellet på 4,5 prosent ligger tydelig utenfor støyen. Utdataene er token for token identiske med vLLM, og topp vertsminne er 24,88 GiB mot 28,18.

Rekkefølgen i arbeidet er poenget for andre som porterer noe. Vektene konverteres til én GGUF først, grafen portes med paritetstest mot referansetensorer komponent for komponent, og optimalisering kommer sist. I depth-anything.cpp ga det 1,31 ganger farten til PyTorch på CPU, ikke fra bedre matmul-kjerner, men fra å cache to posisjonsinnbygginger som ble regnet på nytt ved hver forward og kostet rundt 95 millisekunder i vertssiden.

Hva bør du gjøre?

1. Sett opp paritetstester mot referansetensorer før du optimaliserer noe. depth-anything.cpp har 37 ctest-tilfeller, og en port som er rask og litt feil er verdiløs.
2. Profiler vertssiden før du skriver egne kjerner. Begge de avgjørende gevinstene i disse portene var cachede beregninger, ikke kjernearbeid.
3. Se på topp minnebruk, ikke bare gjennomstrømning, hvis du kjører flere tjenester på samme maskin.