Model reference · open weights

Ivme-Conversate

LLMs IvmeLabs Text gen 1 build Open weights 546 dl/mo

Ivme-Conversate is an open-weight language model from IvmeLabs. Ivme-Conversate-v3-Base (FP32) weighs 50 MB; the smallest configuration that runs it is RTX 3060 12 GB.

For self-hosting, compare this build's requirements below with the GPU you plan to rent.

  • Ivme-Conversate-v3-Base is a 25M parameter decoder-only language model developed by IvmeLabs for English text generation.
  • It features a 1024 token context window and utilizes a custom digit-atomic tokenizer alongside QK-Norm and XSA attention mechanisms to improve coherence.
  • The model is released under the Apache 2.0 license.

Summary of the IvmeLabs/Ivme-Conversate-v3-Base model card, 2026-10-01

What it is

Released byIvmeLabs
Released2026-09-13
Parameters25M
VRAM50 MB for the weights

What it runs on

Memory and cards for Ivme-Conversate-v3-Base (FP32)

50 MBweights, file size
762 MBruntime overhead, at least

How much memory each request adds isn't estimated yet for this architecture. The weights need at least the cards below, plus room for the context.

CardWeights alone
RTX 3060 12 GBfits
RTX 4060 Ti 16 GBfits
RTX 3090 24 GBfits
RTX 4090 24 GBfits
RTX 5090 32 GBfits
L40S 48 GBfits
A100 80 GBfits
H100 80 GBfits
RTX PRO 6000 Blackwell 96 GBfits
DGX Spark (GB10) 128 GB unifiedfits
H200 141 GBfits
B200 180 GBfits

From the model card

What IvmeLabs says about Ivme-Conversate

Read the model card

İvme (Turkish: acceleration) is a series of stupidly small language models built to punch above their weight. This is the third release: a 24.79M parameter decoder-only base model trained from scratch, with a deeper/narrower architecture, two new attention-level changes, a digit-atomic tokenizer, and a revised data mix.

v2 fixed v1's biggest problem (coherence) mostly through data — more tokens, better weighted toward staying on topic. v3 keeps that lesson but changes the architecture itself for the first time since v1: more layers, a narrower hidden dimension, and two specific attention modifications (QK-Norm and XSA) chosen because they target coherence directly rather than just adding parameters. The tokenizer was also rebuilt to keep every digit as its own token, aimed squarely at v2's other well-known weak spot: arithmetic.


Model Details

ParameterValue
ArchitectureDecoder-only transformer, dense (no loops, no exotic recurrence)
Parameters24,787,520
Layers16
Hidden dim320
FFN dimSwiGLU (~853)
Attention heads8, full attention (no GQA), head_dim 40
Attention variantQK-Norm + XSA (Exclusive Self Attention, arXiv:2603.09078)
Context length1024 tokens
Vocab size16,000 (custom digit-atomic BPE)
Positional encodingRoPE (θ=10,000)
NormalizationRMSNorm (pre-norm)
EmbeddingsTied input/output
BiasesNone

v2 was 10 layers × 384 hidden dim (depth:width ≈ 0.026). v3 deliberately goes deeper and narrower — 16 layers × 320 hidden dim (depth:width ≈ 0.050) — while landing in almost exactly the same parameter budget. Depth tends to help multi-step reasoning and cross-sentence coherence more than raw width does; width tends to help how much can be memorized per token. This is a real rebalancing of the budget, not a token gesture: the embedding table's share of total parameters drops from v2's 25.8% to v3's 20.7%, with the difference going into deeper transformer layers.

QK-Norm: per-head RMSNorm applied to queries and keys before the RoPE rotation and the dot product, for training stability at higher depth and a higher effective learning rate.

XSA (Exclusive Self Attention): after standard scaled-dot-product attention produces output yᵢ for token i, subtract the projection of yᵢ onto that token's own value vector vᵢ:

zᵢ = yᵢ − (yᵢ · vᵢ) / (‖vᵢ‖² + ε) · vᵢ

The idea, from the source paper: standard attention lets a token attend heavily to itself, which can let a model get lazy and just echo its own representation forward instead of pulling in genuinely new context from other tokens. XSA removes that redundant self-component. Zero extra parameters, negligible extra compute.


Benchmarks

Benchmarks were run with lm-evaluation-harness via a transformers-compatible custom model wrapper, plus ArithMark 3.0 via its official evaluation script.

Benchmarkv2v3
WikiText-2 (byte perplexity) ↓2.22502.1362
BLiMP (macro-average) ↑75.09%78.49%
ARC-Easy (acc) ↑43.56%43.60%
ARC-Easy (acc_norm) ↑39.98%39.02%
ARC-Challenge (acc_norm) ↑—24.06%
HellaSwag (acc_norm) ↑—28.82%
PIQA (acc_norm) ↑—57.78%
ArithMark-3 (acc_norm) ↑—34.70%

BLiMP moved up a real 3.4 points — the clearest confirmation that the depth/width rebalancing and the two attention changes did what they were meant to do for grammaticality and coherence. WikiText-2 perplexity also improved.

ARC-Easy is flat to slightly down (acc_norm: 39.98% → 39.02%), not up. Worth being straightforward about this rather than spinning it: ARC-Easy tests science-fact recall, which leans more on raw embedding/knowledge capacity than on the kind of cross-sentence reasoning BLiMP measures. v3 deliberately shrank the embedding table's share of the parameter budget (25.8% → 20.7%) to buy depth, and also cut Cosmopedia's weight hard (27% → 5.6%, it was stale synthetic data) in favor of more naturalistic web text. Both are plausible, specific mechanisms for a small knowledge-recall cost alongside the coherence gain — this looks like a real tradeoff from the choices made, not noise.

BLiMP paradigm breakdown

Strong on core agreement paradigms, several near-ceiling:

ParadigmAccuracy
blimp_principle_A_case_1100.00%
blimp_anaphor_number_agreement99.30%
blimp_determiner_noun_agreement_198.40%
blimp_sentential_negation_npi_licensor_present97.60%
blimp_anaphor_gender_agreement95.70%

Weaker on long-distance dependencies and island constraints, same pattern as v2 and typical for small models:

ParadigmAccuracy
blimp_wh_vs_that_with_gap_long_distance37.90%
blimp_left_branch_island_echo_question26.20%
blimp_sentential_subject_island41.50%
blimp_coordinate_structure_constraint_complex_left_branch42.10%
blimp_principle_A_reconstruction35.40%

Does the arithmetic tokenizer fix actually work?

Short answer: it fixes the representation, not the reasoning. ArithMark-3 lands at 34.70% (acc_norm), well above the benchmark's 25% random-choice floor and ahead of most other small models in its published leaderboard cohort — a real, positive signal that digit-atomic tokenization helped. But free-form arithmetic generation is still weak: asked directly (1 + 1 =), the model reliably produces plausible-looking numbers that are frequently wrong (1 + 1 = 20).

This split result makes sense once you separate what digit-atomic tokenization actually fixes from what it doesn't. Before v3, multi-digit numbers collapsed into single opaque BPE tokens, so the model never even saw place-value structure — "127" was one indivisible symbol, not 1 hundred + 2 tens + 7 ones. Splitting every digit into its own token fixes that re

Quoted from the model card on Hugging Face. The full card is behind the Hugging Face link above.

How it works

How language models work

Your prompttext / messagesTransformerattention over tokensNext-token loopgenerate + streamResponsetext · tool callsA language model reads your tokens and predicts the next one, again and again, streaming the reply back.
© 2026 AxForge · EU-hosted AI infrastructure Pricing Docs Trust Privacy Terms