inference/research
verifiedhigh · 0.95updated 2026-10-04

TinyLlama-1.1B-Chat-v1.0

dense 1.1B

Fields

id
models/tinyllama-1-1b-chat
Family
llama
Vendor
TinyLlama
Release year
2024
Architecture
dense
Params (B)
1.1
Active params (B)
1.1
Hidden size
2,048
Layers
22
KV heads
4
Head dim
64
GQA ratio
8
Max context
2,048
Context scaling method
native
Activation
silu
Attention variant
GQA (32 query / 4 KV, ratio 8)
KV cache (bytes/token)
22,528
FLOPs per active token
2,200,000,000
Open weights
yes
License
Apache-2.0
notes
CONTEXT SCALING: null is a VERIFIED value, checked against config rather than left blank. config.json declares rope_scaling null, rope_theta 10000, max_position_embeddings 2048. head_dim derived = 2048 / 32 = 64. kv_cache_bytes_per_token = 22 * 4 * 64 * 2 * 2 = 22528 bytes/token at bf16 — the lowest of any decoder in this slice, and it shows why: an 8:1 GQA ratio with a small head_dim. Per layer 1024 bytes/token. At its 2048 context that is only 44 MiB of KV, so this model is almost entirely weight-bound and quantizes to very little; that combination (1.1B params, 22 MiB of KV) is why it remains a popular CI/fuzzing and llama.cpp smoke-test target. 1.36M downloads and 1836 likes make it one of the most-downloaded sub-1.5B models on the Hub. max_position_embeddings is only 2048 — that is the real limitation, not quality; anyone quoting TinyLlama as a 'long context' model is wrong. vocab 32000, intermediate 5632, untied embeddings, rope_theta 10000. TheBloke GGUF and onnx-community ONNX ports both exist. SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=dense-gqa. REQUIRED KERNEL CLASS: ordinary causal attention plus GEMM/GEMV. This is the baseline every engine in this repo implements, so the join here is a floor rather than a filter: no engine record in data/engines/ states that dense GQA is unsupported. SUPPORTED BY (cited): vLLM LlamaForCausalLM / Qwen2 / Qwen3 / Mistral / Phi3ForCausalLM rows [[mdl2-vllm-supported-models-2026-10]]; TensorRT-LLM LlamaForCausalLM, Qwen2ForCausalLM, Qwen3ForCausalLM, Phi3ForCausalLM rows [[mdl2-trtllm-supported-models]]; SGLang generative table (Llama, Qwen, Mistral families) [[mdl2-sglang-generative-models]]; llama.cpp LLM_ARCH_LLAMA [[pap-arch-llamacpp-arch-registry]]. HARD CONSTRAINTS THAT DO APPLY even to dense GQA, and they are model-shape rather than architecture-class: tensor-parallel size must divide the attention head count or the engine refuses to start [[mgpu-tp-size-must-divide-attention-heads]] (affects vllm and sglang); and a GQA KV cache is the thing paged-attention machinery exists for, so an engine with no paged KV (llama.cpp's slot-based pool [[llama-cpp]], exllamav2 [[exllamav2]]) loses the concurrency lever rather than the ability to run. ONE HARDWARE-DEPENDENT KERNEL GATE THAT IS NOT ABOUT GQA: on RDNA, vLLM's custom paged-attention kernel is gated on head_size == 128 AND block_size == 16, so a dense GQA model with head_dim 256 falls to the Triton 2D fallback and decode falls off a cliff - measured 12.1 tok/s at 518 tokens of context to 4.2 tok/s at 32k, with kernel_paged_attention_2d growing 28.3x [[rdna-triton-paged-attn-decode-cliff]]. Check head_dim before blaming the card.

Notes

CONTEXT SCALING: null is a VERIFIED value, checked against config rather than left blank. config.json declares rope_scaling null, rope_theta 10000, max_position_embeddings 2048. head_dim derived = 2048 / 32 = 64. kv_cache_bytes_per_token = 22 * 4 * 64 * 2 * 2 = 22528 bytes/token at bf16 — the lowest of any decoder in this slice, and it shows why: an 8:1 GQA ratio with a small head_dim. Per layer 1024 bytes/token. At its 2048 context that is only 44 MiB of KV, so this model is almost entirely weight-bound and quantizes to very little; that combination (1.1B params, 22 MiB of KV) is why it remains a popular CI/fuzzing and llama.cpp smoke-test target. 1.36M downloads and 1836 likes make it one of the most-downloaded sub-1.5B models on the Hub. max_position_embeddings is only 2048 — that is the real limitation, not quality; anyone quoting TinyLlama as a 'long context' model is wrong. vocab 32000, intermediate 5632, untied embeddings, rope_theta 10000. TheBloke GGUF and onnx-community ONNX ports both exist.

SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=dense-gqa. REQUIRED KERNEL CLASS: ordinary causal attention plus GEMM/GEMV. This is the baseline every engine in this repo implements, so the join here is a floor rather than a filter: no engine record in data/engines/ states that dense GQA is unsupported. SUPPORTED BY (cited): vLLM LlamaForCausalLM / Qwen2 / Qwen3 / Mistral / Phi3ForCausalLM rows [[mdl2-vllm-supported-models-2026-10]]; TensorRT-LLM LlamaForCausalLM, Qwen2ForCausalLM, Qwen3ForCausalLM, Phi3ForCausalLM rows [[mdl2-trtllm-supported-models]]; SGLang generative table (Llama, Qwen, Mistral families) [[mdl2-sglang-generative-models]]; llama.cpp LLM_ARCH_LLAMA [[pap-arch-llamacpp-arch-registry]]. HARD CONSTRAINTS THAT DO APPLY even to dense GQA, and they are model-shape rather than architecture-class: tensor-parallel size must divide the attention head count or the engine refuses to start [[mgpu-tp-size-must-divide-attention-heads]] (affects vllm and sglang); and a GQA KV cache is the thing paged-attention machinery exists for, so an engine with no paged KV (llama.cpp's slot-based pool [[llama-cpp]], exllamav2 [[exllamav2]]) loses the concurrency lever rather than the ability to run. ONE HARDWARE-DEPENDENT KERNEL GATE THAT IS NOT ABOUT GQA: on RDNA, vLLM's custom paged-attention kernel is gated on head_size == 128 AND block_size == 16, so a dense GQA model with head_dim 256 falls to the Triton 2D fallback and decode falls off a cliff - measured 12.1 tok/s at 518 tokens of context to 4.2 tok/s at 32k, with kernel_paged_attention_2d growing 28.3x [[rdna-triton-paged-attn-decode-cliff]]. Check head_dim before blaming the card.

Cross-references

This record references no other records — it is a leaf. It is cited by 0.