Choosing the Right Ollama Model for AI File Renaming

Pull a random model off Ollama's library page and point it at your Downloads folder, and you'll get names back. That part's easy. Getting names that are actually right, on a folder that has a scanned electric bill next to a 401k statement next to a screenshot of a Slack thread, is a different problem. Every model on that library page was trained differently, sized differently, and is good at reading different things. Some can't read images at all. Some can read images but choke on small dense text. A couple were built specifically for documents and nothing else.

This is a walk through the models people actually reach for when they wire Ollama into a file renamer, what each one is genuinely good at, where each one falls apart, and a method for testing them against your own files instead of taking anyone's word for it, including this article's.

Figure out if you even need vision first

This is the step people skip, and it costs them the most. A model's vision ability only matters if the document you're feeding it doesn't already have a text layer.

A 401k statement or a mortgage statement downloaded straight from the provider's portal is, almost always, a real PDF with selectable text underneath. Open it, hit Cmd/Ctrl+F, and the words highlight. That file doesn't need a vision model at all. The text can be pulled out directly and handed to a plain text model, which will be faster, cheaper on RAM, and won't hallucinate a number it misread off a blurry scan.

A bill you photographed with your phone, a receipt somebody scanned on an office copier, or a fax that got saved as a PDF: none of that has a text layer. The pixels are all there is. That's when you need a model that can actually look at the image and read it, the way OCR software does, except with enough language understanding to also decide "this is an electricity bill from March" rather than just transcribing text.

Mixed folders, which is most people's real folders, need a vision-capable model so you're not running two separate pipelines. That's most of what this article covers.

The models worth knowing about

Qwen2.5-VL: the default pick for documents

Alibaba's Qwen2.5-VL comes in 3B, 7B, 32B, and 72B sizes, and it's the one most people should try first. It was trained with invoices, forms, and structured documents specifically in mind, not just photos of dogs and street signs, and it can point at where on the page it found something rather than just guessing.

Pros:

• Strongest OCR-style reading of invoices, receipts, and forms in this list
• 4 sizes to choose from, so you can trade quality for RAM as needed
• Returns structured output (bounding boxes, key-value pairs), useful if you're building your own naming template

Cons:

• 3B is noticeably weaker on cluttered or low-quality scans, so treat it as the budget option, not the default
• 32B/72B need serious VRAM to run at usable speed

Granite 3.2 Vision: small, and built for exactly this job

IBM's Granite 3.2 Vision is only 2B parameters, about 2.4GB on disk, which makes it the one to try if you're on an older machine or don't want to dedicate much RAM to this. What makes it interesting isn't the size, it's the training: IBM built it specifically for pulling structured content out of tables, charts, infographics, and scanned documents, rather than general photography.

Pros:

• Punches well above its 2B size on statements, tables, and forms
• Tiny footprint, and it runs fine on machines that can't touch a 7B+ model
• Fast, since there's a lot less to load and run per file

Cons:

• Short 16K context window that struggles with very long, multi-page statements
• Noticeably worse than the bigger models on general photos rather than documents

DeepSeek-OCR: when you need the text, not a guess at the text

DeepSeek-OCR is a 3B model built for one job: getting text out of an image accurately, using far fewer tokens than describing the image in prose would take. For a dense mortgage statement with a wall of numbers, that precision matters more than the vision models above, which are built to describe and summarize as much as to transcribe.

Pros:

• The most accurate raw text extraction of anything in this list, especially on dense numeric documents
• Token-efficient, so it's fast even at longer documents

Cons:

• Not an instruction-following chat model, so it won't reliably hand you a filename on its own
• Picky about prompt formatting; a missing newline or punctuation mark can throw the output off
• Best used as step one of two: extract text here, then name the file with a regular model

Gemma 2, 3, and 4: Google's lineup, and which generation actually matters

Gemma shows up across three live generations on Ollama right now, and they're different enough that "just use Gemma" isn't a complete answer.

Gemma 2 (2B, 9B, 27B) is text-only, with no vision at all. It's older and smaller-context than Gemma 3, but it's still a reasonable, lightweight pick for naming files that already have a text layer, if you'd rather not pull Qwen3 or gpt-oss for that.

Gemma 3 (1B, 4B, 12B, 27B) added vision, but only from 4B up. The 1B and 270M variants are text-only despite the family name, which trips people up. From 4B on, it's a solid all-rounder: decent reasoning, 140+ language support, and quantization-aware (QAT) builds that hold quality close to full precision at roughly a third of the memory.

Gemma 3n (e2b, e4b) is a separate edge-optimized line built for phones, tablets, and older laptops. It trades capability for a much smaller footprint, and is worth knowing about if Granite Vision still feels too heavy for your hardware.

Gemma 4 (e2b, e4b, 12b, 26b MoE, 31b dense), released April 2026, is the newest and best-performing generation, built from the same research as Gemini 3. The e2b and e4b sizes add audio input on top of text and image, run in under 1.5GB and roughly 9.6GB respectively, and land noticeably closer to cloud-model quality than Gemma 3 did at similar sizes. The 26B mixture-of-experts build is the one to reach for if you want near-flagship results without a 30B+ dense model's full memory cost.

Pros:

• Gemma 4 is the strongest small-footprint vision model in this whole list right now, and e4b beats plenty of larger, older models
• Widest size range of any family here, from under 2GB to full workstation-scale
• Apache-friendly licensing and 140+ language support carry across every generation

Cons:

• Confusing lineup: four families (gemma2, gemma3, gemma3n, gemma4) with overlapping size names makes it easy to pull the wrong one
• Not a document specialist the way Qwen2.5-VL or Granite Vision are; on messy scans it can land a notch behind them even at similar size
• Gemma 4's bigger dense/MoE sizes are brand new, so community troubleshooting and prompt tips are thinner than for the older, more established models

LLaVA: the old reliable

LLaVA (7B, 13B, 34B) was one of the first vision models to run well on Ollama, built by bolting a CLIP vision encoder onto Vicuna/Llama. It's had years of real-world mileage, which counts for something, and version 1.6 improved its handling of higher-resolution images and OCR-style tasks.

Pros:

• Battle-tested, with years of real usage, prompts, and community fixes to draw on
• Runs fine on modest hardware for its size class

Cons:

• Aging next to Qwen2.5-VL, Granite Vision, and Gemma 4 on dense, small text like a receipt's line items
• 13b variant's 4K context is tight for anything beyond a single-page document

Llama 3.2 Vision: strong captions, so-so on paperwork

Meta's Llama 3.2 Vision (11B, 90B) is built and marketed around visual reasoning, captioning, and general Q&A about images, which it does well. Photos, screenshots, diagrams: it handles those confidently.

Pros:

• Genuinely strong at describing photos, screenshots, and diagrams in natural language
• 128K context window on both sizes

Cons:

• Less convincing on dense scanned paperwork with lots of small text, which just isn't what it was optimized for
• Image+text output is English-only regardless of the source document's language
• Meta's license restricts multimodal use in certain regions, so check it applies to you before relying on it

Qwen3: fast, text-only reasoning

Qwen3 ships as dense models up to 32B plus mixture-of-experts builds (30B-A3B, 235B-A22B), all text-only. No image input, full stop. But remember the first section: a lot of your documents don't need vision anyway.

Pros:

• A thinking-mode toggle you can flip mid-conversation, so simple files skip the extra reasoning overhead
• The 30B-A3B MoE build only activates a fraction of its parameters per token, so it's cheaper to run than its size suggests

Cons:

• No vision at all, so it's useless alone on a scan or photo
• Larger dense sizes need real hardware to stay fast

gpt-oss: OpenAI's open-weight text reasoning

gpt-oss (20B, 120B) is OpenAI's open-weight release, also text-only. For statements and reports that already have a text layer, it's a genuinely better tool than any vision model here, because all of its training depth went into text reasoning rather than being split with an image encoder.

Pros:

• Adjustable reasoning effort (low/medium/high) per request, so you can trade speed for accuracy on the fly
• Apache 2.0 license and solid tool-calling support if you want to script around it

Cons:

• No vision, so pair it with a vision model or an OCR step for anything scanned or photographed
• 16GB minimum for the 20B build is heavy for a task that's "just rename my files"

Side-by-side

RAM figures are rough. Plan for roughly the model's file size on disk plus headroom for context, and expect swapping models in and out of memory to be the slowest part if you're tight on RAM. FilesDesk's own system requirements call out 8GB as the practical floor for local AI, with more (and a GPU, if you have one) making things noticeably faster rather than strictly necessary.

What the filenames actually look like

Specs and RAM numbers only tell you so much. What matters is the actual filename you end up with. These aren't pulled from one live benchmark run; they're representative of each model's typical output style based on what it was trained and built for, so you can see the practical difference before you run your own test. Two example source documents: a phone photo of an electric bill, and a native-text 401k statement PDF.

Source: a phone photo of a Pacific Power electric bill

Account holder Simmons, dated March 14, 2026, amount due $142.87. No text layer, just the photo.

Source: a native-text 401k statement PDF

Fidelity, Q1 2026, participant J. Ortiz. Real text layer underneath, no OCR needed.

The pattern that matters most here: vision models built for documents (Gemma 4, Qwen2.5-VL, Granite Vision) name the electric bill with specific, structured fields, while general-purpose vision models (LLaVA, Llama 3.2 Vision) tend to describe it instead. For the 401k statement, any of the text-only models do fine, because the hard part (extracting the text) was never in question.

Matching the model to what's actually in the folder

One thing worth saying plainly: this is a moving target. Ollama's library adds new models and updates existing ones often enough that specific numbers go stale within months. Treat the table above as a starting shortlist, not gospel, and confirm it against your own hardware and your own files before committing to one.

How to actually benchmark these on your own files

This is the part most comparisons skip, and it's the part that actually decides which model is right for your folder. General benchmarks like MMLU or the LMSYS arena tell you how good a model is at answering trivia or holding a conversation. They tell you almost nothing about whether it can read a slightly crooked photo of a phone bill and produce a name you'd search for six months from now. So build your own test, and it's less work than it sounds like.

1. Pull 30–50 real files, not stock examples. A handful of scanned bills, a couple of statements, a receipt or two, a screenshot. Redact account numbers first if you're worried about what ends up in a spreadsheet, but keep the layout and image quality realistic. A clean sample PDF from the internet won't tell you how a model handles the crooked photo you actually took.
2. Decide what "correct" means before you look at a single result. Write down a rubric: right document type, right date, right vendor or account, name specific enough that it wouldn't collide with a similar file next month. Score against that rubric, not against whether the name "feels" fine.
3. Keep the prompt and template identical across models. If you change the instructions between runs, you're benchmarking the prompt, not the model. Run every candidate through the exact same template and same file set.
4. Test the quantization you'll actually run, not the biggest version that exists. Ollama defaults to a 4-bit quantized pull for most models. If that's what you'll run day to day, benchmark that specific tag. A full-precision cloud version of the same model can perform meaningfully better and will mislead you about what's on your own disk.
5. Run each file more than once. Local models sample by default, so some run-to-run variation is normal, especially at smaller sizes. If a model's output swings wildly between identical runs, that instability matters as much as its average accuracy.
6. Measure the whole pipeline, not just tokens per second. Include model load time, especially if you're switching between models on a machine that can't hold more than one in memory at once. A model that scores marginally higher but reloads every time you switch document types can be slower in practice than a slightly less accurate one that stays resident.
7. Turn it into a number you can compare later. Something as simple as "27 of 30 usable names" per model, tracked in a spreadsheet, beats a gut feeling every time and gives you something concrete to re-check after an Ollama update.
8. Re-run it when anything changes. New Ollama version, new model tag, new hardware: quantization schemes and default templates shift between releases, and a benchmark from six months ago (including the general shape of the one in this article) can quietly go stale.

Setting it up in FilesDesk

Once you've picked a model, using it in FilesDesk is the easy part. Install Ollama, run ollama pull on whichever model you landed on, then in FilesDesk go to Settings → AI Provider, choose "Ollama (local)," and select the model from the list. FilesDesk talks to Ollama over localhost:11434 by default, so nothing about your files leaves the machine. Local model use is included with the $40 lifetime license, and unlike the cloud providers, it doesn't use any credits. Run it as much as you want.

For the full walkthrough, including hardware tiers by Mac chip and how to verify nothing's touching the network, see our guide to offline AI file renaming on Mac.

Frequently asked questions

Do I need a vision model to rename PDFs with Ollama?

Only if the PDF doesn't already have a real text layer. A statement exported straight from a bank or 401k provider is usually just text underneath, so a text-only model like gpt-oss or Qwen3 can read it directly and name it faster than a vision model would. A PDF made by scanning or photographing a paper document has no text layer, so it needs a vision-capable model such as Qwen2.5-VL, Gemma 3, or Granite 3.2 Vision to read it through OCR.

What's the best Ollama model for scanned receipts and bills?

Gemma 4, specifically gemma4:e4b, is the overall pick right now. It's the newest generation in this list and reads scanned and photographed paperwork more accurately than older models near its size, while running in around 9.6GB of RAM. Qwen2.5-VL is the proven alternative, especially the 7B size, because it was trained specifically on invoices, receipts, and structured documents. Granite 3.2 Vision is worth trying too if you're short on RAM. It's only 2B parameters, and IBM built it specifically for tables, forms, and scanned documents rather than general photos.

How much RAM do I need to run a vision model in Ollama?

As a rule of thumb, plan for RAM roughly equal to the model's file size on disk, plus some headroom for context. A 3B vision model like qwen2.5vl:3b needs about 4–6GB free, a 7B model needs 8GB or more, and anything past 13B is more comfortable with a dedicated GPU. FilesDesk's own system requirements call out 8GB RAM as the practical minimum for local AI, and note that a GPU speeds things up but isn't required.

Is DeepSeek-OCR good for naming files?

DeepSeek-OCR is excellent at pulling text out of a scan accurately, which is genuinely useful for dense documents like mortgage statements. But it's an OCR engine, not an instruction-following chat model, so it doesn't reliably decide on a filename by itself. It works best paired with a second step, or as a way to get clean text for a model like Qwen3 or gpt-oss to then summarize into a name.

Why does the same Ollama model give different filenames each time?

Local models sample from a probability distribution by default, so a small amount of run-to-run variation is normal, especially in smaller models. If you're seeing wildly different names for the same document, check your prompt template for ambiguity first, then try a lower temperature setting if your runner exposes one. It's also worth testing the exact quantized version you're running, since a heavily quantized model tends to wobble more than a full-precision one.

Should I trust public LLM leaderboards when picking a model for file renaming?

Not on their own. Benchmarks like MMLU or the LMSYS arena measure general chat quality and reasoning, not whether a model can read a slightly blurry photo of a receipt and produce a filename you'd actually search for. Use leaderboards to shortlist candidates, then run your own small test on your own documents before deciding.