Back to Blog
June 21, 2026

SFT in Practice: How Fine-Tuning a Small Language Model Can Beat GPT-5 at Invoice Processing

SFT in Practice: How Fine-Tuning a Small Language Model Can Beat GPT-5 at Invoice Processing

SFT in Practice: How Fine-Tuning a Small Language Model Can Beat GPT-5 at Invoice Processing

When you think "AI for invoice processing," the first thought is probably GPT-4o or GPT-5 via API. Quick to set up, works out of the box. The problem starts when you need to process 20,000 invoices per day, financial data cannot leave company infrastructure, and the API bill keeps growing. At Data Science Summit AI Edition 2026, Kamil Rzechowski from Virtuslab showed there's a better way — backed by concrete numbers directly from the presentation slides.

The Problem: Running LLMs in Production Is Not Just an Accuracy Question

Large Language Models like GPT-5 or Gemini are exceptional for prototyping. They accept arbitrary input formats, handle unfamiliar document types, and require no training data preparation. But in production environments, a three-way tension emerges:

  • Cost — API calls to frontier models are expensive. At thousands of requests per day, costs scale linearly
  • Latency — large models have high Time-to-First-Token; for real-time workflows this is often disqualifying
  • Data privacy — sending invoices with vendor data and transaction amounts to an external API is a compliance risk in any regulated industry

Small Language Models (SLMs) solve these problems, but have lower out-of-the-box accuracy on specialized tasks. That's exactly why Supervised Fine-Tuning (SFT) is needed.

What Rzechowski Showed on the Slides

The presentation focused on a concrete case study: fine-tuning a Vision Language Model (VLM) for the task of extracting key fields from invoice images. The following technical data was confirmed directly from the slides:

Training Setup (from slides)

Fine-tuning was performed using LoRA (Low-Rank Adaptation):

  • LoRA parameters: rank = 4, α = 8
  • Trainable parameters: 4.36M out of 2.13B total — just ~0.20% of the entire model
  • Hardware: NVIDIA L4 GPU (Cloud VM instance)
  • Training time: 3 hours
  • Total compute cost: $8

This is the key insight: LoRA fine-tuning does not require retraining the entire model. Only a fraction of parameters are modified, reducing cost and training time to a minimum.

How This Looks in Practice — An Example with Qwen3-VL

To illustrate this method with concrete numbers, let's look at a similar case study published by Virtuslab on their technical blog. The base model used there was Qwen3-VL-2B-Instruct — a Vision Language Model with ~2.13 billion parameters, consistent with the numbers presented by Rzechowski.

Data Preparation

The training dataset consisted of 1,662 samples — a mix of:

  • Invoice photographs (varied layouts, varied image quality)
  • Receipt scans
  • Digital invoice PDFs in English and French

Sources were two public datasets (Creative Commons 4.0): the Fatura dataset and a labeled restaurant receipt dataset from Zenodo.

Results: Fine-Tuned SLM vs LLM

After fine-tuning, the model achieved comparable or higher accuracy than frontier-class GPT models on this specific invoice data extraction task. Specialization works in its favor: a model trained exclusively on invoices, with a precisely defined output format, simply understands the structure of these documents better than a general-purpose model.

Performance (Throughput)

On an NVIDIA L4 GPU (24GB VRAM), measured throughput at various batch sizes:

Batch sizeThroughput (samples/s)Wall time (128 samples)
10.54237 s
82.4751.9 s
324.1231.1 s
644.3329.6 s

At batch size 64, the model processes over 4 invoices per second on a single L4 card.

Cost Analysis: When Self-Hosting Pays Off

Cost comparison per request:

ModelCost per request
GPT-4o-mini$0.0036
GPT-5.2$0.0025
Self-hosted SLM on L4 (24/7 VM)volume-dependent

Cost parity point: at ~10,320 requests per day, the self-hosted L4 VM reaches cost parity with GPT API. Additional inference optimizations (vLLM, TensorRT-LLM) can increase throughput 4-8x further.

Three Business Dimensions Where SLMs Win

1. Data Safety

Invoices contain vendor data, transaction amounts, account numbers — information sensitive under GDPR and financial regulations. A self-hosted SLM means data never leaves company infrastructure.

2. Long-Term Cost

An API model is a variable cost — it scales linearly with volume. A self-hosted SLM is a fixed cost (infrastructure) plus a one-time fine-tuning cost. In the example above: just $8 for training + VM cost.

3. Speed and Latency

An SLM on a dedicated GPU significantly beats API model latency in production scenarios, especially for batch processing. No network round-trip, no queuing on the provider's side.

Practical Takeaways: When to Deploy SFT

Decision workflow:

Is the workflow well-defined and stable?
├── NO → Use LLM via API (prototyping, changing requirements)
└── YES → Is volume high (>10k requests/day)?
    ├── NO → API may be economically fine
    └── YES → Is data sensitive?
        ├── NO → Calculate cost parity point
        └── YES → SFT + self-hosted SLM is the default choice

Key observation: LoRA allows sharing a single base model across multiple agents — each agent uses a different LoRA adapter tailored to its specific task. One GPU VM serves an entire fleet of specialized document AI agents.

From Prototype to Production

The migration path is straightforward: start with LLM via API, validate the workflow and collect data, then fine-tune an SLM on the collected data and move to self-hosted infrastructure. With a ready dataset — as Rzechowski's presentation shows — you need 3 hours of training time and $8. Total deployment time: roughly one week of ML engineer work.

SFT is not an academic experiment. It's an engineering make-or-buy decision for production back-office automation.

Sources

  1. Kamil Rzechowski, Virtuslab — "SFT: Scaling Small Vision-Language Models for High-Load Invoice Processing", Data Science Summit AI Edition 2026 (presentation slides)
  2. Virtuslab Blog — "SFT: Scaling Small Vision-Language Models" (2026): https://virtuslab.com/blog/ai/sft-scaling-small-vision-language-models/
  3. CogitX — "SLMs vs LLMs" (2026): https://cogitx.ai/blog/slms-vs-llms
  4. CogitX — "Small Language Models (SLMs): Comprehensive Guide 2026" (2026): https://cogitx.ai/blog/small-language-models-slms-comprehensive-guide-2026
  5. IBM Think — "What are Small Language Models?" (2024): https://www.ibm.com/think/topics/small-language-models
  6. Komatsu KPS — "SLM vs LLM: Choosing the Right AI Architecture" (2026): https://home.kps.komatsu/blog/slm-vs-llm-choosing-the-right-ai-architecture
  7. HorizonIQ — "SLM vs LLM: Key Differences and Use Cases" (2025): https://www.horizoniq.com/blog/slm-vs-llm/
  8. Nebius — "What is supervised fine-tuning in LLMs?" (2024): https://nebius.com/blog/posts/fine-tuning/supervised-fine-tuning

Komentarze