770B LLM Official Release Review: Parameters, Pricing, and Multimodal Capabilities

1. Background: A Release Claiming a Spot “Among the Strongest Open-Source Models”

A cloud vendor recently released the official version of its latest-generation large language model, and the official announcement described it as having “joined the ranks of the strongest open-source models for the first time.” The claim quickly sparked discussion in developer communities—and the reason is not complicated: when third-party benchmark results surfaced around the same time, the picture was far less tidy. On a composite intelligence index, the model scored about 11 points below a competitor released in the same period, and its hallucination rate was flagged as “high.”

That makes the question concrete: has the model’s capability genuinely stepped up a level, or has the marketing narrative run ahead of the substance? This article takes no sides. It simply breaks things down from an engineering perspective: how to read the parameter numbers, how to work out real costs, what the multimodal capabilities can actually do, and who the model is for.

2. Architecture and Parameters: What 770B Total Parameters Mean

2.1 Get the Parameter Accounting Right First

Start with the size. The model’s headline 770B figure is its total parameter count. It uses a Mixture-of-Experts (MoE) architecture that activates roughly 49B parameters per inference. This distinction is critical: under MoE, total parameters determine the model’s capacity ceiling and knowledge coverage, while activated parameters are what more directly drive the compute cost and latency of each inference call.

For a same-family comparison, the previous generation was under 300B; this generation is about 2.6× larger, making it the vendor’s biggest model to date. From an engineering perspective, a leap of this scale usually implies two things: significantly more data and compute invested in training, and a need for more refined expert routing and GPU memory scheduling on the inference side—otherwise costs spiral out of control.

2.2 The Supporting Specifications

Dimension	Specification	Engineering implication
Context length	1M tokens (API)	Long documents and large code repositories fit in a single input
Vision understanding	Introduced for the first time	Reads images and analyzes charts
Computer use	Supported for the first time	Executes cross-application tasks via command line and GUI
Architecture	MoE	770B total parameters, ~49B activated

The two first-time capabilities—vision understanding and computer use—are the biggest additions over the earlier preview version. A useful metaphor: the preview was a straight-A student who could only read text; the official release has “grown eyes and hands.” It can look at images and operate interfaces. For workflows involving screenshots, reports, and UI mockups, this is a qualitative shift from “unusable” to “usable.”

3. Pricing and Access: How to Compare Fairly

3.1 API Pricing

API pricing is unchanged from the preview version:

• Input: ¥6 (about US$0.86) per million tokens
• Output: ¥18 (about US$2.57) per million tokens
• Cache hits: ¥0.3 (about US$0.04) per million tokens

(US dollar figures are approximate conversions at 7 CNY per USD.) All three tiers share one billing basis. On the numbers alone, this pricing sits on the cheaper end for flagship-tier models.

3.2 Convert Currency and Units Before Comparing

The most common trap in model selection is comparing quotes in different currencies and units directly. Example: if a competitor’s API output is priced at US$10 per million tokens, that converts to roughly ¥70 at 7 CNY per USD—about four times this model’s output price.

Here is a general-purpose conversion template you can reuse:

def cost_per_million(price, unit="CNY", fx_rate=7.0):
    """
    price: quoted price per million tokens
    unit:  original currency, CNY or USD
    fx_rate: USD-to-CNY exchange rate
    Returns the price converted to CNY.
    """
    if unit == "USD":
        return price * fx_rate
    return price
# Examples
print(cost_per_million(10, "USD"))  # ~70.0
print(cost_per_million(18, "CNY"))  # 18

One caveat: real-world cost also depends on cache hit rates, input/output ratios, and any extra token consumption from chain-of-thought reasoning. A low unit price does not equal a low total cost—when a model produces verbose reasoning traces, output tokens can balloon quickly.

3.3 How Everyday Users Can Try It

For most users, the simplest path is a mainstream AI coding assistant or office productivity app that lists the model in its model selector. Free trial credits were typically offered during the launch window; check the official documentation for current access options and quotas. For the hands-on tests in this article, we ran the model with thinking intensity set to “high.”

4. Official Benchmarks vs. Third-Party Evaluations: Why They Disagree

This is the most interesting part of the release.

The official line emphasizes that the model has “joined the ranks of the strongest open-source models for the first time,” focusing on overall capability and its significance for the open-source ecosystem.

Third-party evaluations offer a finer-grained breakdown: roughly 11 points behind on the composite intelligence index, and a hallucination rate labeled “high.”

The two are not necessarily contradictory, for three reasons:

1. Different benchmark mixes. A composite intelligence index typically blends math, code, common sense, instruction following, and other subtests. Strength distribution across subtests varies a lot between models—a model strong in code but weaker in common-sense QA will see its composite score pulled down.
2. Hallucination rate depends on methodology. Hallucination rate is highly sensitive to how it is measured: fact-checking, self-consistency, or human annotation? “High” means different things under each method. For production scenarios that demand reliability, hallucination rate often matters more than the composite score.
3. Marketing framing vs. engineering framing. “Strongest open-source” usually points to a specific leaderboard or a specific dimension, while developers care about “how it performs on my tasks.”

The rational approach: treat benchmarks as a filter, and hands-on evaluation as the basis for decisions.

5. Hands-On Test 1: Code Generation for a 3D Interactive Scene

The first test is a typical 3D interactive mini-game scenario, chosen to examine the model’s handling of complex logic organization, state management, and render loops—and to compare it head-to-head with a same-period competitor.

Tasks like this are discriminating because they test several things at once:

• Scene graph and object hierarchy design
• Coupling between the frame loop and input events
• Correctness of physics or collision logic
• Whether the code structure is maintainable

In practice, with thinking intensity set to high, the model produced a reasonably complete implementation with clear module divisions. Edge cases—state transitions, resource cleanup—still required manual correction. Compared with the competitor, the style differences were clear: one model tends to produce longer but more complete implementations, while the other produces terser skeletons that need filling in.

The takeaway for developers: when evaluating models on tasks like this, don’t just ask “does it run”—ask “how much work is it to modify.” Maintainability is the long-term cost.

6. Hands-On Test 2: Sketch-to-Webpage, Testing Vision Understanding

The second test converts a hand-drawn sketch into a web page, focusing on vision understanding—a capability the official version introduces for the first time.

The pipeline is roughly:

1. Feed in a hand-drawn wireframe.
2. The model recognizes the layout structure (navigation, cards, buttons, forms).
3. The model outputs runnable HTML/CSS.

<!-- Illustrative structure, not actual test output -->
<div class="page">
  <header class="nav">...</header>
  <main class="grid">
    <section class="card">...</section>
    <section class="card">...</section>
  </main>
</div>

Typical behavior observed in testing:

• Layout recognition: judgments about regions, alignment, and hierarchy are basically usable; the model can distinguish primary from secondary areas.
• Detail fidelity: restoration of icon semantics and spacing proportions is mediocre and often needs manual tuning.
• Code quality: generated styles lean toward inline styles or simple class names; how production-ready the output is depends heavily on prompt constraints.

Conclusion: vision understanding has crossed the “usable” threshold. It fits rapid prototype validation and first-draft generation in design-to-code workflows, but it is not ready for direct production-grade frontend delivery.

7. Conclusion: Who Is This Model For?

Taking the parameters, pricing, the benchmark disagreements, and both hands-on tests together:

Good fits:

• Document analysis and codebase understanding that need very long context
• Vision-dependent prototyping, chart interpretation, and sketch-to-code
• Cost-sensitive batch inference workloads
• Experimental scenarios involving cross-application automation

Proceed with caution:

• Factual Q&A that is extremely sensitive to hallucination
• High-reliability systems shipped directly to production
• Tasks whose cost structure is dominated by output tokens and sensitive to output length

Selection advice:

1. Use public benchmarks for the initial screen, then run small-sample tests on your own task set.
2. Convert unit prices into “cost per thousand tasks,” not “price per million tokens.”
3. For multimodal capabilities, distinguish clearly between “demo-ready” and “production-ready.”
4. Track how thinking intensity affects both cost and quality, and configure it in tiers when needed.

In one sentence: this official release does complete a generational catch-up in parameter scale, context length, and multimodal capability. The gap between the official claims and the third-party evaluations stems more from differences in evaluation methodology than from inflated capability claims. For developers, it is a solid cost-performance option—but whether it is the “strongest” depends entirely on your tasks.