llama.cpp خام اگر بیشترین tokens/second و کنترل کامل میخواهید؛ Ollama اگر نصب یکدستوری و یک سرور API میخواهید که از جعبه بیرون آمده کار کند. Ollama یک موتور رقیب نیست — یک سرویس Go است که llama.cpp را بهعنوان بکاند inference در خود بستهبندی کرده، مدیریت مدل اضافه کرده (ollama pull llama3.1) و روی پورت 11434 یک REST API سرو میکند. پس سؤال واقعی این نیست که «کدام موتور سریعتر است» بلکه این است که «چه مقدار کنترل روی پیچومهرههای آن موتور میخواهید». چون Ollama پیشفرضهای محافظهکارانه عرضه میکند (کوانتیزاسیون Q4_K_M، context محتاطانه، و تا مدتی اخیر بدون flash attention)، همان سختافزار میتواند اعداد محسوساً متفاوتی بدهد. در ادامه: اینکه واقعاً چه فرق دارد، شکاف سرعت از کجا میآید، اجرای همان مدل در هر دو، و یک جدول تصمیم.
تفاوت llama.cpp و Ollama چیست؟
llama.cpp خودِ موتور inference است: یک پروژه C/C++ تکقطعهای از Georgi Gerganov سازنده GGUF که مدلهای کوانتیزهشده را روی CPU، GPU یا ترکیبی از هر دو اجرا میکند. در اختیارتان میگذارد llama-cli را برای promptهای تکضربی و llama-server — یک سرور HTTP سازگار با OpenAI — بهعلاوه هر فلگ تنظیمی که موتور پشتیبانی میکند: offload لایهها به GPU، کوانتیزاسیون KV cache، speculative decoding، samplerهای سفارشی.
Ollama یک محصول لایهبندیشده روی همان موتور است. llama.cpp را fork و vendor میکند و بعد در اینها میپیچد:
- یک رجیستری مدل (
ollama pull،ollama list) با شکستن خودکار وزنهای GGUF، - سیستم Modelfile (یک مشخصات شبیه Dockerfile برای قالبهای prompt و پارامترها)،
- یک daemon پسزمینه که مدلها را در VRAM گرم نگه میدارد و REST API خودش را عرضه میکند،
- تشخیص خودکار سختافزار با پیشفرضهای امن.
پیامد عملی: با Ollama شما مدلها را مدیریت میکنید؛ با llama.cpp شما inference را. اگر تا حالا خواسته باشید فرمت کوانتیزاسیون را عوض کنید، KV cache را کوانتیزه کنید، context را از پیشفرض بالاتر ببرید یا لایههای مشخصی را به GPU ثابت کنید، آن خاک llama.cpp است. Ollama بیشتر این پیچها را — عامدانه — پنهان میکند.
| llama.cpp | Ollama | |
|---|---|---|
| چیست | موتور inference (C/C++) | سرویسی که llama.cpp را میپیچد |
| نصب | بیلد از سورس یا بسته | نصبکننده یکخطی، باینری تکفایلی |
| اجرای مدل | llama-cli -m model.gguf + فلگها | ollama run llama3.1 |
| API | سازگار با OpenAI (llama-server) | REST خودش + endpoint سازگار با OpenAI |
| مدیریت مدل | فایلهای GGUF را خودتان میگیرید | رجیستری: pull/list/rm |
| پیشفرضها | همهچیز را خودتان انتخاب میکنید | امن: Q4_K_M، context محتاطانه |
| بهروزرسانی موتور | روز اول (upstream) | عقبتر از releaseهای upstream |
| عمق تنظیم | کامل (کوانت KV، decode گمانهزن، samplerها) | عبور محدود |
| مناسب برای | کار روی کارایی، سرورها، دستگاههای لبه | شروع کار، لپتاپ توسعه |
آیا llama.cpp سریعتر از Ollama است؟
روی همان فایل GGUF، همان کوانتیزاسیون، همان context و همان نسخه llama.cpp — نه، در نویز هم میمانند، چون Ollama خودش همان llama.cpp است که ریاضیات را انجام میدهد. هر بنچمارک «Ollama 30 درصد کندتر است» که میبینید، در واقع مقایسه پیشفرضهاست. شکاف از سه جا میآید:
- انتخاب کوانتیزاسیون. رجیستری Ollama بهطور پیشفرض Q4_K_M میدهد. همان مدل را با Q5_K_M یا Q6_K از llama.cpp اجرا کنید و با سرعی مشابه، کیفیت بهتری به ازای هر token میگیرید — یا برای سرعت خام، Q4_0/IQ4 را انتخاب کنید.
- flash attention و کوانتیزاسیون KV cache. ترکیب
--flash-attnبا-ctk q8_0 -ctv q8_0حجم KV cache را بهشدت کم میکند؛ در contextهای طولانی tokens/second را بالا میبرد و اجازه میدهد contextهای بزرگتر در همان VRAM جا شوند. Ollama فقط بخشی از این را بیرون میدهد. - عقبماندگی نسخه. llama.cpp هفتهای بهینهسازیهای کرنل فرود میآورد؛ Ollama طبق تقویم خودش upstream را merge میکند. یک بیلد تازه llama.cpp میتواند روی همان دستگاه، محسوساً سریعتر از باینری Ollama چندماهه باشد — تا وقتی Ollama برسد.
دستور بنچمارک سریع، مستقل از موتور — سرعت ارزیابی prompt و تولید را گزارش میدهد:
./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1 آن را روی فایل مدل خود Ollama (~/.ollama/models/blobs/... با تغییر نام به .gguf) اجرا کنید و معمولاً دقیقاً اعداد Ollama را بازتولید میکنید — و بعد با افزودن -ctk q8_0 در context با 16 هزار توکن از آنها جلو میزنید.
چگونه همان مدل را در هر دو اجرا کنیم؟
هر دو GGUF مصرف میکنند. حداقلِ سرتاسر برای هر کدام:
# --- Ollama path: install, pull, serve ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b # downloads Q4_K_M, loads into VRAM, opens a chat
# its API, OpenAI-compatible style:
curl -s http://localhost:11434/v1/chat/completions -d '{
"model": "llama3.1:8b",
"messages": [{"role": "user", "content": "Say hi in 5 words"}]
}' # --- llama.cpp path: build, download GGUF, serve ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON # or -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j
huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF
Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models
./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
-ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080 llama-server شمای OpenAI Chat Completions را عرضه میکند، پس همان curl قبلی روی http://localhost:8080/v1/chat/completions بدون تغییر کار میکند. هر ابزاری که برای OpenAI API ساخته شده — اسکریپتها، ویرایشگرها، پایپلاینهای RAG — میتواند به هرکدام اشاره کند. کار واقعی را فلگها میکنند: -ngl 99 همه لایهها را به GPU میفرستد و --flash-attn با آن جفت -ctk/-ctv یک context با 16 هزار توکن را در کارت 8 گیگابایتی نگه میدارد که پیشفرضهای Ollama قبولش نمیکردند.
برای انتخاب خود فایل GGUF و معنی برچسبهای کوانت، ببینید اجرای مدلهای GGUF بهصورت محلی.
کی Ollama منطقیتر است؟
بیشتر مردم باید با Ollama شروع کنند و این جایزه تسلیبخش نیست:
- میخواهید امشب کار کند. یک دستور، مدل کشیده میشود، API بالا میآید. llama.cpp یعنی انتخاب بکاند (CUDA/Vulkan/HIP/Metal)، بیلد، و گرفتن دستی وزنها.
- با مدلهای زیادی سروکارتان است. رجیستری، تخلیه خودکار و Modelfileها از مدیریت دستی پوشههای فایل GGUF بهترند.
- ماشینتان متوسط است. پیشفرضهای Ollama بهدلیلی محافظهکارانهاند — تقریباً همیشه جا میشوند و اجرا میشوند.
- سطح API پایدار میخواهید. daemon مربوط به Ollama چرخه حیات مدلها را مدیریت میکند تا یک سرویس بلندمدت مجبور نباشد.
llama.cpp خام را وقتی انتخاب کنید که بنچمارک میگیرید، در هر مقیاسی سرو میدهید، روی گوشی یا Raspberry Pi اجرا میکنید، در VRAM کم context طولانی لازم دارید یا قابلیتی را میخواهید همان روز merge شدن در upstream. کاربران قدرتمند معمولاً هر دو را دارند: Ollama برای مدلهای روزمره و یک بیلد پینشده llama.cpp برای همان یک کاری که 20 درصد آخر را میخواهد.
اگر مقایسه واقعی شما بین اپهای گرافیکی دسکتاپ است، آن محور دیگری است — ببینید مقایسه Ollama و LM Studio — و برای انتخاب موتور به ازای هر کار، بهترین LLMهای محلی برای کدنویسی سمت مدل را پوشش میدهد.
کدام را استفاده کنید؟
بر اساس کنترل تصمیم بگیرید، نه سرعت. موتورها یکیاند؛ پیشفرضها نه. اگر هدف «اجرا شود و API بدهد» است Ollama را نصب کنید — چند پیچی را از دست میدهید که قرار نبودید بچرخانید. اگر هدف tokens/second، طول context یا کنترل کوانتیزاسیون است llama.cpp را بیلد بزنید — همه پیچها را میگیرید، به بهای مدیریت خودتانِ مدلها. هر طور باشد همان فایلهای GGUF را اجرا میکنید و جابهجایی بعدی هزینهاش یک بعدازظهر است، نه یک بازنویسی.
و وقتی خود مدلها معما هستند — فایلها، کوانتها، VRAM — راهنمای راهاندازی محلی GGUF را بخوانید که Ollama، llama.cpp و vLLM را دستوربهدستور پیش میبرد.
FAQ
آیا Ollama صرفاً یک پوسته دور llama.cpp است؟
از نظر تاریخی بله — موتورش مشتقی از llama.cpp است. کنترل مستقیم را با یک رجیستری مدل، یک API و پیشفرضهای معقول معامله میکنید.
کدام سریعتر است، llama.cpp یا Ollama؟
همان GGUF، همان ریاضیات — با پیشفرضها برابرند. بردهای تنظیم (offload لایهها، context، اندازه batch) سهم llama.cpp است.
میتوانم همان GGUF را در هر دو استفاده کنم؟
بله — یک Modelfile دور همان فایل، عین هم بارگذاری میشود. انتخاب را بر اساس گردشکار بکنید، نه مدل.
— mrsaynothing
— mrsaynothing
یادداشتهای میدانی درباره AI، لینوکس و self-hosting.
این نوشته را در dev.to بحث کنید dev.to ↗
آموزش بعدی با ایمیل
هر نوشته یک ایمیل. درستش کن، برو سراغ بعدی.
این چیست؟حذف فایلهای untracked در Git: راهنمای امن git clean
این نوشتهها را میپسندید؟ این همان کاری است که برای زندگی از آن درمیآورم. استخدامم کنید