![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F1973217%2Fdbd9dd1814ade77cc5c840319d36cf72%2FScreenshot%202025-04-02%20at%2016.55.07.png?generation=1743580526542546&alt=media\")
\nThe reward was optimized steadily throughout training, but after step 60, catastrophic shifts occurred, causing a substantial decline in performance. We thus decided to use checkpoints from earlier steps for evaluation.
First of all, congratulations to all the participants for making it through this long and challenging competition. We’d also like to express our sincere appreciation to the organizers for designing such an interesting competition with a high-quality dataset, and to the Kaggle team for providing the extensive computational resources that made this possible.
\nOur team identified the main challenge of this competition as the redundancy in the reasoning process of the DeepSeek R1 series models — specifically, their long output token lengths, which made it difficult to solve 50 problems within the 5-hour time limit. To address this, we aimed to fine-tune a distilled version of the R1 model to reason more efficiently.
\nOur final model scored 29 on public LB and 28 on private LB.
\nICML2025 AI for Math Workshop
\nA Practical Two-Stage Recipe for Mathematical LLMs: Maximizing Accuracy with SFT and Efficiency with Reinforcement Learning
https://github.com/analokmaus/kaggle-aimo2-fast-math-r1
\nhttps://huggingface.co/RabotniKuma/Fast-Math-R1-14B
\nhttps://www.kaggle.com/models/analokamus/fast_math_r1_14b/
https://huggingface.co/datasets/RabotniKuma/Fast-Math-R1-SFT
\nhttps://huggingface.co/datasets/RabotniKuma/Fast-Math-R1-GRPO
OpenR1 Math: We randomly sampled 3000 examples where the R1’s trace had more than 12800 tokens and an accuracy of over 50%, along with another 3000 examples where the accuracy ranged between 50% and 75%.
\nopenr1_hard: \"~2.5k hard samples from open-r1-math-220k. Samples deemed as hard were unsolvable by r1-distill-32b after 4 tries.\" (Thank you for the dataset, @andy2709 )
\nLight-R1-SFTData: We used the 2nd stage data from Light-R1-SFTData. (Big thanks to LightR1 team, @zouhaosheng )
We merged all the datasets mentioned above, removed duplicates, and selected the correct generation with the shortest token length. For samples in the Light-R1 dataset where ground truth answers were not provided, we extracted and substituted the answers from the R1 traces. As a result, we constructed a high-difficulty dataset consisting of 7900 problem - R1 trace - answer sets.
\nBased on our prior experiments, we observed that the 14B models demonstrated more stable performance. Therefore, we chose DeepSeek-R1-Distill-Qwen-14B as our starting point. A full-parameter supervised fine-tuning training was conducted on a machine with 8 H200 GPUs, using the SFTTrainer from the trl library.
\nTraining time: approx. 10 hours (8× H200 GPUs)
\nWe evaluated the model’s performance using a dataset of 40 problems, consisting of 10 reference problems and 30 from AIME 2025.
\nInitially, we generated answers using 16k tokens × 32 prompts. We then applied post-hoc filtering based on token length and the number of prompts to assess performance under various inference conditions.
| Experiment | \nToken budget | \nAccuracy (majority@32) | \nAccuracy (pass@32) | \nNum of answers collected | \nAverage generation length | \nPublic LB (quantized model) | \n
|---|---|---|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-14B | \n16384 | \n0.700 | \n0.775 | \n21.775 | \n9684 | \n25 | \n
| DeepSeek-R1-Distill-Qwen-14B | \n12800 | \n0.675 | \n0.775 | \n16.775 | \n8331 | \n\n |
| DeepSeek-R1-Distill-Qwen-14B | \n9000 | \n0.525 | \n0.600 | \n12.500 | \n4725 | \n\n |
| SFT | \n16384 | \n0.750 | \n0.825 | \n20.725 | \n10396 | \n23 | \n
| SFT | \n12800 | \n0.725 | \n0.725 | \n15.700 | \n7024 | \n\n |
| SFT | \n9000 | \n0.550 | \n0.550 | \n11.600 | \n4387 | \n\n |
Our local validation scores improved remarkably after the first-stage SFT. However, we observed that the Public LB scores tended to be slightly lower.
\nWe believe this was due to increased reasoning redundancy introduced by SFT, causing many examples to fail to reach a conclusion within the time limit.
\nTo address this, our next objective was to apply reinforcement learning to encourage the model to reach accurate conclusions using fewer tokens, while maintaining performance.
Light-R1-SFTData: We used the 2nd stage data from Light-R1-SFTData.
\nWe used the faster version of trl GRPOTrainer created by @andy2709 (again, thank you so much!).
\nWe used the following reward function:
\n</think> tag to save time, therefore we designed the reward to match the pattern r\"^.*?oxed{(.*?)}.*?</think>.*?$\".Training time: approx. 10 hours (8× H200 GPUs)
\nSame as first stage.
\n
\nThe reward was optimized steadily throughout training, but after step 60, catastrophic shifts occurred, causing a substantial decline in performance. We thus decided to use checkpoints from earlier steps for evaluation.
| Experiment | \nToken budget | \nAccuracy (majority@32) | \nAccuracy (pass@32) | \nNum of answers collected | \nAverage generation length | \nPublic LB (quantized model) | \n
|---|---|---|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-14B | \n12800 | \n0.675 | \n0.775 | \n16.775 | \n8331 | \n25 | \n
| DeepSeek-R1-Distill-Qwen-14B | \n9000 | \n0.525 | \n0.600 | \n12.5 | \n4725 | \n\n |
| SFT | \n12800 | \n0.725 | \n0.725 | \n15.7 | \n7024 | \n23 | \n
| SFT | \n9000 | \n0.550 | \n0.550 | \n11.6 | \n4387 | \n\n |
| SFT + GRPO (best checkpoint) | \n12800 | \n0.725 | \n0.775 | \n18.5 | \n6817 | \n29 | \n
| SFT + GRPO (best checkpoint) | \n9000 | \n0.625 | \n0.700 | \n15.25 | \n4759 | \n\n |
GRPO enabled us to train a model that preserved accuracy while significantly improving inference efficiency through shorter token lengths.
\nWe applied 4-bit quantization using AutoAWQ.
\nWe observed some degradation in validation performance after quantization, and attempted to recover it through calibration on a math-specific dataset. Unfortunately, this approach did not succeed in preserving the original performance.
We trained a ModernBERT model to predict the shortest token length of correct R1 traces for each problem in the OpenR1 Math dataset, thereby quantifying problem difficulty.
\nOn the validation set, we observed a moderate correlation between the predicted difficulty and the actual number of tokens generated, as shown in the figure below.
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F1973217%2F75f9af2011608c982ac21ca1bd091464%2Flongcontext_tokenlength_scatter.png?generation=1743582693786625&alt=media\")
Using this model, we scaled the output token length dynamically during inference. This approach stabilized the Public LB scores and led to an improvement of approx. +1 point (though it could be placebo).
\nprompt_config0 = (\n system=(\n \n \n ),\n prompt=\n)\n\nprompt_config1 = (\n system=(\n \n \n ),\n prompt=\n)\nMany studies have explored controlling the reasoning processes of LLMs through constrained decoding methods, such as:
\n\nWe experimented extensively with these approaches and tuned various parameters; however, none of them proved effective on our validation dataset. Our hypothesis is that these methods might only be suitable for relatively simple problems.
\nWe also experimented with rewriting the original R1-Qwen model’s reasoning process into a more compact one, following the SkyThought approach, and retraining the model via SFT and DPO. Although this method significantly reduced the number of tokens generated before reaching an answer, it also caused a substantial drop in accuracy.
\nFor highly capable LLMs, forcibly altering their natural reasoning process externally might not be an effective strategy, particularly when dealing with complex problem-solving scenarios like ours.
", "comments": [ { "id": 3168397, "author_name": "xz", "author_url": "", "post_date": "2025-04-02T11:45:28.740000", "content": "Thanks for sharing! I tried to use the cosine reward in a first couple of my experiments as well, I think after certain steps, depending on your lr and beta, it will just give up on difficult problems because it is afraid of the penalty for providing long and incorrect solutions.
", "votes": 6, "replies": [ { "id": 3168499, "author_name": "Togawa Sakiko", "author_url": "", "post_date": "2025-04-02T14:02:24.060000", "content": "Based on this issue, there seems to be a small bug in the arguments of cosine reward in the repo open-r1.
\nThe default value of cosine_min_value_wrong is set to 0 and the cosine_max_value_wrong is -0.5 in the config file, which makes the longer incorrect solutions are penalized more than shorter ones after we swap the min/max value. So if you use the default value in configs.py, I suggest you may try to use the value in rewards.py😉.
Giving higher reward to longer incorrect answer will lead to reward hacking. It can be used on a base model to encourage outputting longer reasoning traces but not ideal for a model like deepseek r1 distill.
", "votes": 0, "replies": [] } ] }, { "id": 3169125, "author_name": "Chan Kha Vu", "author_url": "", "post_date": "2025-04-03T06:26:33.273000", "content": "I also have this impression (just checked my veRL fork, the rewards values are correct - my wrongs are from -1.0 to -0.5 and my corrects are 0.5 to 1.0). In (most) of my experiments, overlong buffer (from DAPO) has a more gentle effect than cosine length reward.
\nBut again, there are sooooo many factors and other parameters that goes into each experiments that I'm not sure what caused what lol. Maybe cosine is fine and the reason that experiment was worse was from a totally different reason
", "votes": 1, "replies": [ { "id": 3169281, "author_name": "xz", "author_url": "", "post_date": "2025-04-03T09:37:06.117000", "content": "Yeah, it’s is kinda hard to know for sure. The length normalization from Dr GRPO paper also has a length bias, although removing standard deviation is definitely a sound idea.
", "votes": 0, "replies": [] } ] } ] }, { "id": 3168372, "author_name": "NguyenThanhNhan", "author_url": "", "post_date": "2025-04-02T11:13:28.410000", "content": "@analokamus Thanks for sharing your team's solution. I also really appreciate you testing out and verifying my GRPO implementation correctness 🤣.
\nI could only afford to lora finetune the r1 14b model with GRPO on 16k sequences and got kinda similar validation results on reference + aime 25. However, the public LB score was really absymal and completely discouraged me from sharing anything 🥲
", "votes": 6, "replies": [] }, { "id": 3190249, "author_name": "Darragh", "author_url": "", "post_date": "2025-04-30T11:21:51.580000", "content": "Congrats @analokamus @inoueu1 @charmq
\nI have some questions for your great approach - we missed this training based on length.
/<think> … we tried this and it seems the best answer usually comes after that in the summarise. Maybe I missed something. Thank you, @darraghdog !
\nAs a Kaggler-runner, it’s an honor to see you on the Kaggle leaderboard, rather than on Strava.
You’re raising really important points
\n\n\nIs there a weighting to the three reward functions you used - Format reward / Cosine reward / Length reward ? Or equal weight.
\n
We used equal weight, and the range of reward values can be found here.
\n\n\nIf I look at the description of the three rewards they seem more focused to length, than accuracy. Is there a risk the model could lose accuracy, or you did not see that. I am just learning GRPO, maybe that is handled with KL divergence already.
\n
This was the most challenging part of developing our GRPO recipe.
\nOne of the biggest pitfalls in RL is reward hacking, and we encountered it in the beginning.
\nEarly on, we experimented with simple reward functions such as format reward, accuracy reward, and length reward, but they often led to models that “confidently generated incorrect answers without thinking deeply.”
To address this, we replaced the accuracy reward with a cosine reward and tuned its scaling parameters (max_value_wrong and min_value_correct).
\nThis allowed us to moderately shorten the reasoning process while maintaining accuracy.
\nHowever, since we were also modifying the dataset at the same time, we plan to run additional ablation experiments as part of the paper we’re currently preparing to verify whether this effect was truly due to the reward change.
\n\nFor Format reward, what is the reason you stop at / … we tried this and it seems the best answer usually comes after that in the summarise. Maybe I missed something.
\n
We observed a similar drop in accuracy when applying early stopping at without RL.
\nHowever, by explicitly incorporating format rewards into the RL objective during training, we found that the resulting accuracy gap became almost negligible, especially considering the benefit by the 300–400 tokens saved.
Thank you for the explanation, looking forward to the paper and trying this out more. Yes, AIMO (and small injury) kept me off Strava.. good to see you going strong.
", "votes": 2, "replies": [] } ] } ] }, { "id": 3168535, "author_name": "JasonZuo", "author_url": "", "post_date": "2025-04-02T14:34:01.233000", "content": "Great efforts! Our approach is actually quite similar to yours : ). We only SFT-ed for 2 epochs (maybe we should do more epochs like yours, but fear for overfitting XD) by distilling on QwQ-32B on 16k math problems selected from LIMO dataset. This step is quite crucial. Then, for GRPO we used verl (and based on DeepScaleR's work), which is quite a handy and efficient library. Interestingly, we have similarly used length penalty and reward reweight (the cosine reward in your post). We also stop at during training, but didn't use a format reward because we thought that the model might somehow hack the reward----anyhow, the format reward is implicit in the rule-based reward. We track our training progress primarily based on the number of solved-alls and solved-nones at each batch (shape of 32bs, 8gens, and 12k len).
", "votes": 4, "replies": [] }, { "id": 3168273, "author_name": "ducnh279", "author_url": "", "post_date": "2025-04-02T09:42:29.830000", "content": "Training a model with controlled response length is a clever approach in the context of this competition!
\nI remember asking deepseek 1 + 1 = ? and it responded with nearly 1k tokens. 😆
", "votes": 2, "replies": [ { "id": 3168334, "author_name": "", "author_url": "", "post_date": "2025-04-02T10:34:44.047000", "content": "", "votes": 0, "replies": [] } ] }, { "id": 3178083, "author_name": "corochann", "author_url": "", "post_date": "2025-04-13T17:39:54.280000", "content": "Congrats @analokamus @inoueu1 @charmq , and thank you for sharing detailed writeup!
\nIt's interesting that the purpose of the RL was to reduce reasoning tokens.
\nAnd it is also informative that constrained decoding and off-policy SFT & DPO didn't work well.
Thanks for your great article! Respect! 🎩🎩🎩
", "votes": 1, "replies": [] }, { "id": 3168773, "author_name": "Quickpanda", "author_url": "", "post_date": "2025-04-02T19:03:19.137000", "content": "Great article! looking for the full version.
\nThanks for sharing!
Congratulations and Thanks for this post! Your team's identification of main challenge what I was looking for. I had a reasonable doubt about it but couldn't find ways to verify it. All my efforts went in opposite direction in using RAG, verification prompts, detailed prompts which must have resulted in more tokens, and always scored less than the simple prompt notebook. I got to learn lot from your post, thanks again.
", "votes": 1, "replies": [] }, { "id": 3168208, "author_name": "a14iiiii", "author_url": "", "post_date": "2025-04-02T08:24:40.113000", "content": "Congratulation! I also tried SFT on 7B qwen2.5-ds model using Light-R1-SFTData(stage 2), I set epoch to 3 and it seems to underfit, after several attempts, finally i abandoned🫠
", "votes": 1, "replies": [ { "id": 3168251, "author_name": "RabotniKuma", "author_url": "", "post_date": "2025-04-02T09:14:01.073000", "content": "Initially, we also conducted similar training and came to the conclusion that SFT wasn’t particularly helpful. However, in the case of task-specific LLMs like this one, it’s possible that extended SFT might actually be more effective — this is something we’d like to explore further through additional experiments.
\nAnother point is that R1-Qwen-7B was originally trained starting from Qwen-Math-7B, whereas the 14B version was based on the general-purpose Qwen-14B. Our experiments also suggested that it’s more difficult to improve the 7B model’s performance further using math-specific datasets, compared to the 14B model.
", "votes": 2, "replies": [] } ] }, { "id": 3168468, "author_name": "冬云金雨", "author_url": "", "post_date": "2025-04-02T13:26:42.880000", "content": "Hello! I'm interested in your GRPO session, have you tried 0 for the beta parameter? Which is better 0 or 0.04?
", "votes": 2, "replies": [ { "id": 3169153, "author_name": "RabotniKuma", "author_url": "", "post_date": "2025-04-03T06:59:20.153000", "content": "Hi, I didn't try that, but I would like to run some additional experiments later. I will add this to the queue.
", "votes": 1, "replies": [] }, { "id": 3170775, "author_name": "JasonZuo", "author_url": "", "post_date": "2025-04-05T02:07:22.183000", "content": "Removing kl works. Not sure how much KL hinders convergence. We first adopted it, but soon dropped it for the rest of our experiments. The model's KL loss won't go away too far per se even with beta=0, otherwise the model's training just failed.
", "votes": 0, "replies": [] } ] }, { "id": 3168236, "author_name": "AI-Cat", "author_url": "", "post_date": "2025-04-02T08:58:34.080000", "content": "You did a great job! My applause! I really missed node with 8xH200.
\nI take my hat off to you, I have nothing even close to that.
", "votes": 2, "replies": [ { "id": 3168243, "author_name": "RabotniKuma", "author_url": "", "post_date": "2025-04-02T09:08:32.373000", "content": "Hi Konstantin,
\nI’d like to return the same kind words to you. Throughout this competition, you’ve been very active in the discussions, and I’ve learned a lot from your comments. I’m also really looking forward to seeing your solution, especially since you’ve managed to consistently achieve wonderful results without any fine-tuning.
\nOur team happened to have access to good amount of compute resources this time, so we deliberately took an approach centered around large scale fine-tuning - something most teams wouldn’t typically be able to do, in hopes of gaining additional insights.
\nWhile compute is undeniably a big advantage in competitions like this, we hope to give back to the community by sharing as much of what we’ve learned as possible.
Hi Rabotni,
\nIn fact, I just did what anyone can do, without additional computing resources. I squeezed out of the model everything that it can reproduce in 7.2 minutes. My solution is based on an accurate planner and a selected strategy for its work. I tried many strategies, but one turned out to be very successful.
", "votes": 2, "replies": [] }, { "id": 3168403, "author_name": "bliao", "author_url": "", "post_date": "2025-04-02T11:54:25.103000", "content": "Can't wait to hear your solution!
", "votes": 0, "replies": [] }, { "id": 3168505, "author_name": "", "author_url": "", "post_date": "2025-04-02T14:09:51.740000", "content": "", "votes": 0, "replies": [] }, { "id": 3168507, "author_name": "Jason Bourne", "author_url": "", "post_date": "2025-04-02T14:11:00.877000", "content": "I have no access to computing resources too . My laptop gpu is 3080, so I spent almost 2k RMB on renting cloud gpus😱
", "votes": 2, "replies": [] }, { "id": 3169136, "author_name": "AI-Cat", "author_url": "", "post_date": "2025-04-03T06:39:34.350000", "content": "And how many hours did you get for that money? And what computing power?
", "votes": 0, "replies": [] } ] } ] }, { "id": 3200308, "author_name": "IOC", "author_url": "", "post_date": "2025-05-12T11:55:13.060000", "content": "What are the differences between Hugging Face’s Open-R1 and the Open-R1 you have mentioned?
", "votes": 0, "replies": [] }, { "id": 3175536, "author_name": "Raviksh Singh Dikola", "author_url": "", "post_date": "2025-04-10T09:10:16.993000", "content": "thanks for sharing this article it provides great insight 🤗
", "votes": 0, "replies": [] }, { "id": 3168527, "author_name": "", "author_url": "", "post_date": "2025-04-02T14:23:24.950000", "content": "", "votes": 1, "replies": [] }, { "id": 3168281, "author_name": "", "author_url": "", "post_date": "2025-04-02T09:54:35.147000", "content": "", "votes": 0, "replies": [] }, { "id": 3169598, "author_name": "HARRABI Raouf", "author_url": "", "post_date": "2025-04-03T16:24:27.873000", "content": "thanks a lot for sharing, big love
", "votes": 0, "replies": [] } ], "comment_count": 33, "messages": [ { "id": 3168197, "postDate": "2025-04-02T08:12:48.697Z", "content": "First of all, congratulations to all the participants for making it through this long and challenging competition. We’d also like to express our sincere appreciation to the organizers for designing such an interesting competition with a high-quality dataset, and to the Kaggle team for providing the extensive computational resources that made this possible.
\nOur team identified the main challenge of this competition as the redundancy in the reasoning process of the DeepSeek R1 series models — specifically, their long output token lengths, which made it difficult to solve 50 problems within the 5-hour time limit. To address this, we aimed to fine-tune a distilled version of the R1 model to reason more efficiently.
\nOur final model scored 29 on public LB and 28 on private LB.
\nICML2025 AI for Math Workshop
\nA Practical Two-Stage Recipe for Mathematical LLMs: Maximizing Accuracy with SFT and Efficiency with Reinforcement Learning
https://github.com/analokmaus/kaggle-aimo2-fast-math-r1
\nhttps://huggingface.co/RabotniKuma/Fast-Math-R1-14B
\nhttps://www.kaggle.com/models/analokamus/fast_math_r1_14b/
https://huggingface.co/datasets/RabotniKuma/Fast-Math-R1-SFT
\nhttps://huggingface.co/datasets/RabotniKuma/Fast-Math-R1-GRPO
OpenR1 Math: We randomly sampled 3000 examples where the R1’s trace had more than 12800 tokens and an accuracy of over 50%, along with another 3000 examples where the accuracy ranged between 50% and 75%.
\nopenr1_hard: \"~2.5k hard samples from open-r1-math-220k. Samples deemed as hard were unsolvable by r1-distill-32b after 4 tries.\" (Thank you for the dataset, @andy2709 )
\nLight-R1-SFTData: We used the 2nd stage data from Light-R1-SFTData. (Big thanks to LightR1 team, @zouhaosheng )
We merged all the datasets mentioned above, removed duplicates, and selected the correct generation with the shortest token length. For samples in the Light-R1 dataset where ground truth answers were not provided, we extracted and substituted the answers from the R1 traces. As a result, we constructed a high-difficulty dataset consisting of 7900 problem - R1 trace - answer sets.
\nBased on our prior experiments, we observed that the 14B models demonstrated more stable performance. Therefore, we chose DeepSeek-R1-Distill-Qwen-14B as our starting point. A full-parameter supervised fine-tuning training was conducted on a machine with 8 H200 GPUs, using the SFTTrainer from the trl library.
\nTraining time: approx. 10 hours (8× H200 GPUs)
\nWe evaluated the model’s performance using a dataset of 40 problems, consisting of 10 reference problems and 30 from AIME 2025.
\nInitially, we generated answers using 16k tokens × 32 prompts. We then applied post-hoc filtering based on token length and the number of prompts to assess performance under various inference conditions.
| Experiment | \nToken budget | \nAccuracy (majority@32) | \nAccuracy (pass@32) | \nNum of answers collected | \nAverage generation length | \nPublic LB (quantized model) | \n
|---|---|---|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-14B | \n16384 | \n0.700 | \n0.775 | \n21.775 | \n9684 | \n25 | \n
| DeepSeek-R1-Distill-Qwen-14B | \n12800 | \n0.675 | \n0.775 | \n16.775 | \n8331 | \n\n |
| DeepSeek-R1-Distill-Qwen-14B | \n9000 | \n0.525 | \n0.600 | \n12.500 | \n4725 | \n\n |
| SFT | \n16384 | \n0.750 | \n0.825 | \n20.725 | \n10396 | \n23 | \n
| SFT | \n12800 | \n0.725 | \n0.725 | \n15.700 | \n7024 | \n\n |
| SFT | \n9000 | \n0.550 | \n0.550 | \n11.600 | \n4387 | \n\n |
Our local validation scores improved remarkably after the first-stage SFT. However, we observed that the Public LB scores tended to be slightly lower.
\nWe believe this was due to increased reasoning redundancy introduced by SFT, causing many examples to fail to reach a conclusion within the time limit.
\nTo address this, our next objective was to apply reinforcement learning to encourage the model to reach accurate conclusions using fewer tokens, while maintaining performance.
Light-R1-SFTData: We used the 2nd stage data from Light-R1-SFTData.
\nWe used the faster version of trl GRPOTrainer created by @andy2709 (again, thank you so much!).
\nWe used the following reward function:
\n</think> tag to save time, therefore we designed the reward to match the pattern r\"^.*?oxed{(.*?)}.*?</think>.*?$\".Training time: approx. 10 hours (8× H200 GPUs)
\nSame as first stage.
\n
\nThe reward was optimized steadily throughout training, but after step 60, catastrophic shifts occurred, causing a substantial decline in performance. We thus decided to use checkpoints from earlier steps for evaluation.
| Experiment | \nToken budget | \nAccuracy (majority@32) | \nAccuracy (pass@32) | \nNum of answers collected | \nAverage generation length | \nPublic LB (quantized model) | \n
|---|---|---|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-14B | \n12800 | \n0.675 | \n0.775 | \n16.775 | \n8331 | \n25 | \n
| DeepSeek-R1-Distill-Qwen-14B | \n9000 | \n0.525 | \n0.600 | \n12.5 | \n4725 | \n\n |
| SFT | \n12800 | \n0.725 | \n0.725 | \n15.7 | \n7024 | \n23 | \n
| SFT | \n9000 | \n0.550 | \n0.550 | \n11.6 | \n4387 | \n\n |
| SFT + GRPO (best checkpoint) | \n12800 | \n0.725 | \n0.775 | \n18.5 | \n6817 | \n29 | \n
| SFT + GRPO (best checkpoint) | \n9000 | \n0.625 | \n0.700 | \n15.25 | \n4759 | \n\n |
GRPO enabled us to train a model that preserved accuracy while significantly improving inference efficiency through shorter token lengths.
\nWe applied 4-bit quantization using AutoAWQ.
\nWe observed some degradation in validation performance after quantization, and attempted to recover it through calibration on a math-specific dataset. Unfortunately, this approach did not succeed in preserving the original performance.
We trained a ModernBERT model to predict the shortest token length of correct R1 traces for each problem in the OpenR1 Math dataset, thereby quantifying problem difficulty.
\nOn the validation set, we observed a moderate correlation between the predicted difficulty and the actual number of tokens generated, as shown in the figure below.
Using this model, we scaled the output token length dynamically during inference. This approach stabilized the Public LB scores and led to an improvement of approx. +1 point (though it could be placebo).
\nprompt_config0 = (\n system=(\n \n \n ),\n prompt=\n)\n\nprompt_config1 = (\n system=(\n \n \n ),\n prompt=\n)\nMany studies have explored controlling the reasoning processes of LLMs through constrained decoding methods, such as:
\n\nWe experimented extensively with these approaches and tuned various parameters; however, none of them proved effective on our validation dataset. Our hypothesis is that these methods might only be suitable for relatively simple problems.
\nWe also experimented with rewriting the original R1-Qwen model’s reasoning process into a more compact one, following the SkyThought approach, and retraining the model via SFT and DPO. Although this method significantly reduced the number of tokens generated before reaching an answer, it also caused a substantial drop in accuracy.
\nFor highly capable LLMs, forcibly altering their natural reasoning process externally might not be an effective strategy, particularly when dealing with complex problem-solving scenarios like ours.
", "rawMarkdown": "First of all, congratulations to all the participants for making it through this long and challenging competition. We’d also like to express our sincere appreciation to the organizers for designing such an interesting competition with a high-quality dataset, and to the Kaggle team for providing the extensive computational resources that made this possible.\n\nOur team identified the main challenge of this competition as the redundancy in the reasoning process of the DeepSeek R1 series models — specifically, their long output token lengths, which made it difficult to solve 50 problems within the 5-hour time limit. To address this, we aimed to fine-tune a distilled version of the R1 model to reason more efficiently.\n\nOur final model scored **29 on public LB and 28 on private LB**.\n\n## Paper\nICML2025 AI for Math Workshop\n[A Practical Two-Stage Recipe for Mathematical LLMs: Maximizing Accuracy with SFT and Efficiency with Reinforcement Learning](https://arxiv.org/abs/2507.08267)\n\n## Github\nhttps://github.com/analokmaus/kaggle-aimo2-fast-math-r1\n\n## Model\nhttps://huggingface.co/RabotniKuma/Fast-Math-R1-14B\nhttps://www.kaggle.com/models/analokamus/fast_math_r1_14b/\n\n## Dataset\nhttps://huggingface.co/datasets/RabotniKuma/Fast-Math-R1-SFT\nhttps://huggingface.co/datasets/RabotniKuma/Fast-Math-R1-GRPO\n\n# First stage: intensive SFT using a high-difficulty dataset\n## Dataset\n[OpenR1 Math](https://huggingface.co/datasets/open-r1/OpenR1-Math-220k): We randomly sampled 3000 examples where the R1’s trace had more than 12800 tokens and an accuracy of over 50%, along with another 3000 examples where the accuracy ranged between 50% and 75%.\n[openr1_hard](https://huggingface.co/datasets/hoanganhpham/openr1_hard): \"~2.5k hard samples from open-r1-math-220k. Samples deemed as hard were unsolvable by r1-distill-32b after 4 tries.\" (Thank you for the dataset, @andy2709 )\n[Light-R1-SFTData](https://huggingface.co/datasets/qihoo360/Light-R1-SFTData): We used the 2nd stage data from Light-R1-SFTData. (Big thanks to LightR1 team, @zouhaosheng )\n\nWe merged all the datasets mentioned above, removed duplicates, and selected the correct generation with the shortest token length. For samples in the Light-R1 dataset where ground truth answers were not provided, we extracted and substituted the answers from the R1 traces. As a result, we constructed a **high-difficulty dataset consisting of 7900 problem - R1 trace - answer sets**.\n\n## Training\nBased on our prior experiments, we observed that the 14B models demonstrated more stable performance. Therefore, we chose DeepSeek-R1-Distill-Qwen-14B as our starting point. A full-parameter supervised fine-tuning training was conducted on a machine with 8 H200 GPUs, using the SFTTrainer from the trl library.\n\n### Key parameters\n- per_device_train_batch_size = 1\n- gradient_accumulation_steps = 8\n- num_train_epochs = 20 \n - This number is unusually big, but we found that meaningful performance gains only emerged after long long training\n- max_seq_length = 24000\n- packing = True\n- learning_rate = 1e-5\n- lr_scheduler_type = cosine\n- system_prompt = \"Please reason step by step, and put your final answer within \\\\boxed{{}}.\"\n\nTraining time: approx. 10 hours (8× H200 GPUs)\n\n## Evaluation\nWe evaluated the model’s performance using a dataset of 40 problems, consisting of **10 reference problems and 30 from AIME 2025**.\nInitially, we generated answers using 16k tokens × 32 prompts. We then applied post-hoc filtering based on token length and the number of prompts to assess performance under various inference conditions.\n\n## Results\n\n| Experiment | Token budget | Accuracy (majority@32) | Accuracy (pass@32) | Num of answers collected | Average generation length | Public LB (quantized model) |\n|-------------------------------|---------------------|--------------------------|---------------------|--------------------------|---------------------------|-----------|\n| DeepSeek-R1-Distill-Qwen-14B | 16384 | 0.700 | 0.775 | 21.775 | 9684 | 25 |\n| DeepSeek-R1-Distill-Qwen-14B | 12800 | 0.675 | 0.775 | 16.775 | 8331 | |\n| DeepSeek-R1-Distill-Qwen-14B | 9000 | 0.525 | 0.600 | 12.500 | 4725 | |\n| SFT | 16384 | 0.750 | 0.825 | 20.725 | 10396 | 23 |\n| SFT | 12800 | 0.725 | 0.725 | 15.700 | 7024 | |\n| SFT | 9000 | 0.550 | 0.550 | 11.600 | 4387 | |\n\n\nOur local validation scores improved remarkably after the first-stage SFT. However, we observed that the Public LB scores tended to be slightly lower.\nWe believe this was **due to increased reasoning redundancy introduced by SFT, causing many examples to fail to reach a conclusion within the time limit**.\nTo address this, our next objective was to apply reinforcement learning to encourage the model to reach accurate conclusions using fewer tokens, while maintaining performance.\n\n# Second stage: GRPO for more efficient reasoning\n## Dataset\n[Light-R1-SFTData](https://huggingface.co/datasets/qihoo360/Light-R1-SFTData): We used the 2nd stage data from Light-R1-SFTData.\n\n## Training\nWe used the [faster version of trl GRPOTrainer](https://github.com/nhannguyen2709/open-r1) created by @andy2709 (again, thank you so much!).\n\nWe used the following reward function:\n1. Format reward\nIn our submission, generation is stopped at the `` tag to save time, therefore we designed the reward to match the pattern `r\"^.*?oxed{(.*?)}.*?.*?$\"`.\n2. Cosine reward (correct [1.0, 0.1], incorrect [-0.1, -1.0], max_len=30000)\nCompared to a normal accuracy-based reward, cosine reward applies a continuous penalty to longer correct reasoning traces and shorter incorrect ones.\n3. Length reward\nLength-based rewards to discourage overthinking and promote token efficiency.\nPaper: https://arxiv.org/abs/2501.12599\n\n### Key parameters\n- num_generations = 8\n- beta = 0.04\n- per_device_train_batch_size = 2\n- gradient_accumulation_steps = 8\n- num_train_epochs = 1 \n- max_completion_length = 16384\n- learning_rate = 4e-6\n- lr_scheduler_type = cosine\n- system_prompt = (\n 'You are a helpful and harmless assistant. You are Qwen developed by Alibaba. '\n 'You should think step-by-step. Return final answer within \\\\boxed{{}}.'\n )\n\nTraining time: approx. 10 hours (8× H200 GPUs)\n\n## Evaluation\nSame as first stage.\n\n## Results\n\nThe reward was optimized steadily throughout training, but after step 60, catastrophic shifts occurred, causing a substantial decline in performance. We thus decided to use checkpoints from earlier steps for evaluation.\n\n| Experiment | Token budget | Accuracy (majority@32) | Accuracy (pass@32) | Num of answers collected | Average generation length | Public LB (quantized model) |\n|-------------------------------|---------------------|--------------------------|---------------------|--------------------------|---------------------------|-----------|\n| DeepSeek-R1-Distill-Qwen-14B | 12800 | 0.675 | 0.775 | 16.775 | 8331 | 25 |\n| DeepSeek-R1-Distill-Qwen-14B | 9000 | 0.525 | 0.600 | 12.5 | 4725 | |\n| SFT | 12800 | 0.725 | 0.725 | 15.7 | 7024 | 23 |\n| SFT | 9000 | 0.550 | 0.550 | 11.6 | 4387 | |\n| SFT + GRPO (best checkpoint) | 12800 | **0.725** | **0.775** | **18.5** | 6817 | **29** |\n| SFT + GRPO (best checkpoint) | 9000 | **0.625** | **0.700** | **15.25** | 4759 | |\n\n\nGRPO enabled us to train a model that preserved accuracy while significantly improving inference efficiency through shorter token lengths. \n\n# Submission inference setup\n## Quantization\nWe applied 4-bit quantization using [AutoAWQ](https://github.com/casper-hansen/AutoAWQ).\nWe observed some degradation in validation performance after quantization, and attempted to recover it through calibration on a math-specific dataset. Unfortunately, this approach did not succeed in preserving the original performance.\n\n## Inference time scheduling\nWe trained a ModernBERT model to predict the shortest token length of correct R1 traces for each problem in the OpenR1 Math dataset, thereby quantifying problem difficulty.\nOn the validation set, we observed a moderate correlation between the predicted difficulty and the actual number of tokens generated, as shown in the figure below.\n\n\n\nUsing this model, we scaled the output token length dynamically during inference. This approach stabilized the Public LB scores and led to an improvement of approx. +1 point (though it could be placebo).\n\n## Misc.\n- Prompts: prompt_config0 * 8 + prompt_config1 * 2 (10 prompts in total)\n```python\nprompt_config0 = dict(\n system=(\n 'You are a helpful and harmless assistant. You are Qwen developed by Alibaba. '\n 'You should think step-by-step. Return final answer within \\\\boxed{{}}, after taking modulo 1000.'\n ),\n prompt='{question}'\n)\n\nprompt_config1 = dict(\n system=(\n 'You are a helpful and harmless assistant. You are Qwen developed by Alibaba. '\n 'You should think step-by-step. After you get your final answer, take modulo 1000, and return the final answer within \\\\boxed{{}}.'\n ),\n prompt='{question}'\n)\n```\n- Output token length: 10500 - 13300 (dynamic scaling described above)\n- vLLM version 0.7.3 with V1\n\n# What didn’t work\n## Constrained decoding\nMany studies have explored controlling the reasoning processes of LLMs through constrained decoding methods, such as:\n\n- https://arxiv.org/pdf/2501.18585\n- https://arxiv.org/pdf/2412.21187\n\nWe experimented extensively with these approaches and tuned various parameters; however, none of them proved effective on our validation dataset. Our hypothesis is that these methods might only be suitable for relatively simple problems.\n\n## Rewritiing the reasoning process and retraining\nWe also experimented with rewriting the original R1-Qwen model’s reasoning process into a more compact one, following the [SkyThought](https://github.com/NovaSky-AI/SkyThought) approach, and retraining the model via SFT and DPO. Although this method significantly reduced the number of tokens generated before reaching an answer, it also caused a substantial drop in accuracy.\n\nFor highly capable LLMs, forcibly altering their natural reasoning process externally might not be an effective strategy, particularly when dealing with complex problem-solving scenarios like ours.\n", "votes": 89 }, { "id": 3168397, "postDate": "2025-04-02T11:45:28.740Z", "content": "Thanks for sharing! I tried to use the cosine reward in a first couple of my experiments as well, I think after certain steps, depending on your lr and beta, it will just give up on difficult problems because it is afraid of the penalty for providing long and incorrect solutions.
", "rawMarkdown": "Thanks for sharing! I tried to use the cosine reward in a first couple of my experiments as well, I think after certain steps, depending on your lr and beta, it will just give up on difficult problems because it is afraid of the penalty for providing long and incorrect solutions.", "votes": 6, "replies": [ { "id": 3168499, "postDate": "2025-04-02T14:02:24.060Z", "content": "Based on this issue, there seems to be a small bug in the arguments of cosine reward in the repo open-r1.
\nThe default value of cosine_min_value_wrong is set to 0 and the cosine_max_value_wrong is -0.5 in the config file, which makes the longer incorrect solutions are penalized more than shorter ones after we swap the min/max value. So if you use the default value in configs.py, I suggest you may try to use the value in rewards.py😉.
Giving higher reward to longer incorrect answer will lead to reward hacking. It can be used on a base model to encourage outputting longer reasoning traces but not ideal for a model like deepseek r1 distill.
", "rawMarkdown": "Giving higher reward to longer incorrect answer will lead to reward hacking. It can be used on a base model to encourage outputting longer reasoning traces but not ideal for a model like deepseek r1 distill." } ] }, { "id": 3169125, "postDate": "2025-04-03T06:26:33.273Z", "content": "I also have this impression (just checked my veRL fork, the rewards values are correct - my wrongs are from -1.0 to -0.5 and my corrects are 0.5 to 1.0). In (most) of my experiments, overlong buffer (from DAPO) has a more gentle effect than cosine length reward.
\nBut again, there are sooooo many factors and other parameters that goes into each experiments that I'm not sure what caused what lol. Maybe cosine is fine and the reason that experiment was worse was from a totally different reason
", "rawMarkdown": "I also have this impression (just checked my veRL fork, the rewards values are correct - my wrongs are from -1.0 to -0.5 and my corrects are 0.5 to 1.0). In (most) of my experiments, overlong buffer (from DAPO) has a more gentle effect than cosine length reward.\n\nBut again, there are sooooo many factors and other parameters that goes into each experiments that I'm not sure what caused what lol. Maybe cosine is fine and the reason that experiment was worse was from a totally different reason", "votes": 1, "replies": [ { "id": 3169281, "postDate": "2025-04-03T09:37:06.117Z", "content": "Yeah, it’s is kinda hard to know for sure. The length normalization from Dr GRPO paper also has a length bias, although removing standard deviation is definitely a sound idea.
", "rawMarkdown": "Yeah, it’s is kinda hard to know for sure. The length normalization from Dr GRPO paper also has a length bias, although removing standard deviation is definitely a sound idea." } ] } ] }, { "id": 3168372, "postDate": "2025-04-02T11:13:28.410Z", "content": "@analokamus Thanks for sharing your team's solution. I also really appreciate you testing out and verifying my GRPO implementation correctness 🤣.
\nI could only afford to lora finetune the r1 14b model with GRPO on 16k sequences and got kinda similar validation results on reference + aime 25. However, the public LB score was really absymal and completely discouraged me from sharing anything 🥲
", "rawMarkdown": "@analokamus Thanks for sharing your team's solution. I also really appreciate you testing out and verifying my GRPO implementation correctness 🤣.\n\nI could only afford to lora finetune the r1 14b model with GRPO on 16k sequences and got kinda similar validation results on reference + aime 25. However, the public LB score was really absymal and completely discouraged me from sharing anything 🥲", "votes": 6 }, { "id": 3190249, "postDate": "2025-04-30T11:21:51.580Z", "content": "Congrats @analokamus @inoueu1 @charmq
\nI have some questions for your great approach - we missed this training based on length.
/<think> … we tried this and it seems the best answer usually comes after that in the summarise. Maybe I missed something. Thank you, @darraghdog !
\nAs a Kaggler-runner, it’s an honor to see you on the Kaggle leaderboard, rather than on Strava.
You’re raising really important points
\n\n\nIs there a weighting to the three reward functions you used - Format reward / Cosine reward / Length reward ? Or equal weight.
\n
We used equal weight, and the range of reward values can be found here.
\n\n\nIf I look at the description of the three rewards they seem more focused to length, than accuracy. Is there a risk the model could lose accuracy, or you did not see that. I am just learning GRPO, maybe that is handled with KL divergence already.
\n
This was the most challenging part of developing our GRPO recipe.
\nOne of the biggest pitfalls in RL is reward hacking, and we encountered it in the beginning.
\nEarly on, we experimented with simple reward functions such as format reward, accuracy reward, and length reward, but they often led to models that “confidently generated incorrect answers without thinking deeply.”
To address this, we replaced the accuracy reward with a cosine reward and tuned its scaling parameters (max_value_wrong and min_value_correct).
\nThis allowed us to moderately shorten the reasoning process while maintaining accuracy.
\nHowever, since we were also modifying the dataset at the same time, we plan to run additional ablation experiments as part of the paper we’re currently preparing to verify whether this effect was truly due to the reward change.
\n\nFor Format reward, what is the reason you stop at / … we tried this and it seems the best answer usually comes after that in the summarise. Maybe I missed something.
\n
We observed a similar drop in accuracy when applying early stopping at without RL.
\nHowever, by explicitly incorporating format rewards into the RL objective during training, we found that the resulting accuracy gap became almost negligible, especially considering the benefit by the 300–400 tokens saved.
Thank you for the explanation, looking forward to the paper and trying this out more. Yes, AIMO (and small injury) kept me off Strava.. good to see you going strong.
", "rawMarkdown": "Thank you for the explanation, looking forward to the paper and trying this out more. Yes, AIMO (and small injury) kept me off Strava.. good to see you going strong.", "votes": 2 } ] } ] }, { "id": 3168535, "postDate": "2025-04-02T14:34:01.233Z", "content": "Great efforts! Our approach is actually quite similar to yours : ). We only SFT-ed for 2 epochs (maybe we should do more epochs like yours, but fear for overfitting XD) by distilling on QwQ-32B on 16k math problems selected from LIMO dataset. This step is quite crucial. Then, for GRPO we used verl (and based on DeepScaleR's work), which is quite a handy and efficient library. Interestingly, we have similarly used length penalty and reward reweight (the cosine reward in your post). We also stop at during training, but didn't use a format reward because we thought that the model might somehow hack the reward----anyhow, the format reward is implicit in the rule-based reward. We track our training progress primarily based on the number of solved-alls and solved-nones at each batch (shape of 32bs, 8gens, and 12k len).
", "rawMarkdown": "Great efforts! Our approach is actually quite similar to yours : ). We only SFT-ed for 2 epochs (maybe we should do more epochs like yours, but fear for overfitting XD) by distilling on QwQ-32B on 16k math problems selected from LIMO dataset. This step is quite crucial. Then, for GRPO we used verl (and based on DeepScaleR's work), which is quite a handy and efficient library. Interestingly, we have similarly used length penalty and reward reweight (the cosine reward in your post). We also stop atTraining a model with controlled response length is a clever approach in the context of this competition!
\nI remember asking deepseek 1 + 1 = ? and it responded with nearly 1k tokens. 😆
", "rawMarkdown": "Training a model with controlled response length is a clever approach in the context of this competition! \n\nI remember asking deepseek 1 + 1 = ? and it responded with nearly 1k tokens. 😆", "votes": 2, "replies": [ { "id": 3168334, "postDate": "2025-04-02T10:34:44.047Z", "rawMarkdown": "", "isDeleted": true } ] }, { "id": 3178083, "postDate": "2025-04-13T17:39:54.280Z", "content": "Congrats @analokamus @inoueu1 @charmq , and thank you for sharing detailed writeup!
\nIt's interesting that the purpose of the RL was to reduce reasoning tokens.
\nAnd it is also informative that constrained decoding and off-policy SFT & DPO didn't work well.
Thanks for your great article! Respect! 🎩🎩🎩
", "rawMarkdown": "Thanks for your great article! Respect! 🎩🎩🎩", "votes": 1 }, { "id": 3168773, "postDate": "2025-04-02T19:03:19.137Z", "content": "Great article! looking for the full version.
\nThanks for sharing!
Congratulations and Thanks for this post! Your team's identification of main challenge what I was looking for. I had a reasonable doubt about it but couldn't find ways to verify it. All my efforts went in opposite direction in using RAG, verification prompts, detailed prompts which must have resulted in more tokens, and always scored less than the simple prompt notebook. I got to learn lot from your post, thanks again.
", "rawMarkdown": "Congratulations and Thanks for this post! Your team's identification of main challenge what I was looking for. I had a reasonable doubt about it but couldn't find ways to verify it. All my efforts went in opposite direction in using RAG, verification prompts, detailed prompts which must have resulted in more tokens, and always scored less than the simple prompt notebook. I got to learn lot from your post, thanks again.", "votes": 1 }, { "id": 3168208, "postDate": "2025-04-02T08:24:40.113Z", "content": "Congratulation! I also tried SFT on 7B qwen2.5-ds model using Light-R1-SFTData(stage 2), I set epoch to 3 and it seems to underfit, after several attempts, finally i abandoned🫠
", "rawMarkdown": "Congratulation! I also tried SFT on 7B qwen2.5-ds model using Light-R1-SFTData(stage 2), I set epoch to 3 and it seems to underfit, after several attempts, finally i abandoned🫠", "votes": 1, "replies": [ { "id": 3168251, "postDate": "2025-04-02T09:14:01.073Z", "content": "Initially, we also conducted similar training and came to the conclusion that SFT wasn’t particularly helpful. However, in the case of task-specific LLMs like this one, it’s possible that extended SFT might actually be more effective — this is something we’d like to explore further through additional experiments.
\nAnother point is that R1-Qwen-7B was originally trained starting from Qwen-Math-7B, whereas the 14B version was based on the general-purpose Qwen-14B. Our experiments also suggested that it’s more difficult to improve the 7B model’s performance further using math-specific datasets, compared to the 14B model.
", "rawMarkdown": "Initially, we also conducted similar training and came to the conclusion that SFT wasn’t particularly helpful. However, in the case of task-specific LLMs like this one, it’s possible that extended SFT might actually be more effective — this is something we’d like to explore further through additional experiments.\n\nAnother point is that R1-Qwen-7B was originally trained starting from Qwen-Math-7B, whereas the 14B version was based on the general-purpose Qwen-14B. Our experiments also suggested that it’s more difficult to improve the 7B model’s performance further using math-specific datasets, compared to the 14B model.", "votes": 2 } ] }, { "id": 3168468, "postDate": "2025-04-02T13:26:42.880Z", "content": "Hello! I'm interested in your GRPO session, have you tried 0 for the beta parameter? Which is better 0 or 0.04?
", "rawMarkdown": "Hello! I'm interested in your GRPO session, have you tried 0 for the beta parameter? Which is better 0 or 0.04?", "votes": 2, "replies": [ { "id": 3169153, "postDate": "2025-04-03T06:59:20.153Z", "content": "Hi, I didn't try that, but I would like to run some additional experiments later. I will add this to the queue.
", "rawMarkdown": "Hi, I didn't try that, but I would like to run some additional experiments later. I will add this to the queue.", "votes": 1 }, { "id": 3170775, "postDate": "2025-04-05T02:07:22.183Z", "content": "Removing kl works. Not sure how much KL hinders convergence. We first adopted it, but soon dropped it for the rest of our experiments. The model's KL loss won't go away too far per se even with beta=0, otherwise the model's training just failed.
", "rawMarkdown": "Removing kl works. Not sure how much KL hinders convergence. We first adopted it, but soon dropped it for the rest of our experiments. The model's KL loss won't go away too far per se even with beta=0, otherwise the model's training just failed. " } ] }, { "id": 3168236, "postDate": "2025-04-02T08:58:34.080Z", "content": "You did a great job! My applause! I really missed node with 8xH200.
\nI take my hat off to you, I have nothing even close to that.
", "rawMarkdown": "You did a great job! My applause! I really missed node with 8xH200.\n\nI take my hat off to you, I have nothing even close to that.", "votes": 2, "replies": [ { "id": 3168243, "postDate": "2025-04-02T09:08:32.373Z", "content": "Hi Konstantin,
\nI’d like to return the same kind words to you. Throughout this competition, you’ve been very active in the discussions, and I’ve learned a lot from your comments. I’m also really looking forward to seeing your solution, especially since you’ve managed to consistently achieve wonderful results without any fine-tuning.
\nOur team happened to have access to good amount of compute resources this time, so we deliberately took an approach centered around large scale fine-tuning - something most teams wouldn’t typically be able to do, in hopes of gaining additional insights.
\nWhile compute is undeniably a big advantage in competitions like this, we hope to give back to the community by sharing as much of what we’ve learned as possible.
Hi Rabotni,
\nIn fact, I just did what anyone can do, without additional computing resources. I squeezed out of the model everything that it can reproduce in 7.2 minutes. My solution is based on an accurate planner and a selected strategy for its work. I tried many strategies, but one turned out to be very successful.
", "rawMarkdown": "Hi Rabotni,\n\nIn fact, I just did what anyone can do, without additional computing resources. I squeezed out of the model everything that it can reproduce in 7.2 minutes. My solution is based on an accurate planner and a selected strategy for its work. I tried many strategies, but one turned out to be very successful.", "votes": 2 }, { "id": 3168403, "postDate": "2025-04-02T11:54:25.103Z", "content": "Can't wait to hear your solution!
", "rawMarkdown": "Can't wait to hear your solution! " }, { "id": 3168505, "postDate": "2025-04-02T14:09:51.740Z", "rawMarkdown": "", "isDeleted": true }, { "id": 3168507, "postDate": "2025-04-02T14:11:00.877Z", "content": "I have no access to computing resources too . My laptop gpu is 3080, so I spent almost 2k RMB on renting cloud gpus😱
", "rawMarkdown": "I have no access to computing resources too . My laptop gpu is 3080, so I spent almost 2k RMB on renting cloud gpus😱", "votes": 2 }, { "id": 3169136, "postDate": "2025-04-03T06:39:34.350Z", "content": "And how many hours did you get for that money? And what computing power?
", "rawMarkdown": "And how many hours did you get for that money? And what computing power?" } ] } ] }, { "id": 3200308, "postDate": "2025-05-12T11:55:13.060Z", "content": "What are the differences between Hugging Face’s Open-R1 and the Open-R1 you have mentioned?
", "rawMarkdown": "What are the differences between Hugging Face’s Open-R1 and the Open-R1 you have mentioned?" }, { "id": 3175536, "postDate": "2025-04-10T09:10:16.993Z", "content": "thanks for sharing this article it provides great insight 🤗
", "rawMarkdown": "thanks for sharing this article it provides great insight 🤗" }, { "id": 3168527, "postDate": "2025-04-02T14:23:24.950Z", "rawMarkdown": "", "votes": 1, "isDeleted": true }, { "id": 3168281, "postDate": "2025-04-02T09:54:35.147Z", "rawMarkdown": "", "isDeleted": true }, { "id": 3169598, "postDate": "2025-04-03T16:24:27.873Z", "content": "thanks a lot for sharing, big love
", "rawMarkdown": "thanks a lot for sharing, big love" } ], "complete": true, "source": "live", "fetched_at": "2026-10-20T06:42:38Z", "competition_id": 86023, "competition_slug": "ai-mathematical-olympiad-progress-prize-2", "team_id": 13275024, "solution_url": "/competitions/ai-mathematical-olympiad-progress-prize-2/writeups/fast-math-r1-14b-lb-pub-29-pvt-28-enhancing-the-ef" }