Neural Mastery

Model Catalog & Benchmarking Framework

Choosing a model for a system is a recurring decision this site's content can't make for you with a fixed answer — specific models and their benchmark scores change every few months, often faster than any static page can track responsibly. What stays durable is the framework: which categories of model exist, which attributes actually matter for choosing between them, and which benchmark dimensions matter for each type of system. This page is that framework — deliberately a methodology, not a snapshot leaderboard that would be stale within a quarter of being written.

Model Categories

A rough taxonomy of the model types most system-design decisions choose between, each covered in depth elsewhere on this site:

CategoryCovered in
LLMLLMs & GenAI, Foundation Model Internals
VLM (vision-language)Modern Vision & Multimodal, Multimodal & Generative Models
Embedding modelRAG — Choosing an Embedding Model
Reranker (cross-encoder)RAG — Re-ranking with Cross-Encoders
Speech (ASR/TTS)Speech & Audio Tasks
Image generationGenerative Models
Video generation/understandingModern Vision & Multimodal
Audio generationSpeech & Audio Tasks
Reasoning modelsTraining Pipeline — GRPO
LLM
VLM
Embedding
Reranker
Speech (ASR/TTS)
Image generation
Video
Audio generation
Reasoning models
A taxonomy, not a leaderboard -- categories stay stable even as which specific models lead within each one changes.
LLM → covered in depth at "LLMs & GenAI".

The Model Card Attribute Checklist

When evaluating any model against this checklist, whatever its category — the same attribute set the Model Cards standard formalizes:

Total: 47B (memory)
Active: 13.2B (compute)
This decoupling is exactly why MoE models get more knowledge capacity without a proportional inference-cost increase.
Memory footprint (weights to load): scales with 47B TOTAL params. Per-token inference COMPUTE: scales with only 13.2B ACTIVE params. A dense model with 13.2B params would cost the same to run per-token, but this model has far more knowledge capacity in the 47B it can draw from.
  • Context length: maximum sequence length supported — directly bounds KV cache memory requirements at serving time.
  • Modalities: what input/output types the model actually supports (text-only, text+image-in, text+image+audio, etc.).
  • Training data and recency: what it was trained on, and its effective knowledge cutoff — directly relevant to the RAG vs. fine-tuning decision.
  • License: see Legal, Licensing & Governance — Model Licenses — check the actual current terms before commercial use, every time, since terms have changed between versions of the same model family.
  • Benchmark scores: reported scores on standard benchmarks — read alongside AI Evaluation — Benchmark Design's contamination/saturation cautions before trusting a number at face value.
  • Hardware requirements: VRAM needed to serve at a given precision — see LLM Inference Optimization — GGUF Ecosystem for concrete size-math worked examples.
  • Inference support: which engines support it (see LLM Inference Engines) — a model with narrow engine support is a real operational constraint, not just a technical footnote.
  • Fine-tuning support: whether LoRA/QLoRA tooling has mature support for the architecture — see Training Pipeline — PEFT.
  • Quantization support: whether pre-quantized versions (GGUF, AWQ, GPTQ) are readily available, or quantization has to be done in-house.
  • Use cases: what the model card/provider explicitly states it's suited (and not suited) for — the out-of-scope-uses section is often more informative than the intended-use section.
Architecture
Parameters
Context length
Modalities
Training data & recency
License
Benchmark scores
Hardware requirements
Inference support
Fine-tuning support
Quantization support
Use cases
The same attribute set the Model Cards standard formalizes -- applies to any category above.
Total AND active (for MoE) -- active params determine per-token inference cost.

Benchmark Dimensions by System Type

What to actually measure, by the kind of system being built — durable regardless of which specific models are being compared:

For any served model (inference benchmarking):

DimensionCovered in
Latency (TTFT, TPOT, end-to-end, P50/P95/P99)LLM Inference Optimization — Inference Metrics Summary
Throughput (tokens/sec, requests/sec)same
Memory (weights + KV cache)LLM Inference Optimization — KV Cache
Cost (per 1M tokens)AI Cost Engineering

For retrieval (embedding/reranker benchmarking):

DimensionCovered in
Recall@k, Precision@kLearning-to-Rank — Ranking Evaluation Metrics
MRR, NDCGsame
Retrieval latencyRAG — Evaluating RAG
Cost per queryAI Cost Engineering

For general model quality: see AI Evaluation in full — traditional metrics, LLM-as-judge, RAG evaluation, agent evaluation, and human/adversarial evaluation, each with the specific metrics and methodology to apply.

System type
Latency (TTFT, TPOT, end-to-end, P50/P95/P99)LLM Inference Optimization
Throughput (tokens/sec, requests/sec)LLM Inference Optimization
Memory (weights + KV cache)LLM Inference Optimization — KV Cache
Cost (per 1M tokens)AI Cost Engineering
For general model quality: see AI Evaluation in full (LLM-as-judge, RAG eval, agent eval, human/adversarial eval).
Durable regardless of which specific models are being compared -- the dimension set is what stays true.

How to Use This Page

When choosing a model for a real system: pull the current, specific candidates from primary sources (the model provider's own documentation, the inference engine's supported-models list, current leaderboards — treated with the benchmark design skepticism this site teaches, not at face value) and evaluate them against the attribute checklist and benchmark dimensions above. The checklist and dimensions are what stay true regardless of which specific models exist when you're reading this — that durability is the point.

1. Pull current candidates
2. Apply benchmark-design skepticism
3. Evaluate against the attribute checklist
4. Score against benchmark dimensions
The checklist and dimensions stay true regardless of which specific models exist when you're reading this -- that durability is the point.
Don't take a leaderboard number at face value -- contamination and saturation are real, common failure modes.

Next: ML System Design Roadmap — where model selection fits into the full 9-step system design framework.

Last updated Sep 5, 2026Edit this pageReport an issue
← Previous
ML System Design Case Studies
Next →
Technology Ecosystem Map