Teams looking for GPU cloud Brazil options, or anywhere else in Latin America, face a simple tension. Users in São Paulo, Mexico City or Santiago get the best experience from a nearby GPU, but the widest choice of machines is often elsewhere. Cloudj lets you handle that with one tool: a country filter over a live inventory of independent host machines. This guide shows how to search Latin American codes first, how to fall back to the United States without hurting users more than necessary, and how to route traffic through a VPS in Miami or Dallas.
The GPU cloud North America guide covers the US and Canada side of this picture in more depth.
GPU cloud Brazil, Mexico or Chile: pick codes by where users are
Latin America is large, and its networks do not all point the same way. Use this as a starting point, then measure from your users.
| Main audience | Search first | Add next | Common fallback |
|---|---|---|---|
| Brazil | BR | AR, CL | US |
| Mexico and Central America | MX | CO | US |
| Chile, Argentina, Southern Cone | CL, AR | BR | US |
| Andean countries (Colombia, Peru) | CO, PE | CL, MX | US |
| Mixed Latin American audience | BR, MX, CL | AR, CO | US |
Open the GPU deploy page and type the codes into the Country field, separated by commas or spaces, for example BR, MX, CL. Results are sorted by total price, lowest first. If a machine is listed, you can deploy it; stock changes during the day, so an empty search today does not mean an empty search tomorrow. For a full walkthrough of the filter, see how to filter GPUs by country.
What to check in the results
Each machine shows its country only, never a city, so a BR listing is "somewhere in Brazil". Also check:
- Reliability, shown as a percentage;
- Max duration and the "available until" date, after which the instance and its disk are removed;
- Bandwidth price per TB for download and upload;
- the Datacenter badge, and the "Datacenter only" switch if you want to restrict to data-centre hosts;
- download speed, which affects how long it takes to pull a large model.
Serving Portuguese and Spanish models
Most open language models handle Spanish well, and Portuguese reasonably well, but quality varies by model and size. A few practical points:
- Test with real prompts. Use the kind of messages your users actually send, including informal Brazilian Portuguese or regional Spanish, before you choose a model size.
- Size VRAM for the whole request. Weights are only part of the memory. Long conversations and parallel users need room for the KV cache. A quantized 7B-8B model fits on a 12-16 GB card; a mid-size quantized model generally needs a 24 GB card such as the RTX 4090.
- Speech workloads. Transcription in Portuguese and Spanish is usually lighter than a chat model, and fits well on 12-24 GB cards.
These are general guidelines, not benchmarks. Deploy for an hour, test, and destroy if it does not fit; billing is per minute.
When to fall back to the US
If your Latin American search is empty after loosening filters, add US. It is the common fallback for the region because so much of Latin America's international traffic is routed through the United States, especially through hubs on the east and south coasts.
Whether the extra distance is acceptable depends on the job:
- Batch jobs (training, embeddings, transcribing an archive): the US is fine, and so is anywhere else with a good price.
- Chat and voice for Mexico: a US host is often a reasonable compromise.
- Interactive apps for Brazil or the Southern Cone: the distance to the US is noticeable. Keep searching locally at different times of day, and measure. The article on real-time AI latency explains how to budget for it.
US coverage, and which US codes and filters to use, is covered in the GPU cloud USA guide.
A Miami or Dallas VPS in front
Cloudj does not run VPS locations in Latin America, but its United States VPS locations include Miami and Dallas, which sit on common routes for Latin American traffic. A VPS there makes a stable front end:
- it holds your domain, TLS certificate, API, queue and database;
- it forwards inference to the GPU instance, wherever the GPU is;
- when the GPU machine reaches its date or goes offline, you deploy a new one and change one address.
The GPU itself has no hardware SLA and is not moved automatically if the host goes offline, so the VPS is what gives your users a constant address. Connect the two over SSH:
ssh -N -L 8000:localhost:8000 -p <port> root@<gpu-host>Miami tends to suit Brazil and the Caribbean; Dallas often suits Mexico. Test both from your users' networks; the article on US East vs West VPS explains how the US coasts compare.
Payments and budgeting
GPU billing runs per minute from a prepaid balance in US dollars, and the price shown at deploy is locked for that instance. A deposit is held when you deploy and the unused part returns after you destroy the instance, sometimes after up to 72 hours while bandwidth charges settle. Live "from" prices per model are on GPU cloud.
FAQ
Can I search Brazil, Mexico and Chile together?
Yes. Enter BR, MX, CL in the Country field and the results include all three.
Is a US GPU fast enough for Brazilian users?
It depends on the app. For batch work, yes. For interactive chat, measure from your users before deciding.
Does Cloudj have a VPS in Brazil?
No. The closest Cloudj VPS locations for Latin American traffic are in the United States, such as Miami and Dallas.
Will I see the city of a GPU host?
No. GPU locations are shown at country level only.
Search Latin America first
Open the GPU deploy page, enter BR, MX, CL, and keep US ready as a fallback. Compare live prices for each model on GPU cloud.