Choose models based on reality, not leaderboards.
80% of enterprise problems are tabular. State-of-the-Art models often fail in production due to latency limits. Stop guessing and calculate the trade-offs.
The Tabular Reality
Despite the hype around deep learning and LLMs, gradient boosted trees (XGBoost, LightGBM, CatBoost) remain the dominant algorithms for structured, tabular data—which makes up the vast majority of enterprise use cases.
Deep Dive: Tabular vs DL| Algorithm | Best For | Setup Time |
|---|---|---|
| XGBoost | General tabular, missing data | Low |
| LightGBM | Large datasets, speed | Low |
| CatBoost | High cardinality categoricals | Low |
| TabNet (DL) | Self-supervised pretraining | High |
Core Trade-offs in Production
1. Cost vs Accuracy
A 1% increase in accuracy might require a 10x increase in compute cost. For many applications, a simpler, cheaper model serving as a baseline provides 95% of the value for 1% of the cost.
Calculate Inference Cost →2. Latency Budgets
Real-time recommendation systems often have latency budgets <100ms. A massive Transformer model is physically incapable of meeting this without specialized hardware (TensorRT, quantization) or caching.
Estimate Latency →3. Memory (VRAM)
Serving LLMs locally requires fitting weights, KV cache, and activations into VRAM. Choosing between a 7B, 13B, or 70B parameter model dictates your infrastructure choices instantly.
VRAM Calculator →LLM Selection Matrix
When selecting a Large Language Model for a task, you must decide between utilizing a managed API (OpenAI, Anthropic) or hosting an open-weights model locally (Llama 3, Mistral). The decision hinges on data privacy, scale, and specific task requirements.
- Local / Open Weights: Zero data egress, predictable fixed costs at high volume, customizable via fine-tuning.
- Managed APIs: Zero ops overhead, access to state-of-the-art reasoning (GPT-4 class), variable costs.
Quick Decision Rule
If requests per minute > 10,000 and data is PII, run local 8B class models quantized to 4-bit. Otherwise, start with an API.
Computer Vision Architectures
The shift from Convolutional Neural Networks (CNNs) to Vision Transformers (ViTs) changed the landscape, but didn't obsolete CNNs for edge devices.
| Architecture Family | Strengths | Weaknesses |
|---|---|---|
| ResNet / EfficientNet | Excellent spatial inductive bias, fast on edge devices, easy to train from scratch. | Struggles with global context compared to attention mechanisms. |
| Vision Transformers (ViT) | Incredible scaling laws, captures global context perfectly, SOTA on massive datasets. | Data hungry, requires massive pretraining, computationally heavy. |
| YOLO (v8/v9/v10) | Unmatched for real-time object detection and segmentation. | Specific to bounding box/segmentation tasks rather than general representation. |
Vision Selector Tool
Input your constraints (FPS requirements, deployment hardware, dataset size) to get a recommended architecture family.
Open Vision SelectorTime Series Forecasting
Baselines beat complexity 90% of the time.
Statistical Baselines
Never train a neural network without first fitting an ARIMA, ETS, or simple Exponential Smoothing model. They are robust, interpretable, and shockingly hard to beat on univariate data.
Read Guide →Tree-based Models
By extracting lag features, rolling windows, and datetime components, models like LightGBM often outperform complex LSTMs while training orders of magnitude faster.
Deep Learning (Transformers/LSTMs)
Reserved for massive, multivariate datasets with complex cross-series dependencies (e.g., retail forecasting across thousands of SKUs). Overkill for simple sales forecasting.
Embedding Models
The backbone of RAG (Retrieval-Augmented Generation) and semantic search.
Open Source (e.g., BGE, Nomic)
Models sitting atop the MTEB leaderboard are often small enough to run locally (e.g., 384 or 768 dimensions), saving massive API costs at scale and keeping proprietary documents internal.
Choosing EmbeddingsCommercial (e.g., OpenAI, Cohere)
High dimensions (1536+), requiring more vector database storage, but offering out-of-the-box multilingual support and zero infrastructure management.
The Model Optimization Hierarchy
Tier 1 (Highest ROI)
Prompt Engineering & Data Formatting
Before touching model weights, ensure your prompt provides exhaustive context, examples (few-shot), and explicit constraints. This solves 70% of performance issues.
Tier 2
Retrieval-Augmented Generation (RAG)
If the model lacks specific knowledge (e.g., internal company policies), use RAG to inject it at runtime rather than fine-tuning.
Tier 3
Parameter-Efficient Fine-Tuning (LoRA)
If the model needs to learn a specific tone, format (e.g., complex JSON), or dialect, use LoRA. It requires vastly less compute than full fine-tuning.
Tier 4 (Lowest ROI / Highest Cost)
Full Fine-Tuning & Pretraining
Only required when injecting entirely new languages, profound domain shifts, or creating foundational capabilities.
RAG Pipeline Failures
Most RAG pipelines fail not because of the LLM, but because of poor retrieval.
- Chunking: Naive fixed-size chunking splits semantic concepts in half.
- Embeddings: Using a general model instead of a domain-specific one.
- Re-ranking: Failing to use a Cross-Encoder to re-rank the top K results before feeding them to the LLM.
The Synthetic Data Shift
The era of human-labeled datasets is ending for many tasks. The new paradigm relies on distillation.
- Teacher Models: Use high-capability models (GPT-4) to generate high-quality outputs.
- Student Models: Fine-tune an open 8B parameter model on those outputs to achieve near-parity for that specific task.
- Economics: This drops inference costs by 95% at scale.
Ready to make a decision?
Stop guessing. Use our calculators to model out your infrastructure requirements.
Evaluation is harder than training
Training an LLM to generate code is easy. Measuring if that generated code is actually good across a corpus of 10,000 queries is brutally hard. If you don't have an automated evaluation harness (LLM-as-a-judge, unit tests, deterministic asserts), you are flying blind.
The Evaluation Pipeline
- Deterministic Checks: Regex matching, JSON schema validation, compile tests. (Cost: Free)
- Embedding Similarity: Cosine distance against a known good answer. Good for facts, bad for reasoning. (Cost: Low)
- LLM-as-a-Judge: Asking GPT-4o to grade a local model's output based on a rubric. Highly effective, but expensive at scale. (Cost: High)
- Human-in-the-loop: The gold standard. Essential for initial baseline setting, but unscalable for CI/CD. (Cost: Extreme)
Model Selection Cheat Sheet
| Use Case | Default Winner | When to switch | Alternative |
|---|---|---|---|
| Tabular Classification | XGBoost | Dataset > 10M rows | LightGBM |
| Time Series (Univariate) | ARIMA / ETS | Strong non-linear lags | LightGBM (with lag features) |
| Image Classification (Edge) | MobileNetV3 | Need bounding boxes | YOLOv8 Nano |
| General Chat / Reasoning | GPT-4o (API) | Strict Data Privacy (PII) | Llama-3-70B (Local/VPC) |
| RAG Embeddings | BGE-M3 (Local) | Zero infrastructure budget | text-embedding-3-small (API) |
Stop building proof of concepts that can't scale.
A Langchain script calling OpenAI in a Jupyter notebook is not a product. It's a demo.
Context Windows
Just because a model claims a 1M token context window doesn't mean you should use it. Needle-in-a-haystack retrieval degrades heavily past 128k tokens, and latency scales linearly. Chunk and embed instead.
Agentic Loops
Giving an LLM a 'while(true)' loop and tool access is a recipe for $50 API bills per query and infinite loops. Constrain generation paths with explicit state machines.
Vector DB Bloat
You probably don't need a distributed Vector Database for 10,000 documents. A simple flat file with Numpy, or a Postgres pgvector extension, is vastly simpler to maintain.
Prompt Injection
If you take user input and place it directly into a prompt with system instructions, you will be hacked. Delimiters help, but structural isolation (API vs Local) is the only true defense for critical actions.
Frequently Asked Questions
Should I train my own foundation model from scratch?
Almost certainly not. Unless you have $10M+ in compute budget and a highly specialized domain (e.g., BloombergGPT for finance, though even that was quickly eclipsed by general models), you should fine-tune an existing open-weights model.
Are smaller models actually getting better?
Yes. The trend is moving from massive parameter counts (100B+) to aggressively trained smaller models (8B-14B) exposed to trillions of high-quality tokens (like Llama 3 8B). These small models match the reasoning capabilities of 70B models from just a year prior.
How do I handle hallucination in production?
You cannot eliminate it, but you can mitigate it. 1. Use strict RAG architectures (grounding). 2. Lower the temperature parameter to 0 for factual extraction. 3. Ask the model to cite its sources from the provided context chunks. 4. Implement deterministic checks on the output.
What hardware do I need to run an 8B parameter LLM?
If quantized to 4-bit (GGUF or AWQ), an 8B model requires roughly 6-8GB of VRAM depending on context length. This means it can run comfortably on a consumer RTX 3060/4060, or a Mac with 16GB of Unified Memory.
Don't guess.
Calculate.
Use the interactive tools below to definitively answer your architecture questions based on hardware math, not marketing hype.
The Quantization Compromise
Dropping a model from 16-bit to 4-bit precision reduces memory by 75%. But what does it cost in accuracy?
Read the Quantization GuidePerplexity Impact
In standard language modeling, moving from FP16 to INT8 causes near-zero degradation. Moving to INT4 causes minor degradation on complex reasoning, and 3-bit causes severe collapse.
Formats Matter
GGUF is best for CPU/Mac inference. AWQ (Activation-aware Weight Quantization) retains better accuracy for GPU inference than older GPTQ methods.