This model card provides an overview of our tokenizer-free llama-3.1-70b-tfree-hat model based on Llama, a foundation model developed by Aleph Alpha Research* and publicly available under the Open Aleph License, a license explicitly allowing for non-commercial research and educational use.
The model is based on the Llama 3.1 70B base model’s pre-trained backbone, replacing the Llama tokenizer with our Hierarchical Autoregressive Transformer (HAT) architecture which is described originally in our paper. This novel architecture integrates character-level encoding and decoding with the word-level backbone, allowing for improved text compression (less sequence positions) and performance in the languages it has been trained on, and potentially higher robustness to prompt changes, as well as improved adaptability to new languages & domains via fine-tuning.
The model was pre- and post-trained in English & German on carefully curated data in compliance with applicable EU and national regulations, including copyright and data privacy laws. The model has not been optimized for code generation and math and is thus not evaluated extensively on respective benchmarks.
Please note that the realized inference speed strongly depends on the maturity of the inference implementation beyond the intrinsic text compression of any model. The current publicly available inference implementation is in a non-optimized state, hence any benchmark on speed must take account of that. We are releasing an optimized vLLM-based inference solution that is still under active development.
You can find all model weights and their corresponding safetensors conversions at the following links:
We provide access to our model through the channels listed below.
HuggingFace: The model’s weights are available on HuggingFace under the Open Aleph License, a license explicitly allowing for non-commercial research and educational use.
We do not collect PII (personally identifiable information) for any of these channels. We do not log user inputs to the models. We do not train on user data.
Note: The same models are made available to users regardless of their geographic location and their input language but subject to sanction regimes, technology export regulations, and other restrictions that may apply. The same offering is provided to all countries within and external to the European Union if no legal restrictions apply.
How to use
Inference
We release a vLLM-based inference implementation adapted to our llama-3.1-70b-tfree-hat model here. Please note that this inference implementation is still under active development.
Prompt formatting
The prompt format used for this model is identical to the Llama prompt format. We highly recommend using it when prompting the models to ensure optimal performance for the supervised fine-tuned and direct-preference-optimized model versions. You can format your prompt in the recommended format by setting add_llama_template=True in the model._prepare_input method.
Evaluation
Performance: Our T-Free model delivers strong performance in both English and German. For evaluation purposes, we compare our model with Llama-3.3-70B-Instruct. Respective benchmarks and results can be found in the tables below.
Efficiency: Our tokenizer-free approach results in improved text compression, providing a foundation for improved efficiency in inference speed. We measure in terms of words processed across all languages and domains. We define the metric as tokenizer fertility or bytes per sequence position, where a higher value indicates better performance. Latency and throughput are currently out of scope for research-centric evaluations and will be addressed in the future. Currently, our evaluation framework automatically measures bytes per sequence position across datasets, allowing us to derive text compression scores and analyze variations across different dataset distributions. The end to end resulting efficiency is dependend on the inference implementation beyond the scope of the here provided inference implementation and reported compression scores.
Disclaimer: The results presented below were generated using our internal inference implementation, not the inference module mentioned above.We plan to make source-available both our evaluation framework and a high-performance vLLM integration for this model in the coming weeks to ensure reproducibility. Our goal with this initial release is to provide the community with a straightforward codebase that demonstrates the architecture and supports basic inference capabilities.
Metric Glossary
log_acc: Average Accuracy Loglikelihood norm_log_acc: Average Normalized Loglikelihood Accuracy comp_acc: Average Completion Accuracy norm_prob_mass: Average Probability Mass Normalized bleu: Average BLEU Score rouge_gm: Average ROUGE-Geometric-Mean F1: Average F1 CS: Chatbot Style IF: Instruction Following LC: Language Consistency CI: Concordance Index ES: Exponential Similarity
SFT Benchmarks
MTBench winrates
English/German MTBench numbers are based on datasets created with FastChat for the corresponding models.
The model uses a hierarchical autoregressive architecture consisting of three components: encoder, backbone, and decoder together with connector layers between components. Encoder, backbone, and decoder are all instances of autoregressive transformers with pre-norm residual blocks in the style of Llama, using a SwiGLU unit as a feed-forward block, with all model parameters active during training and inference. The backbone model uses standard causal attention, while the encoder and decoder use local causal attention with a finite look-back window.
The encoder processes input text as a sequence of UTF-8 bytes and produces a sequence of activations of the same length. This sequence is then split into chunks corresponding to words or other semantic units in the text (this is further explained below). In the encoder-backbone connector layer, for each word, a learned latent vector cross-attends to its corresponding chunk of encoder activations. The resulting sequence of latent vectors then serves as input to the backbone. The backbone processes this latent sequence and produces a sequence of word-level representations. Finally, the decoder module is another transformer that acts on the byte-level activations and has an LM head that produces next-byte probabilities. To make use of the higher level information stored in the word-level embeddings during decoding, another cross-attention mechanism is used. In each transformer block of the decoder, every byte-level position cross-attends to the backbone’s word-level representations that correspond to the words preceding this byte.
To split arbitrary byte sequences, we adopted the guidelines from UAX #29, which splits text into words for common Western languages but also produces meaningful semantic units for other types of languages (e.g. Chinese, Japanese, Korean). From now on, we refer to these splits as words.
We also merged leading whitespace and trailing punctuation into the words to reduce sequence length at the word level.
To improve the processing of code and math documents, we made additional adjustments to the Unicode splitter. First, we split instances of camel cases like FooBar into Foo and Bar. Second, we treated math symbols (again by Unicode standard) as separate words.
Pre-Training
Approach
We randomly initialized all model parameters of the encoder, decoder, and connector layers. The backbone architecture precisely matches the Llama 3.1 70B architecture, this allowed us to initialize the weights to the pre-trained Llama 3.1 70B base model weights. The model was then trained on the next-byte-prediction objective on a large and diverse document corpus (see below). Initially, we trained on sequences up to 3500 words with global batch size of 1024 for 30,000 steps, totaling to an amount of 108B words. We then continued training on sequences of up to 16000 words with global batch size 128 for another 5000 steps, totalling to another 10.2B words, where we upweight longer documents to make use of the extended context. The training was conducted in our Scaling framework.
Data sources
The model was trained on a filtered subset of diverse corpora of text data including proprietary curated datasets, high-quality web content, public domain sources, German texts, mathematical texts, and programming code. The proportions and sources of data we used in the pre-training were:
English Language Data (70%)
curated web and synthetic data (63%)
high quality curated sources such as Wikipedia and public domain books (7%)
German Language Data (7%)
curated web and synthetic data (6.3%)
high quality curated sources such as Wikipedia and public domain books (0.7%)
Mathematical Content (5%)
mathematical code and proofs (2%)
mathematical word problems and equations (3%)
Programming Code (18%)
general programming code (11%)
high-quality and synthetic Python code (7%)
Data curation
We applied a range of curation techniques, e.g., for German as described in Aleph-Alpha-GermanWeb. These include but are not limited to:
URL filtering. We used a URL filter developed to filter out fraudulent, harmful, and illegal content from an explicit blocklist, e.g., adult websites, or URLs containing words associated with fraudulent, harmful, or adult content.
Text extraction. Natural language texts which were embedded HTML and other web programming languages were extracted using the Resiliparse text extractor.
Language identification. We used a fastText language classifier trained on character n-grams from Wikipedia to identify, retain, and sort texts into English and German.
Repetition removal. We applied heuristic methods for detection and removal of repetitions on the line, paragraph, and character level.
Document- and line-level filtering. We utilized additional document-level heuristics to ensure documents had reasonable numbers and quality of words, naturalistic symbols-to-words and numbers-to-words ratios, not predominantly made up of bullet points, and a sufficient quantity of real words.
Deduplication. Using exact and fuzzy deduplication to remove duplicate documents.
Synthetic data
We also generated synthetic data by using permissively-licensed LLMs.
Instruction Fine-tuning
Approach
We optimized llama-3_1-70b-tfree-hat-sft for instruction-following using a standard post-training pipeline. We applied supervised fine-tuning (SFT) to train the model on both single-turn and multi-turn (chat) instruction-following tasks.
Data
The data used for instruction fine-tuning is based on a mixture of user prompts and model competitions. The data mixture consists of roughly 2M samples from diverse datasets including but not limited to: specialized reasoning datasets covering mathematics, programming, and logical inference; human feedback focused on helpful and harmless responses; a small curated set for specific response patterns; safety and robustness subsets for appropriate boundaries; collaborative conversational data; multilingual conversation prompts; tabular data reasoning for structured information; and formal mathematics with advanced problems.
We synthesized responses to the prompts using Qwen 2.5-32B and Qwen 2.5-72B. Additionally, we improved German performance by translating English prompts using Mistral-Nemo-Instruct-2407, generating the corresponding answers using Mistral-Small-3.1-Instruct, and performing quality filtering using an LLM judge based on Llama-3.3-70B-Instruct. Lastly, we supplemented the synthetic data with proprietary human-generated SFT data as well as further data sources.
Legal Compliance
We acknowledge and abide by applicable national and international regulations, including copyright, data privacy, and other related legislation. Any text and data mining by us is performed in compliance with Directive (EU) 2019/790 and its respective national transposition. During the training and fine-tuning of our models, we comply with applicable data privacy laws, including Regulation (EU) 2016/679 (GDPR) and national data privacy regulations. To the extent possible and foreseeable, we also took legislation with forthcoming obligations into account, such as the obligations for General Purpose AI Models under Regulation (EU) 2024/1689 (EU AI Act), and will constantly monitor such developments and adapt our products and this model card accordingly.
Resource Usage
Compute & Training Efficiency
The following table shows the compute resources used in the training stages for the 70B model.
Model
Training phase
GPUs
Approximate average power consumption per GPU
Approximate GPU hours
70B
Continued pre-training
512 x H200
460W
49,920
70B
Long context adaptation
256 x H100
160W
3200
70B
Long context SFT
512 x H100
160W
12290
Environmental Impact
Our H200 and A100 infrastructure runs entirely on 100% renewable energy, ensuring that no CO₂ emissions are directly incurred from training. In addition to this, the H200 data center boasts a power usage effectiveness (PUE) of ≤1.2. Its operation also maintains a net-zero water footprint. Specific number on renewable energy usage for the H100 GPUs is not yet available to us.
To estimate the carbon footprint of inference, we base our calculations on publicly available data from the infrastructure provider and, where applicable, standard emissions accounting methodology. We report:
Carbon emitted: GPU runtime emissions
Carbon emitted accounting for PUE: GPU runtime emissions scaled by the data center's PUE
Because the data centers operate fully on renewable energy, both metrics for its operation (excluding infrastructure-related emissions, e.g., initial chip manufacturing) are effectively zero. For H100 GPU infrastructure no information has been made available to us.
Metric
H200 GPU
H100 GPU
A100 GPU
Carbon emitted
0 kg CO₂
no information available
0 kg CO₂
Carbon emitted accounting for PUE
0 kg CO₂
no information available
0 kg CO₂
Power Consumption
GPU Model
Max Power (W)
A100
400 W
H100
700 W
H200
700 W
Numbers may be contextualized with reference to publicly available studies, such as the carbon footprint of language model training.
Intended Use
These models are intended to be deployed as components of AI systems or applications. Use-cases and the model's capabilities include but are not limited to: text generation, classification, summarization, question answering, and labeling. Note that applications might require additional model adaptations or components for guarding against unwanted application behavior or model output.
Non-Permitted Use
Our models shall not be used for illegal or unlawful actions of any kind and with any illegal or unlawful content. This includes in particular prohibited practices according to Article 5 of Regulation (EU) 2024/1689 (EU AI Act) and other activities such as engaging in terrorism, violence, human trafficking, illegal distribution of materials to minors, sexual solicitation, any other criminal activities, harassment, discrimination, creating or promoting malicious code or activities risking death or harm, including those related to military or nuclear applications, and activities not in compliance with sanction regimes, technology export regulations, and other restrictions that may apply. The models are to be used following ethical standards. The utilization of our technology is always governed by, and may be limited in accordance with, our Terms and Conditions, the Open Aleph License, or any specific agreement we might have established with you.
Although we do not inspect the requests sent to our API, we regularly review and monitor potential violations that may be related to our models and depending on the circumstances of the specific case take legal action against them. This includes but is not limited to, enforcement to remove published model content, requesting compensation for damages caused, and account termination or removal of credits.
For non-anonymous reports, we also provide an appeals mechanism for usage policy violations via our dedicated contact address violations@aleph-alpha.com to communicate with us.
Customers and partners are enabled to use our ticketing system for appeals, claims, and feedback.
Risks and Limitations
Note: Language models are not agents and not optimized for prescriptive actions. The use of language models in high-stake environments, for critical decisions or to support a user's wellbeing should be performed with additional guardrails in place.
Risk Categories
In the following sections, we describe risk categories and provide examples of completions we would consider inappropriate or harmful. We then describe steps to minimize these risks.
Harmful Language
Large language models can sometimes generate undesired outputs that are unsuitable for certain applications. This includes producing content with harmful language, discriminative content, inappropriate tone and style, systemic biases, or suggestions that might encourage illegal actions. Such outputs can also include incorrect, outdated information, or material that is not suitable for all ages. While we constantly take efforts to reduce the likelihood of such undesired outputs, this possibility can never be fully ruled out. To minimize these issues, the following strategies can be employed:
Abide by the guidance on illegal use provided for in this Model Card.
Crafting prompts carefully to guide the model's output more effectively.
Utilizing a finetuned model (often referred to as a control or instruct model) that prioritizes using explicitly provided information.
Employing a finetuned model designed to maintain an appropriate tone and style, including avoiding offensive language.
Conducting additional validations at the application level to ensure output quality and appropriateness.
Systemic Biases
Language models obtain world-knowledge from their pre-training data and may therefore exhibit the same systematic biases that are present in the data. Differing deployment scenarios (including differing cultural contexts) can expose systematic biases in different ways. We acknowledge the cultural diversity of communities and users inside and outside the EU. For larger deployments, we encourage users to track systematic biases relevant to their use-case, and we are happy to consult on bespoke fine-tunings to alleviate such biases.
Outdated World Knowledge
Pre-training was performed using a fixed dataset, created at a fixed date in the past. Accordingly, the world knowledge of foundation models is limited to the information contained in its training data. More recent information may not be known to the model or misunderstood when presented as input during live usage.
Risks include:
Generation of personally identifiable information. Models are not explicitly trained to provide such information, but may seem to provide personally identifiable information. This does not necessarily imply the presence of such information in training data, as hallucination is possible.
Generation of unintended, irrelevant, or repetitive outputs. This includes the production of incorrect or outdated information.
Risks may be mitigated by:
Injecting context, where relevant.
Crafting prompts carefully to guide the model's output more effectively.
Performing validations on the application layer, e.g., classifying the output.
Using the repetition penalty, especially in the case of repetition, or other parameters available in the API (see documentation).
Avoiding of use cases targeted at retrieval of personally identifiable information.
Political Bias
Our models have not been optimized to represent a political opinion or take a specific point of view. They may generate outputs that contradict a user's opinion or expectation, e.g., produce hateful, violent or inappropriate, biased, or discriminatory content. Such behavior may be addressed by:
Crafting prompts carefully to guide the model's output more effectively.
Performing validations on the application layer, e.g., via Red-Teaming or classifying the output.
Mistaken for a Human
Users may attribute human traits to AI models. This also includes the fact that content generated by the model is not explicitly detectable at this point. It is therefore required to:
Inform end users that they are interacting with or reading output of an AI.
Design the system in a way that mitigates the impact of unintended interpretation of the output.
Other Errors
Any AI module can produce errors, even after implementing all the recommended measures. When integrating foundation language models into an application, users should:
be aware of the risk of (harmful) failure cases and implement the use case in a way that mitigates such risks.
be aware that foundation models do not contain application logic, e.g., content filters. Enforcement policies relevant to the use case need to be implemented in the application layer.
avoid unsupervised use in high-stakes environments.
validate output with adequate measures.
Mitigation Approach
We specifically tailor model alignment and risk mitigation techniques to each user-facing application built on top of our models, working closely with our customers to refine them according to their unique requirements. Our intention is for these models to undergo further fine-tuning by us and our customers, utilizing their own datasets alongside our support and datasets to ensure suitability for end-user applications, including harm mitigation efforts. Our customers are responsible for adhering to the terms and conditions when aligning the models in their downstream applications.
Reproducibility
Some inference parameters, e.g., temperature, lead to the random sampling of outputs, which precludes the reproducibility of outputs. Even when such parameters are not in use, outputs may diverge slightly on a numeric level for technical reasons. One may implement the following measures if needed:
Logging of past model outputs on the application layer (Aleph Alpha Research is not storing any data and/or using any data provided in prompts for the training of its LLMs).
This list of risks, biases, and limitations may not be complete, as improving the understanding and behavior of language models is an ongoing research topic in the AI science community.
