The Evolution of LLM Post-Training: From Code Execution to 3D Modeling

    This article explores the shift in large language model development from parameter scaling to post-training capability density. It analyzes recent advancements in terminal-level code tasks, script-based 3D modeling, financial document understanding, and hallucination mitigation, providing developers with actionable insights for integrating these capabilities into their workflows.

    The Evolution of LLM Post-Training: From Code Execution to 3D Modeling

    1. The Turning Point of Post-Training Paradigms: Why Iteration Speed Matters More Than Parameter Scale

    Over the past year, the competitive focus in the large language model (LLM) space has shifted from “pre-training parameter scale” to “post-training capability density.” A representative signal of this shift is that systematic post-training on the same base model can yield comprehensive capability improvements, allowing models to approach or even surpass some independently trained frontier models on multiple high-difficulty benchmarks. This indicates that data construction, reward modeling, and targeted capability enhancement during the post-training phase are becoming the critical variables determining a model’s practical value.

    This article analyzes a recent concentrated release of capabilities by domestic models in the post-training domain. We will explore five dimensions—code generation, 3D modeling, financial document understanding, hallucination mitigation, and security research—discussing the technical logic behind these capabilities and their practical impact on developer workflows.

    2. Terminal-Level Code Tasks: Capability Stratification from Completion to Autonomous Execution

    2.1 The Inherent Difficulty of Terminal Tasks

    Traditional code completion benchmarks (such as function-level generation or single-file bug fixing) primarily test a model’s syntax comprehension and local reasoning. Conversely, Terminal-style Benchmarks require the model to perform multi-step operations within an interactive command-line environment: reading file system states, executing commands, parsing outputs, adjusting strategies based on error messages, and ultimately achieving a high-level goal. These tasks impose composite requirements on the model:

    • Long-range planning: Decomposing the target into an executable sequence of commands;
    • Environment awareness: Understanding the current working directory, dependency states, and permission constraints;
    • Error recovery: Pinpointing issues from non-zero exit codes and stderr outputs;
    • Cost control: Executing as many effective operations as possible within a limited token budget.

    2.2 Score Jump Brought by Post-Training

    In the latest post-training iteration, domestic models improved their scores on terminal-level code tasks from the previous generation’s baseline to 65.7. This score positions them favorably among peers, second only to a few closed-source frontier models, and surpassing some contemporary competitors. More noteworthy is the cost dimension: on the same task set, the per-task cost of these models falls into the lowest bracket among frontier models.

    It is crucial to distinguish between two concepts: lowest cost and optimal cost-effectiveness. While some lightweight models offer lower per-call costs, their completion rates on terminal tasks lag significantly, resulting in a higher “average cost per completed task.” The optimization goal during post-training is fundamentally about finding a better Pareto frontier between capability and cost.

    2.3 Impact on Developer Workflows

    For developers routinely handling CI/CD script debugging, environment configuration migration, and batch file processing, the enhancement in terminal-level capabilities means more “glue” tasks can be delegated to the model. A typical implementation pattern looks like this:

    1. # Example: Integrating the model into a local terminal agent loop
    2. # Model receives natural language goal -> generates command -> executes -> reads output -> corrects
    3. while not task_done:
    4. cmd = model.generate_next_command(history, env_state)
    5. result = execute(cmd)
    6. history.append((cmd, result))

    The engineering value of this pattern lies in freeing developers from the “check documentation — try command — read error” loop, allowing them to focus on goal definition and result verification.

    3. Script-Based 3D Modeling: From MCP Dependency to Direct Generation

    3.1 The Specifics of 3D Modeling Tasks

    3D modeling fundamentally differs from 2D image generation. Beyond visual plausibility, it demands geometric consistency, topological correctness, and editability. A qualified modeling output must satisfy:

    • No self-intersections in the mesh and correct normal directions;
    • Traceable parametric history for subsequent modifications;
    • Materials, lighting, and camera layouts that align with physical intuition.

    Traditional solutions often rely on intermediate layers like the Model Context Protocol (MCP) to translate model outputs into instructions recognizable by modeling tools. The issue with this approach is that the abstraction granularity of the intermediate layer is often insufficient, making it difficult to express complex geometric operations precisely.

    3.2 The Technical Path of Direct Script Generation

    A key capability enhancement in the post-training phase is the model’s ability to directly write scripts for professional modeling tools (such as Blender or CAD software), bypassing the intermediate layer to manipulate geometric primitives, modifier stacks, and material nodes directly. On tool-dependent CAD benchmarks, this model achieved a score of 92.7, approaching the level of closed-source frontier models and leading among open-source alternatives.

    The technical highlights include:

    1. API semantic understanding: The model must accurately grasp the Python API naming conventions and parameter agreements of the modeling tool;
    2. Geometric reasoning: Understanding the actual impact of rotations, boolean operations, and chamfers on the mesh;
    3. Layout planning: Inferring spatial relationships between objects based on natural language descriptions.

    3.3 Online Preview and Editing Loop

    The simultaneously launched online 3D creation feature encapsulates the aforementioned capabilities into an interactive product format. Upon receiving a user’s description, the model generates a script and renders a previewable 3D model. Users can adjust the layout, materials, and geometric parameters online, and export the final result in a print format or as a video/Live photo.

    The significance of this closed loop lies in combining “script generation” with “instant visual feedback,” lowering the barrier for non-professional users to utilize 3D tools while preserving the space for professional users to fine-tune via scripts.

    4. Financial Document Understanding: Retrieval, Reconciliation, and Multi-Step Numerical Reasoning

    4.1 Why Financial Documents are a Hard Nut to Crack

    The difficulty of financial document understanding tasks lies not in a single capability, but in the concatenation of multiple capabilities:

    • Retrieval: Locating relevant tables and footnotes from hundreds of pages of PDFs;
    • Cross-document reconciliation: Comparing caliber differences across reporting periods;
    • Multi-step numerical reasoning: Calculating ratios, growth rates, and adjusted metrics.

    These tasks demand high-level context management, numerical precision awareness, and the judgment to know “when to say I don’t know” from the model.

    4.2 Benchmark Performance and Capability Positioning

    On a complex analysis benchmark targeting real-world financial documents, the model scored 64.4, ranking favorably among evaluated models. On a benchmark covering the complete investment workflow (from target screening to profitability analysis), the score improved to 58.6, marking significant progress over the previous generation.

    The practical implication of these numbers is that the model can now assume the role of junior analytical assistant—extracting key financial metrics from annual reports, calculating preliminary valuation ranges, and flagging data anomalies. However, stages involving critical judgments still require manual review.

    5. Hallucination Mitigation and Security Research Capabilities

    5.1 The Downward Curve of Hallucination Rates

    In internal stress test sets, the model’s error rate dropped from 23.4% in the previous generation to 8.3%, a reduction of more than half. This improvement is primarily attributed to factuality reward signals and refusal calibration introduced during the post-training phase:

    • Rewarding correct answers to verifiable questions;
    • Rewarding reasonable expressions of “uncertainty” for unanswerable questions or those beyond the model’s knowledge boundary;
    • Penalizing clearly contradictory answers.

    5.2 Positive Correlation with Security Research Capabilities

    A notable observation is that as post-training scales, the model’s performance on vulnerability research-related tasks continues to improve. This is no coincidence—vulnerability research is fundamentally a deep code comprehension + counterfactual reasoning task, sharing the same underlying capabilities as terminal-level code improvements.

    Naturally, this introduces dual-use risks: the same capabilities can be used for defensive research or potentially abused. Therefore, releasing these capabilities requires accompanying usage policies and access controls.

    6. Practical Recommendations for Developers

    Synthesizing the analysis above, we offer the following references for developers:

    1. Prioritize validating terminal-level capabilities for code tasks: If your workflow involves extensive shell operations and environment interactions, prioritize empirical testing on terminal-style benchmarks rather than solely looking at function-level completion scores.
    2. Focus on script editability for 3D modeling: Choose solutions that support direct script output to avoid precision loss caused by intermediate layer abstractions.
    3. Retain manual review steps in financial scenarios: Position the model as an information extraction and preliminary calculation tool; key conclusions still require cross-validation.
    4. Focus on cost-effectiveness rather than absolute cost: In long-range tasks, completion rates dictate actual expenditure more than per-call pricing.
    5. Proactively evaluate the double-edged sword of security capabilities: When introducing autonomous code execution capabilities, implement sandboxing and least-privilege strategies.

    7. Conclusion

    The capability density competition in the post-training phase is reshaping the evaluation standards for the practical value of LLMs. From terminal-level code execution to script-based 3D modeling, and from financial document understanding to hallucination mitigation, every capability enhancement is backed by systematic engineering in data construction, reward modeling, and inference optimization. For developers, understanding the technical boundaries and applicable scenarios of these capabilities holds greater long-term value than chasing benchmark scores.