< backnashgpt
The models are learning how to range bet
August 9, 2026
nashgpt is a 56.7M parameter language model trained on the traces of a flop-only heads-up game theory optimal poker solver. It's built on top of TurboFire, a barebones, unoptimized GTO solver that I began working on earlier this year. (there's more planned, though!) I had planned to implement turn and river solving for the project, but it's an incredibly unfortunate timing for a RAM crisis and solving a complete game requires around ~512GB of RAM. Solving only the flop requires a fraction of a percent of the total RAM required, totaling around 3MB for a single run. Flop-only solver runs are incredibly quick, providing a clean way to generate a gigabyte of synthetic data to train a language model.
This idea came to me after reading the OthelloGPT paper, which proved that language models can construct a "model of the world" based on its training data. As a derivative project I thought I could at least attempt to apply poker theory in language models, even if it's not a groundbreaking discovery. Over the span of a few weeks, I attempted to absorb as much information as possible regarding transformer models, which was an uphill battle coming from a non-ML background. In my studying, I came across a project by a group of researchers who attempted a similar project named PokerGPT, with a ~1B parameter model. It still didn't hurt to replicate the idea with output from my own solver, though.
Most of the pieces required for this project were already in my possession - I only had to put them in place. Late July, I (an agent on my behalf) modified my GTO solver to implement a tree walker that would navigate the computed game tree for every hand within our range. The solver was given BTN vs BB ranges with around 60-80% of possible pre-flop hands in play. Once solving was complete, which only took around 3 seconds, the game tree would be traced for each hand in the BB's range (us).
Instead of showing traces for each hand where we'd walk down the game tree of the dominant solver action, we showed a distribution of each action that the solver had generated for every action. In learning how transformer models worked, I discovered the concept of soft cross-entropy, which is a training method that learns on the distribution of tokens rather than attempting to predict a single correct token. This method works perfectly for this project, as the solver output is a distribution of actions.
The entire output file was ~1.2GB with around 10k solver iterations. I rented an Nvidia A40 for around $0.45 an hour on RunPod, which gave plenty of headroom. Training the model took around 10 hours, with results that were plausibly GTO.
| Action | Solver | LLM | Diff |
|---|---|---|---|
| SB_BET25 | 35.6% | 34.3% | −1.3 |
| SB_BET100 | 28.0% | 22.5% | −5.5 |
| SB_CHECK | 25.2% | 19.2% | −6.0 |
| SB_BET123 | 8.2% | 11.6% | +3.5 |
| SB_BET52 | 2.7% | 5.2% | +2.6 |
| SB_BET10 | 0.4% | 7.2% | +6.8 |
