How to Make Your Own AI

Understanding the AI Development Spectrum

Creating an artificial intelligence system is entirely achievable today, but the technical requirements, financial investment, and development path vary radically depending on what "making an AI" means for a specific use case. Developing AI no longer requires an advanced doctorate in mathematics or a multi-million-dollar compute cluster unless one is training a frontier foundation model from the ground up. Modern AI development spans three distinct tiers: building on top of pre-trained foundation models, adapting open-weight architectures through fine-tuning, and engineering custom statistical or deep learning models from scratch. A practical guide to building agents How to Build an AI Agent | IBM

┌─────────────────────────────────────────────────────────────────────────┐
│                       The AI Development Spectrum                       │
├──────────────────┬─────────────────────────┬────────────────────────────┤
│ Application Tier │ Fine-Tuning Tier        │ Scratch Training Tier      │
│ (Prompt / RAG /  │ (LoRA / Full Parameter  │ (Custom Architectures /    │
│  Agents)         │  Adaptation)            │  Classical ML / Pre-train) │
├──────────────────┼─────────────────────────┼────────────────────────────┤
│ Low Compute      │ Moderate Compute        │ High/Extreme Compute       │
│ Hours to Days    │ Days to Weeks           │ Weeks to Months            │
│ Off-the-shelf    │ Domain-specific datasets│ Massive raw datasets       │
└──────────────────┴─────────────────────────┴────────────────────────────┘

Selecting the wrong tier is the most common pitfall in artificial intelligence projects. Training a model from scratch when a structured prompt or Retrieval-Augmented Generation (RAG) system would suffice wastes computational resources and developer time. Conversely, relying purely on prompt engineering when an application demands strict deterministic outputs, low latency, or deep proprietary domain logic often leads to unreliable systems. Choosing the right path requires understanding the trade-offs across data, compute, and architectural complexity. A practical guide to building agents Making the machine: the machine learning lifecycle

Phase 1: Problem Formulation and Metric Selection

Every successful AI project starts by defining the concrete operational problem rather than selecting a model. Artificial intelligence algorithms optimize mathematical loss functions, which means qualitative business objectives must be translated into quantifiable targets. Practitioners must first determine the core functional category of the system: classification (categorizing inputs), regression (predicting continuous numerical values), clustering (discovering latent groupings), generation (producing novel text, code, or images), or reinforcement learning (optimizing sequences of actions through rewards). How to Build an AI Agent | IBM ML development phases | Machine Learning

Once categorized, teams must establish offline evaluation metrics and production constraints before writing code. A model that achieves exceptional statistical accuracy is unusable if its inference latency exceeds acceptable boundaries or its memory footprint cannot run on target hardware.

• Statistical Metrics: For classification tasks, accuracy is frequently misleading on imbalanced data; balanced accuracy, precision, recall, and $F_1$ score provide far more reliable assessments. Regression models rely on Mean Squared Error (MSE), Root Mean Squared Error (RMSE), or Mean Absolute Error (MAE). Generative systems are assessed using operational benchmarks like perplexity, automated LLM-as-a-judge rubrics, or deterministic exact-match checks.
• Operational Constraints: Projects must establish hard limits for maximum round-trip latency (e.g., under 200 ms for interactive typing), memory consumption (VRAM/RAM limits), and runtime costs (target cost per 1,000 queries, such as under $0.005).

Phase 2: Data Acquisition, Cleaning, and Engineering

Data quality dictates the performance ceiling of any artificial intelligence model. The maxim "garbage in, garbage out" holds across both classical linear regressions and multi-billion-parameter neural networks. Constructing a training dataset involves sourcing, filtering, formatting, and structural validation. Making the machine: the machine learning lifecycle ML development phases | Machine Learning

Sourcing and Ingestion

Depending on the objective, training data originates from internal application databases, public repositories (such as Hugging Face Datasets, Kaggle, or government registries), web scraping pipelines, or synthetic data generation. When using synthetic data produced by larger models, developers must implement strict rejection sampling to prevent model collapse or iterative degradation caused by hallucinated patterns.

Preprocessing and Normalization

Raw real-world data contains missing values, corrupt encodings, and noise that destabilize gradient optimization. The preprocessing pipeline must address several core challenges:

1. Handling Missing and Corrupted Values: For structured tabular data, missing cells must either be removed (if missing completely at random and sample sizes permit) or imputed using median values, k-nearest neighbors (KNN), or predictive imputation algorithms.
2. Text Normalization and Tokenization: Natural language data must be normalized (stripping invisible control characters, standardizing Unicode encodings) and broken down via tokenizers (such as Byte-Pair Encoding or WordPiece) that map textual sub-words to numerical token IDs.
3. Scaling Numerical Features: Deep neural networks and distance-based algorithms require input variables to operate on comparable scales. Features are standardly rescaled via Z-score standardization ($z = \frac{x - \mu}{\sigma}$) or min-max normalization into ranges like $[0, 1]$ or $[-1, 1]$.

Raw Unstructured Data
         │
         ▼
┌──────────────────────────────┐
│  Deduplication & Filtering   │ (MinHash, exact string match, heuristic filters)
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ Text/Feature Normalization   │ (Unicode fixes, whitespace stripping, imputation)
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ Tokenization / Vectorization │ (BPE tokenizers, dense embeddings, one-hot encodings)
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│  Dataset Partitioning (Splits│ Train (70–80%) / Validation (10–15%) / Test (10–15%)
└──────────────────────────────┘

Dataset Partitioning and Leakage Prevention

To verify that an artificial intelligence model learns generalizable patterns rather than simply memorizing training records, the dataset must be split into three non-overlapping subsets: a training set (used directly by the optimization algorithm to update parameters), a validation set (used during development to tune hyperparameters and detect overfitting), and an untouched test set (evaluated once at the very end to estimate real-world performance). ML development phases | Machine Learning

Critical Warning: Data leakage occurs when information from outside the training dataset contaminates the model during preparation. Standard examples include computing normalization parameters ($\mu, \sigma$) across the whole dataset before splitting, or failing to split longitudinal time-series data chronologically. Any leakage artificially inflates validation metrics while causing catastrophic failures in production.

Phase 3: Model Architecture and Implementation Paths

Once data is formatted, builders choose between three primary implementation tracks: building custom machine learning models, fine-tuning pre-trained networks, or constructing autonomous agent architectures.

Path A: Building Classical Machine Learning from Scratch

For structured, tabular business data (such as predicting real estate values, customer churn, or credit risk), classical algorithms often outperform deep neural networks in compute efficiency, interpretability, and sample complexity.

Using Python's scientific ecosystem (pandas, scikit-learn, xgboost), a standard pipeline vectorizes data, trains an ensemble model (like a Random Forest or Gradient Boosted Decision Tree), and tunes hyperparameters via cross-validation.

import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.metrics import classification_report

# 1. Feature matrix (X) and label vector (y)
X = np.random.randn(5000, 20)
y = (X[:, 0] * 2.0 + X[:, 1] - X[:, 2] > 0).astype(int)

# 2. Strict dataset separation
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.20, random_state=42, stratify=y
)

# 3. Model instantiation and training
model = GradientBoostingClassifier(
    n_estimators=100,
    learning_rate=0.1,
    max_depth=3,
    random_state=42
)
model.fit(X_train, y_train)

# 4. Evaluation on unseen validation holdout
predictions = model.predict(X_test)
print(classification_report(y_test, predictions))

Path B: Fine-Tuning Open-Weight Deep Learning Models

When building specialized language, vision, or multi-modal systems, pre-training a model from scratch is rarely economical. Instead, developers adapt open-weight architectures (such as Meta's Llama, Mistral, or Google's Gemma) using Parameter-Efficient Fine-Tuning (PEFT) techniques like Low-Rank Adaptation (LoRA) or Quantized LoRA (QLoRA). A practical guide to building agents

Rather than recalculating all billions of weights in a network—which requires enterprise-scale multi-GPU clusters—LoRA freezes the primary weights and inserts low-rank decomposition matrices into the attention layers. This reduces trainable parameters by over 99%, allowing a high-performance open model to be adapted on a single consumer GPU with 16GB to 24GB of VRAM.

$\Delta W = B \times A$

Where $W \in \mathbb{R}^{d \times k}$ represents the frozen model weights, $B \in \mathbb{R}^{d \times r}$, and $A \in \mathbb{R}^{r \times k}$, with the rank $r \ll \min(d, k)$.

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer
from datasets import load_dataset

model_id = "mistralai/Mistral-7B-v0.1"

# 1. Load tokenizer and base architecture
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id, 
    load_in_4bit=True, 
    device_map="auto"
)

# 2. Define Parameter-Efficient Adapter Configuration
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)

# 3. Configure training arguments
training_args = TrainingArguments(
    output_dir="./custom_ai_adapter",
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,
    learning_rate=2e-4,
    num_train_epochs=3,
    logging_steps=10,
    fp16=True
)

Path C: Assembling Retrieval-Augmented Generation (RAG) and Agents

If the objective is an AI that synthesizes internal knowledge bases or interacts with external software tools, training weights is often unnecessary. Instead, developers build agentic workflows or RAG pipelines. A practical guide to building agents How to Build an AI Agent | IBM

An agentic architecture consists of:

1. A Core Reasoning Engine: An instruction-tuned LLM capable of function calling.
2. Tools and Integrations: APIs, Python code executors, or web scrapers that the model invokes deterministically when it needs external facts or actions.
3. Memory Systems: Vector databases (such as Qdrant, Milvus, or pgvector) storing chunked document embeddings to give the model access to private data without retraining.
4. Planning and Reflection Loops: Prompt scaffolds (like ReAct or Plan-and-Solve) that instruct the model to review intermediate results, assess failures, and iterate before returning a final output. A practical guide to building agents How to Build an AI Agent | IBM

Phase 4: Validation, Alignment, and Guardrails

Once an AI model produces outputs, it must undergo systematic validation before release. Standard automated loss tracking is insufficient for diagnosing systematic edge-case failures, cognitive biases, or adversarial vulnerabilities. A practical guide to building agents ML development phases | Machine Learning

                      Validation Workflow
                               │
       ┌───────────────────────┴───────────────────────┐
       ▼                                               ▼
┌─────────────────────────────┐         ┌─────────────────────────────┐
│    Quantitative Testing     │         │    Qualitative Alignment    │
├─────────────────────────────┤         ├─────────────────────────────┤
│ • Benchmark regression runs │         │ • Adversarial red-teaming   │
│ • Loss / Perplexity checks  │         │ • Prompt injection probes   │
│ • Precision / Recall curves │         │ • Toxicity / Bias filtering │
│ • Latency / Memory profiling│         │ • Hallucination audits      │
└─────────────────────────────┘         └─────────────────────────────┘

Addressing Overfitting and Underfitting

For custom models, the training curves reveal core architectural issues:

• Underfitting: The model cannot achieve low loss on the training set. This indicates insufficient model capacity, overly aggressive regularization, or uninformative features. Solutions include increasing parameters, expanding training epochs, or engineering more expressive inputs.
• Overfitting: The model demonstrates near-zero error on the training split, but validation error spikes upward. The model has memorized sample noise rather than generalizable signals. Mitigations include applying dropout layers, weight decay ($L_1$ or $L_2$ regularization), data augmentation, or early stopping during gradient updates.

Safety Filters and Adversarial Red-Teaming

For generative architectures, validation must test how the model behaves when challenged. Adversarial testing ("red-teaming") attempts to force the model into producing harmful content, hallucinating citations, or revealing system prompts via prompt injection. Production deployments implement guardrail frameworks (such as NeMo Guardrails or Llama Guard) that analyze both the incoming user request and the model's generated response through separate classification checks before presenting the output to the end user. A practical guide to building agents

Phase 5: Deployment, Serving, and Maintenance (MLOps)

Transitioning an artificial intelligence model from an experimental Python notebook into an active software environment requires production engineering known as Machine Learning Operations (MLOps). Models must be converted into fast inference artifacts, exposed via scalable network interfaces, and tracked continuously for quality degradation. What Is Model Deployment?

Model Optimization and Quantization

Running raw, full-precision (FP32) neural network weights in production is memory-inefficient and slow. Optimization techniques reduce latency and hardware costs:

• Quantization: Compresses weight representations from 16-bit floating-point numbers down to 8-bit, 4-bit, or even smaller integer formats (using methods like AWQ, GPTQ, or GGUF). This often halves memory consumption with negligible drops in practical output fidelity.
• Optimized Execution Engines: Runtimes such as ONNX Runtime, TensorRT-LLM, or vLLM apply kernel fusions, PagedAttention, and continuous batching to maximize hardware throughput and handle concurrent queries without running out of memory.

Serving Infrastructure

Depending on privacy requirements, budget, and traffic patterns, teams select between three primary serving patterns:

1. Local and Edge Inference: Running models locally using runtimes like Ollama, llama.cpp, or ONNX on end-user workstations or embedded microcontrollers. This provides complete data sovereignty and zero ongoing cloud inference costs, but remains constrained by local memory and compute speed.
2. Serverless Cloud APIs: Deploying containerized endpoints on platforms like RunPod, Modal, AWS SageMaker, or Google Cloud Vertex AI that scale to zero instances when idle. This pattern is ideal for sporadic traffic profiles. What Is Model Deployment?
3. Dedicated GPU Clusters: Reserving dedicated virtual machines (such as cloud instances with NVIDIA H100 or A10G GPUs) behind a load balancer running high-performance serving software (vLLM or Triton Inference Server). This provides predictable latencies for enterprise-scale workloads. What Is Model Deployment?

   Client App / User
           │
           ▼
┌──────────────────────┐
│  API Gateway / WAF   │ (Rate limiting, auth, basic input sanitization)
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ Guardrail Evaluator  │ (Prompt injection check, policy enforcement)
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ Inference Server     │ (vLLM / Triton running AWQ/FP8 quantized model)
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ Observability Engine │ (Telemetry: latency, drift, token counts, logs)
└──────────────────────┘

Monitoring Concept Drift and Degradation

An AI model frozen in time degrades as the external world shifts. This performance decay occurs through two distinct mechanisms:

• Data Drift: The statistical distribution of incoming production inputs changes relative to the training distribution (e.g., changes in user vocabulary, emerging topics, or new consumer trends).
• Concept Drift: The statistical relationship between inputs and the target labels changes over time (e.g., historical spending patterns predicting fraud in 2020 may no longer predict fraud accurately today).

Robust production architectures continuously log telemetry—such as request latency, confidence scores, output token volume, and end-user engagement signals—feeding those metrics into dashboards that trigger automated retraining pipelines when performance metrics fall below acceptable thresholds. Making the machine: the machine learning lifecycle What Is Model Deployment?

Hardware Sizing and Toolchain Selection

Building artificial intelligence effectively requires matching hardware and software tools to the scale of the target problem. The following breakdown outlines the infrastructure and frameworks required for typical deployment tiers:

Compute Profiles

• Tier 1 (Local CPU / Standard Laptop): Sufficient for classical tabular modeling (Scikit-Learn, LightGBM up to several million rows), lightweight RAG prototypes, and running quantized small language models (1B to 3B parameters) via llama.cpp.
• Tier 2 (Prosumer Workstation / 1–2 GPUs with 16–24GB VRAM): Required for local LoRA/QLoRA fine-tuning of 7B-to-14B parameter models, processing high-resolution computer vision workflows, or running low-latency multi-user local RAG servers.
• Tier 3 (Multi-GPU Cloud Nodes / 80GB+ VRAM): Essential for distributed training, multi-node fine-tuning of 70B+ parameter models, and high-throughput production serving clusters running continuous batching engines.

Recommended Software Ecosystem

• Core Languages: Python remains the primary development language across all domains; Mojo, C++, and Rust are increasingly used for building underlying inference engines and low-level matrix operation runtimes.
• Classical ML: scikit-learn, xgboost, lightgbm, statsmodels.
• Deep Learning Frameworks: PyTorch (dominant in modern research and development), JAX (favored for high-scale mathematical transformations).
• Open Model Hubs & Training: Hugging Face transformers, peft, accelerate, trl.
• Agentic Frameworks: LangChain, LlamaIndex, CrewAI, Semantic Kernel.
• Inference Runtimes: vLLM, Ollama, llama.cpp, TensorRT-LLM, Triton Inference Server.
• Storage & Vectors: Chroma, Qdrant, Weaviate, PostgreSQL with the pgvector extension.

By starting with a clear problem definition, maintaining clean data pipelines, and selecting the most efficient implementation track along the AI spectrum, developers can reliably take an AI concept from a working prototype all the way into production. A practical guide to building agents How to Build an AI Agent | IBM ML development phases | Machine Learning

What "making your own AI" actually means

For almost everyone asking how to make their own AI, the practical answer is: you will not train a model from scratch — you will assemble a system around an existing model. Modern AI products are layers. At the bottom sits a pretrained model (either a hosted API or a downloadable open-weight model), and above it sit the parts that actually make it yours: instructions, your own data, tools it can call, guardrails, and an interface. Building your own AI means choosing which of those layers you control.

That framing matters because "build your own AI" covers wildly different levels of effort. Writing a focused system prompt in a no-code assistant builder is a weekend's work. Fine-tuning an open-weight model on your own examples is a few days of data work plus a few hours of GPU time. Pretraining a frontier-scale foundation model is an industrial undertaking requiring a large GPU cluster, a data pipeline, and a specialist research team — it is not something an individual or small team replicates, and no honest guide should suggest otherwise.

So the honest answer to can you make your own AI? is yes — at four very different levels:

Start with the task, not the model

The most common failure in building your own AI is choosing a model before defining the job. Before touching tooling, write down three things: the exact inputs the system will see, what a correct output looks like, and how you will know it is wrong. Then collect 30–100 real examples of that task and put them aside as an evaluation set.

This is not bureaucratic. Every later decision — hosted versus local, retrieval versus fine-tuning, big model versus small — is a trade-off you can only resolve by measuring. A useful discipline from the fine-tuning world applies to every level: the thing you must prove is whether your fancier approach actually beats a plain, well-written prompt on held-out examples.

A second early decision is deployment. Hosted APIs are the fastest path to a working prototype and require no infrastructure; self-hosting an open-weight model is what you choose when data must not leave your environment, when you need offline operation, or when per-token costs dominate at your volume.

Level one: the configured assistant

The lowest-effort version of your own AI is a model you have not changed at all, wrapped in instructions that constrain it. Major providers offer no-code builders for this, and the same thing is easy to build yourself in a few dozen lines of code against any chat API.

What makes a configured assistant good or bad is almost entirely the specification you give it:

• Role and scope — what it does, and explicitly what it refuses or escalates.
• Output contract — the exact format expected, ideally shown rather than described.
• Worked examples — two or three input/output pairs covering the tricky cases.
• Failure behaviour — what to say when the answer isn't in the provided material.

This level is underrated. A large share of real internal AI tools never need anything more, and starting here gives you the baseline that justifies (or kills) the next level of complexity.

Level two: grounding it in your own data

If your AI needs to answer questions about your documents — policies, product specs, tickets, a wiki — the standard technique is retrieval-augmented generation (RAG). Instead of baking knowledge into the model, you store your text in a searchable index, retrieve the most relevant passages at query time, and paste them into the prompt as context.

The pipeline has four stages, and each one is a place where quality is won or lost:

1. Ingest and chunk — split documents into passages small enough to be precise but large enough to stand alone.
2. Embed and index — convert chunks into vectors with an embedding model and store them in a vector database (self-hosted options and managed services both exist).
3. Retrieve and rerank — fetch candidates for the user's question, then reorder them so the best passages land closest to the model's attention.
4. Generate with citations — instruct the model to answer only from the retrieved text and to name its sources.

RAG is the right default for most knowledge-facing assistants because it separates knowledge from behaviour: updating an answer means editing a document, not retraining anything, and the model works from retrievable text rather than reconstructing facts from memory, which reduces hallucination and makes answers auditable.

Be aware of the trade-offs, though. The "no retraining needed" advantage holds only if retrieval quality is high — poor ranking poisons everything downstream, and in practice RAG systems fail in a number of well-documented, non-obvious ways, from missing content to badly ordered context. Retrieval also adds latency and consumes input tokens on every call, so at high query volumes the context cost is a real budget line, not a rounding error.

Level three: fine-tuning an open-weight model

Fine-tuning is what people usually imagine when they talk about making their own AI, and it answers a different question than RAG does. The cleanest way to hold the distinction: retrieval changes what the model knows; fine-tuning changes how the model behaves. Reach for fine-tuning when you need a consistent voice, a rigid output format, or reliable performance on a narrow task — and expect a fine-tuned model to go stale on facts, because its knowledge is a snapshot of its training data. A reasonable decision rule is to use retrieval when your knowledge changes often, fine-tuning when knowledge is stable but behaviour is specialised, and both together in mature production systems.

How parameter-efficient fine-tuning works

You almost never retrain all the weights. LoRA (low-rank adaptation) freezes the base model and trains small adapter matrices injected into its linear layers; QLoRA adds 4-bit quantization of the frozen base on top, cutting memory further at a modest quality cost. The memory saving comes from two places: LoRA eliminates gradients and optimizer state for everything except the adapter, and QLoRA additionally shrinks the frozen base weights themselves. Choose QLoRA when memory is the binding constraint, and 16-bit LoRA when you have VRAM to spare and want to eliminate quantization as a source of error.

The tooling has consolidated. Common 2026-era guidance is to use Unsloth for single-GPU runs, Axolotl for YAML-configured multi-GPU pipelines, MLX-LM on Apple Silicon, and Hugging Face TRL when you want direct control; a frequent starting recipe is a 4-bit base with a rank-16 LoRA adapter targeting all linear projections. Usefully, adapters are portable — because these frameworks share the Hugging Face model format underneath, an adapter trained in one generally loads in another.

A minimal single-GPU configuration looks like this:

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Meta-Llama-3.1-8B-Instruct",
    max_seq_length=2048,
    load_in_4bit=True,          # QLoRA
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    lora_alpha=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
)

The hard part is not the code — it's the dataset. You need consistently formatted input/output pairs that demonstrate the behaviour you want, cleaned of contradictions, with a held-out split you never train on. Training wall-clock time varies enormously with model size and hardware, and published figures from framework comparisons should be treated as rough planning numbers rather than guarantees for your setup.

Picking and licensing a base model

Open-weight releases from several labs — Meta's Llama, Mistral, Alibaba's Qwen, Google's Gemma, Microsoft's Phi, and others — are distributed through model hubs and can be quantized, fine-tuned, and deployed offline.

Licensing deserves a careful read rather than an assumption, because "open" is used loosely. Several families ship many releases under Apache 2.0 or MIT, which permit commercial use and redistribution of fine-tunes; others use source-available community licences that allow commercial use subject to conditions such as attribution or large-scale usage thresholds. Terms differ per model and change with each release, so check the licence file on the specific weights you intend to ship, and get legal review if you are redistributing a fine-tune commercially or operating in a regulated sector.

Running it yourself

If you self-host, two concepts govern everything: quantization and memory. Quantization compresses weights to fewer bits per parameter, which is why a model needing roughly 16 GB at 16-bit precision can fit in about 5 GB. The dominant local format is GGUF, defined by the llama.cpp project — a free, MIT-licensed C/C++ inference engine that supports quantization from roughly 1.5 bits up to 8 bits, ships an OpenAI-compatible llama-server, and acts as the backend for much of the local-AI ecosystem including Ollama.

Rough memory planning for 4-bit models, which should be treated as approximate and hardware-dependent:

| Model size | ~Q4 memory |