Use cases: image classification, object detection and segmentation, medical imaging — anything where the data sits on a spatial grid and nearby values are related to each other.

Math summary: a small learned kernel slides across the input computing a dot product at every position; reusing the same weights everywhere (weight sharing) is what gives translation invariance and far fewer parameters than a fully-connected layer over the same input. Stacking convolution, a nonlinearity, and pooling builds up from local edges to whole-object features layer by layer.

Does this use Fourier math across a 2D array? Yes and no, precisely. The Convolution Theorem — real, established math that predates neural networks entirely — says spatial-domain convolution is mathematically equivalent to multiplication in the frequency domain. In practice, most modern CNN layers don't route through Fourier space: the small 3×3/5×5 kernels that dominate today's architectures are usually computed directly (or via im2col plus matrix multiply, sometimes Winograd), because the FFT round-trip overhead isn't worth it at that size. But FFT-based convolution is real and implemented, not just theoretical — cuDNN exposes it as a selectable algorithm, and its own autotuner picks FFT over direct methods exactly when the kernel is large enough to make the frequency-domain route actually win. And independent of how it's computed: the filters a CNN's early layers actually learn are oriented, edge-detecting, frequency-selective patterns — the same territory classical Fourier-based image analysis covers either way.

Use cases: sequential and time-series data — historically language modeling, speech, anything where order carries meaning, before Transformers displaced it for most large-scale text work.

Math summary: one hidden state carried forward and updated at every step (h_t = f(W_xx_t + W_hh_t−1 + b)), with the same weights reused at every timestep. Trained via backpropagation through time — which is exactly why vanilla RNNs struggle with vanishing or exploding gradients over long sequences.

Use cases: tabular data, simple classification and regression, and — less obviously — as a structural building block inside almost every other architecture, including the position-wise feedforward sublayer sitting inside every Transformer block.

Math summary: stacked layers of weighted sums plus a nonlinear activation, no recurrence, no convolution — every input connected to every output by a learned weight. The Universal Approximation Theorem is the formal reason a large-enough single hidden layer can approximate any continuous function, even though in practice depth is what actually makes training tractable.

Use cases: was the default for sequence modeling — translation, speech recognition, longer-form language modeling — before Transformers took over around 2017; still shows up where a Transformer's full attention is more compute than the problem needs.

Math summary: an RNN variant with a separate cell state plus three learned gates (input, forget, output) that decide what gets written into, kept in, or read out of that cell state at each step. That gating is specifically what fixes vanilla RNNs' vanishing-gradient problem over long sequences.

Use cases: the dominant architecture today — every model already covered on this page (Gemma 4, gpt-oss, Nemotron 3) is a transformer or transformer-hybrid, plus vision transformers and multimodal models.

Math summary: self-attention — every token computes a weighted combination of every other token's value vector, with the weights coming from a scaled query-key dot product run through softmax. No recurrence at all, so the whole sequence processes in parallel instead of one step at a time, which is the real reason it displaced RNNs and LSTMs at scale. Position has to be added back in explicitly (positional encoding), since attention alone has no built-in sense of order.

Adversarial examples — inputs deliberately engineered, often via small, human-imperceptible perturbations, to make a trained model mispredict, exploiting the gap between how a model and a human actually read the same input.

YOLO-style detectors — built for real-time object detection in a single pass over an image.

Genetic algorithms. Maintain a population of candidate solutions, score each with a fitness function, keep the best performers, and recombine/mutate them into the next generation — repeat until the population converges on something good. NASA's ST5 mission (2006) used one to evolve a spacecraft antenna: instead of an engineer hand-shaping the geometry, the algorithm bred thousands of candidate wire shapes against a simulated radiation pattern, and the winning antenna looked like nothing a human would have designed — bent and asymmetric — but outperformed the conventional design it replaced.

Branch prediction. A CPU speculatively executes past an if before it knows which way the branch will actually go, and being wrong means throwing away that work. Modern high-end predictors (AMD Zen and recent Intel cores among them) do this with a perceptron — literally a small neural network taking a long history of recent branch outcomes as input, weighting them, and predicting taken/not-taken from the weighted sum (Jiménez & Lin, 2001). The "AI" framing isn't a stretch here: it's a real, tiny neural net running billions of times a second in hardware you already own.

Hyperparameter optimization. Grid search (try every combination on a fixed grid) is the simplest approach and also provably wasteful in high dimensions: Bergstra & Bengio (2012) showed random search finds better configurations faster once you have more than a couple of hyperparameters, because a grid wastes trials on unimportant dimensions. Modern tuning tools (Optuna, for one) go further with Bayesian methods — using the results collected so far to model which unexplored region of the space is likely to be good, instead of sampling blindly.

Company: Google

E2B/E4B totals include Per-Layer Embeddings (PLE) — a runtime that supports offloading PLE to host memory can run below this floor; the numbers above assume it doesn't.

• Architecture: this is where a real 31B Gemma actually lives — Gemma 3's largest is 27B, not 31B, so if you've seen "31B Gemma" mentioned, it's this generation. The 26B model is a sparse MoE (25.2B total, 3.8B active); the rest are dense.
• License: plain Apache 2.0, dropping the more restrictive Gemma Terms of Use.

Company: NVIDIA

Super/Ultra's max context isn't stated in NVIDIA's own Nemotron 3 Nano report (arXiv:2512.20848), which covers the 30B-A3B Nano only — marked "not stated" rather than assumed to match Nano's. The Nano 4B row is sourced from its Hugging Face model cards, not that paper.

• Architecture: "Nano" actually spans two different designs, not one size of one design. Nano 30B-A3B is the hybrid Mamba-2 + Transformer + Mixture-of-Experts model — 23 Mamba-2 layers, 23 MoE layers (128 routed experts + 1 shared, 6 active per token), and 6 GQA attention layers, ~3B active parameters per token. Nano 4B is a separate, smaller, non-MoE model — mostly Mamba-2 and MLP layers plus just 4 attention layers — compressed from the previous-generation Nemotron Nano 2 9B using NVIDIA's "Nemotron Elastic" framework, aimed at edge hardware like Jetson Thor and GeForce RTX.
• License: open-weight but, like Gemma, not OSI-approved — shipped under NVIDIA's own "Nemotron Open Model License," then migrated in mid-2026 to the Linux Foundation's new OpenMDW-1.1 framework, submitted for OSI review but not yet OSI-approved.
• Worth flagging: NVIDIA reused this name once before — an unrelated, much smaller "Nemotron-3-8B" shipped back in November 2023, and has nothing to do with this 2025–2026 family.

Why did bf16 improve model accuracy?

Company: OpenAI

• Architecture: mixture-of-experts — 20b runs 3.6B active parameters per token, 120b runs 5.1B active, both shipping in native MXFP4 quantization, with adjustable reasoning effort and built-in tool use.
• License: Apache 2.0.

• What it is: not a model, but the hub almost everything above gets downloaded from, plus the libraries that actually run it: transformers, diffusers, accelerate, and huggingface_hub (all Apache 2.0).
• Worth knowing: diffusers specifically is the standard library for running image-generation models like SDXL and Flux locally — it's hardware-agnostic by design, running on whatever PyTorch device is available, which is exactly what makes the CUDA/ROCm/XPU comparison below possible to make apples-to-apples.

Tree-of-Thought pruning is the closest conceptual match: a value/evaluator model scores partial reasoning branches (roughly "promising," "maybe," "dead end") and decides which are worth expanding before fully computing them — the same shape as a branch predictor deciding which path to speculate down. 2026 work here includes OS-Pruner (pruning reasoning chains via optimal-stopping theory) and ToTRL.

Reasoning-level speculative decoding is newer and aimed specifically at reasoning speed: SpecReason has a small draft model propose reasoning steps that a larger model verifies, reporting both a 1.5–2.5x speedup and a accuracy gain over reasoning without it. SSR, ConfSpec (confidence-gated step-level speculation), and "Lookahead Reasoning" are adjacent 2026 papers doing variations on the same draft-then-verify idea, one reasoning step at a time instead of one token at a time.

Token-level speculative decoding is the most mature and widely deployed of the three: EAGLE-3 (a draft head that fuses features across every transformer layer) merged into vLLM, SGLang, and TensorRT-LLM in early 2026, reporting 3–4x throughput gains. This is closer to raw generation speed than reasoning quality, but it's the same predict-then-verify shape at the smallest possible grain: one token at a time.

Worth naming the near-miss too: a paper that initially looked like a direct "branch prediction for LLMs" hit (arXiv:2512.21323, "Parallel Token Prediction") turned out, on actually reading the abstract, to describe a parallel decoding scheme in terms of determinism and throughput, with no branch-prediction framing at all — a reminder that a title matching a search doesn't mean the paper says what you expect.

Why a token needs 4 bytes now. A token ID is just an index into the vocabulary, and a 2-byte unsigned integer (uint16) can only address 65,536 distinct values. Current vocabularies blow past that: Gemma 3 and Gemma 4 both use roughly 262K entries, OpenAI's gpt-oss uses exactly 201,088, and Llama 3 uses 128,256 — every one of them more than double the uint16 ceiling. That's the real, structural reason token IDs are stored as 4-byte (uint32) integers today: the vocabulary itself outgrew the smaller type.

Converting tokens to something human-sized. OpenAI's own documented rule of thumb is roughly 4 characters or 0.75 words per token for English prose. Pair that with a commonly-cited (though not formally standardized) convention of about 500 words per single-spaced page, and a context window converts into pages a reader could actually hold. Lines of code are much fuzzier — there's no single authoritative source, estimates run anywhere from about 10 to 15 tokens per line depending on language and style, so treat the code column below as a rough, order-of-magnitude estimate, not a precise conversion.

So: how large does your context window truly need to be when you're searching for one answer? Almost certainly nowhere near 384 pages' worth. Finding a single fact doesn't require holding the whole haystack in memory at once — it requires the ability to look, find, and forget everything except the answer and a trail back to it. That reframes a big context window as a budget to spend deliberately, not a warehouse to fill: work one step at a time, compact what you found into a short summary the moment that step finishes, and carry only the compacted summary — not the raw material that produced it — into the next step. Repeat, and no single step ever needs more than a fraction of the nominal window, no matter how many steps the overall task takes. It's also, not coincidentally, close to how a long agentic coding session survives running past its own context limits in the first place.

• OpenTelemetry — not a tool with a UI, but the vendor-neutral standard (APIs, SDKs, and a collector) for traces, metrics, and logs underneath both entries below. A CNCF graduated project (the merger of OpenTracing and OpenCensus), Apache 2.0. Knowing this exists is what makes "OpenTelemetry-based instrumentation" in the next bullet a meaningful claim rather than jargon.
• Arize Phoenix — Arize AI's open-source tracing, evals, and embedding-drift tool: OpenTelemetry-based instrumentation, LLM-graded response/retrieval evals, and UMAP-plus-clustering drift analysis for RAG pipelines. The main server is licensed Elastic License 2.0, not Apache — free to self-host and modify, but not OSI-approved, and it can't be resold as a hosted service. A few sub-packages (the client, evals, and OpenTelemetry libraries) are separately Apache 2.0. Distinct from Arize's paid "Arize AX" enterprise platform, which Phoenix isn't a stripped-down version of.
• Pydantic Logfire — the Pydantic team's observability platform, also built on OpenTelemetry, with automatic instrumentation for Pydantic models, FastAPI, Django, SQLAlchemy, and OpenAI calls specifically. Licensing is split and worth getting right: the logfire SDK itself is MIT and exports OTel-compatible data to any backend, not just Logfire's own; the hosted platform (the actual UI and backend you'd look at) is closed-source, freemium, and only self-hostable under a paid enterprise license — don't confuse "the client is open source" with "the product is open source."
• Grafana (or a custom UI) — OTel data still has to go somewhere and get looked at, and Phoenix/Logfire aren't the only options. Grafana itself has no ingestion of its own; it's the visualization layer on top of Tempo (traces, OTLP-native), Mimir (metrics), and Loki (logs) — all three, plus Grafana core, were relicensed from Apache 2.0 to AGPLv3 in 2021 and still are today. The "edges" (plugins, agents like the Grafana Alloy OTel Collector distribution, client libraries) stay Apache 2.0. Because OpenTelemetry is a vendor-neutral standard, a fully custom UI querying that same data directly is just as valid a choice — Grafana is the common one, not the only one.

• LangGraph — the LangChain team, MIT license. Supports cyclic graphs (not just one-way chains), which is what agentic control flow — retry, reflect, re-plan — actually needs. Built-in checkpointing/persistence (in-memory, SQLite, or Postgres savers) for durable, resumable execution, plus human-in-the-loop pause/inspect/modify and LangSmith tracing integration.
• Langflow — MIT license. A visual, drag-and-drop builder for LangChain-based agent and RAG flows; a flow exports as a REST API, an MCP server, or plain JSON. Acquired by DataStax and then IBM, but development stays open source.
• Hermes — Nous Research ships two distinct things under this name. The Hermes model family (Hermes 3, Hermes 4) is a line of fine-tuned LLMs with a native tool-calling format built in, not an orchestration framework. Separately, Hermes Agent is a standalone, MIT-licensed, self-improving CLI/TUI agent — skill creation, subagent delegation, scheduled automations, and gateways into Telegram/Discord/Slack/WhatsApp/Signal, model-agnostic via any OpenAI-compatible provider.
• agentic-api (vllm-project/agentic-api) — Apache 2.0, Rust, and very new (created March 2026). A gateway that adds server-side conversation state and tool-call-loop orchestration on top of vLLM, exposing an OpenAI-compatible Responses/Messages API — a separate, early-stage companion project, not part of core vLLM.
• ADK (google/adk-python) — Apache 2.0. Google's code-first Python Agent Development Kit: optimized for Gemini but explicitly model- and deployment-agnostic, deploying via Cloud Run or Vertex AI Agent Engine.
• Pydantic AI (pydantic/pydantic-ai) — MIT, from the Pydantic team. A type-safe agent framework built directly on Pydantic's own validation/schema system, aimed at production apps that need structured, validated output regardless of which LLM provider is behind it. Past 1.0 (shipped September 2025) and now on a stable 2.0 line (June 2026).
• OpenAI Agents SDK (openai/openai-agents-python) — MIT, OpenAI's own official successor to the earlier experimental swarm project. Deliberately lightweight: built around native OpenAI tool/function calling and structured JSON-schema output rather than a heavy orchestration abstraction, with an April 2026 update adding sandboxing, longer-horizon execution, and subagents.
• CrewAI (crewAIInc/crewAI) — MIT, now backed by CrewAI Inc. rather than a purely community project. Role-based multi-agent orchestration: a "crew" of agents with defined roles and goals hand tasks off to each other. No longer depends on LangChain — a standalone architecture it moved to deliberately, for a lighter footprint.
• Smolagents (huggingface/smolagents) — Apache 2.0, Hugging Face. Its core idea (the CodeAgent) is agents that write and execute actual Python code as their action mechanism, instead of emitting JSON tool-calls — Hugging Face's argument is that real code (loops, conditionals, nested calls) is more expressive than a flat call format. Deliberately minimal: the core logic is roughly 1,000 lines.

Release dates are each project's first public release (verified against GitHub tags/PyPI), and Popularity is these five projects' current GitHub star counts translated into a relative 1–5 scale — CrewAI (58K) and LangGraph (41K) lead, Pydantic AI (20K) trails, with OpenAI Agents SDK and Smolagents (29K each) in between. Learning curve (Easy/Average/Hard) and Reliability (stars) are comparative editorial judgments, not benchmark measurements — nobody ran a controlled study across all five.

• SGLang (sgl-project/sglang) — Apache 2.0, maintained by LMSYS with contributions from xAI, NVIDIA, AMD, Intel, and LinkedIn. Its core technique is RadixAttention, a prefix-caching scheme the project credits with a 5x inference speedup. Since November 2025, SGLang Diffusion extends that same scheduler/kernel stack to image and video generation (Wan, Hunyuan, Qwen-Image, Flux), claiming 1.2–5.9x speedups — genuinely not just a text-LLM server anymore, though the diffusion piece is a newer module layered on top of the core.
• vLLM (vllm-project/vllm) — Apache 2.0, born at UC Berkeley's Sky Computing Lab and now a large multi-company/academic project (2,000+ contributors). Core technique is PagedAttention (paged KV-cache memory management) plus continuous batching. Widely regarded as the standard for high-throughput, many-concurrent-user serving in datacenters — that's an industry consensus, worth being clear, not a claim the project's own docs make in those words.
• Intel llm-scaler (intel/llm-scaler) — Apache 2.0. Intel's own extended fork of vLLM for its multi-GPU platforms (Arc B60/B70, A770): Intel-specific kernels, FP8/INT4 quantization, multi-node deployment, LoRA support. Actively developed, but Intel's own docs say its Docker images are "intended for demo purposes only, not intended for production use" — a real maturity caveat, consistent with the Kernel Landscape section's read on XPU as the roughest of the three backends.
• Lemonade (lemonade-sdk) — Apache 2.0, AMD-sponsored, targeting Ryzen AI NPUs plus Radeon integrated/discrete GPUs, OpenAI-API-compatible. One caveat: the underlying FastFlowLM NPU kernels are proprietary (free for "reasonable commercial use" per AMD), so the full stack isn't 100% open source end to end, even though Lemonade itself is.
• llama.cpp (ggml-org/llama.cpp) — MIT, created by Georgi Gerganov (also the creator of the underlying ggml tensor library), 700+ contributors, 100K+ GitHub stars. The base engine Ollama and LM Studio are built on — Ollama's own docs credit the llama.cpp project directly. The ggml/llama.cpp team joined Hugging Face in February 2026.
• Candle (huggingface/candle) — dual Apache 2.0/MIT, Hugging Face's own minimalist Rust-native inference framework: no Python or GIL overhead, with CUDA and WASM support — built for lightweight, serverless-friendly binaries rather than a full training stack.
• Ollama (ollama/ollama) — MIT, built on top of llama.cpp/ggml. The dominant one-command local-serving tool — the reason most people's first local model ever ran was a single ollama run away.
• TensorRT-LLM (NVIDIA/TensorRT-LLM) — Apache 2.0, NVIDIA-maintained. Compiles a model through TensorRT with custom attention/GEMM/MoE kernels and runtime techniques (disaggregated prefill-decode, speculative decoding) for NVIDIA-GPU-optimized inference — the CUDA-native counterpart to vLLM's more hardware-agnostic approach.

• Fireworks AI — a hosted inference platform for open-weight models (Qwen, DeepSeek, Kimi, and others), not a foundation-model lab itself. Pay-per-token, tiered by model size (roughly $0.10/1M tokens under 4B, $0.20/1M for 4B–16B, $0.90/1M for 16B+), plus GPU-hour billing for dedicated deployments and per-token billing for fine-tuning (LoRA and full SFT/DPO). Its differentiator is FireAttention, a custom CUDA attention kernel built specifically to beat stock vLLM performance on the same hardware.
• OpenAI API — pay-per-token. Honest gap in this research: sources disagreed on the current flagship model, with some pointing to a "GPT-5.6" generation and OpenAI's own pricing page also listing a higher-tier "gpt-6-astra" — not confident enough to state a single current flagship as fact, so treat "what's newest" as unsettled rather than picking one. Notable API features: the Responses API and built-in tools.
• Anthropic API — pay-per-token, current lineup Claude Opus 5, Sonnet 5, Haiku 4.5, and Fable 5. Notable features: prompt caching, extended/adaptive thinking, computer use, and long context on current models.
• Featherless AI — the pricing-model outlier here: a flat-rate subscription, not pay-per-token (chat plans roughly $10–$25/month, developer/credit plans from $50/month), for access to a very large catalog of open-weight and community fine-tuned models — catalog-size estimates vary by source (tens of thousands of models), so treat any exact number as approximate rather than precise.
• Google Gemini API — pay-per-token, tiered by context length. Same honest gap as OpenAI above: some sources cite Gemini 3.1 Pro as flagship, while Google's own pricing page foregrounds Gemini 3.8 Flash as "most intelligent" — naming that suggests the Flash line may have outpaced Pro, but not confirmed with confidence. Notable features: native multimodality, context up to 1M tokens, and grounding with Google Search.

• NVIDIA CUDA — the default path, and it isn't close. CUDA became the de facto ML backend through the mid-2010s (TensorFlow and PyTorch both built around it first, cuDNN arrived in 2015), and PyTorch 2.7 (April 2025) added official Blackwell support via CUDA 12.8. Nearly every diffusers tutorial, doc, and community troubleshooting thread assumes CUDA — it's the backend everything else gets compared against.
• AMD ROCm — scoped to the two RDNA generations in the lab above:
  • R9700 (RDNA4) — officially supported (gfx1201). 32GB is "ECC-capable," likely driver-level in-band ECC rather than true hardware ECC — unconfirmed against AMD's own spec sheet. Works but young: vendor guides disagree on which ROCm version added it (6.4.2 vs. 7.0.2), and open GitHub issues still show gfx1201 gaps (FP8 falling back to FP32, missing hipBLASLt kernels).
  • Strix Halo iGPU (RDNA 3.5, gfx1151) — support tier is unsettled even in AMD's own docs (GitHub issue: "Confusing ROCm support for gfx1151"). Works on Linux with ROCm 7.0–7.2, often needing a manual GFX-version override; Windows is weaker. For SDXL/Flux, community reports say Vulkan currently beats ROCm on this chip — none of this is AMD-confirmed.
• Intel XPU — native torch.xpu support landed as a prototype-level feature in PyTorch 2.5 (October 2024), after Intel's own separate extension package (IPEX) had covered the gap; Intel has since wound down active IPEX development in favor of upstreaming directly into stock PyTorch. SDXL and Flux Schnell/Dev are genuinely workable on Arc consumer cards (the B580 gets roughly RTX-3070-class SDXL speeds), but it's the roughest of the three: manual attention/VAE slicing is required on memory-constrained cards, FP16 is reportedly unstable on integrated GPUs (BF16 recommended instead), and Flux needs IPEX-provided patches rather than running out of the box. Workstation-class Arc Pro cards specifically don't have public SDXL/Flux benchmarks yet, as far as I've found.

Why did bf16 improve model accuracy?

Ranked by how likely each one is to just work today: CUDA, then ROCm, then XPU — a real gap, not a rounding error, and worth knowing given the AMD and Intel cards sitting in the lab above.

A 4B-parameter model, shrunk down (quantized) to save space, takes up about 2.6GB — the same size as Gemma 3's 4B variant covered earlier in this outline. Your GPU talks to the rest of the computer over a connection called PCIe, which on most modern gaming PCs moves data at roughly 32GB per second. Do the math: moving 2.6GB across that connection takes about 80 milliseconds — call it under a second once you add in some setup overhead. That's not a guess; it's arithmetic. A well-architected system doesn't need a huge model sitting in memory to do something complicated — it just needs to know which small model to grab next, and a fast enough connection to grab it.

This is exactly what Liquid AI's LFM2.5 lineup is built for. Instead of one big model, it's a whole family: text models from 230M up to an 8B mixture-of-experts variant, small vision models, an audio model, and a set of tiny specialists — ones just for search, translation, math, or handling sensitive data safely. All of it is open-weight (free to download and inspect) under an Apache-2.0-based license. That's what a swap-friendly system actually looks like in practice: not one model trying to do everything, but a bench of small, fast specialists you call in only when you need them.

Robots make this pattern non-negotiable. A robot exploring a cave or a tunnel doesn't have the battery or the cooling to keep a giant model running the whole time — see the tunnel-imaging and SLAM work in the Computer Vision section below. What it does have room for is a coordination layer and a rotation of small, focused models: one to see, one to plan a path, one to understand language, swapped in only when the task actually needs them. That's not a workaround for weak hardware — on a robot, it's simply the right way to build it, no matter your budget.

Swapping a frozen model in and out is the easy case. The harder question is what happens when the model keeps changing itself after it's deployed — learning and updating its own behavior in the real world through reinforcement learning. That trades something you can test and trust for a moving target. AI systems that optimize hard for a reward tend to find sneaky shortcuts researchers didn't intend — a well-documented problem called reward hacking (or specification gaming). It gets riskier once the model can act in the real world and watch what happens next. A model you can swap out, inspect, and roll back is simply safer to build on than one that's quietly rewriting itself while it runs.

• Stable Diffusion XL (SDXL) — Stability AI, open-weight (CreativeML Open RAIL++-M).
• FLUX.2-dev — Black Forest Labs, a 32B rectified-flow transformer, open-weight under the non-commercial FLUX license.
• gpt-image-2 — OpenAI's current flagship text-to-image model, via the Images and Responses APIs.
• Midjourney — proprietary, Discord/web-based.
• Adobe Firefly — proprietary, marketed as trained only on licensed and public-domain content for commercial safety.

• Suno (v5.5) — proprietary text-to-song generator, complete with vocals and production.
• Udio — proprietary text-to-song generator, Suno's main competitor.
• MusicGen — Meta, 3.3B parameters, open-weight (CC-BY-NC 4.0 weights, MIT-licensed code).
• Stable Audio Open 1.0 — Stability AI, open-weight, up to 47 seconds of stereo audio at 44.1kHz.
• Lyria 3.5 — Google DeepMind, proprietary, available through Google Flow Music, Gemini, and YouTube's Dream Track.

• Whisper large-v3 — OpenAI, open-weight, Apache 2.0.
• Parakeet TDT 0.6B v2 — NVIDIA, 600M parameters, open-weight (CC-BY-4.0), tops the Hugging Face Open ASR Leaderboard at 6.05% average word error rate.
• Universal-3.5 Pro — AssemblyAI, proprietary API.
• Nova-3 — Deepgram, proprietary API.

This is where the Engineers for Exploration work shows up again — SLAM, structure-from-motion (SFM), Agisoft-based photogrammetry, and point-cloud analysis, applied to mangrove canopy monitoring and Maya archaeological site mapping. On the hardware side, a lot of that field capture runs through a Luxonis OAK 4 D — active stereo depth (with IR illumination for low-light scenes) plus a 48MP RGB camera, a 6-core onboard CPU with 52 TOPS of AI inferencing, and its own Linux-based OS — built by Luxonis (the "OAK" name traces back to "OpenCV AI Kit," the original Kickstarter-funded collaboration with OpenCV.org) and paired with OpenCV itself for the actual perception pipeline.

Spector: An OpenCL FPGA Benchmark Suite (Gautier, Althoff, Meng, and Kastner — UC San Diego, FPT 2016) — from the same Kastner/Gautier lab, this one is a benchmark suite for exploring the design space of high-level synthesis tools on FPGAs, not a computer-vision paper itself, but the methodology that lab's FPGA computer-vision work builds on.