Post-Training Techniques for Domestic LLMs: From Code Intelligence to 3D Content Generation

Competition among large language models is shifting from a “pre-training scale race” to a “post-training engineering race.” The base model determines the ceiling of capability, while post-training methods—instruction fine-tuning, preference alignment, tool-use reinforcement, and verifiable reward training—determine how much of that ceiling can actually be realized. A common feature of the recent round of model updates is that they start from existing base models and apply deep post-training, achieving clear leaps on several difficult tasks. This article follows that technical line, focusing on two main tracks—code intelligence and 3D content generation—and discusses evaluation methods, changes in cost structure, and key engineering considerations.

1. Why Post-Training Has Become the Main Battleground for Capability Growth

Pre-training solves the problem of “knowledge compression and language modeling,” while post-training solves the problem of “how to organize knowledge into reliable behavior.” Once base model scale reaches a certain level, the marginal returns from further increasing parameters diminish, whereas reinforcement learning on high-quality task trajectories, construction of verifiable reward signals, and incorporation of tool execution feedback can often yield higher task pass rates at lower cost.

Key technical elements of post-training typically include:

• Verifiable reward design: For tasks such as code, scripts, and structured output, the execution result itself is a natural reward signal, with no need to rely on subjective scoring models.
• Trajectory quality filtering: Error localization information from failed trajectories is fed back into training data to form “error–correction” paired samples.
• Tool-use strategy learning: Teaching the model to judge when to answer directly and when to verify through an external execution environment.
• Length and cost constraints: Explicitly introducing penalties for reasoning steps or token consumption into training objectives to avoid false improvements from “trading longer reasoning for higher scores.”

Understanding this framework is necessary to objectively interpret the meaning of various benchmark scores: score improvements often come from better post-training strategies rather than sudden changes in base model capability.

2. Code Intelligence: Terminal-Level Tasks Become the New Capability Yardstick

2.1 Why Terminal-Level Tasks Are Harder

Traditional code completion and function-level generation evaluations test “local correctness.” Terminal-level tasks, by contrast, require completing multi-step operations in a real execution environment: reading repository structure, locating faults, modifying files, running validation, handling errors, and iterating. The core difficulties of such tasks are:

1. State awareness: The model must understand the true state of the current environment rather than answering from imagination.
2. Long-range dependencies: A single modification may affect multiple modules, requiring global consistency.
3. Error recovery: Self-diagnosis and retry after execution failure is a key factor determining pass rates.
4. Controllable cost: Multiple rounds of tool calls easily inflate token consumption, so engineering constraints are necessary.

Therefore, evaluating terminal-level tasks usually involves observing two dimensions at once: task pass rate and per-task cost. Looking only at scores without considering cost will overestimate the practical usability of a solution.

2.2 The Two-Dimensional Tradeoff Between Capability and Cost

From public evaluation trends, top models have entered a relatively high range of pass rates on terminal-level tasks, but cost differences are significant. One type of solution pursues extreme low cost, usually through distillation or small parameter counts, suitable for high-frequency, low-complexity batch processing scenarios; another type maintains a high pass rate while keeping cost in a reasonable range, making it more suitable as a main production model.

For engineering selection, a tiered strategy is recommended:

# Pseudocode: route models by task complexity
def route_task(task):
    if task.complexity == "low":
        return "low-cost model"      # high-frequency, format conversion, simple fixes
    elif task.complexity == "medium":
        return "balanced model"      # routine bug fixes, unit test completion
    else:
        return "high-pass-rate model"    # cross-module refactoring, complex environment troubleshooting

The value of this routing design is that it concentrates expensive inference budgets on tasks that truly require long-range reasoning, potentially reducing overall cost by an order of magnitude with limited loss in end-to-end success rate.

2.3 Key Constraints in Practice

When integrating code agents into R&D workflows, several boundaries need to be designed in advance:

• Sandbox isolation: All execution must take place in restricted containers, with direct access to production environments prohibited.
• Auditable changes: Every file modification produced by the model should retain diffs and execution logs.
• Human confirmation points: Modifications involving dependency changes, build configuration, or permissions should require mandatory human review.
• Rollback mechanisms: Isolate model outputs via branches or snapshots to ensure rapid reversion.

These constraints are independent of model capability, but they directly determine whether a solution can actually go live.

3. 3D Content Generation: Bypassing the Protocol Layer with Direct Scripting

3.1 The Distinctive Nature of 3D Creation Tasks

3D modeling, CAD design, and spatial reasoning tasks differ fundamentally from pure text tasks: outputs must be structured geometric and material descriptions that can be parsed by professional tools. Early approaches had the model invoke modeling tool capability interfaces through an intermediate protocol layer, with the platform side handling conversion from parameters to geometry. The problem with this path is a long chain and an expressible range limited by interface capabilities, so complex layouts and detail adjustments often cannot be fully expressed.

3.2 The Technical Value of Direct Scripting

An important change brought by post-training is that models can directly write native scripts for professional modeling tools, completing asset construction, detail refinement, and adjustment of layout, material, and geometric parameters. The technical significance of this shift is:

1. Complete expression space: The scripting language itself is Turing-complete and can express combinations of operations that an interface layer cannot cover.
2. Shorter chain: Eliminating the protocol conversion step reduces the number of failure points and debugging cost.
3. Reproducible results: The script is the artifact, naturally enabling version management and parameterized reuse.
4. Iterative correction: Execution errors can be fed directly back to the model, forming a “generate–execute–correct” loop.

From an evaluation perspective, such capabilities are usually assessed in conjunction with tool dependency conditions: given permission to call modeling tools for execution validation, the evaluation examines whether the generated script can correctly build the target structure. Public trends show that open-source solutions have reached scores close to closed-source top-tier levels on such tasks, with the gap mainly appearing in stability on extremely complex scenarios.

3.3 Typical Workflow Example

# Pseudocode: closed loop of direct scripting + execution validation
def build_asset(spec, model, executor, max_rounds=3):
    script = model.generate_script(spec)      # generate modeling script
    for _ in range(max_rounds):
        result = executor.run(script)         # execute in sandbox
        if result.ok:
            return result.artifact            # produce model file
        script = model.repair(script, result.error_log)  # correct based on error log
    raise BuildError("retry limit exceeded")

The key to this pattern is using “execution feedback” as a shared signal for both training and inference, so the model gradually learns to write scripts that actually run, rather than scripts that merely look reasonable.

3.4 Implementation Considerations

• Version compatibility: Modeling tool scripting APIs change across versions, so the execution environment version should be pinned.
• Geometric validity checks: Successful script execution does not equal reasonable geometry; topology, normals, scale, and other checks should be added.
• Asset standards: Unify naming, hierarchy, and units to avoid generated results being difficult to integrate into downstream pipelines.
• Compute budget: The execution overhead of 3D tasks is far higher than text tasks, requiring queue-based scheduling and timeout settings.

4. The Right Way to Evaluate Capabilities

When facing various benchmarks, it is advisable to maintain three clear-headed understandings:

1. Look at task definitions: Whether tool calls are allowed and whether multiple retries are permitted significantly affects score comparability.
2. Look at cost metrics: Per-task token consumption, execution time, and concurrency limits should all be considered.
3. Look at failure distribution: Average scores mask the long tail; what truly determines production usability is the failure rate in complex scenarios.

A more pragmatic approach is to build your own evaluation set: sample tasks from real business scenarios, annotate pass criteria, and use small-scale, highly representative samples for A/B comparisons rather than directly trusting public benchmark rankings.

5. Conclusion

The maturation of post-training techniques has made the capability growth path of large models more engineering-driven: using verifiable rewards to drive behavior optimization, tool execution loops to improve reliability, and cost constraints to ensure usability. The two main tracks of code intelligence and 3D content generation happen to represent two typical task forms—the former relies on environment interaction and long-range reasoning, while the latter relies on structured output and execution validation. When integrating these two types of capabilities into R&D and creation workflows, the real challenge lies not in the model itself but in building engineering infrastructure such as sandboxes, auditing, validation, and scheduling. Only by laying these foundations solidly can each post-training improvement in model capability be reliably converted into productivity.