Why the Term MaaS Has Become as Overused as “Mid‑Platform”

In the rush of digital transformation, the author warns that the term MaaS (Model‑as‑a‑Service) has suffered from “concept inflation”, similar to the overused “mid‑platform” label. When technical terms become marketing jargon, the real obstacle to digital adoption is not technology but the organizational friction and strategic inertia hidden behind vague concepts.

Four Distinct MaaS Business Models

Token‑flow model (e.g., Volcano Engine) : Provides dozens of large‑model APIs (including Doubao, DeepSeek) via a unified inference platform, competing on price to attract enterprise customers. This aligns closely with the original MaaS definition – selling model inference itself.

Full‑stack platform model (e.g., Alibaba Cloud Baolian, Baidu Qianfan) : Covers end‑to‑end capabilities from model invocation, fine‑tuning, data labeling to Agent development. Analysts label this as “MaaS 2.0”, which already exceeds the literal meaning of “model as a service”.

Industry‑deep model (e.g., Tencent Cloud, Huawei Cloud) : MaaS is positioned as a component within vertical solutions – gaming cloud for Tencent, government cloud for Huawei – embedding large‑model capabilities into industry‑specific delivery.

Independent inference‑service model (e.g., Silicon Flow) : Operates as a “model supermarket”, integrating hundreds of open‑source models for inference without developing its own models.

Why the Same Name Masks Different Products

The four models sell fundamentally different value: compute efficiency, tool‑chain lock‑in, industry know‑how, and model flexibility. Their cost structures, procurement logic, and the internal departments they engage differ, yet they share the same label, leading to inconsistent market metrics such as “largest model‑call share” or “top AI cloud revenue”.

Seller’s Incentive: Bundling Sells Better

A cloud vendor who owns model APIs, fine‑tuning platforms, Agent frameworks, and delivery teams can increase switching costs by packaging everything under a single “MaaS” umbrella. Disaggregated sales would let customers price‑compare each module and replace them individually, whereas a bundled offering makes comparison harder and replacement more costly.

Buyer’s Incentive: A Vague Term Helps Bypass Organizational Gaps

Enterprises often lack clear answers to questions such as who will build the solution, whether IT or the business owns it, budget sources, and accountability for outcomes. Stating a project will use “MaaS” lets stakeholders move forward without resolving these issues, buying time while the organization remains ambiguous.

Risks of the Vagueness

Problems hidden by the vague term do not disappear; they surface later as data‑labeling gaps, ineffective prompts, unclear business scenarios, or model outputs that no one trusts for decision‑making. The real blockers are rarely the model calls themselves.

Practical Guidance

Ask three concrete questions when hearing “MaaS”: (a) Which layer are we buying – API calls, platform tool‑chain, or industry delivery? (b) What is the pricing model – per token, per call, packaged, or seat‑based? (c) What steps remain from “usable” to “good enough” – data, prompts, evaluation, integration?

Translate “MaaS” in internal documents into precise work definitions, e.g., “We need external model‑API capacity for X calls per month and will internally build Prompt management and evaluation for three pilot scenarios.” This forces clarity on what is purchased versus what must be built.

When a boss says “Let’s also adopt MaaS”, respond by reframing the request into a concrete requirement list that distinguishes model‑call capability, customization, and AI‑application delivery, and tie each to budget, team, and timeline.

Ultimately, the term MaaS will continue to be inflated as long as vendors need a broad label and buyers need a shortcut. By demanding precise definitions and exposing hidden questions early, organizations can avoid the hidden costs that emerge after project launch.

—END—