AM-Thinking-v1 is a 32-billion-parameter open-source LLM that achieves strong reasoning ability by combining supervised fine-tuning and reinforcement learning in its training. Starting from a base 32B model (Qwen-2.5 32B), the developers first applied reasoning-focused supervised fine-tuning on curated math and coding problems with step-by-step worked answers. They then ran a reinforcement learning phase, similar in spirit to RLHF, to sharpen chain-of-thought behavior and reward correct multi-step reasoning. The result is a mid-scale open model aimed at hard reasoning tasks rather than general chat breadth.
If you ship agents or eval pipelines that depend on math, code, or structured problem solving, AM-Thinking-v1 matters because it shows what a specialized training recipe can do at 32B parameters without jumping to the largest closed models. You still need to evaluate it on your tasks, but the release is a useful reference point for reasoning-centric open weights.
Build better agents with Arize
Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.
Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.
Key takeaways
- AM-Thinking-v1 builds on Qwen-2.5 32B with two stages: reasoning SFT, then RL on math and code trajectories.
- The model targets step-by-step reasoning quality, not just final-answer accuracy on easy prompts.
- Open weights at 32B make it feasible to fine-tune, trace, and compare against your own baselines in-house.
- Reported benchmark gains on math and coding sets do not transfer automatically to your product prompts; run your own eval suite.
- Pair model choice with trace capture and task-specific judges so you can see where reasoning breaks in production.
Training pipeline in plain terms
The base checkpoint is Qwen-2.5 32B, a general-purpose foundation model. The first stage feeds it datasets of complex math and programming problems where each example includes a worked answer with explicit intermediate steps. Supervised fine-tuning nudges the model toward emitting similar reasoning patterns: decompose the problem, show intermediate results, then state a final answer.
The second stage treats reasoning quality as something to optimize, not only imitate. Reinforcement learning assigns reward when trajectories are correct and coherent, penalizing shortcuts or inconsistent steps. That phase is closer to how teams refine models with human or automated preference signals, but here the reward signal is tuned for math and code reasoning rather than conversational helpfulness.
Together, the stages aim for a model that thinks in steps on hard inputs while staying small enough to run on a single high-memory GPU cluster or a modest serving footprint compared with 70B+ alternatives.
Where AM-Thinking-v1 fits among reasoning models
Reasoning-focused LLMs sit on a spectrum. At one end are general chat models with light chain-of-thought prompting. At the other are large proprietary systems trained with heavy RL on broad task mixes. AM-Thinking-v1 occupies a practical middle: open weights, 32B scale, and a narrow training focus on math and code reasoning.
That focus has tradeoffs. The model may excel on competition-style math or LiveCodeBench-style coding while underperforming on open-ended writing, tool orchestration, or domain-specific retrieval tasks you care about. Treat published benchmark numbers as a signal to run your own evals, not as a deployment guarantee.
Teams building AI engineering workflows often keep one reasoning-specialized model in the comparison set alongside a general model and a smaller latency-optimized option. AM-Thinking-v1 is a candidate for the reasoning slot when you can afford 32B inference and want open weights.
Evaluating AM-Thinking-v1 on your workloads
Before routing production traffic, build a golden set that mirrors real failure modes: multi-step calculations, unit errors, off-by-one loops, ambiguous problem statements, and prompts that require citing intermediate results. Score both final answers and reasoning traces.
Useful checks include:
- Exact match on final answers for math with canonical forms.
- Execution or unit tests for generated code.
- Step-level judges that flag skipped logic or contradictions between steps and conclusions.
- Latency and token cost per successful solve, not only accuracy.
Trace each run so you can inspect where reasoning derails. A model that gets the right answer with invalid intermediate steps may fail on slightly harder variants. Prompt learning playbooks that iterate on few-shot examples and rubrics help when you fine-tune prompts around a fixed open checkpoint rather than retraining weights.
If you fine-tune AM-Thinking-v1 on proprietary data, re-run the same eval suite after each checkpoint. Reasoning gains from base training can erode when later SFT overfits narrow formats.
Deployment and ops considerations
Thirty-two billion parameters in fp16 still demand serious GPU memory and batching strategy. Quantization reduces cost but can hurt multi-step math unless you validate per task. Set max tokens high enough for full derivations; truncating thought mid-stream produces confident wrong finals.
Log prompts, completions, token usage, and eval scores together. When accuracy drops after a library or tokenizer update, you want diffs tied to model version and decoding parameters. Open weights simplify reproducibility, but your serving stack still versions artifacts.
For coding use cases, sandbox execution remains mandatory. A model that reasons well on paper can emit subtle bugs. Run tests in isolation and treat the model as a draft author, not an authority.
How AM-Thinking-v1 relates to broader LLM training ideas
The release illustrates a pattern more teams are exploring: start from a capable base, specialize with curated reasoning data, then apply RL on trajectories rather than only on single-token perplexity. That pattern shows up across modern LLM post-training discussions. Understanding how LLMs are built and trained clarifies why a two-stage recipe can move reasoning benchmarks without doubling parameter count.
AM-Thinking-v1 is not a replacement for application-level guardrails, retrieval, or tool use. It is a checkpoint you can instrument, compare, and fine-tune when reasoning quality at open mid-scale is the bottleneck.
FAQ
What base model does AM-Thinking-v1 use?
It starts from Qwen-2.5 32B. The released weights reflect additional supervised fine-tuning on math and coding reasoning data followed by a reinforcement learning stage tuned for multi-step problem solving.
Is AM-Thinking-v1 only for math and coding?
Training emphasized those domains, so expect the strongest behavior there. You can prompt it for other tasks, but there is no guarantee it generalizes better than the base Qwen model outside reasoning-heavy workloads. Evaluate on your own prompts before committing.
How does AM-Thinking-v1 compare to much larger models?
Public results report competitive scores on selected math and coding benchmarks relative to larger models. Your mileage depends on prompt format, decoding settings, and whether your tasks match the training distribution. Run head-to-head evals on your golden set rather than relying on leaderboard rank alone.
Do I need RLHF infrastructure to use AM-Thinking-v1?
No. The RL stage is already baked into the released checkpoint. You consume it like any other fine-tuned open model: download weights, serve, prompt, and evaluate. Further RL or SFT on your data is optional.
What should I log when serving AM-Thinking-v1 in production?
Log model version, prompt template version, full completion (or hashed traces if policy requires), token counts, latency, and task outcome labels when available. Reasoning models fail in structured ways; traces make those failures debuggable.
