Enterprise LLM Selection Strategy: A High-Low Model Collaboration Practice

1. Introduction: Beyond Benchmark Scores

Over the past two years, domestic large language models (LLMs) have significantly closed the gap with leading international models on public benchmark leaderboards. However, for enterprise developers, the real question has never been “Who ranks higher on the leaderboard?” but rather “Which model is more reliable, cost-effective, and compliant in my project?”

The premise of this question is fundamentally changing. In government, state-owned enterprise, and data-sovereignty-sensitive projects, foreign LLMs and their associated development toolchains are explicitly excluded from the options. Compliance constraints have directly reshaped the selection logic: within the available options, how do we compose the optimal combination?

A clear answer is emerging: do not rely on a single model to do everything. Instead, let large-parameter models and small-parameter models each handle their specific duties, creating a high-low tiered collaboration.

2. Define Your Target Users and Scenarios First

The first step in model selection is not looking at benchmarks, but breaking down your own scenarios. Enterprise AI programming needs generally fall into three categories:

1. Compliance-Sensitive: In government and regulated enterprise projects, foreign models and toolchains are prohibited. Discussing “better user experience with foreign models” is pointless. The question becomes “How to select and combine domestic models?”
2. Quality-Sensitive: Tasks involving architecture design, concurrency control, and complex business modeling require extremely high intent understanding and reasoning depth from the model. The cost of a single rework far exceeds the token cost.
3. Cost-Sensitive: High-frequency batch tasks, such as adding comments in bulk, format conversion, and boilerplate code generation. The unit cost is amplified by the call volume, making cheap but sufficient small-parameter models the better choice.

These three types of needs often coexist within the same project—this is the practical ground for the “high-low collaboration.”

3. Similar Benchmarks, Vastly Different Experiences

Many developers have encountered this phenomenon: two models have similar scores on benchmarks, but their actual usage experience differs significantly. The reason is that benchmarks test “accuracy under explicit instructions,” while real-world engineering tests “inference capability under ambiguous intent.”

Small-parameter models do not “fail to understand” instructions; rather, their processing tends towards literal matching. Prompts must be extremely detailed, boundary conditions must be crystal clear, and there can be no ambiguous phrasing. Once an instruction has room for interpretation, the model will choose a path that seems “literally reasonable”—even if that path runs completely counter to your design intent.

The advantage of large-parameter models lies exactly here: they can infer your unspoken true intent based on the complete context. For example, when asked to “add a lock to archive operations,” a large model will trace back to the modeling relationship that “archives depend on data” in the context, inferring that the lock anchor should be placed on the data. This capability is not reflected in benchmark scores, but it directly determines the rework rate.

Of course, the inference cost of large-parameter models is higher. So the key question is not “which is better,” but “which type of task is worth paying for understanding.”

4. A Typical Case: The “Assumptive” Exclusive Lock

Let’s use a typical scenario to illustrate the weight of this difference. An enterprise system involves data and archive management, with a business rule: archives depend on data; if the data becomes invalid, the archive is also unavailable. To ensure operational safety, an exclusive lock must be added during writes.

The designer’s intent is to directly apply a row-level exclusive lock on the data primary key id, making all archive operations naturally mutually exclusive in transaction semantics. This has three benefits: first, it drastically simplifies code and lock management logic; second, it avoids deadlock risks caused by fragmented lock granularity; third, it prevents another user from concurrently deleting the entire data row while a background task is executing data operations.

The ideal implementation looks roughly like this:

BEGIN;
-- Anchor on the data primary key, apply an exclusive lock to the data row
SELECT * FROM t_data WHERE id = :data_id FOR UPDATE;
-- Archive operations are performed within the same transaction, naturally mutually exclusive
UPDATE t_archive SET status = 1 WHERE data_id = :data_id;
COMMIT;

However, because the prompt omitted the phrase “lock the data primary key id,” the small-parameter model might provide this implementation:

BEGIN;
-- Default choice: lock the archive's parent folder
SELECT * FROM t_archive_folder WHERE id = :folder_id FOR UPDATE;
UPDATE t_archive SET status = 1 WHERE folder_id = :folder_id;
COMMIT;

The problem is that this implementation can pass functional testing. Running in a single thread, the behavior is completely correct, and all test cases pass. But the lock semantics are wrong: concurrent deletion of the data row is not blocked, and the lock granularity is decoupled from the data’s lifecycle. This is the most dangerous type of defect—it doesn’t surface at the functional level, but will cause data consistency issues under concurrent stress or exception paths, multiplying troubleshooting costs.

Faced with the same ambiguous instruction, a large-parameter model behaves differently: it absorbs the modeling description “archives depend on data” from the context and infers that the lock anchor should be the data primary key, even if you didn’t explicitly state it. This is the specific cause of “same scores, different experiences.”

5. Wishful Programming vs. Engineering Contracts

Some might argue: since small models need detailed instructions, just write the instructions completely. This doesn’t contradict “wishful programming” (rapid prototyping where the model is given high-level intent and allowed creative freedom), but the two solve different problems.

The goal of wishful programming is to “get things done”—quick prototypes, scripts, one-off tools where “if it works, it works,” and the model’s free execution is actually efficient. In contrast, the goal of formal enterprise projects is to “do it right and make it maintainable”: the model must follow various explicit or implicit contracts—existing architectural conventions, naming standards, layering rules—and progress along the engineer’s line of thought.

Here is a counter-intuitive engineering judgment: sometimes, even if a more elegant and performant solution exists, engineers will choose a “dumber” approach to maintain consistency with existing code styles and ensure team readability, provided the performance trade-off is acceptable. Human engineers make these trade-offs daily. Large-parameter models have sufficient contextual absorption capacity to understand and respect these trade-offs; small-parameter models tend to act on “local optima,” making the code “smarter” but drifting further from project conventions.

6. The Other Side of Understanding: Grasping the Core

Intent understanding capability isn’t just reflected in writing code. A simple self-test: write a comment with a clear viewpoint and argument structure, and feed it to models of different parameter sizes, asking them to evaluate it.

A typical small-parameter model response will fail to grasp the core point of the comment. The answer will be safe and generic: “On one hand… on the other hand…”, offering a wishy-washy compromise, or even nitpicking on minor details while avoiding the core argument.

A large-parameter model will do things a small model cannot: extract the core argument of the text; judge whether the argument actually holds water; explain the principles behind why it is valid or invalid; and identify the boundary conditions where it applies.

Mapped to development scenarios, this difference translates to the quality of code reviews, requirement clarification, and solution discussions—the outputs of these phases rely directly on the ability to “grasp the core,” which is precisely the value zone of large-parameter models.

7. Implementation Strategy: The High-Low Collaboration Matrix

Returning to the initial question: under compliance constraints, the pragmatic approach is not betting on a single model, but utilizing a high-low collaboration. A directly actionable division of labor is as follows:

Delegate to large-parameter models (paying for understanding):

• Requirement clarification and solution design: translating vague business descriptions into technical architectures.
• Error-prone core logic: concurrency control, transaction boundaries, state machines.
• Cross-module refactoring decisions and code reviews.
• Troubleshooting and root cause analysis for complex issues.

Delegate to small-parameter models (saving costs on throughput):

• Templated CRUD, boilerplate code, and data object conversion.
• Bulk generation of unit tests.
• Generation of logs, comments, and documentation.
• Mechanical tasks like format conversion and batch renaming.

The cost calculation is straightforward: the per-call cost of a large model is multiples of a small model, but its rework rate on core logic is low. Small models are cheap and fast, making them ideal for high-frequency mechanical tasks. Routing by “task complexity” rather than a “one-size-fits-all” approach brings both overall cost and quality into a better range.

8. Layered Prompt Engineering

For the high-low collaboration to truly work, prompt strategies must also be layered.

Prompts for small-parameter models should be written as explicit contracts: what the object is, where the lock is applied, how fine the granularity is, what cannot be done, and what the counter-examples are—everything must be strictly defined. For example:

“Apply a row-level exclusive lock to the primary key id of the data table. Note: The lock target is the data primary key, not the archive folder id; the lock must be executed first after the transaction begins; archive updates must be completed within the same transaction; introducing other lock objects is prohibited.”

Prompts for large-parameter models can be written as goal-oriented: provide sufficient business context and design intent, letting the model derive the implementation itself. For example:

“Archives depend on data. I want to ensure that by locking the data row, all downstream archive operations are naturally mutually exclusive in transaction semantics, while also preventing the data from being concurrently deleted while a background task is executing. Please provide a locking strategy and explain the boundary cases.”

The former is like writing contract clauses; the latter is like assigning a task to a senior colleague. Using the wrong prompt for the wrong model—feeding contract-style prompts to a large model wastes its inference capability, while feeding goal-style prompts to a small model results in a repeat of the exclusive lock incident described earlier.

9. Platform Capabilities: Making the Collaboration Strategy Manageable

In a real enterprise environment, high-low collaboration requires platform-level support: unified model access and routing, role-based call permissions, comprehensive call auditing and logging, and data-residency deployment. Cloud platforms represented by Baidu AI Cloud have mature practices in these general capabilities. Enterprise clients can integrate multiple models into a unified management framework under compliance requirements and flexibly schedule them by task type, without having to build separate access and governance infrastructure for each model.

It must be emphasized that the toolchain is merely an amplifier; the model division of labor strategy itself is the input that determines success or failure.

10. Conclusion: “Glory” Comes from Engineering Maturity

Can domestic LLMs restore their glory? If “glory” means topping the leaderboards, the answer remains “in progress.” But if it means “reliably doing work in real enterprise engineering,” then the path is clear: large-parameter models handle understanding and decision-making, small-parameter models handle execution and throughput, and the platform layer provides the compliance and management foundation.

For developers, rather than arguing over which model is stronger, energy is better spent on two things: first, identifying the task intervals in your project that are “worth paying for understanding”; second, establishing different prompt contracts for models of different scales. By achieving these two points, compliance constraints transform from a shackle into a filter—helping you screen out the technical combinations truly suitable for enterprise deployment.