How 9B-Parameter Small Models Can Gain Strong Reasoning Abilities

$# How 9B-Parameter Small Models Can Gain Strong Reasoning Abilities

Small models with fewer parameters are not naturally limited to simple chat or classification tasks. When training data, reasoning objectives, and engineering pipelines are redesigned, a 9B-scale model can also demonstrate capabilities approaching those of larger models in multi-step reasoning, knowledge integration, and task execution. This article systematically explains this phenomenon from the perspectives of technical principles, data construction, training methods, engineering implementation, and evaluation systems.

1. Why Small Models Often “Can Chat, but Cannot Reason”

In many business scenarios, small-parameter models are often used as lightweight conversational entry points because they are inexpensive to deploy, fast to respond, and resource-efficient. However, once a task changes from “generate a natural response” to “solve a problem that requires multiple steps of judgment,” small models tend to expose several typical weaknesses.

First, knowledge coverage may be insufficient. A model with a smaller parameter scale usually cannot internalize as much world knowledge as a model with a much larger parameter scale. When facing complex factual relationships, specialized domain concepts, or cross-domain questions, it may only provide superficial answers and struggle to make stable inferences.

Second, process supervision is often insufficient. Traditional pre-training and ordinary instruction fine-tuning usually focus more on whether the final output is fluent and properly formatted, rather than on fine-grained constraints over how the model arrives at the answer. This can cause models to produce seemingly reasonable answers with incorrect steps in math problems, logic problems, and multi-hop question answering.

Third, error propagation becomes more obvious. Multi-step reasoning tasks usually include stages such as condition recognition, intermediate calculation, result verification, and final answer generation. If an error occurs at one intermediate step, later steps may amplify it. Small models often lack strong self-correction ability, making them more likely to drift away from the target in complex reasoning chains.

Fourth, tool-use and context capabilities may not be fully activated. Many small models are not entirely incapable of task execution; instead, they lack training signals for structured output, tool calling, long-context understanding, and multimodal perception. Therefore, simply increasing parameter size is not necessarily the only path. A more effective approach is to compensate for capability gaps through high-quality data and systematic design.

2. Reasoning Trajectory Data: Teaching Small Models “How to Think”

The key to improving small-model reasoning is not simply adding more question-answer pairs, but introducing high-quality reasoning trajectory data. A reasoning trajectory can be understood as the complete thinking chain formed when a model solves a problem. It usually includes problem understanding, condition extraction, step decomposition, intermediate calculation, result verification, and final answer generation.

The value of high-quality reasoning trajectories is mainly reflected in three aspects.

1. Making Implicit Reasoning Explicit

A normal answer only tells the model “what the final result is,” while a reasoning trajectory tells the model “why the result is obtained this way.” For tasks such as math word problems, logic judgment questions, knowledge question answering, and multi-condition constraint tasks, process information is often more important than the final answer. By learning complete steps, a model can gradually establish a more stable habit of task decomposition.

2. Providing Process-Level Supervision Signals

If only the correctness of the final answer is considered, a model may obtain correct results through guessing, template matching, or surface pattern matching. Process-level supervision, however, can constrain the model to remain reasonable at each step. For example, it can check whether conditions are referenced accurately, whether formulas are correct, and whether intermediate conclusions are consistent. This reduces the phenomenon of “correct answer but wrong process,” which is a form of pseudo-capability.

3. Improving Transfer to Complex Tasks

When a model learns to identify goals from a problem, decompose subtasks, call existing knowledge, and verify results, it is more likely to transfer methods to new tasks. For example, a small model trained with high-quality reasoning trajectories may not only perform better on math problems, but also show more stable performance in information extraction, rule-based judgment, table question answering, and agent tasks.

3. How to Build Reasoning Trajectory Data

Building reasoning trajectory data suitable for training usually requires more than simply collecting existing question-answer pairs. It typically involves collection, cleaning, filtering, verification, and layering.

1. Data Source Design

Common data sources include human annotation, post-generation model filtering, desensitized business logs, and rule-based or template-based synthetic questions. Different sources are suitable for different tasks:

• Human annotation offers high quality but high cost, making it suitable for complex reasoning and professional domains.
• Post-generation model filtering can expand data scale, but requires strict quality filtering.
• Business logs are close to real scenarios, but require thorough desensitization and permission control.
• Synthetic data is suitable for tasks with clear rules and automatic verification, such as arithmetic, format conversion, and logic judgment.

2. Data Quality Filtering

Reasoning trajectory data is most vulnerable to samples that “look complete but are actually wrong.” Therefore, multiple filtering mechanisms are needed:

• Is the final answer correct?
• Is each step logically consistent with the previous step?
• Is there circular reasoning?
• Does it cite nonexistent facts?
• Does it violate problem conditions?
• Is it overly redundant or does it contain ineffective steps?
• Does it conform to the output format of the target task?

For math tasks, programmatic verification can be introduced. For knowledge question answering tasks, factual consistency checks can be added. For tool-calling tasks, it is necessary to verify parameter formats, calling order, and parsing of returned results.

3. Difficulty Layering and Curriculum Design

Not all high-quality trajectories are directly suitable for training. If the difficulty distribution of data is unreasonable, the model may remain focused on simple tasks for a long time and fail to improve complex reasoning. A more reasonable approach is to layer difficulty, for example:

• Single-step calculation;
• Two-step conditional reasoning;
• Multi-hop knowledge question answering;
• Judgment questions with distractors;
• Tasks requiring tool assistance;
• Information retrieval and integration in long contexts.

During training, complex samples can be introduced gradually from easy to difficult, so that the model first establishes basic formatting and step awareness, then improves stability in complex reasoning chains.

4. Training Methods: From “Learning Answers” to “Learning Processes”

High-quality reasoning trajectories can only be converted into model capabilities when combined with appropriate training objectives. Common methods include supervised fine-tuning, rejection sampling, preference optimization, and process rewards.

1. Supervised Fine-Tuning

Supervised fine-tuning is a basic method for directly teaching a model to learn high-quality reasoning trajectories. The training data usually includes the question, reasoning steps, and final answer. By minimizing the difference between predicted output and the real trajectory, the model gradually learns to generate similar structures.

An illustrative data format is shown below:

sample = {
    "question": "A pool has two inlet pipes. If they are opened alone, they take 6 hours and 4 hours respectively to fill the pool. How long does it take if both pipes are opened at the same time?",
    "steps": [
        "Identify the problem type: combining work rates.",
        "The first pipe fills 1/6 of the pool per hour.",
        "The second pipe fills 1/4 of the pool per hour.",
        "When both pipes are open, they fill 1/6 + 1/4 = 5/12 of the pool per hour.",
        "Total time = 1 / (5/12) = 12/5 = 2.4 hours"
    ],
    "answer": "2.4 hours",
    "metadata": {
        "task_type": "math_word_problem",
        "difficulty": "medium"
    }
}

The training objective of supervised fine-tuning can be to make the model generate steps based on the question and output the final answer. This way, the model learns not only the final answer, but also the complete task-handling process.

2. Rejection Sampling and Iterative Filtering

When data is limited, the model can first generate multiple reasoning trajectories for the same question, and then correct samples can be filtered through automatic verification or manual spot checks. This is similar to a closed loop of “generation—verification—retention.” Its advantage is that it can continuously leverage the model’s own capabilities, but its disadvantage is high computational cost, so generation quantity and filtering thresholds need to be controlled reasonably.

3. Preference Optimization

If both high-quality and low-quality trajectories exist, preference optimization methods can be used to make the model more inclined to generate trajectories with clearer logic, shorter steps, and more accurate facts. Compared with simply fitting standard answers, preference optimization focuses more on relative comparison of trajectory quality, which helps reduce redundant thinking and incorrect paths.

4. Process Rewards

The core of process rewards is to evaluate intermediate steps rather than only judging whether the final answer is correct. For example, after each reasoning step, one can check:

• Does the current step rely on the conditions in the problem?
• Is the calculation result accurate?
• Is it consistent with later goals?
• Does it introduce irrelevant expansion?
• Does it omit key constraints?

Through step-level feedback, the model can more precisely learn what constitutes valuable reasoning, rather than simply imitating surface language styles.

5. Improving Math and Knowledge Reasoning Abilities

Math reasoning and knowledge reasoning are two of the most intuitive scenarios where small models can make significant capability leaps.

1. Math Reasoning

Math tasks usually have clear rules and verifiable results, making them an important entry point for training reasoning abilities. Common problems in small models on math tasks include:

• Incomplete condition extraction;
• Incorrect identification of numerical relationships;
• Omission of unit conversion;
• Deviation in intermediate calculation results;
• Lack of verification in multi-step problems.

Through high-quality trajectory training, a model can gradually form a stable process: first understand the problem type, then extract known conditions, establish numerical relationships, perform calculations, and finally check units and reasonableness. Even with limited parameter scale, as long as the training signal is clear enough, the model can improve stability across many similar tasks.

2. Knowledge Reasoning

Knowledge reasoning places more emphasis on factual association and logical relationships. For example, a model may need to infer a final answer based on multiple entities, times, locations, causal relationships, or rule constraints. The key to such tasks is not simple memorization, but the ability to accurately locate relevant information in the context and combine it reasonably.

High-quality trajectory data can help the model learn to distinguish between:

• Core facts in the problem;
• Distracting information;
• Implicit conditions;
• Information that needs to be supplemented by external tools;
• User assumptions that should not be used directly.

This can reduce blind expansion and incorrect attribution in knowledge question answering.

6. Tool Calling: Small Models Can Also Participate in Agent Tasks

Once a small model has structured output capabilities, it can take on more agent tasks. For example, it can convert user intent into a tool-calling plan, analyze returned results, and continue execution based on multiple rounds of feedback.

The advantages of small models in agent scenarios are low cost, fast response, and ease of deployment in edge or private environments. However, they require stricter external constraints; otherwise, problems such as parameter extraction errors, incorrect tool calls, or result parsing failures may occur.

1. Structured Output Is the Prerequisite

Tool calling usually requires the model to output a fixed format, such as function names, parameter types, and parameter values. If trained sufficiently, a small model can generate structured content stably, but the business system still needs format validation and retry mechanisms.

def handle_user_request(user_text):
    plan = model.parse_intent(user_text)
    if not validate_schema(plan):
        return ask_user_to_clarify()
    for action in plan["actions"]:
        if action["type"] == "tool":
            result = tool_executor.run(
                action["name"],
                action["arguments"]
            )
        else:
            result = model.continue_reasoning(user_text, action)
    return model.summarize(result)

2. Tool Execution Needs Isolation and Auditing

Agent tasks often involve queries, calculations, retrieval, or business operations. To ensure safety, tool calls need permission isolation, log recording, and audit tracking. Small models themselves should not directly hold high-risk permissions; instead, actual operations should be completed through a controlled execution layer.

3. Failure Recovery Is Critical

In real business environments, tool-call failures are common. Small models need to learn to perform limited retries after errors, request clarification, or degrade gracefully, rather than continuing to generate meaningless content. To support this, failure cases and recovery strategies can be added to training data, so that the model understands it should stop or ask for help when it cannot continue.

7. Long-Context Capability: Not Simply “Stuffing in More Content”

Supporting long context in a small model does not mean that placing all materials directly into the input will improve performance. Key aspects of long-context capability include information localization, segment-level understanding, cross-segment integration, and noise filtering.

1. Common Challenges in Long Contexts

• Key information may be buried in large amounts of irrelevant content;
• Pronoun references may be complex across the text;
• Multiple material segments may conflict with each other;
• Model attention may become dispersed, causing omissions;
• Extremely long inputs can increase latency and cost.

2. Engineering Approaches

For long-document question answering or knowledge-base scenarios, retrieval augmentation can be combined with context compression:

• Segment and vectorize documents first;
• Retrieve relevant segments based on the question;
• Summarize and deduplicate segments;
• Organize highly relevant content into structured context;
• Allow the model to answer based on refined materials.

This approach can improve the effective use of small models while reducing the burden caused by invalid context.

8. Multimodal Applications: How Small Models Can “Understand Images”

Multimodal capability does not mean that a model must build complete visual understanding from scratch. A common approach is to introduce a visual encoder, convert images into representations that can be processed by a language model, and then use multimodal alignment training to help the model understand relationships between images and text.

For a 9B-scale model, multimodal applications can focus on lightweight and clearly defined tasks, such as:

• Image content description;
• Chart data question answering;
• Document layout understanding;
• Invoice field extraction;
• Text recognition in images;
• Multi-turn follow-up questions based on images.

1. Image Preprocessing Matters

In multimodal tasks, image resolution, cropping methods, compression strategies, and visual feature caching can all affect performance and cost. For small models, blindly increasing image input complexity may lead to significant overhead, so trade-offs need to be made based on task goals.

2. Image-Text Alignment Determines Stability

The model needs to learn how to associate visual information in images with textual questions. For example, in chart question answering, the model must not only recognize numbers, but also understand axes, units, legends, and what the question is pointing to. If the training data lacks sufficient image-text alignment samples, the model may misread content or fabricate answers.

9. Engineering Implementation: Making Reasoning Capabilities Serve Business Stably

Model capabilities ultimately need to be converted into business value through engineering systems. Small-parameter models are especially suitable for scenarios with requirements on cost, latency, and deployment flexibility, but they require a complete serving pipeline.

1. Inference Service Design

Common deployment methods include containerized deployment, elastic scaling, batch processing services, and asynchronous task queues. For high-frequency short requests, the focus can be on optimizing first-token latency and concurrency. For long-text or complex reasoning tasks, asynchronous processing, result callbacks, and caching mechanisms can be used.

2. Caching and Reuse

Reasoning tasks often involve many repeated or similar requests. Semantic caching, result caching, and segment-level caching can reduce repeated computation costs. For example, answers to common questions, tool-call results, or intermediate summaries can be cached to reduce repeated model reasoning.

3. Logging, Monitoring, and Alerting

Inference services need complete records of requests, latency, error types, tool-call status, and output summaries. Through logging services and monitoring and alerting systems, teams can promptly detect increased latency, higher error rates, abnormal outputs, and call-chain bottlenecks.

4. Data Storage and Data Closed Loop

Training data, inference logs, and evaluation results can be managed long term using object storage. High-quality feedback generated during business operations can also be desensitized, filtered, and fed back into training data, forming a continuous improvement loop.

10. Evaluation System: Do Not Rely on a Single Overall Score

Evaluating the reasoning ability of small models should not rely on a single metric. A more reasonable approach is to build a multi-dimensional evaluation system.

1. Capability Dimensions

• Math calculation accuracy;
• Correctness rate of multi-step logical reasoning;
• Consistency in knowledge question answering;
• Information localization ability in long contexts;
• Tool-call success rate;
• Structured output compliance rate;
• Multimodal understanding accuracy;
• Safety and compliance performance.

2. Evaluation Methods

• Automated benchmark testing: use question sets that can be scored automatically;
• Manual spot checks: assess whether the reasoning process is natural and consistent with business expression;
• Adversarial sample testing: check model stability when facing distractors, incorrect premises, or complex conditions;
• End-to-end task testing: observe task completion rates and user satisfaction in real business pipelines.

3. Key Metrics

In addition to accuracy, attention should be paid to:

• Average number of reasoning steps;
• Error propagation rate;
• Number of tool-call retries;
• First-token response latency;
• Cost per task;
• Timeout rate for long-context tasks;
• Multimodal misrecognition rate.

These metrics help teams determine whether model capabilities can truly be deployed in production, rather than only performing well on static test questions.

11. Common Pitfalls and Risk Control

When enhancing small-model reasoning capabilities, several common pitfalls should be avoided.

1. Focusing Only on Answer Correctness and Ignoring Process Quality

If training data only emphasizes the final answer, the model may learn surface patterns and still fail on new problems. Process quality must be included in both data filtering and evaluation systems.

2. Over-Relying on a Single Data Source

A single source can easily introduce distribution bias. Human data, synthetic data, business logs, and model-generated data each have advantages and disadvantages, so they should be combined and continuously verified.

3. Ignoring Safety Boundaries

Small models are more easily affected by incorrect inputs in tool-calling, long-context, and multimodal scenarios. Therefore, input filtering, permission control, output review, and exception circuit-breaking mechanisms are needed.

4. Equating Long Context with Strong Understanding

Longer input does not necessarily mean stronger understanding. If context is poorly organized or contains too much noise, model performance may decrease. Retrieval, summarization, and structured management are still important.

5. Ignoring the Balance Between Cost and Benefit

Enhancing reasoning capability is not about making everything as complex as possible. For high-frequency simple tasks, excessive training on complex reasoning may increase latency and cost. For critical business tasks, correctness and stability should be prioritized.

12. Conclusion: Small Parameters Can Also Deliver Strong Capabilities

The capability ceiling of a small model is not determined only by parameter scale. Through high-quality reasoning trajectory data, reasonable training objectives, engineered tool calling, long-context management, and multimodal alignment, a 9B-scale model can achieve significant capability improvements in many tasks. The real key is to upgrade model capability from “generating text” to “completing tasks.”

For developers and enterprises, what matters more than simply comparing parameter sizes is building a continuously optimizable closed loop: starting from task definition, build high-quality data; starting from training objectives, strengthen process supervision; starting from business scenarios, improve tool calling and evaluation systems; and starting from deployment costs, improve inference efficiency. Parameters are resources, data is fuel, and the engineering system is the track. When these three are combined, even limited parameters can create greater value.