On 25 October, Diario de Jerez featured us in María Valero's report on our work and Sherry 0.1. Seeing our work in our hometown newspaper means a great deal to us. It brings a less visible part of what we do closer to our neighbours: investigating how AI models work and how their behaviour can be improved, beyond the repositories, servers and technical discussions where that work usually happens.
Sherry grew out of a specific question: can an application have more control over the effort a model spends on each answer? Answering it involves mathematics, data and infrastructure. It also reflects the kind of company we want Valendra to be, where client projects, product development and research support one another. The feature gives us an opportunity to tell that story in more detail.
We bring our different disciplines together at Valendra
We are a technology consultancy and engineering company based in Jerez de la Frontera, Spain. We work across cloud infrastructure, data, artificial intelligence and software development. In each area, we want to understand what is holding an organisation back and build a solution its team can operate, maintain and develop further.
We combine our backgrounds in mathematics, infrastructure, distributed systems and machine learning. Coming from different disciplines helps us challenge one another’s assumptions, test our reasoning against data and consider what a solution needs to work in practice.
That combination shapes everyday questions. If a service is slow, we need to understand where time is being spent. If automation produces errors, we need to examine the data and workflow before adding complexity. If a business wants to adopt AI, we need to agree on what counts as an acceptable result and how to verify it. You can learn more about the people behind that work on our about page.
With Sherry, we want to make reasoning effort easier to control
With Sherry, we investigate configurable reasoning. We build on Qwen3.6-35B-A3B, a Mixture of Experts architecture with roughly 35 billion total parameters and around 3 billion active per token. Selective activation distributes computation across experts. Memory and serving requirements still depend on the full model and deployment configuration.
Our research focuses on steering reasoning depth. In our SFT release we introduced three controls through dedicated tokens: low, medium and high. They influence generation behaviour rather than imposing a strict duration or guaranteeing a correct answer.
Consider an application handling tasks of different difficulty. Routing a straightforward request may justify a short answer. Reviewing a function with tricky edge cases may need more steps. Working through a technical question with several constraints may require a deeper exploration. Choosing an effort level lets a team investigate those differences within the same system.
The consequences are visible to the person using the application. Every generation consumes time and serving capacity. Additional reasoning can be worthwhile when it improves the answer. When it merely extends an already sufficient solution, it adds waiting time that should be measured. Understanding that relationship between quality and resources is the question at the centre of Sherry.
We train with verified examples and reinforcement learning
We start from an existing trained model and adapt its behaviour towards a specific objective. In our public Sherry dataset we published 2,061 mathematics reasoning examples with verified answers. We labelled traces by their observed depth, using shorter, intermediate and longer solutions.
We first used supervised fine-tuning, or SFT, to teach the relationship between those labels and response behaviour. We then applied GRPO, a reinforcement-learning method that compares multiple generations. In our technical training write-up we explain how we gave correctness the strongest reward, alongside signals for answer structure and length at the selected effort level.
That reward design matters. A short answer that is wrong does not solve the task, and neither does an extended explanation that ends incorrectly. Evaluation needs to establish what changes in the answer, what it costs to produce and where the adaptation stops being useful. We document those choices so others can understand what we tested and suggest different evaluations.
We publish our results so you can examine them
In our Sherry model card on Hugging Face we publish this comparison against the base model. We used the same evaluation environment and Sherry at high effort:
| Test and metric | Base model | Sherry 0.1 |
|---|---|---|
MATH-500 · math_verify | 88.3% | 97.1% |
| GPQA-Diamond · exact match | 57.1% | 78.3% |
Basic Python · pass@1, 40 tasks | 75.0% | 97.5% |
On GPQA-Diamond, average completion length fell from roughly 20,000 tokens to 7,500. We obtained these results in our controlled evaluation, with a specific scope. We also document possible overlap between training data and mathematical tests, and we are still reviewing the AIME 2025 comparison.
We publish results so they can be examined. A number becomes useful alongside its protocol, conditions and limitations. Teams exploring Sherry can read the documentation, compare it against the base model and evaluate problems representative of their own application. That is the technical conversation we want the release to make possible.
We connect our research with what we build for clients
Our client projects bring us close to concrete constraints: budgets, deadlines, existing systems and the teams that will maintain what we build. Research gives us a way to investigate the tools we might use in that setting more deeply. The connection is valuable when learning leads to better-explained decisions and outcomes that can be checked.
In our AI engineering practice, model selection is one part of the work. Preparing data, integrating the system, deciding how responses will be reviewed and observing behaviour after deployment all require attention. Investigating a particular model behaviour helps us ask better questions about those surrounding layers.
With QDivZero, we work on another part of that process: deploying and operating models. We have also written about joining NVIDIA Inception with QDivZero. Sherry and QDivZero have their own objectives, but both bring us back to making AI systems easier for engineering teams to understand and operate.
We carry our hometown into the project and share what we learn
Calling the project Sherry carries a connection to our city. With its image, we also nod to Fino Caballito, another emblem of Jerez. The horse, the glass of fino sherry and the laptop bring that local reference together with our technology work. We like the idea that someone might find the model, become curious about it and discover that we are developing it here in Jerez.
We also want that curiosity to have a place locally. Through SherryNets, we participate in a community around programming, data and infrastructure. Sharing a question, explaining an experiment or listening to someone approach a problem differently are all ways to help knowledge circulate.
Thank you to María Valero and Diario de Jerez for taking the time to get to know us. We want to build on this coverage through useful projects, research others can examine and opportunities to learn together from Jerez.
You can begin with the original feature in Spanish, explore Sherry on Hugging Face or talk to our team about a data, infrastructure or AI problem you are working through.