Breakthroughs in LLM Post-Training and 3D Script Generation Practices

6 hr ago0 views

Large language model (LLM) iteration has shifted towards a two-stage approach: pre-training for general capabilities and post-training for targeted enhancements. This article explores recent breakthroughs in post-training techniques for a domestic LLM, focusing on its performance in terminal-based coding tasks, direct 3D modeling script generation, and hallucination suppression. It provides engineering insights, effective cost evaluation frameworks, and practical selection guidelines for developers building production-grade applications.

1. From Base Models to Post-Training: The Engineering Logic of Capability Leaps

Current LLM iterations follow a clear two-stage path: first building a general base through large-scale pre-training, and then applying post-training for targeted enhancements across specific capability dimensions. Post-training is not simple fine-tuning; it is a systematic engineering effort combining Supervised Fine-Tuning (SFT), preference alignment, refusal calibration, and tool-call trajectory learning.

Recently, a domestic LLM team released a post-trained version deeply optimized for coding and 3D creation scenarios, several months after their base model launch. The significance of this move lies in validating that “base model + targeted post-training” can push specific task capabilities to a level approaching or even surpassing some frontier closed-source models, without requiring a fresh round of pre-training. For developers, this means the available model pool is no longer limited to the extremes of “large general-purpose” and “small specialized” models. A medium-sized base model combined with high-quality post-training data can be highly competitive in vertical tasks.

From an engineering perspective, the core challenges of post-training focus on three areas: data quality and distribution control, mitigation of catastrophic forgetting, and stability of tool-call trajectories. We will explore these based on public evaluation dimensions below.

2. Coding Tasks: Capability and Cost Dimensions in Terminal Environments

Terminal-style coding tasks (similar to Terminal Bench evaluations) assess a model’s multi-step operational capabilities within a real command-line environment, including file I/O, dependency installation, script debugging, and error recovery. These tasks fundamentally differ from simple function-level code generation—they require the model to possess environmental awareness and long-horizon planning capabilities.

According to public evaluation data, this post-trained version achieved significant improvements in terminal coding tasks, scoring in the first tier of frontier models and leading among domestic models. More notably is the cost dimension: among similar frontier models, its unit cost control for terminal tasks stands out. In comparison, some lightweight models known for low costs have lower unit prices, but their noticeably lower task completion rates result in a higher “effective cost” (the actual expense to complete a task).

The takeaway for developers is that model selection cannot rely solely on token unit price. It is recommended to establish the following evaluation framework:

# Effective cost estimation example (pseudo-code)
def effective_cost(model, task_suite):
    total_tokens = 0
    success = 0
    for task in task_suite:
        result = run_task(model, task)
        total_tokens += result.tokens_used
        if result.passed:
            success += 1
    unit_price = model.price_per_token
    raw_cost = total_tokens * unit_price
    success_rate = success / len(task_suite)
    # Effective cost = raw cost / success rate
    return raw_cost / success_rate if success_rate > 0 else float('inf')

In actual projects, retry counts and manual intervention time should also be factored in to obtain a true cost profile.

3. 3D Modeling and Spatial Reasoning: Direct Scripting Over Tool Dependency

The most noteworthy direction of this post-training for developers is the enhancement of 3D creation and spatial reasoning capabilities. Traditionally, there are two paths for involving LLMs in 3D modeling: operating modeling software via tool-calling protocols (such as MCP-style solutions), or having the model directly generate modeling scripts.

The former suffers from a long link chain, complex state synchronization, and difficult debugging. The latter demands high levels of domain knowledge, geometric intuition, and familiarity with scripting APIs from the model. In CAD-style evaluations under tool-dependency scenarios, this version scored over 92, approaching the level of leading closed-source models. Furthermore, it can reportedly write scripts for mainstream modeling tools directly without relying on tool-calling protocols, completing asset setup, detail refinement, layout adjustments, and material/geometry parameter modifications.

This capability substantially transforms content creation workflows. Consider a typical scenario requiring the batch generation of a set of stylistically uniform architectural components. The traditional workflow involves manual operations by artists in modeling software or writing scripts followed by individual adjustments. The new workflow can be:

# Script-driven modeling workflow example (pseudo-code)
prompt = """
Generate a modeling script with the following requirements:
1. Create a beveled cuboid main body, dimensions 2x1x0.5
2. Array 4 cylindrical decorative parts on top, radius 0.1
3. Assign a unified material slot to all objects
4. Output as a script directly executable by modeling software
"""
script = model.generate(prompt)
execute_in_modeling_tool(script)
# If the result does not meet expectations, pass the render screenshot and error logs back to the model for iterative correction

The key is the closed loop of “generate—execute—feedback—correct.” The model needs to understand the geometric outcomes of operations, not just produce syntactically correct scripts. This requires deep coupling of spatial reasoning and coding capabilities, which is why this version emphasizes both “3D creation and spatial reasoning.”

4. Hallucination Suppression: Credibility as a Prerequisite for Production

No matter how strong a model’s capabilities are, if its hallucination rate remains high, it cannot enter production environments. Public information indicates that internal stress tests showed this version reduced the error rate on difficult samples from approximately 23% in the previous generation to about 8%. This significant drop places it at the forefront among models of the same scale.

Hallucination suppression methods typically include negative sample construction and refusal alignment during training, retrieval augmentation and self-checking during inference, and fact-checking during post-processing. Reusable engineering practices for developers include:

Mandating source citations or confidence score annotations for high-risk outputs;
Adding result validation nodes in the tool-calling chain, for example, preventing the model from “hallucinating” success when a script execution fails;
Establishing a domain-specific regression test set to run after every model version update to monitor hallucination rate changes.

Incorporating the hallucination rate as a hard metric in model selection, rather than just looking at capability scores, is a fundamental requirement for production-grade applications.

5. Implementation Recommendations and Selection Strategy

Overall, these post-training-enhanced models are suitable for the following scenarios:

Terminal automation and script generation: Coding tasks requiring multi-step operations and environment interaction;
Batch 3D content production: Using scripts as intermediate artifacts to replace repetitive modeling labor;
Cost-sensitive frontier capability invocation: Pursuing better effective costs with acceptable success rates;
Knowledge-intensive tasks with low hallucination tolerance: Must be used in conjunction with validation pipelines.

When selecting a model, it is recommended to score based on a four-dimensional matrix: “task success rate × unit cost × hallucination rate × toolchain compatibility,” rather than being driven by a single leaderboard score or unit price. Additionally, due to the rapid pace of model iteration, teams should solidify evaluation sets and regression workflows as core assets, ensuring that changing models does not require changing processes.