Sage-A1.5 on AMD Strix Halo: MTP Performance, Reasoning Loops & Two-Turn Coding Workaround
Sage-A1.5 on AMD Strix Halo: MTP Performance, Reasoning Loops, and a Two-Turn Coding Workaround
Hi InternScience team,
First of all, congratulations on Sage-A1.5! I've been testing the model locally on AMD Strix Halo hardware, focusing on coding performance, reasoning convergence, native MTP acceleration, and autonomous tool-assisted workflows.
I wanted to share some interesting findings, particularly regarding the transition from reasoning to actual code generation.
1. Hardware and inference setup
- Hardware: AMD Ryzen AI Max+ 392, Radeon 8060S, 64 GB unified memory
- OS: Windows
- Runtime: llama.cpp build 11594 (
e0bcaccbe), Vulkan backend - Model: Sage-A1.5 Q5_K_M with importance-matrix quantization (23.87 GiB)
- Context: 65,536 tokens
- MTP: Native integrated MTP,
--spec-type draft-mtp --spec-draft-n-max 2 - Sampling: Initially official Sage settings (temperature 1.0, top_p 0.95, top_k 20, presence_penalty 1.5); additional controlled tests at presence_penalty 0.0 and temperature 0.6
2. Excellent local inference performance
The model runs remarkably fast on the Radeon 8060S.
Measured performance:
| Metric | Result |
|---|---|
| Thinking decode with MTP | 61–65 tokens/s |
| Code generation with MTP | 63–77 tokens/s |
| Thinking decode without MTP | Approximately 58–59 tokens/s |
| MTP speedup during thinking | Approximately 9–12% |
| MTP speedup during code generation | Approximately 13–34% in the measured cases |
| MTP draft acceptance | Approximately 58–88%, depending on task |
Both MTP-enabled and MTP-disabled runs passed our control tasks (08 and 11).
These are promising results for local inference on integrated AMD graphics. The measurements do not establish universal output equivalence between MTP and non-MTP decoding.
3. Reasoning convergence problem
We encountered a reproducible issue on difficult algorithmic coding tasks.
On atcoder_Takahashi Quest:
- With unlimited reasoning, Sage generated 30,000 thinking tokens without producing a final answer.
- Disabling presence penalty did not resolve the behavior.
- Enforcing a reasoning budget of 10,000 tokens successfully closed the thinking block.
- However, Sage continued its mathematical analysis inside Python
#comments, generating thousands of tokens without finishing the executable implementation.
In other words, the model sometimes appears unable to transition from extended mathematical verification to final code generation.
This was especially noticeable when the model became uncertain about an algorithm or its interpretation of an example.
4. Our workaround: Two-turn coding with a comment-loop guardrail
We developed a small autonomous harness that separates problem-solving from implementation.
Phase 1 – Analysis
- Up to approximately 8,000 reasoning tokens
- Original task prompt
- Standard reasoning enabled
Phase 2 – Implementation
- Fresh model context
- The model's own analysis passed to the implementation step
- Thinking disabled
- Temperature 0.6
- Strict instruction to produce executable Python code
Additionally, a streaming guardrail detects excessive Python comment blocks and automatically retries with stricter code-only instructions.
This significantly improved the results on our four selected difficult tasks:
| Task | Single-turn | Autonomous two-turn + guardrail |
|---|---|---|
| 08 – Maximum Non-Decreasing Array Length (code completion) | FAIL | PASS (15/15) |
| 09 – AtCoder Last Train | TRUNC | PASS (15/15) |
| 10 – AtCoder Takahashi Quest | TRUNC | FAIL |
| 11 – Good Partitions | PASS | PASS (15/15) |
Task 09 was particularly interesting: The guardrail detected a comment loop after approximately 477 generated tokens. A single automatic retry produced a complete reverse-Dijkstra implementation passing all 15 tests.
Task 08 was a code-completion task with a provided partial implementation, rather than full code generation.
5. An interesting failure involving self-verification
Task 10 revealed another behavior.
In one analysis trace, Sage derived a valid right-to-left greedy approach. However, during mental verification against a sample, it incorrectly estimated the maximum inventory size and became convinced its own approach was wrong.
In a subsequent autonomous tool-assisted experiment, the model instead proposed an incorrect forward-looking greedy algorithm.
Our Python sandbox correctly rejected that algorithm on the public test cases, but Sage was unable to recover a correct implementation within the allowed retries.
When the correct reverse-scan algorithm was explicitly supplied in a separate control experiment, Sage implemented it successfully and passed all 15 tests.
That assisted result is not counted as an autonomous success.
This suggests an interesting distinction between algorithm discovery, self-verification, and code implementation.
6. Questions for the team
I would be very interested in your recommendations:
- Is this kind of prolonged reasoning or reasoning continuation inside Python comments a known behavior of Sage-A1.5?
- Do you recommend a particular reasoning budget, system prompt, or chat-template configuration for standalone coding tasks?
- Would enabling Sage's trained verification mode help with false self-verification conclusions, or is that mode primarily intended for research and agentic workflows?
- Is there a recommended way to encourage the model to finalize an implementation once it has found a plausible algorithm?
- Are there any Sage-specific considerations for running native MTP under llama.cpp?
Our tests suggest that Sage-A1.5 has excellent potential as a fast local coding agent, particularly when combined with a harness that handles reasoning boundaries, tool execution, and implementation retries.
I'd be happy to share additional logs, prompts, and benchmark details if useful.
Thanks for your work and for making Sage-A1.5 available!