Ollama или LM Studio: бржи одговор није и већа пропусност

У тесту на Mac mini M4 Pro са 64 GB обједињене меморије и моделом Qwen3-Coder-30B, Ollama са механизмом llama.cpp дао је први токен за 175 ms, а LM Studio са механизмом MLX за 291 ms; при даљем генерисању LM Studio је достигао 102,2 токена у секунди, а Ollama 69,8. Ollama је, дакле, у тој конфигурацији раније започео одговор, док је LM Studio брже исписивао његов наставак. То су различите предности за кратак разговор и за дугачак излаз.

Ако бирате окружење за локални чет, оба алата имају графичку апликацију на macOS и Windows, док LM Studio нуди и рад са моделима кроз свој интерфејс на Linux рачунарима. За API и аутоматизацију оба имају локални сервер: одлуку зато више мењају оперативни систем, формат модела и начин управљања сервисом него само постојање API-ја. Објављене брзине описују конкретне механизме извршавања, а не трајан поредак два производа.

Када је важнији први токен, а када остатак одговора

Време до првог токена обухвата чекање да одговор почне. Код интерактивног чета оно је упадљиво када су одговори кратки и корисник одмах поставља следеће питање. Брзина генерисања описује темпо после тог почетка; њена предност расте са дужином одговора, на пример када модел исписује више кода или опширан сажетак.

Разлика у почетном чекању у објављеном мерењу износила је 116 ms. Ако се, само као рачунски пример, претпоставе исти улаз и сталне измерене брзине, LM Studio би надокнадио тај заостатак приближно око 27. токена излаза. То није посебно измерен резултат: стварно трајање захтева мењају обрада улаза, дужина разговора, кеш, учитавање модела и начин приказивања токена. Зато бржи почетак сам по себи не значи и ранији завршетак одговора.

Шта се заправо поредило на Mac рачунару

У тесту је коришћен исти рачунар и модел, али не и истоветан механизам извршавања или формат тежина. Ollama је радио преко llama.cpp са квантизацијом Q4_K_M, а LM Studio преко MLX са четворобитном квантизацијом. Измерена разлика зато припада тим конфигурацијама. Не може се једноставно пренети на LM Studio покренут преко llama.cpp, други модел или рачунар са другачијом графичком архитектуром.

Поступак је имао загревање и један измерени пролаз по механизму, уз уклањање модела из меморије између покретања. То омогућава да се види смер разлике у задатим условима, али не показује колико резултат варира између поновљених захтева или при више истовремених корисника. Посебно за тимски API сервис, број токена у секунди из једног генерисања није исто што и капацитет сервера под оптерећењем.

Постоји и временска граница тог поређења: Ollama је после њега развијала сопствени MLX механизам за Apple Silicon. Ollama објава о MLX механизму описује његова накнадна побољшања брзине и кеширања. Бројеви из старијег теста зато не представљају мерење те варијанте Ollama, нити доказ како би два алата прошла са истим новијим механизмом и моделом.

Шта говори потрошња меморије

У истом тесту резидентна меморија процеса, односно RSS, износила је 41,6 GB за Ollama и 21,4 GB за LM Studio. Објашњење наведено уз резултате је да је Ollama у тој конфигурацији унапред резервисала KV кеш за пуно контекстно окно, док га је LM Studio додељивао према потреби. RSS обухвата цео процес, па те вредности нису величине датотека модела и не треба их читати као сталну разлику у сваком разговору.

Код рачунара са мало слободне меморије овај исход може бити важнији од брзине исписивања текста. Модел мора да стане уз сопствене тежине, кеш разговора и остале покренуте програме. Дужи документ или шири контекст мењају потребе за кешом, а друга квантизација мења величину тежина. Ако једна комбинација због тога не може да остане учитана, њена измерена предност у времену до првог токена има малу практичну вредност.

Графички интерфејс и локални API

LM Studio омогућава претрагу и преузимање модела, разговор у графичком интерфејсу и рад са документима. То је погодно када се модели и упити често мењају током ручног испробавања. Али графички чет више није разлог да се Ollama искључи из избора: Ollama апликација за macOS и Windows такође омогућава преузимање модела, разговор и додавање текстуалних датотека или PDF-ова.

За програм који шаље захтеве моделу, Ollama API документација наводи локални сервер на адреси localhost:11434, изворни API и адресе компатибилне са OpenAI и Anthropic клијентима. Иста документација раздваја локално учитане моделе од модела у облаку. Ако подаци морају да се обрађују на сопственом рачунару, битно је који модел позив користи, а не само то што се клијент повезује на локалну адресу.

Упутство за LM Studio сервер описује локални REST API, JavaScript и Python библиотеке и крајње тачке компатибилне са OpenAI и Anthropic клијентима. Сервер се покреће из графичке апликације или командом lms server start. LM Studio је зато употребљив и за скрипте и за апликације у којима корисник никада не отвара прозор за чет; разлика је у начину подешавања и управљања моделима који одговара постојећем раду тима.

Избор по систему и послу

• На Apple Silicon Mac рачунару, за дугачка генерисања има смисла размотрити LM Studio са MLX. За кратак чет, старији тест показује предност Ollama са llama.cpp у почетном кашњењу. Пошто и Ollama сада има MLX механизам, измерене брзине не решавају избор између њихових новијих конфигурација.
• На Windows рачунару оба алата нуде графички чет и локални API. На Linux рачунару LM Studio нуди апликацију и сервер, а Ollama локално покретање и API. Apple Silicon резултате овде не треба користити као прогнозу брзине: на избор више утичу подршка за конкретан модел и расположива меморија.
• За аутоматизацију је практична разлика у томе како тим жели да учитава моделе и одржава сервис, а не у томе да ли API постоји. Када су приватност и локална обрада услов, и модел и сервер треба да буду на предвиђеном рачунару; подршка за облак у једном алату не претвара сваки његов захтев у локалну обраду.

Ако је главни посао кратак разговор, време до почетка одговора заслужује већу тежину. Ако су то дугачки излази, важнији су темпо генерисања и меморија потребна да модел остане учитан. За фирму која шаље много API захтева, одвојено питање је понашање сервера при стварном броју корисника, које објављени тест једног генерисања није мерио.