Table of Contents
Three reasons to run an LLM locally: privacy (sensitive data stays on your machine), learning (interact with model behavior directly, no API abstraction layer), and cost (hardware is upfront; inference is free after).
The tooling has matured significantly. Ollama is the easiest local LLM runtime to get started with.
TL;DR
- Install Ollama (one command)
- Pull a model (
ollama pull llama3.2) - Chat in terminal (
ollama run llama3.2) - Or use the REST API in your own code
Hardware requirement: 8GB RAM handles 3B/7B quantized models; 16GB+ for smooth 8B–14B. No GPU required—just slower.
Prerequisites
Hardware
| RAM | Models | Speed |
|---|---|---|
| 8 GB | 3B (Llama 3.2 3B, Gemma 2 2B) | Smooth |
| 16 GB | 7B–8B (Llama 3.2 8B, Mistral 7B) | Acceptable |
| 32 GB | 14B (Qwen2.5 14B) | Smooth |
| 64 GB+ | 30B–70B | Model-dependent |
GPU acceleration: Ollama auto-detects NVIDIA CUDA, Apple Metal, and AMD ROCm. With GPU: 10–50x faster. Without: CPU inference works, just slower.
OS
macOS, Linux, Windows (native or WSL2) all supported.
Install Ollama
macOS / Linux:
curl -fsSL https://ollama.com/install.sh | sh
macOS (Homebrew):
brew install ollama
Windows: Download the installer at ollama.com.
Verify:
ollama --version
Pull and Run a Model
# 3B model, ~2GB, good for testing
ollama pull llama3.2
# 8B model, ~5GB, meaningfully better quality
ollama pull llama3.2:8b
# Better multilingual support
ollama pull qwen2.5:7b
Chat interactively:
ollama run llama3.2
# >>> What is Zero-Copy in Kafka?
# Zero-Copy is a technique where...
# >>> /bye
Type /bye or Ctrl+D to exit.
Use the REST API
Ollama runs an OpenAI-compatible REST API at http://localhost:11434:
# Start Ollama (usually auto-starts after install)
ollama serve
cURL:
curl http://localhost:11434/api/generate \
-d '{
"model": "llama3.2",
"prompt": "Explain Zero-Copy in one paragraph",
"stream": false
}'
Python with OpenAI SDK (drop-in replacement):
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # any string—Ollama doesn't validate
)
response = client.chat.completions.create(
model="llama3.2",
messages=[{"role": "user", "content": "Explain Kafka's partition model"}]
)
print(response.choices[0].message.content)
This lets you swap OpenAI API calls for local Ollama by changing only base_url.
Model Selection
| Model | Size | Best For |
|---|---|---|
llama3.2:3b | ~2GB | Quick tests, low-RAM machines |
llama3.2:8b | ~5GB | General purpose, best value |
qwen2.5:7b | ~5GB | Chinese text, multilingual |
mistral:7b | ~4GB | English reasoning, code |
codellama:7b | ~4GB | Code generation |
nomic-embed-text | ~300MB | Text embeddings (RAG) |
ollama list # show downloaded models
ollama rm llama3.2 # delete a model
Complete Example: Local RAG Pipeline
Combine Ollama embeddings and generation for a fully offline RAG setup:
import ollama
import numpy as np
def embed(text: str) -> list[float]:
return ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"]
def cosine_similarity(a, b):
return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
# Local knowledge base
documents = [
"Kafka uses sequential I/O to achieve high throughput",
"Zero-Copy sends data from disk to NIC without CPU involvement",
"Ollama lets you run open-source LLMs locally",
]
doc_embeddings = [embed(doc) for doc in documents]
# Query
query = "How does Kafka achieve performance?"
query_embedding = embed(query)
# Find most relevant document
scores = [cosine_similarity(query_embedding, de) for de in doc_embeddings]
best_doc = documents[np.argmax(scores)]
# Generate answer
response = ollama.generate(
model="llama3.2",
prompt=f"Based on the following, answer the question:\n\nContext: {best_doc}\n\nQuestion: {query}"
)
print(response["response"])
Common Issues
Model is slow?
- Check GPU usage:
ollama psshows the GPU column - Apple Silicon: Metal acceleration is on by default
- NVIDIA: ensure CUDA drivers are installed
Garbled output or poor quality?
- Quantized versions (
q4_0) have lower precision; try a less-quantized variant - For Chinese text,
qwen2.5series has better support
Multi-user Ollama server?
- Ollama handles concurrent requests
- GPU memory is shared; running multiple large models simultaneously may OOM
References
Answers come from this article only. Click any prompt below or open the chat at the bottom right.
🇺🇸 English
Running a large language model on your own laptop used to sound like something only people with a rack of GPUs in their garage could pull off. That's not true anymore. With a tool called Ollama, you can go from nothing installed to chatting with a real model in about three commands. Let me walk you through why you'd want to do this, and exactly how it works.
So — why run a model locally at all, when the cloud APIs are right there? Three reasons. First, privacy. Whatever you type never leaves your machine, which matters a lot when you're feeding it sensitive data. Second, learning. There's no API wrapper sitting between you and the model — you're poking at its raw behavior, which is a fantastic way to actually understand how these things tick. And third, cost. You pay for the hardware once, up front, and after that every single token you generate is free. No metered billing, no surprise invoice at the end of the month.
Here's the whole thing in a nutshell. You install Ollama with one command. You pull down a model with one command. You start chatting in your terminal with one more. And if you want to build something on top of it, there's a REST API waiting for your own code.
Let's talk hardware for a second, because that's the first question everyone asks. The rule of thumb is about your RAM. With 8 gigabytes, you can comfortably run the small 3-billion-parameter models — think Llama 3.2 in its 3B flavor, or Gemma 2 at 2B — and they run smoothly. Bump up to 16 gigs and you're into the 7 and 8 billion range, Mistral 7B, Llama 3.2 8B, at acceptable speeds. With 32 gigs you can smoothly run a 14-billion model like Qwen 2.5. And if you've got 64 gigs or more, you're playing in the 30 to 70 billion territory, though how well that goes depends on the specific model.
Now, do you need a fancy graphics card? No. But it helps enormously. Ollama automatically detects your GPU — NVIDIA CUDA, Apple's Metal on Mac, or AMD's ROCm — and when it finds one, you're looking at anywhere from ten to fifty times faster generation. Without a GPU, it falls back to your CPU. It still works. It's just slower. And on the operating system front, you're covered everywhere: macOS, Linux, and Windows, either natively or through WSL2.
Installing is genuinely a one-liner. On Mac or Linux, you pipe a script from ollama.com straight into your shell. Mac users who live in Homebrew can just brew install it instead. Windows folks download an installer from the site. Then you check that it landed by asking it for its version number.
Once it's installed, you pull a model. If you just want to kick the tires, grab Llama 3.2 — that's the 3B model, about 2 gigabytes, perfect for testing. Want noticeably better answers? Pull the 8B version instead, around 5 gigs, and the jump in quality is real. And if you're working across languages, Qwen 2.5 at 7B has much stronger multilingual support.
To actually talk to it, you run the model by name, and you get a little prompt in your terminal. You type a question — say, "what is zero-copy in Kafka?" — and it just... answers, right there, offline. When you're done, you type slash-bye, or hit Control-D, and you're out.
Here's where it gets interesting for anyone who writes code. Ollama runs a web server on your machine, on port 11434, and it speaks the same language as the OpenAI API. That's the killer feature. It means if you've already got code written against OpenAI, you can point it at your local Ollama by changing exactly one thing — the base URL. You swap in localhost, you hand it any random string as an API key because Ollama doesn't even check it, and everything else stays the same. Your existing OpenAI code now runs entirely on your laptop, for free. You can also hit it with a plain curl request if you just want to fire a prompt and get JSON back.
A quick word on picking a model, because the menu can be overwhelming. If you want the short version: the 3B Llama is your quick-test, low-memory option. The 8B Llama is the best all-around value for general use. Qwen 2.5 shines on Chinese and other languages. Mistral 7B is strong at English reasoning and code. Code Llama is your specialist for generating code. And there's a tiny one called nomic-embed-text, only about 300 megabytes, that doesn't chat at all — its whole job is turning text into embeddings, those numerical fingerprints you need for search and retrieval.
Which brings us to the payoff: building a complete retrieval-augmented generation pipeline that runs fully offline. Here's the shape of it, in plain terms. You start with a small knowledge base — just a handful of facts, say a few sentences about how Kafka gets its speed and what Ollama does. You take each of those sentences and run them through that embedding model to turn them into vectors. Then a question comes in — "how does Kafka achieve performance?" — and you embed that question the same way. Now you compare the question's vector against every document's vector using cosine similarity, which is really just a measure of how close two vectors point in the same direction. The document that scores highest is your most relevant match. Finally, you take that winning document, staple it onto the question as context, and hand the whole package to the chat model to write the answer. Retrieve the right fact, then generate a grounded response — and the entire loop, embedding and generation both, never touches the internet.
Before I wrap up, a few troubleshooting notes worth keeping in your back pocket. If generation feels sluggish, check whether it's actually using your GPU — there's a status command that shows you a GPU column. On Apple Silicon, Metal acceleration is on by default, so you're usually fine. On NVIDIA, make sure your CUDA drivers are actually installed. If the output looks garbled or just low quality, the culprit is often heavy quantization — those compressed q4 versions trade precision for size, so try a less-compressed variant. And if you're running Ollama as a shared server for multiple people, know that it handles concurrent requests fine, but GPU memory is shared — try to run several big models at once and you'll run out of memory.
So let me leave you with the three things that matter. One: local LLMs have crossed the line from "hobbyist project" to genuinely practical, and Ollama is the gentlest on-ramp there is — install, pull, run, done. Two: because it mimics the OpenAI API, migrating existing code is a one-line change, which makes local a low-risk thing to experiment with. And three: with a chat model and a tiny embedding model working together, you can stand up a real, private, fully offline RAG system on hardware you already own. The barrier to running your own AI has basically disappeared — the only thing left is to try it.
🇹🇼 中文
開源模型現在真的很猛。Qwen、Kimi、GLM 這幾個家族,強到什麼程度呢?強到很多情境下,你根本不需要一個託管的 API。你可以直接在自己的筆電上跑,這樣一來,沒有任何人會看到你的對話跟資料——全部留在本機。
好消息是,想在本機跑 LLM,工具生態已經很成熟了。今天我們就來聊五種常見的本地 LLM 執行工具。重點不在教你怎麼裝,而是搞清楚它們各自的定位——你到底該挑哪一個,其實取決於你在做什麼:是快速做原型、想要一個圖形介面、還是要撐起正式的線上流量。
先從最底層的說起,llama.cpp。
這是一個用 C++ 寫的推論引擎,CPU、GPU、Apple silicon 都能跑。它一開始只是有人想在 MacBook 上跑 llama 的一個 side project,結果後來變成幾乎所有其他本地工具賴以建立的地基。
它還帶來一個很重要的東西:本地模型的標準檔案格式,叫 GGUF。一個 GGUF 檔,把權重、tokenizer、還有 metadata 全部打包進單一個檔案,而且支援量化——可以壓到 4-bit 甚至更低。正是這件事,讓那些大型模型能夠塞進消費級的硬體裡。
用法很直接:你從 Hugging Face 抓一個 GGUF 檔,執行 llama.cpp,把模型跟你的 prompt 餵給它,它就吐 token 回來。那什麼時候該用它?當你想要盡可能輕量的 runtime,或者要部署到受限的硬體上——比如邊緣裝置,或是一台沒有獨立 GPU 的筆電。
接下來是 Ollama,你可以把它想成 llama.cpp 外面包的一層 wrapper,目的是讓它變成一個對開發者友善的工具。
它幫你處理掉一堆麻煩事:模型下載、量化選擇、還有啟動本地 server。你只要跑一行 `ollama run` 加模型名稱,它就自動把權重拉下來、把 server 開起來、然後給你一個對話提示字元。上面這些你完全不用手動碰。
而且這個 server 會暴露一個 OpenAI 相容的 API。這點很關鍵——意思是任何 OpenAI 的 client library,你只要改一行 base URL 就能接上去。所以當你想從「挑好一個模型」到「在程式裡直接呼叫它」走最短路徑的時候,Ollama 幾乎就是工程師打造 AI 系統原型時最常見的起點。
第三個是 LM Studio,這個就走圖形介面路線了。
它是一個桌面應用程式,沒有終端機、沒有設定檔。Linux、Mac、Windows 都能裝。你在 app 裡搜尋模型、點下載、然後就開始聊天。底層它一樣是把 llama.cpp 包在一個 UI 之下,但它有個很貼心的地方:在你下載任何東西之前,這個介面會先告訴你硬體需求、量化選項、還有 GPU offload 的設定。如果某個模型對你的機器來說太大,它會事先警告你,不會讓你白下載。
所以 LM Studio 大概是瀏覽跟比較模型最容易的方式。你可以在裡面探索 Hugging Face、看到每一種量化版本、下載個好幾個、然後在它們之間切換而不用重啟任何東西。要搞清楚哪個開源模型最適合你的硬體跟任務,這個特別好用。如果你是一般使用者,只想要一個簡單的介面跟 LLM 聊天,選它就對了。
再來是重量級的——vLLM 跟 SGLang,這兩個是撐正式流量的服務引擎。
vLLM 從一開始的設計目標,就是「同時服務很多使用者」。如果說 Ollama 是拿來快速做原型,那 vLLM 就是為了 production 而生——在一張或多張 GPU 上,跑高吞吐量的推論。
它的速度主要來自兩項技術,值得花點時間講。第一個是 paged attention,一種更省記憶體的 attention 演算法。你想想看,在沒有它的情況下,KV cache 會被存成一整塊連續的記憶體,這其實很浪費。paged attention 做的事,是把 KV cache 切成固定大小的區塊,而這些區塊不需要在 GPU 記憶體裡連續擺放。這樣就騰出了空間,可以支援更大的 batch size,吞吐量跟並行度自然就上去了。
第二個叫 continuous batching,是一種請求排程的技術。沒有它的話,GPU 得等一個 batch 裡每一個請求都跑完,才能開始下一批——很多時間就這樣浪費掉。continuous batching 讓新請求一有空位,就能立刻加入正在跑的 batch。這兩招加起來,GPU 的吞吐量就顯著拉高了。很多公司在背後拿來跑內部聊天機器人、coding assistant、批次流程的,就是 vLLM。
那它有個替代選擇叫 SGLang,來自 Berkeley 的 LMSYS 團隊。它用的技術叫 Radix Attention,靠一個樹狀結構,去跨請求快取那些共享的 prompt 前綴。所以在像 RAG、多輪對話這類「prompt 常常共享一長串共同前綴」的工作負載上,它特別快。像 xAI,還有很多 DeepSeek 的 production 部署,用的就是 SGLang。什麼時候該考慮這兩個?當你已經過了原型階段,需要把本地模型拿去服務真實流量——為公司上線一個聊天機器人、為團隊推一個 coding assistant,或者跑大規模的內部作業。
最後一個,MLX LM,這是 Apple 自己做的,專門在 M 系列晶片的裝置上跑 LLM。它為什麼重要?關鍵在記憶體。
在一般 PC 上,CPU 跟 GPU 有各自獨立的記憶體,模型必須單獨塞進 GPU 那塊記憶體裡,而那塊通常不大。但在 M 系列的 Mac 上,CPU 跟 GPU 共用同一個大記憶體池。舉個例子,一台配 192 GB 記憶體的 Mac Studio,可以載入那些在 PC 上原本得靠好幾張昂貴 GPU 才裝得下的模型。這就是統一記憶體的紅利。
好,五個工具講完,我幫你快速歸納一下怎麼選。想要最輕量的 runtime、或要部署到受限硬體,選 llama.cpp。想從挑模型到寫程式呼叫走最短路徑、做原型,選 Ollama。想要圖形介面、探索跟比較模型,選 LM Studio。要服務真實流量、追求吞吐量,vLLM 或 SGLang。用的是 Apple M 系列、想吃統一記憶體的優勢,那就 MLX LM。
如果要我濃縮成幾個核心重點:第一,這五個工具其實大多站在 llama.cpp 這個地基上,差別在包裝跟定位,不是誰取代誰。第二,選工具的分水嶺,是你在「原型」還是「production」——原型走 Ollama 或 LM Studio,上線就換 vLLM 或 SGLang。第三,硬體決定你的路:受限硬體看 llama.cpp,Apple 晶片別忘了 MLX LM 這條專屬捷徑。搞清楚自己在哪個階段、手上是什麼機器,答案其實就很清楚了。
Tags
Related Articles
RAG's Five Stages: From Pipeline to Reasoning Retrieval, and the Naive RAG on My Own Site
Over the past two years RAG evolved from a 'linear pipeline' to 'loop-based reasoning'. It maps cleanly to five stages: Naive, Advanced, Modular, Graph, Agentic. The real inflection point is control moving from pipeline to agent — a System 1 → System 2 shift. Looking back at engineer-news's own RAG stack, it's stuck at the Naive edge — so this post also lays out what to fix next.
Building a Real RAG: 5 Infra Lessons from InfiniFlow's 2024 Year-in-Review
The previous post zoomed out for a five-stage panorama of RAG. This one zooms in on the five infra lessons any real RAG has to face: document ingestion, contextualized chunking, three-lane hybrid search, tensor reranker, and GraphRAG's semantic gap. Each lesson is checked against engineer-news's current stack, ending with a priority list for a personal site.
J-lens: Anthropic's New Interpretability Tool for Reading Claude's Inner Thoughts via a 'Global Workspace'
Anthropic proposes J-lens, an interpretability tool that captures the 'verbalizable' representations inside a Transformer, and uses it to show that Claude contains a privileged subspace analogous to the neuroscientific 'global workspace' — a small set of vectors that broadcast, drive reasoning, respond to external steering, and even leak signals during deception and evaluation awareness.