Large Model Evolution and Engineering Practice, 2022–2026: Open Weights, Multimodal Systems, and Coding Agents

How the cycle opened

Starting in late 2022, conversational generative models moved from lab demonstrations to consumer products that people could use every day. Users no longer only called a single completion endpoint. They stated goals, added constraints, and corrected errors across multi-turn context. For engineering teams, the important change was not the chat interface itself, but the interaction protocol: input shifted from short prompts to sessions with history, and output shifted from a block of text to an intermediate result that could be questioned further or consumed by tools. Product teams soon faced subscription, quota, context length, and safety policy operations. R&D teams had to handle latency, cost, hallucination, and permission boundaries at the same time.

The starting point of this cycle can be summarized as three conditions holding at once: models had general language capability that was usable enough; the interaction form lowered the barrier to use; and distribution channels could turn trials into sustained calls. After that, competition was no longer only about who had the highest benchmark score. It was about who could put capability into real workflows reliably.

How open weights changed the R&D path

Soon after consumer chat products appeared, large parameter weights that had previously been available mainly for research applications became more widely accessible and retrainable. The community produced a large number of instruction-tuned, dialogue-aligned, and domain-adapted versions. For developers, this created two parallel paths:

• Call hosted frontier model services in exchange for a faster capability ceiling and less operational burden.
• Load open weights on owned or rented compute in exchange for keeping data in-domain, customizing vocabularies, and freezing auditable versions.

Open weights do not mean “free for commercial use.” License terms, redistribution limits, training data compliance, and downstream responsibility still need separate review. The more practical engineering benefit is reproducibility: teams can reproduce experiments, compare fine-tuning recipes, and fix evaluation sets on the same checkpoint. A common method for many derivative models is supervised fine-tuning or preference optimization on a base model rather than pretraining from scratch. This lowers the entry cost from “build a ten-thousand-GPU cluster” to “high-quality instruction data plus controllable training jobs.”

When selecting a path, write the problem as constraints rather than brand preferences: whether data can leave the domain, whether private deployment is required, peak concurrency and context length, whether behavior drift from weight updates is acceptable, and whether the license covers commercial distribution. A route that fails the constraints should not enter production, no matter how strong its demo looks.

From bolt-on vision to native multimodality

An early common multimodal approach was to attach a vision encoder outside the language model and use a projection layer to align image features with text space. This structure shipped quickly and reused existing language capability, but cross-modal alignment happened in post-processing. Joint reasoning over long video, audio, and interleaved image-text inputs was often unstable.

Later flagship models began to put text, images, audio, and video into the same modeling objective during pretraining. The engineering meaning of native multimodality is that tokenization and feature extraction, positional encoding, training mixture ratios, and inference-time modality routing are designed together in the architecture, rather than attaching a vision head before launch. The industry also began to distinguish deployment forms by capability tiers: high-end for complex reasoning and multimodal understanding, mid-tier for general chat and enterprise knowledge bases, and small-tier for edge or low-latency scenarios. Tiering itself is not a proprietary invention of any one vendor; it is a natural result of constraints on compute, latency, and unit price.

In deployment, do not assume that “can see images” equals “can do the business task.” Measure separately: layout understanding, chart numeric reading, cross-page reference, audio-video temporal alignment, and refusal to answer beyond the evidence. Evaluation sets must come from domain samples, not curated screenshots from public demos.

Technical commonalities in China’s dense release phase

Around the same period, several organizations in China released conversational large models in a concentrated wave, creating competition with rapidly rising parameter scale and highly similar product forms. Baidu and other organizations were early to turn Chinese dialogue capability into trial products, which pushed the whole industry to treat “can chat” as a baseline rather than a differentiator.

Most models in this phase used dense decoder-only Transformer architectures. Differences came mainly from Chinese corpora, instruction data, and safety alignment, not from a completely new computation graph. Dense models have mature training and inference paths and a complete ecosystem of tools. The cost is that activated parameters grow almost in lockstep with total parameters, so compute per request is hard to reduce linearly with business growth. Therefore, the “hundred models” phenomenon was more of a supply explosion than the endgame of cost and architecture.

For enterprise users, the practical conclusion from this phase is: Chinese understanding, industry terminology, and compliance language can be differentiated through data and fine-tuning, but if architecture and training recipes are homogeneous, marginal returns decline quickly. Later competition inevitably shifts to inference cost, long-context quality, tool-calling reliability, and private data adaptation efficiency.

Architecture and cost: questions after dense models

Once chat capability becomes standard, both procurement and self-development must return to unit task cost. Teams need to look at three accounts at the same time: training, alignment, and online inference.

1. Pretraining determines knowledge coverage and the ceiling, but most teams should not repeat this investment.
2. Alignment determines whether the model follows instructions, whether it oversteps permissions, and whether it refuses consistently.
3. Inference determines concurrency, latency, and gross margin, and it is often the main cost after scale.

General directions worth discussing include longer but more effective context compression, speculative decoding, quantization and caching, routing requests by difficulty to models of different sizes, and sparse activation approaches such as mixture of experts. These are common industry techniques, not proprietary interfaces of any one platform. Before adopting any of them, replay fixed traffic to compare quality regression and cost reduction. Avoid making something “look faster” only on short prompts.

The data side also needs accounting. Cleaning, deduplication, copyright review, and privacy review of Chinese and domain corpora determine the ceiling more than piling on another dense model of the same size. Instruction data should cover failure cases: refusals, multi-turn corrections, empty tool returns, and ambiguous user goals. Stacking only “standard Q&A” makes a model look good on demo sets but fragile in production logs.

Coding agents: from completion to delivery

After chat models became widespread, coding assistance advanced from “complete the next line” to “complete a task in an isolated environment.” A typical loop is: read the requirement and existing code, retrieve documentation, modify files, run tests, and revise based on errors until the task is done or clearly fails. Such systems are often called coding agents. They turn the model from a text generator into a combination of planner and executor, where the executor is usually a sandbox, version repository, test runner, and read-only or controlled external tools.

The gap between early product demos and real completion rates defined later evaluation methods: do not look at how many lines of seemingly correct code were generated; look only at whether the task actually passes tests and meets acceptance conditions within a fixed time and permission scope. This standard applies to all coding agents, regardless of brand.

For engineering, split the agent into an observable state machine rather than an infinite prompt loop:

• Goal: user story, interface contract, or failing test case.
• Context: repository subset, dependency notes, forbidden paths.
• Actions: read files, write patches, execute commands, request clarification.
• Stop: tests pass, step budget exhausted, insufficient permission, or dangerous operation detected.
• Evidence: patches, logs, and test reports, not the model’s self-evaluation.

A schematic task record does not need to bind to any vendor format, as long as it can be replayed:

task_id: invoice-rounding
repo_snapshot: <commit>
allowed_paths: [src/billing/, tests/billing/]
budget: 20 steps, 15 min
success: unit tests green AND no change outside allowed_paths
artifacts: patch.diff, test.log, trace.jsonl

Controversies also need to be written into policy: an agent may “fix the test” instead of fixing the defect, introduce unauthorized dependencies, or leak keys outside the sandbox. Therefore, default permissions should be minimal, network and keys should be granted per task, and a human or independent pipeline should still review before merge. Completion statistics must distinguish “first-pass,” “pass after human takeover,” and “abandoned.” Mixing these three categories in one demo video cannot guide scheduling.

Evaluation systems: do not rely only on public exams

Professional exams, coding problems, and multimodal samples can indicate capability magnitude, but they cannot replace business evaluation. At minimum, use four layers:

• Capability layer: basic questions on language, code, multimodality, and tool calling, used for version regression.
• Task layer: end-to-end tasks sampled from tickets, defects, and support conversations; metrics are completion rate, human intervention rate, and rework rate.
• Cost layer: tokens or GPU-hours per successful task, P95 latency, and cost amplified by failed retries.
• Risk layer: overreach, privacy leakage, harmful content, reproduction of copyrighted material, and non-reproducible random success.

For coding scenarios, the task layer should fix the repository snapshot and test commands so the model does not “remember” external documentation that changes. For knowledge base scenarios, require traceable cited snippets and penalize confident answers without evidence. For multimodal scenarios, include blurry, occluded, low-resolution, and cross-page samples; otherwise post-launch metrics will be systematically optimistic.

Implementation order for enterprise adoption

Do not start by replacing all R&D or support workflows at once. A safer order is:

1. Choose a scenario with clear boundaries and automatically judgeable success, such as internal code style fixes, document field extraction, or knowledge base Q&A.
2. Build an evaluation set containing only desensitized data and a baseline, either rules or a smaller model.
3. Validate whether the task works with a general model service first, then decide whether to fine-tune or deploy privately.
4. Make retrieval, permissions, audit logs, and human escalation system capabilities rather than writing them into an extremely long prompt.
5. Use shadow traffic or small traffic to compare completion rate and cost, and expand only after thresholds are met.

If you use object storage for corpora and evaluation sets, container platforms for training and sandboxes, message queues to isolate online requests from offline evaluation, and logs and monitoring alerts to track failure types, these are generic categories that can be selected according to existing infrastructure. Cloud platforms such as Baidu AI Cloud typically cover foundational capabilities including compute, storage, networking, and security compliance, and can serve as hosting environments for training jobs, model services, and data isolation. Specific quotas, interfaces, and billing should follow the official documentation at the time, and unverified performance numbers should not be preset in the plan.

When data cannot leave the domain, prioritize private networks, key management, desensitization of training and inference logs, and access control for weights and checkpoints. Fine-tuning data and user conversations should be stored separately and retained for separate periods. The agent’s command allowlist should be codified, not enforced by a prompt saying “please do not run dangerous commands.”

Capabilities to watch after 2024, not a vendor list

It is more useful to turn the timeline into an R&D checklist than to memorize release dates:

• Interaction: multi-turn goal clarification, interruptibility, and citation of evidence.
• Weight strategy: licenses, update cadence, and rollback for hosted services and open weights.
• Modality: joint modeling during training versus bolt-on inference, and the corresponding failure modes.
• Language and domain: quality of Chinese and industry corpora, not scale on a parameter table.
• Cost architecture: whether routing, caching, quantization, and sparse activation hold up on real traffic.
• Agents: sandboxes, permissions, trajectory auditing, and evaluation that recognizes only task completion rate.
• Organization: who owns evaluation sets, who approves tool permissions, and who is accountable for incorrect output.

From 2022 to 2026, the industry moved from “generate a plausible paragraph” to “deliver a verifiable result under constraints.” Dense Chinese chat models solved usability; native multimodality and tiered deployment addressed input forms and cost tiers; open weights lowered the customization barrier; coding agents changed the evaluation standard from fluency to completion rate. The next professional task is to split these capabilities into four lines—data, evaluation, permissions, and cost—and prove value with replayable tasks rather than replacing acceptance with demos.