Summary
- WXYG can be tied to 五象云谷有限公司, a Nanning company formed in 2019 to develop data-centre and cloud services. Its listed parent reported in April 2026 that the original cloud-computing-centre project had reached its intended usable state, while the company's current website promotes a 149,000-square-metre first phase and a shift toward an AI "token factory."
- The public service surface has several layers: colocation, bandwidth and managed data-centre work; physical power and cooling; pooled intelligent compute; model access, scheduling, metering and billing; and a 2023 cooperation design that divided duties among Wuxiang Cloud Valley, Runjian and Alibaba Cloud. Assurance depends on identifying the responsible party at each layer rather than attaching every outcome to the WXYG name.
- APNIC records assign four active-status AS numbers, AS146748 through AS146751, to WXYG. Yet RIPEstat observed no announced prefixes or visible neighbours for any of them from July 1 to July 15, 2026. That does not show that the Nanning centre lacks connectivity, but it means the registrations cannot be used as current evidence of a WXYG-originated public routing surface.
- The strongest buyer test is a service-specific evidence schedule: deployed compute and model versions, token accounting rules, workload and data locations, carrier and path design, measured availability and performance, incident roles, 24-hour escalation authority, recovery tests, change control and an exit method. The public record supports asking those questions precisely; it does not answer them on a customer's behalf.
The word "cloud" has always made physical things sound lighter than they are. WXYG is an especially clear case. Behind the English expansion, Wuxiang Cloud Valley Co., Ltd, sits a Chinese company named 五象云谷有限公司, a large site in Nanning, capital expenditure disclosed through a listed parent, electrical and cooling plant, racks, network options, technicians, software and a more recent attempt to sell AI consumption in the unit that large language models make familiar: the token. The company is not difficult to identify once Chinese-language corporate and technical sources are brought together.
The difficult part is deciding what its identity proves.
It proves more than a directory label. Runjian Co., Ltd disclosed the formation of the venture in 2019. Later disclosures trace construction spending, rack plans, a proposed intelligent-computing expansion and a cooperation agreement with Alibaba Cloud. The company's own domain publishes Nanning and Shenzhen contacts, a colocation configurator, managed-operations tasks, facility-design claims, technical job descriptions and the new token-factory proposition. A national list recognises the centre as a green data centre. This is a thicker public trail than many regional cloud names possess.
But thickness is not the same as continuity. The sources describe different dates, commercial layers and standards of proof. A formation announcement says what a company was set up to do. A fundraising report says how a capital project progressed. A website says what the seller wishes customers to consider. A job advertisement says which work the organisation expects humans to perform. An autonomous-system registration says who has been assigned an internet number. A route collector says whether it can see that number originate public address space. A framework agreement divides intended responsibilities among partners.
None is interchangeable with a service report from a live customer workload.
That distinction matters more now that Wuxiang Cloud Valley is presenting itself not just as a place for equipment but as a factory for model tokens. Colocation has a relatively legible entity: a rack, a power allocation, a port, an address, a remote-hands task. Token supply introduces a stack of less visible dependencies. The model may belong to one party, the platform to another, the accelerator servers to a third investment entity, the data hall to Wuxiang Cloud Valley and the external path to one or more carriers. A request can fail while the building remains powered. It can complete while violating a customer's location rule.
A bill can be arithmetically correct under a token definition the customer did not understand. A model can be available while its quality, version or safety behaviour changes.
The right assessment of WXYG is therefore neither sceptical dismissal nor acceptance by accumulation. The company has a credible physical and organisational base. Its current public offer also leaves important commercial and technical questions open. The public record is valuable precisely because it lets a buyer separate what exists, what is claimed, what has been observed and what still needs to be contracted.
The English name leads to a specific Nanning company
WXYG's identity becomes clearer when the initials are treated as a bridge rather than a brand in isolation. APNIC uses WXYG as the name on four autonomous-system registrations and describes the holder in English as Wuxiang Cloud Valley Co., Ltd. The company's own website identifies the operating company as 五象云谷有限公司. In the Nanning context, "Wuxiang" corresponds to 五象, the Wuxiang area, rather than to an abstract cloud term.
The contact page places the Nanning operation at Building D1, Wuxiang Cloud Valley AI Intelligent Computing Industrial Park, 19 Huawei Road, Liangqing District, and also lists a Shenzhen office, a telephone line and an email on the wxyungu.com domain.
There is also a dated corporate origin. In a July 2019 formation announcement, listed company Runjian said it and Nanning Xiangteng Investment intended to establish Wuxiang Cloud Valley with registered capital of RMB200 million. Runjian was to contribute RMB140 million for 70 per cent, while Xiangteng was to contribute RMB60 million for 30 per cent. The stated purpose was to build and operate data-centre and cloud-computing-centre business. The proposed scope ran from data processing, storage and software to internet data-centre, access, cloud hosting, network management and construction services.
Those are formation facts, not a timeless ownership certificate. They establish why Wuxiang Cloud Valley exists and who originally sponsored it. They should not be silently promoted into a claim about today's shareholding, capital or governance. Corporate structures change, web pages age and a business scope records activities a company may conduct rather than services it has necessarily delivered. A buyer should still obtain the current legal name, registration number, ownership, contracting entity, invoice entity and licence details from current documents.
Even so, the origin matters. Wuxiang Cloud Valley was not created as a generic software reseller that later borrowed an infrastructure vocabulary. The venture was explicitly established around data-centre and cloud operations, backed by a listed company with a broader network-maintenance business and a local investment partner. That makes the site and its operating labour central to the company's identity. The physical and organisational boundary was present before the current AI language arrived.
The public contact surface adds another modest but useful link. The company contact page displays a Guangxi ICP filing and public-security filing, alongside the Nanning and Shenzhen locations. These details help tie domain, company name and place together. They do not answer whether the national phone reaches sales, a network operations centre or an after-hours incident lead. They do not identify which address appears on the customer's contract. But they give a prospective customer concrete fields to reconcile rather than asking that customer to rely on an unaffiliated listing.
Identity diligence should produce one chain with no unexplained jumps: the Chinese legal entity, the English name used in technical registries, the website operator, the facility owner or operator, the contracting party, the party holding relevant telecommunications permissions, the party issuing invoices and the party accepting incident notices. WXYG supplies enough public anchors to construct that chain. Operating assurance begins when the seller confirms it for the exact service.
A capital project that moved from plan to usable state
The data-centre project has a documented financial history, which is more useful than a page of architectural adjectives. In July 2023, Runjian reported that RMB724.485 million of fundraising proceeds had been invested in the Wuxiang Cloud Valley cloud-computing centre by June 30 of that year, equal to 67.07 per cent of the amount then committed. The same disclosure described a first phase in Wuxiang New District with two data-centre buildings of roughly 3,000 racks each, a power building, production support, underground works and fire, security and intelligent-monitoring systems.
It also documented slippage and revision rather than pretending that the original schedule had unfolded untouched. A plan that had put all 6,000 racks into the 2022 deployment year was changed to 2,000 in 2022 and another 4,000 across 2023 to 2025. Runjian proposed moving RMB200 million from the original centre budget into an intelligent-computing-centre project at the same address. That proposal described AI training, inference, rendering and cloud storage, with purchases adjusted to customer demand.
The later record is important. An April 2026 report on fundraising use said the proposed transfer had not been approved or moved by December 2025. Runjian said it had used self-raised funds for intelligent-computing construction instead, cancelled the transfer proposal, returned the money to the original use and considered the Wuxiang Cloud Valley cloud-computing-centre project to have reached its intended usable state. The fundraising project would be closed.
This is strong evidence of a built asset, but its wording deserves discipline. "Reached intended usable state" is a project and accounting conclusion. It is not the same statement as "all 6,000 racks are installed," "all racks are occupied," "the proposed intelligent-computing capacity is live," or "customers receive the advertised performance." The 2023 schedule was a plan. The 2026 closure statement says the original project could be used as intended. Neither provides a live inventory by hall, rack, power density, accelerator type or customer.
The current company profile adds a spatial description: phase one is said to cover 149,000 square metres, including a 57,000-square-metre self-owned intelligent-computing centre and a 92,000-square-metre AI-industry incubation area. Those figures make clear that the Wuxiang Cloud Valley proposition includes more than machine rooms. It is also an industrial property and ecosystem project. That can be commercially useful because customers, suppliers and technical teams may share a campus. It also means headline site area should not be mistaken for white-space area, deployed compute or saleable capacity.
A buyer can turn the capital history into a practical request. Ask for a current facility schedule that identifies commissioned halls, usable rack positions, contracted and available power, supported rack densities, cooling mode, live intelligent-compute clusters, customer segregation, maintenance state and any part of the campus that remains fit-out rather than production space. Reconcile that schedule with the service order. A project can be complete for financing purposes while capacity is still brought into service in commercial increments.
This is not an accusation about WXYG. It is ordinary infrastructure diligence. The company's disclosures are more candid than a simple "largest" or "highest grade" claim because they show investment, revised timing and the distinction between the original facility and later compute. Buyers should preserve those distinctions. The building is the base. The contracted operating unit is what they are purchasing.
One domain now presents two commercial eras
The Wuxiang Cloud Valley website is revealing because it contains two service languages at once. One is the established language of data centres: colocation, dedicated and shared bandwidth, BGP and non-BGP lines, public IP addresses, traffic defence, rack power, on-site duty, inspections, remote work and repair. The other is the new language of AI utility: pooled compute, models, scheduling, token production, metering and settlement.
On the hosting page, a customer can choose 1U, 2U, 4U or a full rack, select BGP or non-BGP connectivity, and consider dedicated or shared bandwidth and different payment periods. The visible page does not finish the transaction. Its configuration area exposes unresolved display variables rather than prices, and it directs the customer to enquire. That is evidence of a product design and sales route, not a public tariff.
The managed-operations page describes a much more labour-intensive offer: 24-hour on-site presence, network and facility monitoring, inspection documents, emergency exercises, work orders, equipment restart, cabling, link maintenance and repair, network changes, access control, power metering, environmental monitoring, dedicated-line work and remote coordination. In other words, the company does not portray the facility as an unattended shell. It presents human work as part of the service.
The newer token-factory page moves the unit of sale upward. Wuxiang Cloud Valley says it combines compute hosting, intelligent scheduling, efficiency optimisation, a model marketplace and precise metering and billing. Compute is to be packaged into a token-denominated product available on demand and charged according to consumption. The parent company's 2025 annual-report summary reinforces the direction, saying the Wuxiang Cloud Valley intelligent-computing centre would develop further toward a token factory and placing it alongside Runjian's pooled-compute and development-platform offer.
This is not merely a change in marketing vocabulary. Colocation sells controlled physical capacity. Raw accelerator rental sells time or access to a device. A model endpoint sells completed inference through software. A token service tries to make a unit of model computation the commercial meter. Each layer changes what the customer must observe and what the provider must control.
If WXYG sells only space and power to a customer who owns the servers, the customer may control the operating system, model and token accounting. If WXYG sells a managed cluster, responsibility moves toward hardware allocation, drivers, scheduling and repair. If it sells tokens through a model platform, it may also influence model selection, versioning, request processing, caching, rate limits, safety filters, logs and billing. A single brand can span these offers, but a single assurance statement cannot.
The coexistence of old and new pages therefore creates a useful diligence test. Ask the seller to identify which public description matches the proposed contract. Is the customer buying colocation, infrastructure as a service, accelerator capacity, a managed model endpoint, a token wallet, an application platform or a combination? Which terms govern each layer? Which legacy options remain generally available, and which pages describe capabilities rather than an orderable product? A broad cloud name becomes safer when the unit of sale is narrow.
A token is a meter only after the rules are visible
Tokens look precise because they can be counted. That apparent precision can hide several commercial choices. Different model families split text and other inputs differently. Input and output tokens may be priced differently. Cached context, system instructions, tool calls, retrieved documents, image or audio encoding, failed requests and retries may be included or excluded. A platform may route requests across models whose tokenisation and output behaviour differ. A total token number without those rules is a counter, not yet a trustworthy billing unit.
Wuxiang Cloud Valley's public proposition is strongest as an operational idea: abstract compute is made consumable, measurable and payable. That is how expensive infrastructure can be shared among organisations that do not want to own a cluster. Scheduling can increase utilisation. Metering can make small experiments possible. A model marketplace can reduce the work needed to bring an application online. These are plausible benefits of the architecture the company describes.
The public pages do not yet let an external reader evaluate the product as a utility. They do not publish a model catalogue with version rules, a token-accounting specification, prices, a service-level schedule, sustained throughput, time-to-first-token, percentile latency, error rates, concurrency limits, regional availability, quality benchmarks or a sample bill. The absence of these items on a public page does not mean a commercial proposal lacks them. It means the phrase "token factory" should be treated as an invitation to request the operating contract, not as the operating contract itself.
A serious evaluation would begin with a reproducible workload. The customer would supply a defined mix of short and long prompts, context sizes, output limits, concurrency and model versions. WXYG would explain where each request runs, how it is queued, how input, cached and output tokens are counted, what happens on timeout, and whether retries produce additional charges. The test would record successful requests, failed requests, first-token delay, completion delay, throughput, model response quality and billed units. Both parties would retain the same trace identifiers and totals.
Quality belongs in that test because a cheap token that does not perform the task is not cheap. For extraction, measure field accuracy and abstention. For retrieval, measure whether answers remain grounded in the supplied documents. For code, use executable tests. For customer service, assess resolution and unsafe invention. For a multilingual application, test the actual languages and scripts. WXYG's platform can automate allocation and metering, but the customer must define the acceptable output.
Version control is equally important. A provider may improve efficiency by changing quantisation, inference software, routing or model release. Those changes can alter latency, output and token counts. The contract should say which changes require notice, which can occur during maintenance, whether a pinned version is available, how rollback works and how a customer can reproduce a disputed result. "Same model name" is not always enough if weights, context handling or safety settings have changed.
This is where enterprise-software automation meets physical infrastructure. Scheduling, metering and billing are software controls over scarce machines. They can reduce manual provisioning, but they add a new supervision cost: someone must validate allocation fairness, bill accuracy, model identity, failed-job handling and change history. The token factory succeeds as a service when that supervision is built into the product rather than pushed onto a customer who can only see a monthly total.
Four AS numbers are assignments, not a visible network
The network-resource evidence is unusually instructive. APNIC has separate records for AS146748, AS146749, AS146750 and AS146751. Each uses the name WXYG, describes Wuxiang Cloud Valley Co., Ltd at a Nanning address, carries China as the country and provides common administrative, technical and incident-response contacts. All four were registered on July 7, 2021 and show active registry status.
That is meaningful resource evidence. Four contiguous numbers tied to the same organisation are unlikely to be a casual directory artefact. They show that Wuxiang Cloud Valley passed through a resource-assignment process and established accountable contacts. They also give customers and researchers exact identifiers to monitor.
But active registry status is not active routing. For the July 1 to July 15, 2026 observation window, RIPEstat marked all four AS numbers as unannounced. The announced-prefix result for AS146748, and the equivalent results for AS146749, AS146750 and AS146751, returned no visible prefixes. Neighbour observations returned no visible adjacent networks for any of the four.
The negative finding has a narrow meaning. It does not prove the Wuxiang Cloud Valley facility has no internet connection. A data centre can buy transit under a carrier's address space, connect customers to several carriers, use partner networks, support private circuits, or have resources that public collectors do not associate with these four numbers. A colocation facility may provide customers with connectivity without originating its own prefixes at all. Collector visibility also has limits.
What the finding does prevent is a common analytical shortcut. The four registrations cannot be presented as proof that WXYG currently originates customer routes, has four live network domains, possesses a particular amount of address space or connects to a particular set of upstreams. The records prove assignment. The observation window found no public origin surface under them. The difference is the heart of network-resource diligence.
This distinction also reframes the company's first-party network claims. The facility page describes multi-line BGP, physically independent external paths, redundant internal design and security services. The hosting page offers BGP and non-BGP choices. These claims can be true even while the WXYG AS numbers remain unannounced, because carrier ASNs may provide the routes. Yet if the customer needs route control, multihoming, DDoS handling or verifiable path diversity, the seller should name the production design rather than point to the four registrations.
The useful questions are concrete. Which AS originates the customer's public prefix? Who holds the address space? Which carriers are contracted? At which building entries and meet-me points do circuits arrive? Do apparently separate carriers share a conduit, exchange or upstream? Is route-origin authorisation in place where applicable? Who can change filters during an incident? How are customer routes validated? Which route collectors should see the service when it is healthy? What private connectivity is available to partner clouds or customer sites?
For a token service, network design affects both performance and control. A model may run in Nanning while prompts arrive through another region. A partner platform may terminate the customer connection before forwarding work to the centre. Storage and observability may sit on different networks. A route outage can isolate the service even when the cluster and power remain healthy. Network assurance therefore requires a service path, not an inventory of unused or invisible identifiers.
Power and cooling claims need tests, not multiplication
The physical facility page contains enough detail to support a serious engineering conversation. Wuxiang Cloud Valley says the centre was built by reference to Uptime Tier III and GB50174-2017 Class A design standards. It describes dual utility supply, an ultimate design with twelve external feeds from two 110kV substations, 2N uninterruptible power, dual-bus distribution, 26 medium-voltage generators in an N+2 arrangement and a 200-cubic-metre underground fuel tank intended to support 18 hours. It also describes several cooling configurations, rack densities from 4kW to 20kW and average PUE of 1.38.
These claims are specific enough to examine and too specific to accept as one undifferentiated reliability score. A dual feed can lose diversity upstream. Generator redundancy depends on available units, switching, fuel quality and load. An 18-hour fuel statement depends on the load and refill plan. A 2N design depends on maintenance state and whether both paths remain separated through the customer rack. PUE depends on measurement boundary, period, load and climate. A design reference says how the facility was intended to be built, not how every component performs on the day a customer needs it.
There is independent support for one environmental claim. Wuxiang Cloud Valley Cloud Computing Center appears at number 19 on the published 2023 national green-data-centre list. That designation is a useful external signal about environmental performance. It should remain in scope. It is not a general certificate for availability, cybersecurity, model quality, support or disaster recovery.
The facility's newer compute headline needs similar care. A May 2026 People's Daily Guangxi profile reports that the centre can deploy up to 40,000P of mainstream intelligent compute and attributes an output of 200 billion tokens per hour to the token-factory proposition. Those numbers communicate scale. The article does not supply the accelerator mix, precision, model, input/output ratio, context length, batch assumptions, sustained duration, utilisation, power draw or independent benchmark needed to compare them with another service.
"P" is especially slippery without a numerical format and workload. Integer inference capability and floating-point training capability are not interchangeable. Peak silicon performance is not application throughput. Token output depends on model size, quantisation, request shape, memory, interconnect, software and quality settings. A small model can produce many more tokens than a large model from the same hardware while doing a different job. Buyers should ask WXYG to translate capacity into their model and service objective.
The correct facility test is layered. Review current single-line electrical diagrams and maintenance state. Witness or inspect recent transfer and generator tests. Confirm fuel contracts and replenishment under regional disruption. Identify the cooling mode assigned to the customer's rack or cluster. Review alarm, capacity and environmental histories for the relevant hall. Ask how concurrent maintenance affects redundancy. Then run the customer workload long enough to connect electrical and thermal behaviour to software performance.
This does not reduce the value of the physical plant. It makes that value legible. WXYG's public disclosures point to serious investment and a usable centre. Assurance comes from showing how the design behaves under load, failure and maintenance, not from adding design labels and capacity maxima until they sound conclusive.
The Alibaba Cloud agreement exposes the control boundaries
The 2023 cooperation agreement with Alibaba Cloud is useful less as a trophy than as a map of divided responsibility. Runjian's official announcement described two intended projects: a China-ASEAN intelligent-computing cloud and a digital-economy innovation centre. In the stated design, Alibaba Cloud would lead construction and operation of a dedicated-cloud node. Wuxiang Cloud Valley would provide the data-centre power and cooling environment. Runjian would invest in 2,500P of servers, while Alibaba Cloud would participate in unified platform management, operations and commercial activity. Wuxiang Cloud Valley would also provide office space and support for the innovation centre.
The announcement is careful about status. It calls the agreement a guiding document reflecting cooperation intent. Project scale was a target, later specifics required separate agreements, no material current-period financial effect was expected and compute leasing was described as uncertain. The agreement had a stated three-year term. The frozen public evidence does not show what was deployed under it, what continues in July 2026 or whether a customer buying today's token service enters an Alibaba-controlled layer.
That uncertainty should not erase the agreement. It should shape the procurement questions. The described division shows why a customer cannot treat WXYG as the sole operator of every possible service simply because the servers sit in its campus. In one arrangement, Wuxiang Cloud Valley may own or operate the environmental base, Runjian may fund compute and Alibaba Cloud may operate the platform. A fault can cross those boundaries.
Suppose a request times out. The cause might be external routing, a cloud-node gateway, scheduler pressure, failed accelerator hardware, storage delay, model-server software, cooling derating or a customer quota. Which party sees the end-to-end trace? Which party opens the incident? Which party is authorised to move the workload? Which clock starts the service-level calculation? Who writes the customer explanation? A partnership announcement cannot answer those questions. A responsibility matrix can.
The same applies to planned changes. The facility operator may schedule electrical maintenance. The platform operator may update a gateway. The compute owner may replace accelerators. The model provider may publish a new version. Each change can affect the service even if the other layers remain stable. The customer needs one coordinated notice, one change history and one accountable service owner.
WXYG can turn the partnership structure into an advantage if it offers that integration explicitly. A local facility, a listed parent's investment capacity and a large cloud partner can provide complementary capabilities. But partnership value is not the number of names in an announcement. It is the removal of gaps between their operational duties.
Data locality starts with the workload, not the street address
Nanning is central to Wuxiang Cloud Valley's proposition. The company sits in the China (Guangxi) Pilot Free Trade Zone's Nanning area, describes a self-owned intelligent-computing centre there and positions the site toward domestic and ASEAN-facing demand. For organisations that want compute in Guangxi, this is a meaningful locality signal. The presence of local technical roles and a defined physical campus can make inspections and incident accountability more tangible than an unspecified global cloud region.
It is not yet a complete data-residency answer. A workload creates several classes of data: prompts, uploaded files, embeddings, model weights, cache entries, outputs, account details, billing records, authentication logs, safety logs, support attachments, traces, backups and diagnostic snapshots. They can have different storage locations and retention periods. A request can execute in Nanning while its account control, logging, support or backup data sits elsewhere. A partner-operated gateway can change the path before the workload reaches the facility.
The token-factory design makes locality both more important and more complicated. Shared scheduling may move work among available resources. A model marketplace may obtain models or services from different parties. Efficiency optimisation may cache repeated context. Precise billing requires records that connect users to consumption. Every useful platform feature creates a data-handling question.
A customer should begin by classifying the workload. Which inputs are personal, confidential, regulated, export-controlled or commercially sensitive? May they be used for service improvement? May an operator inspect them during support? Can they enter a third-party model service? Where may primary and backup copies reside? Who can access them from another jurisdiction? When are they deleted, and what evidence confirms deletion?
Then map the proposed architecture. Name the ingress endpoint, identity service, scheduler, model server, storage, logging, billing and support systems. Mark the legal operator and physical location for each. Identify every external subprocessor and management plane. Document whether telemetry includes content or only technical metadata. Where the seller cannot commit to a fixed location, the customer should decide whether that variability is acceptable rather than accepting "Nanning centre" as a proxy.
Network locality needs equal precision. The WXYG AS registrations do not reveal the live production path, and BGP observations do not reveal the physical fibre route. If a customer requires domestic routing or private connectivity, it should request the carrier and endpoint design, then test it from the actual user and data-source locations. For ASEAN-facing use, latency, cross-border transfer, local regulation and support hours may differ by country. A regional ambition is not a single regional architecture.
Data sovereignty is ultimately about control: the ability to decide where data goes, who can act on it, what rules apply and how the customer exits. WXYG's physical location can support that control. The contract and technical design must complete it.
The hidden product is local technical labour
Cloud services are often sold as automation, yet facilities recover through people. Wuxiang Cloud Valley's public material recognises this more clearly than its token metaphor might suggest. The managed-operations catalogue includes duty coverage, inspections, maintenance records, emergency exercises, network monitoring, cabling, link repair, physical access, power systems and customer support. Its careers page describes the roles behind that list.
Fire-safety duty staff are expected to inspect systems, prepare emergency procedures, record faults and work in a 24-hour shift environment. Power-duty engineers are assigned generators, UPS, distribution, capacity, repair, procedures and risk correction. Information-systems duty engineers cover network, storage, databases, security, cloud platforms, building automation, environmental monitoring, DCIM, cabling and fault response. HVAC engineers cover design, construction, commissioning and optimisation. Sales roles connect customer needs to IDC and cloud solutions.
These descriptions are not proof of how many people WXYG currently employs or whether every shift is filled. A job page can be old, aspirational or actively recruiting. It does, however, reveal the human operating model the company considers necessary. The tasks are specific to a real data centre. They also show why the promise of automated token supply cannot eliminate local labour.
When a breaker trips, a cooling unit alarms or a fibre needs to be moved, software can detect and route the event but a qualified person may still need to act. When a model endpoint behaves incorrectly, platform engineers may need evidence from software and hardware teams. When a customer disputes a bill, someone must reconcile the meter, request trace and contract. Automation changes where labour enters; it does not make responsibility disappear.
Support quality depends on authority as much as availability. A person answering a phone may be able to acknowledge an incident but not enter the hall, change a route, drain a cluster, contact a partner or approve a service credit. A 24-hour duty engineer may protect the facility while the application team works business hours. A partner may own the only useful trace. Buyers should ask who has each permission and how escalation crosses organisations.
The service order should name severity levels, acknowledgement targets, update intervals, restoration objectives, escalation contacts and authority. It should distinguish facility remote hands from platform support and model support. It should say which languages and hours apply to ordinary requests and critical incidents. It should define how customer-authorised work is authenticated, recorded and closed. For important workloads, the customer should exercise the escalation path before an emergency.
Local support can be WXYG's durable advantage. A hyperscale service may offer a larger global platform, but a Nanning team can inspect a specific hall, power path and cable. That advantage exists only if the customer can reach the right person and the contract gives that person a route to act.
What the public record still cannot tell a buyer
WXYG's evidence is strongest at the levels of corporate origin, project investment, facility intent, public service design and technical labour. It is weakest at the level buyers ultimately pay for: repeated outcomes. The public material reviewed for this article does not include a completed customer case with measurable results, a public status history, percentile support performance, independently reproduced token throughput, model-quality results, a current price schedule or a detailed service-level agreement.
That absence should be described accurately. Private business-to-business providers often disclose technical and commercial evidence during a sales process rather than on the open web. Some customers prohibit public case studies. Security-sensitive facilities limit detail. The public gap is not proof of poor operation. It is a reason to make evidence delivery a condition of purchase.
A useful sales-room package would contain a current architecture and responsibility matrix; commissioning and certification documents relevant to the selected hall; twelve months of availability, incident and maintenance data at the right service layer; current capacity and utilisation ranges; a carrier and path summary; a token-meter specification; representative workload results; data-location and retention terms; support staffing and escalation; recovery-test evidence; and a sample exit. Sensitive details can be shared under confidentiality without forcing the buyer to infer performance from publicity.
The package must distinguish infrastructure metrics from application metrics. Facility power availability does not equal model-endpoint availability. Network reachability does not equal successful inference. Successful inference does not equal acceptable accuracy. Token throughput does not equal completed business tasks. A single monthly percentage can hide which layer failed and how much customer work was lost.
For WXYG, the most revealing metric chain would start at capacity and end at accepted output. How much compute was allocated? How long did the request wait? Which model and version ran? How many input, cached and output tokens were counted? Did it complete within the objective? Did it pass the customer's quality test? Was it billed correctly? How much operator work was needed? This chain connects the token-factory claim to customer value.
Commercial evidence matters too. A usage-based offer can reduce commitment, but the customer needs to understand minimum spend, reserved capacity, burst rates, egress, storage, failed jobs, support, private connectivity, model licensing and termination. Colocation, managed infrastructure and tokens may each have separate charges. A low token price can be offset by poor cache economics, long outputs, retries or expensive support. The unit must be evaluated inside the full service.
The public record gives WXYG a better starting position than a company with no traceable facility or operating team. It does not permit an analyst to fill missing outcomes with confidence. The company should be judged on the evidence it can provide for the proposed workload.
A practical proof sequence for customers
A customer does not need to audit the entire Wuxiang Cloud Valley campus to make a proportionate decision. It needs to test the chain that will carry its own service.
First, reconcile identity and scope. Confirm the legal contracting party, service name, facility location, licence basis, partners and subprocessors. Attach the architecture and responsibility matrix to the order. Identify whether the purchase is colocation, managed compute, model access, tokens or a combination. State which public descriptions are incorporated and which are not.
Second, verify the physical allocation. Identify the hall, rack or cluster class, power density, redundancy mode, cooling, maintenance arrangement and available capacity. Review evidence for the selected environment rather than a campus maximum. Record what changes if the service bursts beyond its reserved allocation.
Third, map connectivity. Name the production origin network, address holder, carriers, private links, protection and route-change authority. Test paths from actual user and data locations. Do not use AS146748 through AS146751 as proof unless one of them is actually part of the delivered design and becomes observable as expected.
Fourth, benchmark the software service. Use a fixed workload and retain request-level results. Measure queue time, time to first token, completion time, successful throughput, errors, retries, quality and billed units. Repeat at ordinary and stressed concurrency. Confirm model version and token rules. Run enough tests to reveal variability, not just a demonstration at an empty moment.
Fifth, verify locality and security. Trace prompts, files, outputs, logs, billing, support and backups. Test access controls and customer separation. Review encryption, key responsibility, privileged access, vulnerability handling and incident notification. Confirm deletion and export behaviour with a non-production dataset.
Sixth, exercise people and recovery. Open a routine ticket and a planned high-severity exercise. Follow escalation from customer support to facility, network, platform and partner teams. Test a safe failover or restoration procedure. Measure acknowledgement, diagnosis, authority and communication, not merely final closure.
Finally, test exit before dependence grows. Export customer data, configuration, logs and usage records. Document model and API dependencies. Estimate the time and network cost to move. Establish what WXYG will delete, return or retain at termination. A service is easier to adopt when leaving it is an engineered process rather than a negotiation during distress.
The result should be a small set of thresholds that can be monitored every month: successful task rate, quality acceptance, latency percentiles, token-account variance, service availability, incidents by layer, support response, restoration, capacity headroom, locality exceptions and unresolved changes. This is enough to convert a broad cloud proposition into an operating relationship.
The fair conclusion behind the name
WXYG Wuxiang Cloud Valley Co., Ltd is not an empty cloud label. It can be tied to a Nanning company formed for data-centre and cloud business, a capital project that its listed parent says reached its intended usable state, a large physical campus, a national green-data-centre designation, current colocation and managed-operations descriptions, detailed technical labour roles and a 2026 move toward token-based AI services. Those are material signals of capability and intent.
The network records add evidence and restraint at the same time. Four autonomous-system numbers are genuinely assigned to WXYG, with named contacts and a common Nanning identity. None showed visible prefixes or neighbours in the observed July 2026 window. A careful assessment preserves both facts. It neither calls the registrations meaningless nor turns them into a live network that collectors could not see.
The token-factory proposition is similarly promising and unfinished in public. Packaging model consumption into metered units could make intelligent compute easier to buy. The company describes the right supporting functions: hosting, scheduling, optimisation, models and billing. Yet token volume is not a business outcome, and a platform meter is not trustworthy merely because it returns a number. Customers need model identity, counting rules, performance, quality, locality and dispute evidence.
WXYG's relationship with Runjian and the announced Alibaba Cloud design show why accountability must be explicit. Physical plant, funded servers, cloud platform, network paths and model service can have different operators. The customer should receive one view across them and one owner for the contracted result. Otherwise, a well-built data centre can support a service whose failures fall between organisations.
The strongest part of the Wuxiang Cloud Valley story may therefore be the least fashionable: the technicians, duty roles, maintenance records and local facility work described on its own pages. AI services still depend on electricity, cooling, fibre, access control, repair and people authorised to respond. Nanning locality has value when those people can connect a customer-visible symptom to a physical or software cause.
WXYG deserves to be treated as a serious regional infrastructure and intelligent-compute proposition. It does not deserve automatic assurance from the scale of the campus, the number of design claims, a partner's name, a token-output headline or four assigned AS numbers. The missing step is service proof. When Wuxiang Cloud Valley can show the exact deployed stack, measured workload, data path, live network design, operating responsibilities and recovery performance for a customer, the cloud name becomes something firmer: an accountable system whose value and limits can both be seen.