Post-Training Advances in Chinese LLMs: Code, 3D Modeling, and Financial Reasoning

The Value of the Post-Training Paradigm: Why One Version Iteration Matters

As competition among large language models intensifies, the cost curve of base pre-training has become relatively transparent. The real differentiator increasingly lies in the post-training phase—specifically in data mixing ratios, task design, and alignment strategies. A version that builds on an existing base model and achieves significant improvements across multiple heterogeneous benchmarks suggests that its training pipeline possesses strong generalizability in task transfer and capability activation, rather than merely reflecting single-point optimization.

From an engineering perspective, the significance of such an iteration manifests on three levels. First, capability enhancements spanning code, spatial reasoning, and document understanding imply improved usability in mixed-load scenarios. Second, cost control has emerged as an evaluation dimension on par with performance, indicating that inference efficiency is now integrated into training objectives. Third, hallucination rates and safety research capabilities are measured independently, reflecting that reliability engineering is becoming a standard component of post-training. The following analysis breaks down the iteration across four capability dimensions.

Code Capability: Performance and Cost Structure in Terminal-Level Tasks

What Terminal-Style Benchmarks Actually Measure

Terminal-style benchmarks differ fundamentally from traditional function completion or algorithm problem solving. These tasks require models to execute multi-step operations in a real command-line environment: interpreting natural language instructions, planning operation sequences, writing and executing scripts, reading command outputs, and adjusting strategies based on error messages. They assess “agentic” code capability rather than single-turn generation quality.

Achieving a high score on such tasks typically implies that a model possesses the following characteristics: a stable understanding of shell semantics and common toolchains; the ability to maintain task goals without drift over long contexts; and self-recovery capabilities to correct errors based on execution feedback. The score improvement to 65.7 points on this type of benchmark places the model in a leading position, indicating that its planning and execution capabilities in multi-step code tasks are already relatively mature.

Cost as a First-Class Evaluation Metric

The cost dimension warrants separate discussion. In real production environments, code agents often require repeated invocations and multiple retries, amplifying single-call inference costs severalfold. Consequently, “cost per successful task” is more informative than “price per call.” The source material notes that this version demonstrates strong cost control on such tasks among frontier models, while also acknowledging competitors with lower prices but significantly worse performance. This illustrates an engineering reality: if lower cost comes at the expense of capability, the price advantage in agentic tasks is offset by an increased number of retries.

A simplified cost model can illustrate this point:

# Simplified estimation of cost per successful task
def cost_per_success(price_per_call, success_rate, avg_retries):
    # Expected number of calls ≈ 1 / success_rate, plus retry overhead
    expected_calls = (1 / success_rate) + avg_retries
    return price_per_call * expected_calls
# Option A: lower unit price but lower success rate
print(cost_per_success(price_per_call=1.0, success_rate=0.55, avg_retries=1.2))
# Option B: slightly higher unit price but higher success rate
print(cost_per_success(price_per_call=1.6, success_rate=0.82, avg_retries=0.4))

Under the above assumptions, Option B actually yields a lower cost per successful task. This also explains why, in agentic code scenarios, “cost-effectiveness” must be evaluated by combining success rate with retry behavior, rather than by looking at price lists alone.

Engineering Implementation Recommendations

For teams planning to integrate code agents into their development workflows, three points deserve attention. First, incorporate terminal-style tasks into internal evaluation sets, using real repository build, test, and fix cycles for regression testing. Second, enforce execution sandboxes and timeout constraints on agents to prevent erroneous operations from spreading. Third, log the call chain and failure reasons for each task to support subsequent optimization of prompts and tool orchestration.

3D Modeling and Spatial Reasoning: Script-Driven Control of Professional Tools

Moving Beyond MCP to Direct Script Generation

A technically significant point in the source material is that the model can directly write scripts for professional modeling tools to complete asset construction and refinement, without heavily relying on an external bridge layer such as MCP (Model Context Protocol). The technical implication of this shift deserves elaboration.

The MCP pattern essentially exposes tool capabilities to the model through a standardized protocol, with external services executing the actual operations. Its advantages include unified integration and controllable permissions. Its disadvantages include a longer pipeline, higher context overhead, and a model understanding of tool semantics that is limited by protocol encapsulation. In contrast, direct script generation has the model program against the tool’s native API—requiring the model to understand object models, coordinate systems, geometric operations, material binding, and other concepts, while producing executable script code.

A comparison of the two patterns can be summarized as follows:

Dimension	Protocol Bridge Mode	Direct Script Mode
Context overhead	Higher; requires tool schema description	Lower; focused on script logic
Expressiveness	Limited to exposed interfaces	Close to native tool capabilities
Debugging difficulty	Error messages pass through protocol conversion	Script errors can be read directly
Security boundary	Controllable at the protocol layer	Requires sandbox and permission isolation

Spatial Reasoning Benchmarks and Capability Boundaries

On tool-dependent CAD-style benchmarks, this version achieves a score of 92.7 points, placing it in a leading position among open-source models, with a gap of only single digits to top closed-source models. This result indicates that the model already delivers practical value on the combined task of “spatial relationship understanding + tool invocation + parametric modeling.”

Breaking the task down, this capability typically includes: understanding dimensional, positional, and orientation constraints expressed in natural language; mapping those constraints to parametric geometric operations; handling modeling primitives such as boolean operations, chamfering, and array patterns; and adjusting parameters iteratively based on preview results. A typical workflow can be abstracted as follows:

# Pseudocode: typical flow of script-driven modeling
scene = create_scene()
base = scene.add_primitive("cylinder", radius=0.4, height=0.2)
blades = [scene.add_primitive("box", size=(0.05, 0.02, 0.3))
          for _ in range(8)]
for i, b in enumerate(blades):
    b.rotate_z(i * 45)          # circular array
    b.translate(radial=0.45)    # radial offset
    b.boolean_union(base)       # merge into one solid
scene.apply_material(base, "metal_brushed")
scene.export("impeller.step")

The officially demonstrated use cases cover interior scene vegetation placement, mechanical impeller structures, and lighting product modeling. A common thread is the need to balance geometric precision with structural rationality. It should be noted that such capabilities currently remain primarily in the form of “assisted generation + manual verification.” Strongly regulated scenarios involving engineering dimensional tolerances and assembly constraints still require review by professional staff.

Online Preview and Export Pipeline

The accompanying online 3D feature provides an integrated pipeline for preview, editing, and export. Models can be downloaded for additive manufacturing, and videos or animated photos can be exported for sharing. For developers, the value of such a pipeline lies in shortening the “generate-verify-iterate” feedback cycle: scripts are visualized immediately after generation, quickly exposing geometric errors and reducing unproductive round trips.

Financial Document Reasoning and Hallucination Control

Multi-Step Reasoning on Complex Financial Documents

Benchmarks based on real financial documents typically assess a combination of retrieval, cross-document verification, and multi-step numerical reasoning. This differs from ordinary table-based question answering: document formats are heterogeneous, accounting standards vary, cross-page comparisons are required, and answers often depend on several intermediate calculation steps. Achieving 64.4 points on this type of task and leading comparable models indicates stable performance in long-document localization and numerical chain maintenance.

On investment workflow-style benchmarks covering the full pipeline from target screening to profitability analysis, this version scores 58.6 points, a notable improvement over the previous generation. These evaluations more closely resemble real business processes and emphasize state transfer across multi-stage tasks. In engineering practice, it is advisable to use such capabilities for initial screening and draft generation, while retaining human review and data traceability for key conclusions.

Quantified Reduction in Hallucination Rate

Internal stress testing shows the error rate dropping from 23.4% in the previous generation to 8.3%. This reduction carries significant weight in reliability engineering: in document Q&A and data verification scenarios, each order-of-magnitude reduction in error rate correspondingly lowers manual review costs. It should be emphasized that hallucination control and capability improvement do not always move in the same direction. Achieving lower error rates while simultaneously enhancing capabilities typically depends on targeted design in the post-training phase around refusal strategies, citation constraints, and consistency checks.

Security Research Capability Improving in Parallel

The source material notes that as post-training scale expands, the model’s vulnerability research capability continues to improve. This observation aligns with industry-wide findings: stronger code understanding and reasoning capabilities naturally transfer to tasks such as vulnerability pattern recognition and patch analysis. For defenders, this means models can accelerate code auditing and risk investigation. It also implies the need for accompanying usage policies and access controls to prevent capability misuse.

Selection and Practice Recommendations

Taken as a whole, the improvements in this post-training version exhibit a “multi-point simultaneous” character rather than a single breakthrough. The following practical recommendations are offered for developers and enterprises:

1. Adopt task-type layered evaluation: Establish separate internal benchmarks for code agents, 3D script generation, and document reasoning, avoiding selection decisions based on a single aggregate score.
2. Incorporate cost models into evaluation: Replace unit-price comparisons with “cost per successful task,” fully accounting for retries and manual review overhead.
3. Set boundaries for scripted tool invocation: For operations with side effects, such as modeling and terminal access, enforce sandboxed execution, least-privilege permissions, and operation auditing.
4. Retain human verification steps: In strongly regulated scenarios involving engineering dimensions or financial conclusions, position the model as an accelerator rather than the final decision-maker.
5. Monitor reliability metrics: Include hallucination rate and refusal reasonableness in pre-release acceptance checklists, treating them with the same importance as performance metrics.

Competition in post-training has shifted from “whether it can be done” to “whether it can be done reliably and affordably.” A model that can advance simultaneously across code, spatial reasoning, document understanding, and reliability is more likely to succeed in real-world mixed workloads. For technical teams, the rational approach is to build reproducible evaluation and cost models around their own business needs, ensuring that every version iteration can be quantitatively validated.