At Ordina, our Intelligence engine, internally called Orbi, runs on Multiple Frontier Closed and Open Models. It handles thousands of complex booking conversations, price negotiations, and calendar syncs for service businesses every single day.
But relying exclusively on an external provider introduces a terrifying reality: the single point of failure.
If our upstream provider experiences a degraded state, timeouts, or severe rate-limiting, every single business relying on Ordina to book clients goes down at once. In the service industry, a 30-minute outage isn't just an inconvenience; it is measurable, permanent lost revenue.
We don't accept downtime. So, we decided to engineer a localized, self-hosted fallback system. If the primary APIs trip, Orbi instantly falls back to a model hosted entirely on our own infrastructure.
Here is a deep dive into our localized benchmark, comparing two lightweight titans, Liquid AI’s LFM2.5-2.6B and Google DeepMind’s Gemma 4 E2B, to see which model deserves to be our ultimate safety net.
The Philosophy: Fallbacks are for Narration, Not Mutation
Before selecting a model, we had to define its scope.
Ordina operates on a strict Deterministic Core, Agentic Shell architecture. The LLM is never the source of truth; it is simply a narrator. All booking-critical logic, availability checks, and payment processing live in hard-coded finite state machines.
Because a self-hosted fallback model will naturally be smaller and less capable than our frontier primary model, we severely restricted its permissions. When the chat-engine.ts listener detects a timeout and switches to the fallback, the system goes into "Degraded Mode."
In this mode, the fallback model is only permitted to handle FAQs and narration. It answers questions about location, hours, and policies based on the RAG knowledge base. It is strictly forbidden from executing structured slot extraction, negotiation, or order mutations. If a customer attempts to book a slot while the system is degraded, the fallback politely asks them to hold on or try again shortly.
The Contenders
We needed models that were smart enough to maintain a conversation, but light enough to run via Ollama on a CPU without requiring expensive dedicated GPUs. We selected two cutting-edge, GGUF-quantized models:
1. LFM2.5-2.6B (Liquid AI)
- Architecture: 2.6B parameters, Dense (Hybrid Convolutional + Attention)
- Quantization: 1.7 GB (Q4_K_M)
- Focus: Agentic tool-use and strict instruction following.
- Cold Load Time: ~11 seconds.
2. Gemma 4 E2B (Google DeepMind)
- Architecture: ~2B effective parameters, Edge/Elastic Architecture
- Quantization: 4.3 GB (QAT Q4_0)
- Focus: General multimodal, phone- and edge-optimized.
- Cold Load Time: ~18 seconds.
Note: For these tests, we explicitly disabled reasoning/thinking modes to mirror the low-latency constraints of a production fallback environment.
The Benchmark: Testing for the Real World
We ran the models through 10 realistic, multi-turn scenarios modeled on actual Ordina chat logs. We fed both models the exact same fictional salon data (prices, hours, services).
Crucially, we set "Hallucination Traps." We explicitly asked the models for things not in their context window, like payment links, fake services, or home delivery, to test if they would hallucinate or respect our deterministic boundaries.
1. Speed & Throughput: The Verbosity Trap
In a chat interface, wall-clock time (the time the user spends staring at a typing indicator) is everything.
At first glance, both models had nearly identical raw computational throughput at 14.6 tokens per second. However, the real-world user experience was vastly different:
- LFM2.5-2.6B: Averaged 26.2 seconds per response (Slowest: 49.3s).
- Gemma 4 E2B: Averaged 4.8 seconds per response (Slowest: 15.2s).
Why was Gemma 5.4x faster? The gap wasn't in processor speed; it was in instruction adherence. We strictly prompted both models to reply in "1 to 4 sentences." Gemma 4 E2B listened, averaging a tight, conversational 40 tokens per reply. LFM2.5 completely ignored the constraint, rambling for an average of 342 tokens per reply, forcing the user to wait nearly half a minute to read a massive wall of text.
2. Accuracy & Grounding
Both models performed exceptionally well on the hallucination traps. When asked for a payment link that wasn't in the provided data, both scored a perfect 4/4 in correctly declining the ungrounded request. They both successfully scored 0/10 for hallucinations across the test suite.
3. The "Vibe" Check (Tone & Culture)
Ordina operates globally, but we also have an existing market in Nigeria, so we tested using the familiar tone and culture. Our AI secretary needs to handle local nuances seamlessly.
In one test, we threw a curveball and asked in Nigerian Pidgin: "Una dey open on sunday?"
Without any specific prompting to translate or match the dialect, Gemma 4 E2B smoothly replied: "Glow Studio dey closed on Sundays." It understood the intent, retrieved the grounded business hours, and matched the customer's conversational tone perfectly.
The Verdict & Trade-offs
Gemma 4 E2B is the clear winner and will serve as Ordina's official fallback model.
It delivered a 5.4x faster real-world response time, strictly adhered to our concise length instructions, passed all hallucination traps, and demonstrated impressive unprompted cultural alignment.
The Honest Trade-off: Gemma 4 E2B is heavier on disk (4.3 GB) compared to LFM2.5 (1.7 GB). However, we deploy our localized infrastructure. Even at 4.3 GB, Gemma comfortably fits within the 8 GB RAM ceiling of a persistent container, but worth knowing before scaling further.
By treating our LLMs as interchangeable nodes rather than the entire operating system, we ensure that Ordina remains the most reliable AI secretary on the market.
Because when your business is on the line, "the API is down" is not an acceptable excuse.
