CoolFace
Modelpublic

ahmetggg/luck-spark-l-100m-base

sourceHugging Facemitupdated 1mo agoView on Hugging Face
1likes167downloads
Model Card

Dr. Zeon

πŸ›οΈ THE ARCHITECT v0.1

⚠️ Important Notice: Running the Model Locally (Ollama / LM Studio)

Why isn't this model supported in Ollama or LM Studio?

Unlike standard models (such as Llama, Mistral, or Qwen), The Architect is built on a completely custom, from-scratch PyTorch architecture. It features experimental mathematical layers that do not exist in standard Transformers, specifically:

Holographic State Memory (HSM) Neuro-Symbolic Gating (NSRG)

Because these custom operations are not part of the standard Transformer vocabulary, C++ based inference engines (like llama.cpp, which powers Ollama and LM Studio) cannot natively understand or execute them. Converting this model to GGUF format for Ollama would require writing custom C++ kernels for the HSM and NSRG layers, which is a complex engineering task planned for the future roadmap.

How can you test and use this model?

To ensure everyone can easily run and test this model locally without dealing with complex code, we provide a one-click Python Web UI. It creates a ChatGPT-like interface right in your browser.

Download the app.py and run.bat (Windows) or run.sh (Linux/Mac) scripts provided in this repository. Ensure you have Python installed on your system. Double-click the run.bat file. It will automatically install the required libraries (torch, gradio, tokenizers) and launch a local web server. Your browser will automatically open a clean, interactive UI where you can chat with the model immediately.

Like this Terminal:

@user ξ‚° cd Luck-spark-100m-base

~/Luck-spark-100m-base ξ‚° @user ξ‚° python3 app.py

Model indiriliyor ve yΓΌkleniyor, lΓΌtfen bekleyin... Warning: You are sending unauthenticated requests to the HF Hub. Please set a HF_TOKEN to enable higher rate limits and faster downloads. Model hazΔ±r!

  • β€”Running on local URL: http://1xx.x....
  • β€”To create a public link, set share=True in launch().

No C++ compilation or terminal knowledge required!

A Boutique, From-Scratch Turkish Language Model

THE ARCHITECT is an independently developed, approximately 90M-parameter experimental language model designed and trained entirely from scratch with PyTorch.

The project explores a simple but ambitious research question:

How much language modeling capability can be obtained from a relatively small model through architectural experimentation, aggressive training, and carefully selected Turkish data?

Rather than attempting to compete directly with billion-parameter commercial or open-weight foundation models, THE ARCHITECT is intended as a research-oriented boutique language model: compact, experimental, transparent, and built to investigate alternative architectural ideas.


🧭 Project Philosophy

Modern language models increasingly rely on extremely large parameter counts and enormous computational budgets.

THE ARCHITECT takes a different approach.

The project investigates whether a comparatively small model can obtain useful language representations through:

  • β€”substantial pre-training relative to its parameter count,
  • β€”a Turkish-focused corpus,
  • β€”a custom tokenizer,
  • β€”architectural experimentation,
  • β€”parameter sharing,
  • β€”and experimental memory/gating mechanisms.

This project should not be interpreted as evidence that small models universally outperform large models. Instead, the goal is to investigate the efficiency frontier of language modeling at a small scale.

The model is therefore best understood as an independent research experiment, rather than a commercial competitor to systems such as GPT-class or Llama-class large language models.


🧠 Architecture

THE ARCHITECT is implemented directly in PyTorch rather than being assembled from a standard pretrained Transformer architecture.

The overall structure follows a decoder-only autoregressive language-modeling paradigm, while introducing experimental components inside each block.

High-level block

text
Input Tokens
     β”‚
     β–Ό
Token Embedding
     β”‚
     β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚      ARCHITECT BLOCK        β”‚
β”‚                             β”‚
β”‚  Causal Self-Attention      β”‚
β”‚           β”‚                 β”‚
β”‚       Residual              β”‚
β”‚           β”‚                 β”‚
β”‚       LayerNorm             β”‚
β”‚           β”‚                 β”‚
β”‚         SwiGLU              β”‚
β”‚           β”‚                 β”‚
β”‚       Residual              β”‚
β”‚           β”‚                 β”‚
β”‚       HSM + NSRG            β”‚
β”‚           β”‚                 β”‚
β”‚       LayerNorm             β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
     β”‚
     β–Ό
   Γ— 8 Layers
     β”‚
     β–Ό
Final LayerNorm
     β”‚
     β–Ό
Weight-Tied LM Head
     β”‚
     β–Ό
Token Logits

πŸ”¬ Core Components

1. Causal Multi-Head Self-Attention

THE ARCHITECT uses causal multi-head self-attention.

A triangular causal mask prevents a token from attending to future tokens during autoregressive training.

Formally, positions satisfy:

[ M_{ij} = \begin{cases} 0 & j \leq i \ -\infty & j > i \end{cases} ]

This ensures that prediction at position i cannot directly access tokens occurring after position i.

Configuration

  • β€”16 attention heads
  • β€”64 dimensions per head
  • β€”768-dimensional hidden representation
  • β€”128-token context

2. SwiGLU Feed-Forward Network

The standard ReLU-style feed-forward layer is replaced by SwiGLU.

The implementation uses three linear projections:

[ \text{SwiGLU}(x) ================

W2 \left( \text{SiLU}(W1x) \odot W_3x \right) ]

The intermediate dimension is:

text
2048

SwiGLU-style feed-forward networks are widely used in modern language-model architectures and provide an efficient nonlinear transformation.


🧬 3. Holographic State Memory (HSM)

Holographic State Memory (HSM) is one of the experimental components of THE ARCHITECT.

HSM attempts to introduce a learned state representation that interacts with the current hidden representation.

Conceptually:

text
Current Representation
        β”‚
        β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
        β”‚              β”‚
        β–Ό              β–Ό
      Current       Learned
      State          State
        β”‚              β”‚
        β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜
               β–Ό
          State Binder
               β”‚
               β–Ό
        New Representation

The current implementation should be interpreted carefully.

Despite its name, HSM does not yet constitute a fully recurrent sequence-level memory mechanism. The current implementation behaves more like an experimental dynamic state/bias transformation inside each Architect block.

Layer normalization is used to stabilize its interaction with the main representation.

This distinction is intentional: the project documents what the mechanism currently does, rather than claiming capabilities that have not yet been demonstrated.


🧩 4. Neuro-Symbolic Gating (NSRG)

Neuro-Symbolic Gating (NSRG) is an experimental gating mechanism designed around four learned information-handling operations:

GateConcept
PreservePreserve existing information
EraseSuppress existing information
BindIncorporate new information
ContradictionSuppress contradictory information

The mechanism produces four normalized gate values through a softmax operation.

Conceptually:

text
                  Hidden State
                       β”‚
                       β–Ό
                  Gate Network
                       β”‚
                 Softmax (4)
                       β”‚
        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
        β–Ό              β–Ό              β–Ό
     Preserve         Erase          Bind
                       β”‚
                       β–Ό
                 Contradiction
                       β”‚
                       β–Ό
                State Update

NSRG is experimental and should not be interpreted as a formally verified symbolic reasoning system.

The terminology describes the intended information-routing behavior of the mechanism, not a claim that the model possesses human-like symbolic reasoning.


πŸ”— Weight Tying

THE ARCHITECT shares the weights of:

text
Token Embedding
        ↕
LM Head

This reduces parameter redundancy and improves parameter efficiency.

The embedding matrix is therefore reused when projecting hidden representations back into vocabulary logits.


πŸ“ Model Configuration

PropertyValue
Model nameTHE ARCHITECT v0.1
Model typeDecoder-only autoregressive LM
Parameters~90.72M
Vocabulary32,000
Hidden dimension768
Layers8
Attention heads16
Head dimension64
FFN intermediate dimension2,048
Context length128 tokens
TokenizerCustom BPE
FrameworkPyTorch
Training precisionMixed Precision / AMP
Weight tyingYes
Positional encodingNot currently implemented
KV CacheNot currently implemented

πŸ—£οΈ Training Data

THE ARCHITECT was designed primarily around Turkish-language modeling.

The training corpus contains approximately:

  • β€”~850 MB of text
  • β€”~200–250M tokens
  • β€”700K+ Turkish Wikipedia articles after filtering
  • β€”conversational data from HuggingFaceH4/no_robots
  • β€”Turkish instruction-oriented data

The corpus combines informational, conversational, and instruction-style text.

However, the current model is a base/pretrained language model, not an instruction-tuned assistant.


πŸ”€ Tokenization

THE ARCHITECT uses a custom 32,000-token BPE tokenizer trained with the Hugging Face tokenizers library.

A TemplateProcessing post-processor was incorporated to improve handling of tokenization boundaries and special-token formatting.

The tokenizer was developed specifically for the project's Turkish-focused corpus rather than adopting the tokenizer of an existing large language model.


βš™οΈ Pre-Training

Training was performed using Kaggle GPU infrastructure, primarily Tesla T4 GPUs.

Optimization

ParameterConfiguration
OptimizerAdamW
β₁0.9
Ξ²β‚‚0.95
Weight decay0.1
Initial learning rate3e-4
Warmup500 steps
SchedulerCosine decay
Batch size16
Sequence length128
PrecisionPyTorch AMP
Gradient clippingEnabled

The training system uses mixed precision through PyTorch AMP to reduce memory consumption and improve throughput.


πŸ“ˆ Training Progress

The initial training objective consisted of approximately 570,000 steps, corresponding to one planned epoch over the prepared training configuration.

During training, the observed loss decreased substantially from its initial values.

Approximate observed trajectory:

text
Initial loss
     β”‚
     β”‚  ~11.3
     β”‚
     β–Ό
   ~7–8
     β”‚
     β–Ό
   ~6
     β”‚
     β–Ό
  ~4.5–5.0

At the time of this model-card revision, more than 420,000 training steps had been completed.

Important: Training loss alone is not sufficient to establish model quality. A proper evaluation suite and held-out validation set are required before making quantitative claims about linguistic performance or reasoning capability.

πŸ’Ύ Checkpoint & MLOps System

The training pipeline was designed to survive temporary GPU environments such as Kaggle sessions.

Every 10,000 training steps, the system creates a checkpoint containing model and training state.

Conceptually:

text
Training
   β”‚
   β”œβ”€β”€ Step 10,000 ──► Checkpoint
   β”œβ”€β”€ Step 20,000 ──► Checkpoint
   β”œβ”€β”€ Step 30,000 ──► Checkpoint
   β”‚
   └── ...

Checkpoints contain:

  • β€”model state_dict
  • β€”optimizer state
  • β€”scheduler state
  • β€”global training step
  • β€”associated tokenizer/configuration information where applicable

The checkpoint is automatically uploaded to the Hugging Face Hub.

This allows training to resume after:

  • β€”Kaggle session termination
  • β€”GPU quota exhaustion
  • β€”runtime crashes
  • β€”manual interruption
  • β€”environment resets

The intended workflow is:

text
Kaggle
  β”‚
  β–Ό
Train
  β”‚
  β–Ό
Checkpoint
  β”‚
  β–Ό
Hugging Face Hub
  β”‚
  β–Ό
New Kaggle Session
  β”‚
  β–Ό
Download checkpoint
  β”‚
  β–Ό
Restore model + optimizer + scheduler
  β”‚
  β–Ό
Continue training

πŸ€— Hugging Face Integration

The project uses the Hugging Face Hub as both:

  1. 1.a model distribution platform
  2. 2.a remote checkpoint storage mechanism

Training checkpoints are uploaded automatically during training.

After training, the model is additionally converted into a standard Hugging Face-compatible distribution containing the required configuration, model implementation and serialized weights.

The long-term goal is to make THE ARCHITECT usable through standard Hugging Face tooling rather than requiring the original training notebook.


πŸ§ͺ Current Capabilities

THE ARCHITECT is currently a base language model.

It can perform autoregressive text continuation based on patterns learned during pre-training.

The model has demonstrated learning of Turkish linguistic patterns during training.

However, it should not currently be treated as a general-purpose conversational assistant.

For example, a prompt such as:

text
Türkiye'nin başkenti

may cause the model to continue the text in an encyclopedic or corpus-like style rather than responding conversationally.

This is expected behavior for a base model.


⚠️ Known Limitations

This section is intentionally explicit.

1. Base Model, Not a Chat Model

THE ARCHITECT has not yet undergone a dedicated instruction-tuning or preference-optimization stage.

It should therefore not be expected to behave like ChatGPT or other instruction-following assistants.

Planned:

text
Pretraining
     ↓
SFT
     ↓
Instruction-following model

2. No Positional Encoding

The current architecture does not yet implement RoPE or another explicit positional embedding mechanism.

This is a significant architectural limitation.

Positional information is an important component of Transformer language models, and its absence may limit sequence modeling capability.

Adding a positional mechanism is therefore a major item on the roadmap.


3. Short Context

The current context length is:

text
128 tokens

This is extremely short compared with modern language models.

Long documents, conversations, and multi-paragraph reasoning cannot currently be represented effectively within a single context window.


4. No KV Cache

Inference currently recomputes attention over the sequence for each generated token.

A KV cache has not yet been implemented.

Consequently, autoregressive generation is substantially less efficient than it could be.


5. Experimental HSM

The name "Holographic State Memory" should not be interpreted as evidence of a sophisticated long-term memory system.

The current mechanism does not yet provide a fully persistent sequence-level memory.

It is an experimental architectural component whose usefulness requires further controlled evaluation.


6. Experimental NSRG

NSRG is an architectural hypothesis rather than a proven neuro-symbolic reasoning system.

The four gates are learned neural operations.

The terms:

  • β€”Preserve
  • β€”Erase
  • β€”Bind
  • β€”Contradiction

describe the intended information-routing semantics.

They do not imply formal symbolic reasoning, logical theorem proving, or guaranteed contradiction detection.


7. No Comprehensive Benchmark Yet

The project currently does not provide a comprehensive benchmark suite comparing THE ARCHITECT against established Turkish language models.

Therefore, claims about:

  • β€”intelligence,
  • β€”reasoning,
  • β€”factual knowledge,
  • β€”Turkish superiority,
  • β€”parameter efficiency,
  • β€”or general language-model performance

should be considered research hypotheses rather than established results.

Future evaluations will address this limitation.


🧭 Roadmap

Phase 1 β€” Pretraining

  • β€”[x] Custom tokenizer
  • β€”[x] From-scratch model implementation
  • β€”[x] Causal attention
  • β€”[x] SwiGLU
  • β€”[x] HSM
  • β€”[x] NSRG
  • β€”[x] Weight tying
  • β€”[x] Mixed precision training
  • β€”[x] Automated checkpointing
  • β€”[x] Hugging Face checkpoint integration
  • β€”[ ] Complete ~570K-step training run

Phase 2 β€” Architectural Improvements

  • β€”[ ] Add RoPE
  • β€”[ ] Evaluate alternative positional representations
  • β€”[ ] Improve HSM state propagation
  • β€”[ ] Further stabilize NSRG
  • β€”[ ] Investigate sequence-level memory
  • β€”[ ] Implement KV cache
  • β€”[ ] Optimize inference

Phase 3 β€” Instruction Tuning

After completion of base-model pretraining:

text
THE ARCHITECT Base
        β”‚
        β–Ό
Turkish Instruction Dataset
        β”‚
        β–Ό
Supervised Fine-Tuning
        β”‚
        β–Ό
THE ARCHITECT Instruct

The goal is to transform the base language model into a model capable of following natural-language instructions.


Phase 4 β€” Evaluation

A dedicated evaluation suite is planned, including:

  • β€”Turkish language understanding
  • β€”Turkish text generation
  • β€”reading comprehension
  • β€”instruction following
  • β€”factual knowledge
  • β€”basic reasoning
  • β€”perplexity
  • β€”held-out validation loss
  • β€”comparison with similarly sized Turkish/open models

A key goal is to measure whether the architectural experiments provide measurable benefits rather than relying solely on qualitative impressions.


πŸ§ͺ Research Questions

THE ARCHITECT is ultimately an investigation into several questions:

Can a small model learn substantial Turkish linguistic structure?

Can aggressive training compensate for some of the limitations imposed by a small parameter budget?

Can experimental state mechanisms improve representation quality?

Can information-routing gates provide useful behavior without dramatically increasing parameter count?

How much architectural experimentation is worthwhile at the ~100M parameter scale?

These questions remain open.

The project is designed to produce empirical evidence rather than assume that the proposed mechanisms work simply because they sound theoretically promising.


πŸ“Š Evaluation Philosophy

THE ARCHITECT will prioritize measured results over architectural claims.

Future model releases should ideally report:

MetricPurpose
Validation lossGeneralization
PerplexityLanguage-model quality
Turkish benchmarksLanguage understanding
Generation samplesQualitative behavior
Instruction benchmarksFollowing instructions
Inference speedPractical usability
Memory usageDeployment efficiency
Parameter countModel efficiency

The objective is not merely to build an unusual architecture, but to determine whether the unusual components provide measurable value.


πŸ—οΈ Why "THE ARCHITECT"?

The name reflects the central idea behind the project:

Intelligence is not only a question of how much material is used, but also how that material is organized.

The project therefore treats model architecture as an experimental object rather than assuming that scaling parameters is always the only meaningful direction.

THE ARCHITECT is an attempt to explore that space at a scale accessible to an independent researcher.


πŸ“œ Project Status

Status: Experimental / Research

Version: v0.1 β€” Base Model

Training: In progress

Primary language: Turkish

Model size: ~90M parameters

Instruction tuning: Not yet completed

Production readiness: ❌ No

Research/experimentation: βœ… Yes


βš–οΈ Intended Use

THE ARCHITECT is intended for:

  • β€”educational research
  • β€”language-model experimentation
  • β€”Turkish NLP research
  • β€”architecture experimentation
  • β€”small-model research
  • β€”reproducibility experiments
  • β€”Hugging Face ecosystem experimentation

It is not currently recommended for:

  • β€”production conversational AI
  • β€”high-stakes decision making
  • β€”factual information retrieval without verification
  • β€”medical or legal applications
  • β€”autonomous systems
  • β€”safety-critical applications

πŸ§‘β€πŸ”¬ Development

THE ARCHITECT is an independently developed project.

It is intentionally developed without the infrastructure or computational resources of a large AI organization.

The project therefore emphasizes:

  • β€”transparency,
  • β€”reproducibility,
  • β€”experimentation,
  • β€”documenting failures,
  • β€”and distinguishing hypotheses from demonstrated results.

Architectural components that do not work as expected are considered part of the research process rather than hidden from the model documentation.


πŸ™ Acknowledgements

The project makes use of the broader open-source machine-learning ecosystem, including:

  • β€”PyTorch
  • β€”Hugging Face Hub
  • β€”Hugging Face Tokenizers
  • β€”Kaggle GPU infrastructure
  • β€”publicly available Turkish-language datasets
  • β€”HuggingFaceH4/no_robots

This project would not be practical without the open-source ecosystem surrounding modern machine learning.


πŸ“š Citation

If you use THE ARCHITECT in research or experimentation, please cite the project as:

bibtex
@misc{the_architect_2026,
  title        = {THE ARCHITECT v0.1: A Boutique From-Scratch Turkish Language Model},
  author       = {Independent AI Researcher},
  year         = {2026},
  publisher    = {Hugging Face},
  note         = {Experimental 90M-parameter Turkish language model}
}

⚠️ Final Note

THE ARCHITECT is deliberately presented as an experiment, not a finished claim about the future of language modeling.

A 90M-parameter model is not expected to match the capabilities of modern multi-billion-parameter foundation models.

The interesting question is narrower:

How far can a carefully designed, aggressively trained, Turkish-focused small model be pushedβ€”and which architectural ideas actually help?

That question is what THE ARCHITECT is being built to investigate.

The experiment is still running.