Predicting the Future: A Distributed Multicloud AI Approach

In my last post, I hinted at a new project: finding a way to run dynamic SQL on a dataset using a prompt. My first attempt failed. The SQL Model Context Protocol (MCP) was too fragile to come close to producing the results I wanted. While I laid out a plan for a new approach, I also decided to inject some innovation.

I wanted to mimic a real-world architecture that I believe many companies will implement in the future: Distributed Multicloud AI.

Why Distributed Multicloud AI?
Distributed Multicloud AI allows us to take advantage of open-source models that are more business-trustworthy while spreading operational risk. It also lets us leverage model services tailored specifically to our unique needs.

The news hasn't been good lately for frontier labs - at least, for two of them. Truthfully, I believe the two big frontier labs dominating headlines may have a short shelf life over the next couple of years. On the other hand, I think Palantir is solid. It offers guaranteed data sovereignty and is here to stay. Of course, they are expensive because they built a business model on what AI computing actually costs, rather than trying to sucker people in with free services.

Despite ethical concerns and platforms that may be a little beyond us right now, developers and organizations still have a lot of choices. Personally, I find myself increasingly pulled toward open-source models. That doesn’t mean I am giving up on Azure or Azure AI Foundry, but open-source platforms offer incredible options that are highly focused on specific tasks and very well-reviewed.

I want to pursue a Distributed Multicloud AI mindset - at least for public-facing features. Back-end ERP data is a totally different ballgame.

So, I'm looking to spread the risk and take advantage of all the tools out there.

Step 1 of My Project: Isolating the Data
Step 1 of my plan is officially complete. I wanted to isolate a dataset using Azure Data Factory, so I created a Parquet file as a secure storage solution. This file will be transferred to Hugging Face, where a Qwen2.5-72B-Instruct agent will use smolagents and the Pandas library for dynamic data generation and wide-view analysis of my sports data.

To ensure end-to-end security, the Parquet file is protected with a Shared Access Signature (SAS) token

The process of creating the Parquet in Azure Data Factory was uneventful but enjoyable. It was my first venture into Data Factory, and I found it to be highly user-friendly and straightforward. I'll be honest: I had no idea what a Parquet file was before this, but I know now, and we will see how it works! I was even more excited when I read that Qwen2.5-72B-Instruct with Pandas can query a file using SQL - or so they say.

What Success Will Look Like
As I move along, I will detail my security decisions. For right now, Step 1 is complete. I have isolated a cherry-picked dataset, completely disconnecting it from the parent database.

This configuration allows Hugging Face to securely fetch the data using the SAS token, after which it will simply exist in cached memory. If all works out, I will have isolated a portion of my data on one platform (Azure) and integrated it with completely different model on a completely different platform (Hugging Face) where I will then use Qwen2.5-72B-Instruct with smolagents to build a dynamic text-to-SQL feature.

Can I get there? We'll find out.