Alibaba Cloud provides a globally competitive AI infrastructure, but enterprise AI adoption almost always follows the exact same brutal trajectory across the industry. A smart engineering team builds a killer prototype using a few API keys. The board loves it. They deploy it to production. Everyone applauds. Then month-end hits, and they have burned through their entire annual infrastructure budget in roughly three weeks.
We need to talk about reality. Training Large Language Models and running high-throughput inference endpoints requires massive, sustained computational resources. It is not like hosting a standard frontend application or a simple backend database. If you get the architecture wrong, the cloud provider will happily drain your bank account while your application scales inefficiently.
Between their Machine Learning Platform for AI, generative AI model APIs via DashScope, and their high-performance Elastic Compute Service GPU instances, you have absolutely everything you need to build enterprise-grade AI. But there is a major catch. Without platform-specific expertise, you are almost certainly overpaying by at least 40%. It happens every single day in the industry, from early-stage startups to massive publicly traded companies.
This guide is not theoretical marketing material. It is based on hard-won, expensive lessons from deploying, scaling, and auditing AI systems at scale. We are going to break down exactly how Alibaba Cloud AI pricing works, share the ruthless cost optimization strategies we force enterprise clients to implement, and show you how to reduce your AI infrastructure bill by up to 60%. And we are going to do it without degrading your end-user experience or compromising system reliability.
Is your cloud bill already spiraling out of control? Stop guessing and start saving. Specializing in rescuing over-provisioned cloud environments is exactly what we do. Book a Cloud AI Cost Audit and identify your biggest money leaks right on the call. No sales fluff. Just pure architecture review.
1. Demystifying Alibaba Cloud AI Core Services and Pricing Models
To architect effectively, you have to understand exactly where the cloud provider makes its money. Stop treating cloud AI like traditional web hosting. The billing mechanics are entirely different, and if you treat a GPU node like an ordinary web server, you are going to fail spectacularly when traffic spikes.
1.1 Model-as-a-Service (MaaS): DashScope API Gateway
Let us start with DashScope, the managed API gateway for foundation models, primarily featuring the Tongyi Qianwen family, widely known as Qwen. It uses a strict Pay-As-You-Go token-based model. You pay for what you send to the model in the form of input tokens, and what the model generates in the form of output tokens.
My golden rule for production deployments? Start here. Do not build custom models or host open-source models yourself unless you possess a proprietary dataset that gives you a massive, unassailable business advantage. Renting the API is almost always cheaper for the first year of a product’s lifecycle while you validate product-market fit.
1.1.1 API Performance and Cost Benchmarks
Understanding the tiers of the Qwen family is critical for routing workloads efficiently. Not every prompt requires a massive reasoning engine.
- Qwen-Turbo: First Token Latency sits around 40 to 60 milliseconds. Sustained Throughput is 60 to 90 tokens per second. Example Cost is roughly $0.15 per 1 million tokens. Use this for 80% of your tasks. Summarization, data extraction, and basic intent routing do not need heavy compute. It is cheap, it is incredibly fast, and developers severely underestimate its capabilities.
- Qwen-Plus: First Token Latency is around 150 to 250 milliseconds. Sustained Throughput is 30 to 50 tokens per second. Example Cost is roughly $0.60 per 1 million tokens. This is the absolute sweet spot for Retrieval-Augmented Generation pipelines and conversational agents. It offers great reasoning capabilities without breaking the bank.
- Qwen-Max: First Token Latency is 350 to 500 milliseconds. Sustained Throughput drops to 15 to 25 tokens per second. Example Cost jumps to ~$2.80 per 1 million tokens. This model rivals the top-tier global models, but watch your wallet. It is expensive and significantly slower. Only route to the Max tier for multi-step, complex reasoning that Turbo and Plus fail at.
1.1.2 The Regional Latency Trap
I routinely see global teams complain about the “sluggish” DashScope API. They look at the 400 millisecond response time in their network tab and immediately blame the Large Language Model for being poorly optimized.
The model is not slow. Physics is slow.
If you route API calls from a server located on the US East Coast to a primary DashScope endpoint located in Hangzhou, you are eating 200 to 260 milliseconds of dead network time before the model even wakes up to process the first token. You have submarine cables, complex routing protocols, and often deep packet inspection adding massive latency to the initial TLS handshake.
The fix: Always deploy your core application servers in the exact same region as your DashScope API endpoint. If your users are global, put an edge cache or a lightweight regional server near them, but keep the heavy backend orchestration logic co-located with the AI API.
We Build Optimized Cross-Border Infrastructure
Routing AI traffic across complex cross-border networks requires more than just deploying an API key in an environment variable. It requires deep, painful knowledge of networking protocols and compliance routing.
We design, deploy, and manage high-speed, compliant architectures. If your global users are experiencing high latency when querying Hangzhou or Beijing AI endpoints, stop letting network physics kill your user experience. We build the bridges that bypass the bottleneck.
👉 Speak to our Network Architecture Team Today
1.2 Platform-as-a-Service (PaaS): Machine Learning Platform for AI (PAI)
When managed API models are not enough—perhaps due to compliance, data privacy mandates, or custom fine-tuning needs—you move to PAI. This is essentially the managed infrastructure for the entire machine learning lifecycle. Under the hood, it eliminates the absolute operational nightmare of managing raw Kubernetes clusters with hardware device plugins, CUDA toolkits, and constant NVIDIA driver mismatches.
1.2.1 Interactive Development Realities with PAI-DSW
The Data Science Workshop module is billed hourly. It is a managed interactive development environment running JupyterLab. It is absolutely fantastic for prototyping, exploratory data analysis, and testing small scripts on a single GPU.
The production reality is that it is terrible if your data scientists forget to turn them off. I have seen data science teams leave heavily provisioned instances running over a four-day holiday weekend because they did not want to lose their shell history or local state. You must implement aggressive auto-shutdown policies for these environments, or they will become your largest source of wasted capital.
1.2.2 Distributed Training Workloads with PAI-DLC
The Deep Learning Containers module is billed per-second. This is the only sane way to run multi-node, distributed batch training for custom foundation models. You submit a job, the system spins up the necessary nodes across the network, runs the training script, and shuts them down the exact millisecond the job finishes.
1.2.3 Model Inference with PAI-EAS
The Elastic Algorithm Service is billed hourly or via reserved instances. This is for actual model inference. You take your trained model, and this service wraps it in a production-ready API endpoint. It is highly reliable and handles load balancing automatically, but you must remember that you pay for idle time. If no one is calling your API at 3:00 AM, you are still paying for the hardware unless you actively and aggressively configure auto-scaling.
1.3 Infrastructure-as-a-Service (IaaS): GPU Instances
For engineering teams that demand absolute control—usually because they are using Alibaba Cloud Kubernetes and deploying massive custom orchestrations with Helm—you have to bypass the managed services and buy raw virtual machines.
1.3.1 A Consultant’s Warning on Virtualization
If you are running massive distributed training jobs, meaning dozens of hardware accelerators talking to each other across a cluster, never use standard virtual machines like the standard gn-series.
When deep learning models train, they have to constantly share weights and gradients across the network using the NVIDIA Collective Communications Library. A standard hypervisor sitting between the virtual machine and the physical network card introduces micro-seconds of latency. In distributed training, those micro-seconds compound into days of wasted compute time as GPUs sit idle waiting for network packets to arrive.
Use the Elastic Bare Metal instances (ebmgn-series). Bare metal bypasses the virtualization layer entirely, yielding a tangible 5% to 8% performance bump in cross-node communication. At scale, that saves days of compute time and thousands of dollars. Pay the premium for bare metal if you are doing heavy training. Period.
2. Deep Dive: Compute vs. API-based AI Pricing Comparison
This is the most common debate moderated between technical leaders inside an organization. The lead engineer wants to host an open-source model like Llama 3 or Qwen-OpenSource on PAI-EAS because it gives them total control over the architecture and ensures data never touches a shared service. The finance director wants to use managed DashScope APIs because it requires zero upfront capital and zero maintenance overhead.
Who is right? You have to actually do the math, and you have to do it correctly.
2.1 The Break-Even Analysis (And Why It Lies to You)
You must calculate the exact threshold where renting dedicated hardware becomes cheaper than paying per API token.
2.1.1 The Theoretical Math
Here is the standard formula every junior architect uses to justify buying servers:
Monthly Break-Even Tokens = (Monthly Server Cost / Cost per 1M Tokens) * 1,000,000
Let us say a dedicated instance with a 24GB GPU running 24/7 costs roughly $828 per month. You compare this to the managed Qwen-Plus API, which costs about $0.60 per 1 million tokens.
$828 / $0.60 * 1,000,000 = 1.38 Billion Tokens
The engineer looks at this calculation and tells the executive team that if the application processes more than 1.38 billion tokens a month, the company immediately saves money by hosting it internally.
2.1.2 The Production Reality and the DevOps Tax
This formula is a complete lie. It assumes your hardware runs at 100% utilization, 24 hours a day, 7 days a week, pushing tokens at maximum theoretical throughput without ever crashing or needing reboots.
It will not.
User traffic is highly spiky. You will have massive traffic peaks at 10:00 AM when employees log in, and dead silence at 2:00 AM. A self-hosted node will likely sit idle 40% to 60% of the time, doing absolutely nothing while still costing you money every single hour. Furthermore, you cannot run production on a single node. You have to run at least two instances behind a load balancer for high availability, which instantly doubles your base compute cost to over $1,600 a month.
Then, you must factor in the DevOps tax. You need a highly paid human being to monitor the cluster, patch security vulnerabilities, update hardware drivers, and debug Out-Of-Memory errors when user payloads get too large. A cloud engineer costs your company hundreds of dollars a day in salary and benefits. That engineer’s time vastly outweighs the API cost savings.
In reality, you likely need to hit 2.5 to 3 Billion tokens per month to actually break even on self-hosting once you factor in idle time, instance scaling buffers, and engineering maintenance overhead. Stick to the managed DashScope APIs until your token volume absolutely forces your hand.
3. When NOT to Use Managed Cloud Native AI Services
Managed AI platforms are fantastic. Architecting around them is highly efficient and saves months of development time. But you have to know when it is the wrong tool for the job. Do not force a square peg into a round hole just because it is easy.
3.1 Strict Multi-Cloud Mandates
If your enterprise architecture review board strictly requires workloads to be seamlessly portable to other major global cloud providers within 30 days, do not use proprietary abstractions like PAI-EAS.
3.1.1 The Kubernetes Escape Hatch and Operational Overhead
Instead, you have to provision generic Kubernetes clusters. You will deploy raw compute nodes, install your own ingress controllers, manage your own Prometheus scraping for metrics, and deploy models using standard Docker containers and open-source Helm charts.
You are actively choosing operational hell over managed convenience, but that is the trade-off you make for true multi-cloud portability. Managing a GPU-enabled Kubernetes cluster is not a part-time job. Expect to dedicate at least 20 to 30 engineering hours per week purely to cluster maintenance, upgrading device plugins, and managing node pools. If you do not have a dedicated DevOps team, this route will crush your product velocity.
YAML
# A standard Kubernetes YAML snippet to deploy a portable pod.
# Notice how manual this is compared to clicking a button in a managed service.
apiVersion: apps/v1
kind: Deployment
metadata:
name: foundation-inference
spec:
replicas: 2
template:
spec:
tolerations:
- key: "hardware/accelerator"
operator: "Exists"
effect: "NoSchedule"
containers:
- name: model-server
image: internal-registry.domain.com/ai-prod/model-inference:v1
resources:
limits:
nvidia.com/gpu: 1
3.2 Ultra-Low Latency Edge Requirements
Sometimes the cloud is simply too far away from the physical event.
3.2.1 Factory Floor and Autonomous Systems
If you are building an AI system for factory floor quality control, robotic automation, or autonomous vehicle inference, you typically require response times strictly under 10 milliseconds. You cannot tolerate a round-trip to a centralized cloud region, no matter how fast the fiber optic cable is. In these cases, you must deploy local hardware or use edge computing nodes. Do not route these critical, life-safety workloads to centralized API endpoints.
4. Proven Strategies for Cost Optimization
If you are committed to the cloud and running workloads at scale, here is how we stop the bleeding. These are the exact, unapologetic strategies implemented for enterprise clients.
4.1 The Scale-to-Zero Dilemma in Inference
Paying for idle memory is the number one cause of cloud waste. Inference services like PAI-EAS support auto-scaling based on CPU utilization, GPU memory limits, or Queries Per Second. Crucially, they can theoretically scale all the way down to zero instances.
4.1.1 Managing the Cold Start Penalty
Scale-to-zero is a CFO’s dream and a Product Manager’s nightmare. A cold start is the time it takes for the cloud provider to provision the instance, pull your massive 15GB Docker image over the network, load the multi-gigabyte model weights into memory, and expose the endpoint to the load balancer. This process takes anywhere from 45 to 80 seconds.
If a human user opens your web application, types a question into the chatbot, and has to stare at a loading spinner for a full minute while a node boots up, they will abandon the application and never come back.
Only use scale-to-zero for asynchronous, background processing tasks. For example, if you run a batch job every night at midnight to summarize thousands of PDF reports, scale-to-zero is absolutely perfect. For user-facing live APIs, you must maintain a minimum of 1 running replica at all times to ensure immediate response times.
4.2 Spot Instances for Distributed Training
For massive batch training jobs, you are literally burning money if you use standard On-Demand pricing. Always use Preemptible Instances, commonly known as Spot pricing.
4.2.1 The Checkpointing Imperative
Cloud providers sell their excess compute capacity at a massive discount. Top-tier instances drop from $32.00 per hour to $6.50 per hour using spot pricing. This allows you to train massive models for pennies on the dollar.
The catch is that the cloud provider can and will reclaim these instances at any time if a full-paying customer needs the capacity. You get a very brief warning before the server is killed.
Therefore, you must ensure your training code is heavily fault-tolerant. You need to write model checkpoints to Object Storage frequently, such as every 15 minutes or at the end of every epoch. If the spot instance is killed, the training orchestrator will automatically request a new one, and your training script must be smart enough to pull the last checkpoint from storage and resume seamlessly. If you do not implement checkpointing, you will lose days of training progress in a blink when a node is reclaimed.
4.3 Model Quantization via PAI-Blade
Cost optimization is not just about negotiating better server rates; it is about shrinking the payload. Before deploying an open-source model to PAI-EAS, you must compress it.
4.3.1 Halving Memory Requirements
By quantizing your model from FP16 (16-bit floating point) to INT8 (8-bit integer) using optimization toolkits like PAI-Blade, you effectively reduce the model’s memory footprint by 50%.
The financial benefit here is massive. A model that originally required a 24GB VRAM instance can now easily fit onto a 16GB VRAM instance without a significant loss in accuracy. Downgrading the instance size based on quantization can save you up to 40% on your hourly compute bill immediately.
4.4 Storage Tiering with Infrastructure as Code
AI engineering teams hoard data. They keep every raw image, every uncleaned spreadsheet, every log file, and every experimental model weight. Massive datasets sitting in standard storage burn cash unnecessarily.
4.4.1 Automating the Data Lifecycle
You have to implement automated lifecycle policies at the infrastructure level. If a training dataset has not been read or written to in 30 days, move it to Archive storage automatically. It is roughly 80% cheaper and requires zero manual intervention.
Here is the infrastructure code. Make this mandatory in your infrastructure repositories:
Terraform
# Automatically archive files in the raw data folder after 30 days
resource "cloud_storage_bucket_lifecycle_rule" "archive_rule" {
bucket = "prod-ai-training-datasets"
rule {
id = "archive-stale-datasets"
prefix = "raw_data/"
status = "Enabled"
transitions {
days = 30
storage_class = "Archive"
}
}
}
Need Help Implementing This Architecture?
Copy-pasting code snippets from an article is easy. Building resilient, secure, and automated deployment pipelines for AI infrastructure that will not fall over at 2 AM is incredibly hard.
Your engineers should be fine-tuning models, optimizing retrieval pipelines, and shipping actual product features. They should not be spending their valuable cycles fighting with virtual private cloud peering, configuring NAT gateways, debugging identity roles, or figuring out why the container toolkit is failing to mount to the hardware.
Let us manage the infrastructure, so your team can focus on building the AI.
👉 View Our Infrastructure-as-Code Implementation Plans
5. Real-World Architecture: Cost-Optimized Generative AI Retrieval
Let us look at a concrete, real-world example. This exact pattern is deployed for about 80% of enterprise clients who are building internal knowledge bases, typically handling around 10,000 queries a day.
5.1 The Architecture Data Flow
You have to break down the pipeline into asynchronous ingestion steps and synchronous inference steps to control costs.
5.1.1 Ingestion and Serverless Processing
Employees upload enterprise documents to a storage bucket. This automatically triggers an event. The event invokes a Serverless Function instance. The serverless instance spins up instantly, chunks the document text, calls the DashScope Embedding API to turn the text into vectors, and then shuts down immediately. You are billed purely by the millisecond of compute time. The idle cost of this process is absolute zero.
5.1.2 Vector Storage and Inference
The generated embeddings land in an enterprise-grade cloud data warehouse with the Vector Engine enabled. Strictly use serverless computing tiers here to separate storage costs from compute costs. You only pay for the gigabytes of data stored, and the seconds it takes to query them.
When a user asks a question in the frontend, the application embeds the query, performs a rapid similarity search in the vector database, retrieves the relevant context, and passes it all to the managed Qwen API for the final generated answer.
5.2 The Financial Reality
The financial difference between legacy server thinking and modern serverless thinking is staggering.
5.2.1 Self-Hosted vs. Serverless Cost Breakdown
A naive, inexperienced team will try to self-host all of this. They will spin up two dedicated compute nodes for the embedding model and the text generation model. They will run them 24/7 for high availability. That legacy architecture costs over $1,600 a month, even on weekends when absolutely zero employees are using the internal chatbot.
By using Serverless Functions, DashScope APIs, and Serverless Vector Databases, the baseline idle cost of the entire system drops to effectively zero. You pay for the cheap storage, and you pay fractions of a penny per API call. The total optimized architecture costs under $70 a month.
Want this exact architecture deployed in your cloud account by next week? Do not spend three months paying your engineering team to reinvent the wheel. Our team can roll out this proven blueprint securely within your Virtual Private Cloud in a matter of days. Let’s scope your project.
6. Performance & Scaling: Production Best Practices
Cost optimization does not mean building a slow system. You just have to be incredibly smart about where you allocate your resources and how you handle concurrent traffic.
6.1 Solve Network Bottlenecks with Advanced Networking
When running massive multi-node training jobs, standard networking is your enemy.
6.1.1 Bypassing the Kernel Network Stack
The standard latency between nodes is around 50 microseconds. That sounds fast, but for hardware passing gigabytes of tensor data back and forth thousands of times a second, it is agonizingly slow.
You must provision instances with Elastic Remote Direct Memory Access capabilities. This allows the network card of one server to write data directly into the memory of another server, completely bypassing the operating system’s kernel network stack. It drops inter-node latency to under 15 microseconds. Your training jobs will finish 20% to 30% faster, which directly reduces your hourly compute bill.
6.2 The Warm Pool Strategy
We established earlier that scale-to-zero cold starts take 60 seconds.
6.2.1 Masking GPU Boot Times with CPU Baselines
If your Service Level Agreements demand a 2-second response time, but you still want to save money, use a warm pool.
You keep exactly one baseline replica running on the absolute cheapest CPU-only instance available. Standard CPU inference is slow, maybe taking 3 to 4 seconds to generate a response, but it does not require a 60-second boot time.
When the first user of the day hits your API, the cheap CPU instance handles the request. It is a little slow, but acceptable. Simultaneously, that initial traffic spike triggers your auto-scaler to spin up the heavy hardware instances in the background. By the time the second or third user makes a request, the high-performance nodes are online and ready to take over. You save money by not running massive nodes 24/7, but you avoid the catastrophic 60-second timeout.
6.3 Dynamic Batching for High Throughput
If you are running self-hosted models, you cannot process requests one by one if you want to be profitable.
6.3.1 Maximizing GPU Utilization
In PAI-EAS, configure dynamic batching. This tells the system to wait 10 milliseconds to group 8 concurrent user requests together before sending them to the GPU. A 10 millisecond delay is completely invisible to a human user, but it allows the hardware to process multiple requests concurrently. This maximizes hardware utilization and significantly reduces the cost-per-inference.
7. Common Mistakes and System Failures (War Stories)
You want to know what a bad day in the cloud looks like? Avoid these catastrophic blunders that are routinely seen in audits.
7.1 The NAT Gateway Egress Hemorrhage
An audit once revealed a client who racked up a $12,000 Gateway bill over a single three-day holiday weekend.
7.1.1 The Fix for Outbound Bandwidth Fees
They had configured their auto-scaling group to pull a 40GB open-source foundation model directly from a public model repository over the internet every single time a new node spun up. They had an unexpected traffic spike, nodes scaled up and down dozens of times, and every single time, they downloaded 40GB over the Gateway. Cloud providers charge heavily for outbound internet traffic.
Never download models from the public internet in an auto-scaling environment. Bake your models directly into custom Docker images, store those images in your private Container Registry, and pull them using the internal virtual network endpoint. Internal traffic within the same region is free.
7.2 Out of Memory Cascades
Aggressively downsizing your instances to save a few dollars can destroy your system under load.
7.2.1 The Danger of Concurrency
If you provision a GPU with barely enough memory to hold the model weights, it will work fine during testing. But when 10 users hit the API concurrently, the context window memory requirements spike. The GPU runs out of memory, throws an Out-Of-Memory error, and crashes the node. The load balancer routes all traffic to the surviving node, which immediately crashes as well. Always benchmark peak memory during load testing before reducing instance sizes.
7.3 API Rate Limit Retry Loops
When you switch to managed APIs, you are bound by concurrency limits, such as 50 Queries Per Second.
7.3.1 Implementing Exponential Backoff
If your application gets a traffic spike and hits 60 Queries Per Second, the API gateway will return a Too Many Requests error.
If you have poorly written retry logic in your application layer—say, an aggressive loop with no exponential backoff—your servers will frantically hammer the API thousands of times a second trying to get through. This instantly burns out the CPU of your application servers, causing your entire application cluster to crash, even though the AI API was perfectly fine. Always implement exponential backoff with jitter on API calls.
7.4 Infinite Log Retention
Generative AI services create massive telemetry streams.
7.4.1 Capping Telemetry Storage Costs
You are logging every prompt, every generated response, and every system metric. Leaving your Log Service on its default infinite retention setting will silently bloat your cloud bill over time. Cap your retention at 7 or 14 days. You do not need to keep a user’s chatbot prompt from three years ago sitting in hot, expensive storage.
8. Observability and Financial Operations for AI Workloads
One of the largest gaps seen in enterprise deployments is a complete lack of Financial Operations culture applied to AI. Traditional engineering teams are used to monitoring CPU and RAM. In the AI era, you must monitor token burn rate and hardware idle time just as closely as you monitor latency.
8.1 Track Costs in Continuous Integration Pipelines
Do not wait until the end of the month to realize a configuration change just doubled your infrastructure footprint.
8.1.1 Pull Request Cost Analysis
Mandate tools that analyze infrastructure code during the pull request phase to estimate the exact cost impact of infrastructure changes before they are ever merged into the main branch. If an engineer changes a parameter that spins up three additional nodes, the pipeline should flag the financial impact before approval.
8.2 The Tagging Taxonomy
If you run a multi-tenant application, you absolutely must implement strict resource tagging across every single piece of infrastructure.
8.2.1 Multi-Tenant Cost Attribution
A proper taxonomy includes tagging by Environment (Production vs Staging), Cost Center, and Feature. When the bill comes in at $50,000, you need to know exactly which product feature, which client, and which development environment generated that cost. If your cloud resources are not tagged, you are flying blind and cannot accurately calculate your profit margins per customer.
Conclusion: Stop Bleeding Cash on AI Infrastructure
Architecting AI in the cloud gives you access to world-class, globally scaled infrastructure. It can compete toe-to-toe with any data center on earth. But a lazy set-and-forget mentality will result in rapid, catastrophic financial burn.
The Architecture Imperative
The best engineering teams treat infrastructure cost as a primary system metric. It is tracked, monitored, visualized, and debated just as ruthlessly as API latency, system throughput, and model accuracy.
Default to managed APIs when starting out. Ruthlessly implement scale-to-zero architectures where the business logic allows it. Exploit spot pricing for your offline training workloads. Plug your data transfer leaks, quantize your models, and isolate your networking from the public internet.
If your cloud AI spend is scaling faster than your revenue, you do not need a bigger budget from your investors. You need a better architecture.
Ready to stop overpaying?
Restructuring cloud environments to maximize throughput while permanently slashing monthly bills is essential for survival. We guarantee our cost-optimization audits will find savings that more than cover our fee, or you do not pay a dime.
🚀 Book Your Deep-Dive Infrastructure Audit Today and let us turn your cloud from a bloated cost center into a lean competitive advantage.
Read more: 👉 AI for E-commerce Using Alibaba Cloud
Read more: 👉 Hidden Alibaba Cloud Features Developers Should Know