4 min readfrom Machine Learning

I created an autonomous boxing benchmark [D]

Our take

Introducing a novel AI benchmark: autonomous boxing. We've created a dynamic, physics-based environment where LLMs engage in simulated street fights, testing decision speed, adaptability, and strategic thinking. Models, like those utilizing Gemini-Flash-Live, can even dodge and counter punches. Currently tracking metrics like latency, action quality, and contextual awareness, we're seeking input on additional valuable stats to enhance this fun and insightful evaluation tool. For a deeper exploration of LLM training techniques, see our recent article, "Deep Dive on RL and OPD for Training LLMs."
I created an autonomous boxing benchmark [D]

The emergence of robust benchmarks for evaluating large language models (LLMs) is critical as their capabilities rapidly expand, and the recent creation of an autonomous boxing benchmark by u/jerkosaur is a particularly clever and engaging approach. Moving beyond the standard datasets and problem-solving exercises, this benchmark injects a dose of playful complexity, testing not just raw processing power but also decision speed, adaptability, and strategic thinking in a dynamic, real-time environment. The creator’s focus on metrics like reaction latency and stamina efficiency, alongside more traditional measures like tokens per second, provides a nuanced view of LLM performance that goes beyond simply assessing output quality. It's a refreshing departure from the often-sterile nature of existing evaluations, and it highlights the need for more interactive and physically-simulated testing grounds—a point further explored in "How to control reasoning effort and thinking-token budgets in LLMs," which discusses the importance of efficient resource management in complex tasks.

What’s particularly compelling is the emphasis on “Tool Correctness / Validity” and “Invalid Action Recovery.” These metrics address a fundamental challenge in LLM applications: ensuring that the models can reliably interact with external tools and recover gracefully from errors. The boxing scenario, with its defined moves and rules, provides a natural framework for assessing this, forcing models to navigate a constrained action space and react appropriately to unexpected situations. The creator’s observation that models sometimes exhibit "overconfidence" when nearing defeat—continuing to act aggressively even with minimal health—is a fascinating insight into their current limitations in contextual awareness, something that aligns with the challenges of incorporating real-world constraints explored in "Deep Dive on RL and OPD for Training LLMs [D]," which looks at how reinforcement learning and other techniques can improve LLM grounding in reality. The use of Gemini-Flash-Live models, leveraging vision capabilities for dodging and countering, demonstrates the potential of multimodal LLMs in achieving more sophisticated and reactive behavior.

The creator’s openness to feedback and the community-driven nature of the project are also noteworthy. The request for additional stats—beyond the already impressive list—encourages collaborative refinement of the benchmark, ensuring its relevance and effectiveness as LLMs continue to evolve. The idea of introducing time scaling to compensate for the slower inference speeds of local models is a practical consideration, highlighting the challenges of balancing accessibility with performance. Furthermore, the creator's desire to make this a “fun tool” is a valuable perspective. As AI becomes increasingly integrated into our lives, it's important to remember that evaluation shouldn’t solely focus on technical metrics; enjoyment and engagement can be powerful indicators of usability and effectiveness. This approach resonates with a broader discussion about the responsible integration of AI, as observed in "YouTuber Hank Green says his AI usage is ‘not healthy’," which raises important questions about the psychological impact and potential pitfalls of over-reliance on AI tools.

Ultimately, the autonomous boxing benchmark represents a significant step forward in LLM evaluation. It moves beyond static datasets to create a dynamic, engaging, and multifaceted testing environment. The focus on speed, adaptability, and error recovery provides a more realistic assessment of LLM capabilities, and the open-source nature of the project fosters collaboration and innovation. As LLMs become increasingly capable of interacting with the real world, benchmarks like this will be essential for understanding their limitations and guiding their development toward more robust, reliable, and beneficial applications. One key question remains: will this type of physics-based benchmark inspire the creation of similar environments for other complex tasks, pushing the boundaries of what LLMs can achieve?

I created an autonomous boxing benchmark [D]

I created an AI boxing match to test the decision speed, adaptability and strategy. I fed the LLMs with data about the current match and if they have vision, they will get even more data. The match has street rules, anything goes and an AI is not defeated until the ref counts to 10 or they do 50% of their HP in damage after being knocked out.

I wanted to create a fun benchmark that isn't just boring problems to be solved. Now I test them while stimulating getting punched in the face.

I've been testing with gemini-flash-live models because of the speed and vision support it offers. With these models, they can actually dodge punches and counter punches. Local models on my own hardware (5060ti 8gb) take a while to inference so I'm not sure if I should introduce time scaling to compensate otherwise

I want to use this to benchmark models so I'm curious on what kind of stats would be useful? Here is what I'm tracking have so far:

Speed and Latency Metrics
In a real-time fight, a model's speed directly correlates to its "physical" speed. Fast models should attack faster so larger models aren't necessarily going to hit harder.

  • Tokens per Second (TPS) / Throughput: This will help you balance local models against cloud APIs. A model might have a fast TTFT but a slow TPS, meaning its actual action execution takes too long.
  • End-to-End Latency: The total time from when the model receives the snapshot (the prompt) to when the action is executed in the game. This accounts for tool-calling delays.
  • Reaction Latency: Measure the specific delay between an opponent's telegraph (e.g., a heavy punch winding up) and the model's defensive output (e.g., a dodge or block).

Action Quality and "Tool" Correctness
the model's actions (punching, guarding, taunting) act as tool calls. You need to track how well they use these tools under pressure. Sometimes the model's may not really guard/block so they are typically the ones that find themselves KOd.

  • Tool Correctness / Validity: How often does the model hallucinate an action that doesn't exist? (trying to a move that isn't in their move list, or sending invalid JSON).
  • Invalid Action Recovery: If an LLM outputs an invalid JSON string or an impossible move, how quickly does it realize the error and output a valid move in the next tick?
  • Stamina Efficiency (Resource Management): track the ratio of damage dealt to stamina spent. Models that mindlessly throw heavy attacks without connecting should score lower on efficiency.

Adaptive Strategy and State Awareness
How well does the model understand the physical reality of the game? Are they constantly backing away and punching air?

  • Accuracy: The percentage of attacks that completely miss the opponent's hitboxes. This indicates poor spatial awareness or poor timing.
  • Block/Dodge Success Rate: The percentage of times the model successfully defends against an incoming attack when it had the stamina and time to do so.
  • Contextual Relevancy (State Adherence): Does the model act based on the current state? For instance, if the model has 1% HP, does its behavior change to become more defensive, or does it keep acting like it's at full health? (Happens sometimes, they get overly confident when about to get knocked out 😆 )

Beyond these metrics, I'm also tracking various fighting stats like hits landed/missed, where it hit, how many times they were downed or knocked out the ref.

Are there important stats that I'm missing or any that might be useful or fun that would be nice to see? I'm still trying to balance a lot of the actions but it's coming along great so far!

I think making a physics-based benchmark and doing a N series test to find out which model performs better is a ton of fun and I genuinely laugh at the stuff they say or do. I want this to make this a really fun tool with great metrics so any advice in terms of what you would like to see would be extremely helpful! Thanks for reading!

I posted a longer breakdown of the system here:
https://www.youtube.com/watch?v=inlXe5Buc7s

submitted by /u/jerkosaur
[link] [comments]

Read on the original site

Open the publisher's page for the full experience

View original article