DeepMath blog

Code: https://github.com/intellabs/DeepMath
Model: https://huggingface.co/Intel/deepmath-v1

Author: danielfleischer

1_58_llm_extreme_quantization.md

@@ -59,7 +59,7 @@ model = AutoModelForCausalLM.from_pretrained(
 )    
 tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")
 
-input_text = "Daniel went back to the the the garden. Mary travelled to the kitchen. Sandra journeyed to the kitchen. Sandra went to the hallway. John went to the bedroom. Mary went back to the garden. Where is Mary?\nAnswer:"
+input_text = "Daniel went back to the garden. Mary travelled to the kitchen. Sandra journeyed to the kitchen. Sandra went to the hallway. John went to the bedroom. Mary went back to the garden. Where is Mary?\nAnswer:"
 
 input_ids = tokenizer.encode(input_text, return_tensors="pt").cuda()
 output = model.generate(input_ids, max_new_tokens=10)

_blog.yml

@@ -4905,3 +4905,30 @@
     - mlx
     - community
     - open-source
+
+- local: open-asr-leaderboard
+  date: Nov 21, 2025
+  tags:
+    - audio
+    - speech
+    - leaderboard
+
+- local: rapidfireai
+  date: Nov 21, 2025
+  tags:
+    - llm
+    - experimentation
+    - fine-tuning
+    - post-training
+    - trl
+    - rapidfireai
+
+- local: intel-deepmath
+  date: Nov 25, 2025
+  tags:
+    - llm
+    - reasoning
+    - agents
+    - math
+    - grpo
+

anylanguagemodel.md

@@ -1,6 +1,6 @@
 ---
 title: "Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms"
-thumbnail: /assets/anylanguagemodel/banner.png
+thumbnail: /blog/assets/anylanguagemodel/banner.png
 authors:
 - user: mattt
   guest: true

assets/intel-deepmath/banner.png

@@ -627,7 +627,7 @@ class DataCollatorCTCWithPadding:
     Data collator that will dynamically pad the inputs received.
     Args:
         processor (:class:`~transformers.Wav2Vec2Processor`)
-            The processor used for proccessing the data.
+            The processor used for processing the data.
         padding (:obj:`bool`, :obj:`str` or :class:`~transformers.tokenization_utils_base.PaddingStrategy`, `optional`, defaults to :obj:`True`):
             Select a strategy to pad the returned sequences (according to the model's padding side and padding index)
             among:

assets/open-asr-leaderboard/thumbnail.png

@@ -786,7 +786,7 @@ class DataCollatorCTCWithPadding:
     Data collator that will dynamically pad the inputs received.
     Args:
         processor (:class:`~transformers.Wav2Vec2Processor`)
-            The processor used for proccessing the data.
+            The processor used for processing the data.
         padding (:obj:`bool`, :obj:`str` or :class:`~transformers.tokenization_utils_base.PaddingStrategy`, `optional`, defaults to :obj:`True`):
             Select a strategy to pad the returned sequences (according to the model's padding side and padding index)
             among:

assets/rapidfireai/thumbnail.png

@@ -0,0 +1,143 @@
+---
+title: "DeepMath: A Lightweight Math Reasoning Agent for LLMs"
+thumbnail: /blog/assets/intel-deepmath/banner.png
+authors:
+- user: danf
+  guest: true
+  org: Intel
+---
+
+<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/intel-deepmath/deepmath-figure.jpg" style="width:600" alt="An LLM is using a calculator to answer questions." />
+
+# DeepMath: A Lightweight Math Reasoning Agent for LLMs
+
+*By Intel AI — Daniel Fleischer, Moshe Berchansky, Moshe Wasserblat*
+
+
+Large language models (LLMs) have made impressive strides in reasoning tasks, yet mathematical problem-solving remains a challenge. Traditional "chain-of-thought" reasoning often produces verbose explanations and error-prone arithmetic. **DeepMath** tackles this by combining a small Python executor with a fine-tuned LLM, enabling concise, computation-driven reasoning.
+
+## The Big Idea
+
+DeepMath is built on **Qwen3-4B Thinking** and fine-tuned with **GRPO (Group Relative Policy Optimization)**. Instead of verbose text, the model emits **tiny Python snippets** for intermediate steps, runs them in a secure sandbox, and folds the results back into its reasoning, reducing errors and output length.
+
+✅ No file I/O, no network calls, strict timeouts.
+
+✅ Safe, deterministic, and auditable.
+
+We evaluate DeepMath on four math datasets: **MATH500, AIME, HMMT, and HLE,** and show that:
+
+- The math agent alone improves accuracy and reduces verbosity.
+
+- GRPO training alone biases outputs toward brevity and correctness.
+
+- Combining the agent with GRPO yields the largest gains.
+
+👉 Code and evaluation scripts: <https://github.com/IntelLabs/DeepMath>
+👉 Model: <https://huggingface.co/Intel/deepmath-v1>
+
+## Why DeepMath?
+
+LLMs often struggle with numeric precision and produce unnecessarily long reasoning chains. Two opportunities stand out:
+
+1. **Offload deterministic computation** to a safe executor.
+
+2. **Train models to prefer concise, computation-oriented traces** over verbose text.
+
+DeepMath implements both. The model learns to generate short Python snippets, which are executed in a sandbox and reintegrated into the context. GRPO fine-tuning encourages this behavior by rewarding correctness and encouraging shoter outputs.
+
+## How It Works
+
+- Base model: [Qwen3-4B Thinking](https://huggingface.co/Qwen/Qwen3-4B-Thinking-2507).
+- Executor constraints: sandboxed environment, allow-list of imported modules, per-snippet timeout.
+- Inference: based on [SmolAgents](https://github.com/huggingface/smolagents/), a math agent was created. vLLM is used as the inference engine.
+- Training: based on the GRPO trainer in [TRL](https://github.com/huggingface/trl), we modified TRL's vLLM client and server to generate GRPO completions using our DeepMath agent.
+
+<figure>
+<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/intel-deepmath/trl-grpo-vllm-deepmath.png" style="width:400" alt="Changes to vLLM client and server in TRL library." />
+<figcaption><p>Figure 1: The vLLM client and server were modified to use the DeepMath agent in generating the candidates, while using the vLLM backend.</p></figcaption>
+</figure>
+
+- **Agent Interface:** During inference, the model can output normal tokens or special agent calls containing Python snippets.
+
+- **Execution:** Snippets run in a sandboxed environment with strict safety constraints (no file I/O, no network, timeouts).
+
+- **Design Goals:**
+
+  - **Concision:** Replace multi-line textual calculations with short, focused snippets.
+
+  - **Determinism & Safety:** Enforce strict execution limits.
+
+  - **Interpretability:** Snippets are readable and auditable.
+
+<figure>
+<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/intel-deepmath/output-example.png" style="width:700" alt="Output example: it contains a short python snippet as well as its output which is used in the reasoning process."/>
+<figcaption><p>Figure 2: Output example where python code is generated, evaluated and the answer is inserted into the trace and used for context.</p></figcaption>
+</figure>
+
+## Training with GRPO
+
+We fine-tune the model using **GRPO**, a reward-based optimization that balances:
+
+- **Accuracy Reward:** +1 for correct answers.
+
+- **Using code snippets:** +1 for generating code snippets, weighted 10:1 vs. the accuracy reward.
+
+- **Length reduction:** shorter lengths are encouraged by limiting the GRPO completion candidates to 5k tokens.
+
+- **Temperature Scheduling:** We implemented linear temperature scheduling (T=1.2 → T=0.7) to balance exploration and stability during training. This approach aims to enhance experimentation during the initial training phases, subsequently reducing the temperature as we refine our proficiency in the skill.
+
+- **In-context Learning**: we include 4 solved examples where the trace contains agent calls and executor outputs, so the model learns the syntax and the call/response pattern.
+
+- **Dataset**: we used [OpenMathReasoning](https://huggingface.co/datasets/nvidia/OpenMathReasoning) dataset, the tool-usage subset. Note that GRPO only uses the <u>problem</u>, not the solution in the data. Choosing this dataset ensures problems benefit form tool use.
+
+## Evaluation
+
+We benchmarked DeepMath against baselines on four datasets. Metrics include:
+
+- **majority@16** (robustness across samples).
+
+- **Mean output length** (brevity).
+
+<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/intel-deepmath/main-results.png" style="width:800" alt="Main results table."/>
+
+**Key Insight:** DeepMath reduces output length by up to **66%** while improving accuracy on challenging datasets.
+
+## Why It Matters
+
+- **Accuracy:** Offloading computation reduces arithmetic errors.
+
+- **Efficiency:** Shorter outputs mean faster inference and easier interpretability.
+
+- **Safety:** Sandbox execution mitigates risks of running arbitrary code.
+
+## Conclusion
+
+DeepMath demonstrates a practical and lightweight way to combine a small executor with an LLM and to train the model to prefer short, computation-driven traces. Offloading deterministic computation reduces arithmetic and numerical errors and shortens traces, and GRPO fine-tuning further encourages concise, correct answers. The result is a more accurate and more interpretable math-solving agent without requiring a massive model or heavyweight external tools.
+
+## Try It Yourself
+
+Check out the GitHub repo and share your feedback! Contributions welcome. 🚀
+
+<https://github.com/intel/DeepMath>.
+
+## Citation
+
+If you use DeepMath in your research, please cite:
+
+```bibtex
+@software{deepmath2025,
+  author = {Fleischer, Daniel and Berchansky, Moshe and Wasserblat, Moshe},
+  title = {DeepMath: A Lightweight Math Reasoning Agent for LLMs},
+  year = {2025},
+  publisher = {Intel AI Labs},
+  url = {https://github.com/IntelLabs/DeepMath}
+}
+```
+
+## Limitations & Future Work
+
+- **Scope**: we focused on a small model and on mathematical reasoning.
+
+- **Generalization**: evaluated on contest-style math; results may not transfer to open-ended mathematical creativity or formal proofs.
+
+- Executing generated code is inherently risky. DeepMath uses strict sandboxing and resource limits, but any deployment should carefully manage attack surfaces and enforce rate limits.

fine-tune-wav2vec2-english.md

@@ -311,7 +311,7 @@ Why does this matter to us? Well, we have seen that loading data from VRAM has a
 
 ![The arithmetic intensity of two GEMMs](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/mi300kernels/gemm_AI.png)
 
-In a skinny GEMM the number of rows of the output tile is limited and so is the the arithmetic intensity. Already this means that we are going to need to load a lot of data to compute an output tile. Furthermore, since we are using FP8 arithmetic, computation is quite fast, so we cannot rely on computation time to hide the latency of data loading. All in all, it would be ideal to have more threads in charge of loading data than threads in charge of computing the result. 
+In a skinny GEMM the number of rows of the output tile is limited and so is the arithmetic intensity. Already this means that we are going to need to load a lot of data to compute an output tile. Furthermore, since we are using FP8 arithmetic, computation is quite fast, so we cannot rely on computation time to hide the latency of data loading. All in all, it would be ideal to have more threads in charge of loading data than threads in charge of computing the result. 
 
 To achieve this, we are going to use a technique called **warp specialization**. Instead having all warps in the thread block execute the same instructions, we are going to dedicate some warps to loading data only and some to computing the results only. The warps in charge of loading data are called **producers** and the ones that compute the results are named **consumers**. Producers and consumers work asynchronously: producers first load data from the VRAM, which is slow, and make it available to the consumers by storing it in a shared memory buffer. Until data is available in shared memory, the consumer is idle. After it data is made available, the consumer loads it from shared memory, which is fast, and computes the result. 
 Coordination of producers and consumers is achieved through a queue stored in shared memory. When a producer finishes storing data in a shared memory buffer \\( i \\) , it changes the state of the \\( i \\) th variable of the queue to signal data is available there. The consumer is watching out for this, and begins loading data afterwards. When it is done, it changes the \\( i \\) th variable of the queue to signal that data can be written over in buffer  \\( i \\) .