In-Place Tokenizer Expansion for Pre-trained LLMs
Abstract: A tokenizer fixed at the start of pre-training allocates vocabulary in proportion to the pre-training corpus, reflecting the deployment priorities at that time. When those priorities shift, languages added later are split into many more tokens per word, which can raise latency, compute, and energy consumption for users of those languages. Cloud models can afford a broad vocabulary because the embedding and LM-head matrices are a small fraction of their parameters. On a compact model those matrices are a material share of per-token decode bandwidth, so on-device models ship small vocabularies and accept fragmentation outside a fixed language set. We present tokenizer expansion, an in-place recipe for upgrading a pre-trained model's tokenizer when the model producer controls its design. We continue the existing tokenizer's BPE merges on a multilingual corpus, so most source tokens carry over unchanged as single tokens and every new token has an exact decomposition into source tokens. We copy the carried-over embedding rows unchanged and initialize new rows as the mean of their source sub-token embeddings. A two-stage adaptation, embedding-only training then full-model continued pre-training, recovers source-checkpoint quality. We apply the recipe to a continued pre-trained checkpoint of LFM2-8B-A1B, an 8B-parameter Mixture-of-Experts model, to help produce LFM2.5-8B-A1B with a 128K tokenizer. The expanded tokenizer encodes Hindi and Vietnamese in roughly $2.4\times$ and $2.6\times$ fewer tokens than the source (up to $4.0\times$ on Thai). Combining these reductions with the measured per-token cost of the larger vocabulary, we estimate a $2.2$-$3.7\times$ per-character decode speedup for these languages across our reference devices. We release the model weights and the expanded tokenizer, and report the negative findings that shaped the recipe.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
In-Place Tokenizer Expansion for Pre-trained LLMs — Explained Simply
What is this paper about?
This paper shows a practical way to upgrade how a LLM breaks text into pieces (called “tokens”) so it works better for more languages, especially on phones and small devices. The authors expand the model’s “tokenizer” without throwing away the model’s past learning, making it faster and more efficient for languages like Thai, Hindi, and Vietnamese.
What questions are the researchers asking?
They focus on three main questions:
- How can we add better support for new or under-served languages without retraining a whole model from scratch?
- Can we expand the tokenizer in a way that keeps most of the model’s knowledge and quality?
- Does this upgrade actually make typing and reading in those languages faster and more efficient on devices like phones and laptops?
How did they do it? (Methods in everyday terms)
First, a quick analogy:
- Think of text as being built from Lego pieces. A tokenizer decides how big those pieces are. If your pieces are too tiny, you need lots of them to build a word, which takes longer. If pieces are right-sized, you use fewer pieces per word and build faster.
- Old tokenizers were optimized for English and code, so languages like Thai or Hindi got lots of tiny pieces, making them slow and expensive on devices.
Here’s the approach the authors used:
- Keep the original Lego set and continue adding new, larger pieces using the same building rules (“BPE merges”). This is like learning which tiny pieces often go together and turning them into a single bigger piece.
- Make sure every new big piece is exactly made from a few old smaller pieces. That way, nothing is mysterious or incompatible.
What about the model’s “memory” of pieces?
- Every token has a learned “embedding” (a number vector that tells the model what that piece means).
- For old pieces that carry over: copy their embeddings exactly.
- For each new piece: average the embeddings of the old pieces it’s made from (like mixing paint colors to get a good starting color).
How do they train after this change?
- Stage 1: Train only the new token embeddings (everything else in the model is frozen). This lets the new pieces settle in without messing up what already works.
- Stage 2: Unfreeze the whole model and continue training on a balanced mix of languages so the model adapts smoothly.
- After that, they run their regular “mid-training” and “post-training” steps (things like teaching it to handle longer contexts and polishing its skills).
What did they find, and why does it matter?
The results are both practical and measurable:
- Many languages now use far fewer tokens per word:
- Thai: about 4× fewer tokens
- Hindi: about 2.4× fewer tokens
- Vietnamese: about 2.6× fewer tokens
- Fewer tokens per word means fewer steps to generate text. On phones and laptops, that can make typing or reading results appear much faster.
- Even though a bigger vocabulary makes each step slightly heavier (about 7–10% slower per token), the overall per-character speed for these languages still improves a lot—roughly 2.2× to 3.7× faster.
- English and code stay basically the same length-wise, with a small per-character speed cost (up to ~9%) due to the larger output layer. That trade-off buys big wins for under-served languages.
- Model quality recovered and held steady:
- Right after swapping tokenizers (before training), quality dropped.
- Training Stage 1 (embedding-only) recovered most of the dip.
- Training Stage 2 (full model) matched or exceeded the starting quality on their benchmark tests.
- Important lessons they learned (what didn’t work well):
- Training the whole model immediately after the swap could hurt quality; warming up by training only the new embeddings first works better.
- The language mix in training matters. If they used mostly English data, some tasks got worse. A balanced multilingual mix fixed that.
Why is this important?
- Fairness and accessibility: People who use Thai, Hindi, Vietnamese, and other languages get faster, smoother results without needing a huge, cloud-only model.
- Efficiency on devices: On-device models are limited by memory and energy. This method improves performance where it matters most—how quickly text appears—without needing to rebuild everything from scratch.
- Practical upgrade path: Companies can improve language support for already-deployed models by “expanding” the tokenizer in place, rather than starting over.
In short
The team found a clever, careful way to grow a model’s vocabulary so it works better for more languages, especially on phones and other small devices. They do this by building new tokens out of old ones, gently retraining the model in two stages, and proving that it becomes faster for many languages while keeping (or improving) overall quality.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The paper proposes an in-place continued-BPE tokenizer expansion and a two-stage adaptation recipe, but several aspects remain untested or under-specified. Future work could address the following concrete gaps:
- Generalizability across architectures:
- Does the recipe transfer to dense transformer models, larger/smaller MoE topologies, or non-MoE architectures, and to models without tied embeddings/LM head (beyond the assertion that it “applies”)?
- How does expansion behave for different hidden sizes and depth (e.g., small 1–3B vs. ≥30B parameters)?
- Tokenizer family and algorithm assumptions:
- Can a comparable “continued training” construction be developed for unigram tokenizers (SentencePiece), WordPiece, or other non-BPE schemes? What are the analogues of deterministic decompositions and their quality implications?
- How does the method interact with byte-level choices and Unicode normalization (e.g., NFC vs. NFKC, combining marks), especially for scripts with diacritics?
- Minimal adaptation cost and schedule sensitivity:
- What is the minimal Stage 1 token budget and LR schedule needed to recover quality (600B is costly)? Can shorter Stage 1 and/or Stage 2 suffice without regressions?
- Sensitivity to learning-rate warmups, optimizer choice, and freeze/unfreeze schedules (e.g., progressive unfreezing vs. two-stage)?
- Embedding initialization design space:
- Ablations on alternative initializers beyond unweighted means (e.g., frequency-weighted means, learned projection, distillation-based initializers) and their impact on convergence speed and final quality.
- Effect of decomposition length on initialization quality (some tokens decompose into up to 64 source tokens): do long decompositions slow convergence or degrade downstream performance?
- Data mixture and distribution shifts:
- More systematic study of Stage 2 data mixtures: quantify trade-offs between preservation of previously supported languages/domains and gains in under-tokenized languages; provide mixture recipes and reproducible weighting.
- Impact of expansion on domain performance outside languages (e.g., math, code, JSON/tooling tokens) under different mixtures, given observed small dips.
- Robustness and safety:
- Impact on safety alignment, toxicity, and jailbreak robustness in newly supported languages; does the expansion introduce new failure modes or bypasses?
- Effects on hallucination rates and calibration across languages after expansion.
- Code-switching and mixed-script inputs:
- How does the expanded tokenizer affect code-switching performance and robustness (e.g., Hindi–English, Vietnamese–English mixes), including segmentation behavior and generation fidelity?
- Benchmarks and evaluation breadth:
- Limited evaluation on generative, long-form multilingual tasks (beyond Global-MMLU MCQ). Add free-form QA, summarization, and instruction following in under-tokenized languages to isolate tokenizer effects.
- Direct perplexity and loss tracking per language pre- and post-expansion to quantify modeling quality independent of benchmark idiosyncrasies.
- Lack of Thai evaluation due to benchmark availability—construct or identify Thai benchmarks to confirm reported compression translates to quality and UX gains.
- Isolation of tokenizer effects:
- Controlled end-to-end latency/energy measurements with matched outputs (e.g., constrained decoding to fixed-length character outputs) to validate the synthesis-based speedup estimates and capture system-level effects.
- Isolation of tokenizer-only contribution to downstream chat/tool-use improvements by holding mid- and post-training fixed (e.g., A/B checkpoints with/without expansion under identical post-training).
- Long-context behavior:
- Effects of expansion on 32K/128K context performance, throughput, and memory use under realistic KV cache sizes and diverse device thermals. Does the per-token vocabulary penalty shrink as claimed in long contexts?
- Device and quantization coverage:
- Throughput and energy characterization across more devices (other mobile SoCs, x86 CPUs, discrete GPUs) and quantization schemes (Q8, Q5, Q3, mixed-precision, KV-only quantization). Are conclusions stable across deployment profiles?
- Batch-size sensitivity (BS>1, speculative decoding, assisted decoding) and its interaction with vocabulary-size penalties.
- Energy and memory footprint:
- Measure per-character energy consumption and DRAM bandwidth utilization on devices (not just tokens/sec), and evaluate real-world battery impact for target languages.
- Memory footprint and residency constraints on devices with tight RAM budgets; measure paging/fault risks from the larger LM head in multi-app scenarios.
- Router and expert dynamics (MoE-specific):
- Provide the promised diagnostics: how does expert load/routing change after expansion? Do new-language tokens shift specialization or cause imbalance?
- Impact on expert capacity and drop rates for rare/long-decomposition tokens.
- Vocabulary scaling beyond 128K:
- Complete and extend the partial scaling study: quantify the knee where added merges stop paying for additional languages; model the Pareto frontier of compression gains vs. LM-head penalties across 128K/192K/256K+.
- Explore adaptive or per-device vocabularies (e.g., pruned LM heads) to mitigate per-token costs while preserving compression for specific deployments.
- Alternative deployment optimizations:
- Investigate LM-head compression (e.g., low-rank factorization, product quantization, block-sparse projections) to reduce the per-token penalty of larger vocabularies without harming accuracy.
- Explore dynamic or selective softmax over language-specific sub-vocabularies during decoding.
- Tokenizer design trade-offs:
- Compare continued-BPE expansion directly against vocabulary union methods and against re-trained tokenizers with CVA, holding adaptation tokens constant; report compression, quality, training cost, and latency side by side.
- Analyze unreachable/low-utility tokens and pruning strategies post-expansion to avoid dead capacity.
- Backward compatibility and ecosystem impacts:
- Operational impacts of changing token IDs (e.g., prompt caching, retrieval indices, tool schemas, safety filters). Provide migration guidance or mapping tools that preserve caches and embeddings for downstream systems.
- Data transparency and reproducibility:
- Detailed disclosure of the multilingual corpora, weighting, and filtering used for continued BPE and Stages 1–2; release scripts and seeds to enable replicable expansions on other bases.
- Applicability beyond languages:
- Evaluate expansion targeted at specialized domains (biomedicine, legal, code-specific libraries) and measure whether domain-specific merges yield similar latency-quality trade-offs.
- Error and noise robustness:
- Effects on noisy inputs (typos, OCR artifacts, informal transliterations) in under-tokenized languages—does expansion improve or degrade robustness?
- Tool use and structured I/O:
- Verify that changes to token segmentation do not regress tool-call adherence and JSON formatting across languages; provide tests for function-call tokens and schema compliance.
- Catastrophic forgetting and preservation:
- Quantify regression risk with larger multilingual weighting in Stage 2 across a wider set of English/code tasks; explore regularizers or replay to preserve capabilities.
- Theoretical understanding:
- Formal analysis of why the mean-of-subtokens initializer plus Stage 1 works: conditions under which centroids approximate internal token representations; effect of subtoken semantic heterogeneity on convergence.
- Economic comparison:
- Cost-benefit analysis of tokenizer expansion vs. re-pretraining from scratch or training multiple language-specific variants, considering compute, latency, and maintenance costs.
Practical Applications
Practical Applications Derived from “In-Place Tokenizer Expansion for Pre-trained LLMs”
Below are actionable, real-world uses of the paper’s findings and methods, grouped by time-to-deploy. Each item includes sectors, potential tools/products/workflows, and feasibility assumptions or dependencies.
Immediate Applications
- Accelerate and broaden on-device assistants in under-served languages (Hindi, Vietnamese, Thai, Bengali)
- Sector: Mobile/consumer tech, OEMs, voice assistants, accessibility
- What: Swap in the expanded 128K tokenizer (or use LFM2.5-8B-A1B) to cut tokens for target scripts, yielding 2.2–3.7× faster per-character decoding; improve responsiveness and battery life on phones and laptops
- Tools/workflows: Integrate the released tokenizer/model; run per-language latency/fertility checks; re-quantize LM head for device targets (e.g., llama.cpp/ggml pipelines)
- Assumptions/dependencies: Model producer controls tokenizer or adopts the released one; ~100 MiB extra memory for the larger LM head; accepts ~7–10% per-token decode throughput drop for languages near parity (e.g., English)
- Offline, multilingual customer support kiosks and IVR systems with lower latency
- Sector: Retail, telecom, banking, public services
- What: Edge-deploy LLMs to handle queries in Southeast Asian and Indic languages with reduced latency/energy
- Tools/workflows: Device-targeted quantization; language-aware routing to the expanded tokenizer; A/B latency and CSAT evaluation by language
- Assumptions/dependencies: Sufficient on-device RAM to hold the larger LM head; balanced multilingual fine-tuning to avoid regressions
- Keyboard prediction, autocomplete, and input-method editors in local languages
- Sector: OS vendors, keyboard apps, accessibility
- What: Faster token generation for non-Latin scripts improves suggestion latency and battery life
- Tools/workflows: Swap in expanded tokenizer; re-run short SFT for UX style; telemetry on latency and keystroke savings
- Assumptions/dependencies: Minor regression tolerance for English/code (≤~9% per-character slowdown) acceptable
- On-device summarization and translation for privacy-sensitive documents in non-Latin scripts
- Sector: Enterprise productivity, legal, healthcare administration, government
- What: Faster offline summarization/transcreation in Thai/Hindi/Vietnamese; smaller end-to-end wall-clock time and energy use
- Tools/workflows: Batch-mode summarization apps; document pipelines with language detection; per-language throughput benchmarking
- Assumptions/dependencies: Sufficient device memory; availability of quality evaluation datasets in target languages
- Developer toolchain: “Tokenizer Expansion Kit” for in-house models
- Sector: AI/ML platform teams, model producers, academia
- What: Apply continued-BPE extension and the two-stage adaptation recipe (embedding-only → continued pre-training) to existing checkpoints without restarting from scratch
- Tools/workflows: Scripts to continue BPE merges; deterministic decomposition mapping; embedding init via mean-of-subtokens; Stage 1 freeze of copied rows; Stage 2 balanced multilingual CPT; router health monitoring for MoE
- Assumptions/dependencies: Access to the original tokenizer merges; multilingual corpora (weighted to under-tokenized languages); significant compute budget (≈600B tokens Stage 1 + ≈400B tokens Stage 2 in the paper’s reference)
- Serving and evaluation playbooks that use fertility and per-character latency as first-class metrics
- Sector: Model ops, MLOps, QA
- What: Standardize measurements that reflect user-visible performance: tokens/word (fertility), decode t/s deltas from vocab size, and synthesized per-character speedups
- Tools/workflows: Fertility dashboards; per-language regression tests (e.g., Global-MMLU slices); llama-bench or similar device benchmarks
- Assumptions/dependencies: Multi-language test suites and monitoring in CI/CD; device-farm access for reproducible latency measures
- Energy and sustainability optimizations for edge deployments
- Sector: Green IT, device OEMs, telcos
- What: Lower joules/character in under-served languages; reduce thermal throttling in mobile chips
- Tools/workflows: On-device power profiling during decode; adaptive temperature/sampling policies to leverage faster tokens/character
- Assumptions/dependencies: Hardware counters and thermal management APIs; acceptance of slight regressions for English/code
- Safer, controlled upgrade path for existing on-device products
- Sector: Consumer apps, enterprise software
- What: Preserve capability while expanding language coverage, avoiding regressions with the paper’s staged recipe and multilingual mixture
- Tools/workflows: Freeze copied rows in Stage 1; balanced Stage 2 mixture; post-upgrade non-regression suite; rollback plan
- Assumptions/dependencies: Access to training pipeline; ability to collect or license multilingual data; monitoring of MoE router load balancing
- Academic replication and instruction
- Sector: Academia, research labs
- What: Teach and replicate CVA at scale; explore ablations (e.g., why full unfreeze too early degrades performance)
- Tools/workflows: Public checkpoints/tokenizers; controlled comparisons across stages; multilingual benchmarks; ablation templates
- Assumptions/dependencies: Compute and data availability; adherence to released licenses
- Data-center cost reductions for low-resource language workloads
- Sector: Cloud providers, localization platforms
- What: Even for server models (where LM-head cost is a small fraction), the token reduction lowers total FLOPs and wall time for target languages
- Tools/workflows: Language-aware routing; per-language quota planning; cost modeling with fertility and TCO inputs
- Assumptions/dependencies: Multi-language traffic; willingness to maintain tokenizer variants or to adopt the expanded one universally
Long-Term Applications
- Continual, over-the-air tokenizer updates for regional markets
- Sector: Mobile OS, consumer apps
- What: Periodically extend merges to cover emerging languages/scripts; ship small, targeted vocab upgrades with lightweight Stage 1 adaptation
- Tools/products: OTA “tokenizer packs”; incremental embedding-only updates
- Assumptions/dependencies: Efficient patching of LM-head rows; device-friendly safety/quality validation; bandwidth constraints
- Domain- or organization-specific vocabulary expansion (jargon, code, logs)
- Sector: Enterprise software, dev tools, cybersecurity
- What: Continue BPE merges on in-domain corpora to compress specialized tokens (e.g., log keys, API names), boosting throughput and context efficiency
- Tools/products: “CVA-for-domain” pipelines; domain fertility analyzers; change-control for vocab/merges
- Assumptions/dependencies: Proprietary corpora access; governance for tokenizer drift; retraining budgets for Stage 2 when needed
- Hardware–software co-design to offset LM-head scaling costs
- Sector: Semiconductors, inference SDKs
- What: New kernels and memory layouts for large vocab LM-heads (e.g., submatrix/partitioned softmax, block-sparse heads, PQ/low-rank LM-head compression)
- Tools/products: Vendor-optimized libraries; vocabulary-partitioned caches
- Assumptions/dependencies: Hardware support for sparse/partitioned ops; accuracy validation for compressed heads
- Architectural innovations: vocabulary routing and expert heads
- Sector: Foundation model R&D
- What: Route tokens by script/language to head subsets or expert heads to avoid full 128K projection each step; combine with MoE routing
- Tools/products: Mixed-vocab heads; language/script detectors integrated into decode loop
- Assumptions/dependencies: Model changes and training from checkpoints; careful evaluation to avoid accuracy regressions
- Federated or privacy-preserving tokenizer expansion
- Sector: Privacy-first apps, healthcare, finance
- What: Learn new merges from on-device text distributions without centralizing raw data; aggregate merge statistics or differentials
- Tools/products: Federated continued-BPE trainers; secure aggregation protocols
- Assumptions/dependencies: Legal/ethical frameworks; device participation rates; robustness against drift and poisoning
- Policy and standards for “tokenization equity”
- Sector: Public sector, standards bodies, NGOs
- What: Require reporting of token fertility and per-character latency by language in public AI procurement; encourage inclusion of underserved scripts
- Tools/products: Standardized fertility/latency scorecards; certification programs
- Assumptions/dependencies: Stakeholder consensus; availability of multilingual benchmarks and evaluation infrastructure
- Language-aware serving that prunes LM-head reads at runtime
- Sector: Inference platforms
- What: For detected language/script, read only relevant LM-head slices to reduce memory bandwidth per token
- Tools/products: Dynamic LM-head slicers; compile-time graph transforms
- Assumptions/dependencies: Requires architectural change and careful calibration to avoid wrong-token omissions
- Standardized benchmark suites and corpora for under-tokenized scripts
- Sector: Academia, open-source, evaluation startups
- What: Curate high-quality multilingual datasets emphasizing Southeast Asian/Indic languages; track tokenization fairness and decode economics
- Tools/products: Public leaderboards reporting fertility and per-character speed; dataset packs
- Assumptions/dependencies: Licensing for multilingual data; community participation
- Edge–cloud synergy: language-aware pre-tokenization at the edge
- Sector: Cloud, telecom
- What: Edge devices re-tokenize/compress user inputs in local scripts before sending to cloud, reducing bandwidth and cloud compute
- Tools/products: Gateway services; on-device adapters
- Assumptions/dependencies: Trust and security boundaries; consistent tokenizers across edge and cloud
- Multi-modal and robotics assistants with robust multilingual command handling
- Sector: Automotive, AR/VR, robotics
- What: Faster language understanding/generation for commands in under-served scripts; improved responsiveness in real-time settings
- Tools/products: On-device agents with expanded tokenizer; real-time latency monitors
- Assumptions/dependencies: Tight integration with ASR/TTS; further optimization for long contexts and KV-cache management
Cross-cutting assumptions and dependencies to consider
- Control over tokenizer and access to merge tables is key; the continued-BPE approach assumes the producer can extend the original tokenizer.
- Data is decisive: Stage 2 requires a balanced multilingual mixture to avoid regressions; under-weighting target languages can hurt generative quality.
- Compute and memory budgets: Expect significant training tokens for adaptation (paper uses ~1T tokens across stages) and ~100 MiB added footprint for the LM-head at 128K vocab.
- Device behavior: Gains are largest in decode (memory-bandwidth-bound); prefill throughput is largely unaffected. Very long contexts increase KV-cache share, diluting LM-head penalties/benefits.
- Evaluation and safety: Run per-language non-regression suites (e.g., Global-MMLU by language), instruction-following checks post mid/post-training, and MoE router health diagnostics during adaptation.
- Licensing and deployment: Confirm model/tokenizer licenses, regional data compliance, and distribution constraints (e.g., OTA updates, app store policies).
These applications turn the paper’s core innovation—continued-BPE tokenizer expansion plus a two-stage adaptation that preserves capability—into concrete gains in latency, energy, and language coverage, especially on constrained, on-device deployments.
Glossary
- Byte-level BPE tokenizer: A tokenizer that operates on bytes and builds tokens via Byte-Pair Encoding merges. "The expanded tokenizer is a byte-level BPE tokenizer"
- Continued-BPE construction: Extending an existing tokenizer by continuing its BPE merge training on new data. "The continued-BPE construction itself is shared with independent, concurrent work"
- Continued pre-training (CPT): Further training of a pre-trained model on additional data to adapt or improve it. "Stage 2: Continued Pre-training"
- Cross-lingual vocabulary adaptation (CVA): Expanding a model’s vocabulary and continuing training to improve coverage for new languages. "We refer to this procedure as tokenizer expansion, a form of cross-lingual vocabulary adaptation (CVA)"
- Decode latency: The time cost incurred per generated token during inference. "this fragmentation raises decode latency, compute, and energy consumption"
- Decode throughput: The rate of token generation during decoding, typically measured in tokens per second. "Decode throughput drops by 8.6% on the M4 Max CPU, 7.4% on the M4 Max GPU, and 9.4% on the Snapdragon 8 Elite Gen 5"
- Embedding initialization: The method used to set initial values for new token embeddings. "Section~\ref{sec:embed_init} uses this decomposition for embedding initialization."
- Embedding matrix: The parameter matrix mapping token IDs to continuous vector representations (and to logits if tied with the LM head). "the pre-trained model's embedding matrix is reinitialized for the new vocabulary"
- Embedding-only training: A training phase where only the embedding parameters (often new rows) are updated while the rest of the model is frozen. "A two-stage adaptation, embedding-only training then full-model continued pre-training, recovers source-checkpoint quality."
- Expert load balancing: Ensuring MoE experts are utilized evenly during routing to prevent under/overuse. "We monitored expert load balancing and router health throughout the adaptation"
- Expert routing: The mechanism in MoE models that directs tokens to specific expert sub-networks. "As an MoE model, it requires healthy expert routing."
- Fertility (token fertility): The average number of tokens a tokenizer uses per word; a measure of tokenization efficiency. "Token fertility is the average number of tokens a tokenizer uses per word"
- Global-MMLU: A multilingual rendering of the MMLU benchmark covering many languages. "Global-MMLU \citep{singh2024globalmmlu} renders the full MMLU test set"
- KV cache: The stored key and value tensors for attention across decoding steps to speed up inference. "The main thing it leaves out is the KV cache"
- Leaf-based pruning: A tokenizer-side technique to remove unused or unreachable tokens/merges from the vocabulary. "compression, avoidance of unreachable tokens, leaf-based pruning"
- LM-head: The output projection layer mapping hidden states to vocabulary logits. "the embedding and LM-head matrices are a negligible fraction of total parameters"
- LM-head projection: The matrix multiplication that produces vocabulary logits at each decode step. "the output LM-head projection touches the full vocabulary dimension on every decode step"
- Mean-of-subwords centroid: Initializing a new token embedding as the average of its constituent sub-token embeddings. "The mean-of-subwords centroid we use is a simple, established baseline"
- Memory-bandwidth-bound: A performance regime where speed is limited by memory transfer rates rather than compute. "at batch size~1 decode is generally memory-bandwidth-bound"
- Mid-training: An intermediate training phase after (continued) pre-training and before post-training, often adding capabilities like longer context. "after which mid-training and post-training proceed to produce the final model"
- Mixture-of-Experts (MoE): A model architecture that routes inputs to a subset of specialized expert networks. "an 8B-parameter Mixture-of-Experts model"
- Post-training: Final training stages (e.g., instruction tuning, alignment) after pre/mid-training to refine model behavior. "Mid-training and post-training follow the LFM2.5 pipeline"
- Prefill: The initial forward pass over the prompt/context before autoregressive decoding begins. "Prefill is compute-bound and amortizes the LM-head reads across the input, so it barely moves with vocabulary size."
- Quantization (Q4_0): Reducing parameter precision (here, a 4-bit scheme) to speed up inference and reduce memory. "Measured with llama-bench ... at Q4_0 quantization"
- Router health: Diagnostics indicating whether the MoE router is functioning well (e.g., balanced, stable) during training. "We monitored expert load balancing and router health throughout the adaptation"
- Tied embeddings: A design where input embeddings and the output LM-head weights share the same matrix. "tie the input embedding and the output LM head"
- Tokenizer expansion: An in-place upgrade of a model’s tokenizer by adding new merges/tokens while preserving compatibility. "We present tokenizer expansion, an in-place recipe for upgrading a pre-trained model's tokenizer"
- Vocabulary union: Combining the vocabularies of two independently trained tokenizers into one larger set. "takes the union of its vocabulary with the source vocabulary"
- Zero-shot vocabulary swap: Replacing a model’s tokenizer without any adaptation training. "Stage 1 alone recovers most of the dip from the zero-shot vocabulary swap."
Collections
Sign up for free to add this paper to one or more collections.