From Using AI to Building It: Introducing INSTRAT GRO
From Using AI to Building It: Introducing INSTRAT GRO
Why the next competitive advantage in AI will be built—not merely rented
By Asbjørn Levring, Founder and CEO of INSTRAT360
A year ago, I said that INSTRAT360 would eventually train its own AI models from scratch.
At the time, it was an ambition.
Today, it is running code.
We have now completed the first successful smoke tests in an application developed by INSTRAT360 for intelligent AI model development.
We call it INSTRAT GRO.
And this milestone represents something much bigger than one small experiment.
It marks the moment we began moving from building applications that use artificial intelligence to building the underlying models themselves.
This was not fine-tuning
The distinction matters.
We did not take an existing model from OpenAI, Anthropic, Meta or another provider and add a layer of instructions.
We did not fine-tune somebody else’s pretrained weights.
We did not create another prompt wrapper and call it a proprietary model.
For this test, GRO:
- Trained a new BPE tokenizer on our selected corpus
- Defined a new decoder-only Transformer architecture
- Created approximately 3.3 million parameters
- Randomly initialized every model weight
- Trained the model on the new corpus
- Monitored real training loss and execution
- Recorded the configuration, cost and resulting model artifacts
There was no imported model checkpoint and no pretrained foundation model underneath it.
The resulting weights were created during our own training process.
That is genuine from-scratch model training.
A tiny model—and an important result
We should be precise about what we have achieved.
The first model used approximately 2,120 training tokens and contained only 3.3 million parameters. It is not a production LLM, and it is not competing with frontier systems from OpenAI, Anthropic or Google.
That was never the purpose of the experiment.
Its purpose was to prove that the machinery works.
During the tests, training loss fell from approximately 6.03 to 1.8. With such a small corpus, that does not prove general intelligence or useful real-world performance. It proves that the tokenizer, architecture, optimization loop, metrics and model-artifact pipeline are functioning.
Three smoke tests were completed successfully.
The total recorded cost was approximately $0.44.
The model was intentionally small. The milestone is not.
We crossed the line from discussing model development to executing it.
Most companies are still renting intelligence
The first wave of generative AI adoption has largely been built around access.
Organizations connect to a frontier model through an API. They add prompts, retrieval, company knowledge, tools, workflows and governance. The resulting applications can be extraordinarily valuable.
This is also an area in which INSTRAT360 has already developed significant experience.
But an application powered by an external model is not the same as owning the model itself.
The provider still controls the foundation weights, future releases, availability, pricing and many of the model’s fundamental capabilities.
The organization owns the application around the model—but not the intelligence engine at its center.
That distinction will become increasingly important.
In the next phase of enterprise AI, organizations will ask deeper questions:
- Which intelligence should we continue to buy?
- Which capabilities should we adapt?
- Which models should we own?
- Which data should become part of our model assets?
- Can we reproduce exactly how a model was created?
- Can we deploy it in our chosen environment?
- Can we prove that no unapproved data or pretrained weights were used?
- What happens if a provider changes its model, price or terms?
AI sovereignty does not mean rejecting external providers.
It means having choices.
From one model to a portfolio of intelligence
I do not believe every organization needs to build a gigantic general-purpose model.
That would often be commercially irrational.
The more interesting opportunity is a portfolio of smaller, purposeful and economically efficient models.
An organization might own specialized models for:
- Business-document understanding
- Strategy and portfolio classification
- Technical or regulatory terminology
- Structured data extraction
- Assessment and scoring
- Tool selection and function calling
- Quality control
- Industry-specific research
- Danish and English business communication
- Private or sensitive operational use cases
These models do not need to answer every possible question.
They need to perform their intended jobs reliably, efficiently and transparently.
A focused model that an organization can control may be more strategically valuable than a much larger general model it can only access.
GRO supports more than one path
From-scratch training is an important capability—but it is not always the right commercial decision.
GRO is therefore being designed to support several clearly separated model-development strategies.
Build from scratch
The model begins with a new tokenizer, a defined architecture and randomly initialized weights.
This provides the strongest independence and provenance, but it requires more data, experimentation and compute as the model grows.
Continue training an open-weight model
An organization can begin with an approved open-weight foundation and perform continued pretraining using its own domain corpus.
This can introduce specialized language, concepts and relationships into private derivative weights.
Fine-tune for behavior
An existing open-weight model can be trained on approved examples to improve instruction following, structured outputs, tool use and domain-specific behavior.
This is faster and more affordable than full pretraining.
Distill intelligence
Powerful teacher models can help create training examples and evaluations for a smaller, controlled model.
This can produce efficient models designed for specific capabilities and predictable operating costs.
These are not competing ideologies.
They are different engineering and ownership choices.
GRO should help the user understand those choices and select the approach that creates the right balance between quality, independence, speed and cost.
What GRO is designed to become
GRO is not intended to be another technical dashboard filled with disconnected infrastructure settings.
It is an intelligent, conversational and governed model-development environment.
A user should be able to explain the model they want to create:
“I need a private Danish and English model that understands our strategy methodology, produces validated structured outputs and can operate inside our applications.”
GRO should then help translate that purpose into an executable model-development programme.
The journey will cover:
- Defining the model’s purpose and required capabilities
- Selecting the appropriate development strategy
- Collecting and governing the source data
- Cleaning, deduplicating and versioning the corpus
- Creating and reviewing training examples
- Designing a tokenizer and architecture when building from scratch
- Configuring adaptation when using open weights
- Estimating compute requirements and expected costs
- Requiring approval before spending money
- Launching real training infrastructure
- Explaining live metrics and potential problems
- Saving checkpoints and complete model lineage
- Comparing model versions against private evaluations
- Publishing an approved model version
- Deploying and testing the resulting model
The ambition is to make model development understandable without hiding its technical or commercial reality.
GRO is not a replacement for AWS SageMaker
This distinction is important.
AWS SageMaker AI is a powerful managed environment for data scientists and developers to build, train and deploy models. AWS also supports custom training code and containers, allowing organizations to execute their own algorithms and model architectures. AWS describes SageMaker AI here and documents custom training containers here.
GRO operates at a different layer.
AWS can provide the compute, storage, containers, job execution and deployment infrastructure.
GRO provides the intelligent model-development journey:
- Why the model should exist
- What it must be capable of doing
- Which creation path should be selected
- Which data can be used
- What the run should cost
- Who must approve it
- Whether the result is genuinely better
- What is owned and what is licensed
- Whether the model is ready for release
- How every result can be reproduced
SageMaker can operate the infrastructure.
GRO governs and guides the creation of the model.
Over time, GRO should also be capable of working with different compute environments. The model-development lifecycle should not be defined entirely by one infrastructure provider.
The real proprietary asset is larger than the weights
Model ownership matters, but weights alone do not create a durable advantage.
The complete proprietary asset includes:
- Curated source data
- Training and preference datasets
- Tokenizer versions
- Architecture definitions
- Private model weights
- Training configurations
- Evaluation suites
- Human corrections
- Rejected outputs
- Tool-use examples
- Quality standards
- Safety decisions
- Model lineage
- Deployment knowledge
This creates a continuous improvement loop.
GRO can identify where a model is weak, generate or collect targeted corrective examples, retrain a new version and measure whether it improved.
Each approved cycle makes the model—and the surrounding development system—more valuable.
Why the name GRO
We chose GRO because this is fundamentally about growing intelligence deliberately.
But the name also captures three principles:
Guided. Reproducible. Owned.
Guided, because intelligent assistance should make advanced model development understandable and actionable.
Reproducible, because every important decision, dataset, configuration, cost and checkpoint must be traceable.
Owned, because organizations should be able to create model assets they control—while remaining completely transparent about any open foundations and licences involved.
The promise behind GRO is simple:
Build intelligence you can own.
From aspiration to evidence
There is still a significant journey ahead.
A 3.3-million-parameter smoke model is not a finished commercial LLM. Scaling requires larger and better datasets, more compute, careful evaluation, safety work and repeated experimentation.
But every large technological capability begins with a smaller proof that the essential mechanism works.
That is what we have now achieved.
One year ago, training our own models was a statement of intent.
Today, we have trained the first one.
It is small. It is early. And it is real.
INSTRAT360 is no longer building applications that only consume artificial intelligence.
With GRO, we are beginning to build the intelligence itself. Write your post in Markdown.
A subheading
Use bold, italic, links, lists, and quotes.
- First point
- Second point
A pull quote to emphasize something.