CetinLM-1B Base

A from-scratch language-model research platform.
Built to study how far disciplined architecture, data, systems engineering, diagnostics and post-training can push a model before scale becomes the default answer.

CetinLM-1B is not the final product. It is the first instrument in the laboratory.

Phase I base pretraining is complete. Weights are not released yet, hosted inference is disabled, and no claim is made that the frozen Phase-I checkpoint is an instruction-tuned assistant.

Research Thesis

Most people see:

1B parameters

We see:

a controlled research scale
│
├─ small enough to inspect deeply
├─ large enough for real LM behavior to emerge
├─ cheap enough to run repeated systems experiments
└─ structured enough to expose what actually improves learning

The objective is not:

“Can we finish a 1B model?”

The objective is:

“Can we build a repeatable methodology for creating better language models from first principles — and then scale the methodology?”

CetinLM-1B is the test bench for that question.

Phase-I Final Snapshot

Phase-I complete: Step 122,071 · 1,000,005,632 processed tokens · documentation updated 2026-09-01


Model	CetinLM-1B Base
Parameters	1,048,780,544
Final training step	122,071
Processed tokens	1,000,005,632
Phase-I token target	1,000,000,000 tokens
Progress	100%
Best checkpoint	Step 122,000
Best trainer validation loss	3.380473
Standalone reevaluation loss	3.380097
Standalone reevaluation perplexity	29.374
Final observed training loss	3.3256
Training hardware	1× NVIDIA RTX 4070 Ti SUPER 16 GB
Training precision	BF16
Observed steady-state throughput	~5.6K tok/s
Phase-I training sequence length	256
Configured maximum sequence length	4,096

Phase-I base-pretraining progress

0M       200M       400M       600M       800M       1B
│----------│----------│----------│----------│----------│
██████████████████████████████████████████████████████
                         1.000B / 1B  ✓

Phase I is a completed controlled pretraining run, not a claim that CetinLM-1B is a finished assistant. The frozen base checkpoint now serves as the baseline for continued-pretraining, context, post-training and inference research.

Frozen Phase-I checkpoint identifiers

Artifact	Step	SHA256
Best validation checkpoint	122,000	`83E4EA87674F27EF2235AFE891537F67912C0B299BBC6F330980DD44F454073B`
Last Phase-I checkpoint	122,071	`E432BF66A7E635EBEF0EA141E63C28D4C4A3705446B8DF5B9BB2F598FABA8923`

The best-validation checkpoint remains the preferred Phase-I research baseline; the last checkpoint is retained for exact run completion provenance.

What Is Being Built

CetinLM is not a wrapper around an existing pretrained model.

The research stack is being developed as one connected system:

┌───────────────────────────────────────────────────────┐
│                     CETINLM STACK                     │
├───────────────────────────────────────────────────────┤
│                                                       │
│  Data → Tokenizer → Corpus Builder → Binary Shards   │
│    ↓                                                  │
│  Decoder-only Transformer                            │
│    ↓                                                  │
│  GQA + RoPE + SwiGLU                                 │
│    ↓                                                  │
│  BF16 Training + AdamW8bit                           │
│    ↓                                                  │
│  Gradient Checkpointing + Token-Budgeted Updates     │
│    ↓                                                  │
│  Validation + Scientific Diagnostics                 │
│    ↓                                                  │
│  Kernel Profiling + Controlled A/B Tests             │
│    ↓                                                  │
│  Continued Pretraining                               │
│    ↓                                                  │
│  Dynamic Context → SFT → Chat → Reasoning → Code     │
│    ↓                                                  │
│  KV Cache + Runtime + Serving                        │
│                                                       │
└───────────────────────────────────────────────────────┘

The thesis is that model quality is not produced by a single knob.

It emerges from the interaction between:

architecture,
tokenizer design,
corpus quality,
document boundaries,
language mixture,
optimization,
batch geometry,
memory strategy,
attention kernels,
evaluation methodology,
context training,
post-training,
decoding,
and inference runtime.

CetinLM treats those components as one engineering problem.

Model Architecture

CetinLM-1B is a decoder-only causal Transformer trained from scratch.

Component	Configuration
Parameters	1,048,780,544
Vocabulary size	65,536
Hidden size	1,792
Transformer layers	20
Query heads	28
KV heads	7
Attention	Grouped-Query Attention (GQA)
Head dimension	64
MLP intermediate size	7,168
Position encoding	Rotary Position Embeddings (RoPE)
RoPE theta	10,000
Configured max sequence length	4,096
Phase-I training sequence length	256
Dropout	0.0
Bias	False
Input/output embeddings	Tied
Objective	Causal next-token prediction

Architecture sketch

tokens
  │
  ▼
┌─────────────────────┐
│ Token Embedding     │  vocab 65,536 → hidden 1,792
└──────────┬──────────┘
           │
           ▼
┌──────────────────────────────────────────────┐
│              × 20 Transformer Blocks         │
│                                              │
│  RMS/Pre-Norm                                │
│      ↓                                       │
│  GQA Attention                               │
│  28 Q heads / 7 KV heads / RoPE             │
│      ↓                                       │
│  Residual                                    │
│      ↓                                       │
│  RMS/Pre-Norm                                │
│      ↓                                       │
│  SwiGLU MLP                                  │
│  1,792 → 7,168 → 1,792                      │
│      ↓                                       │
│  Residual                                    │
└───────────────────────┬──────────────────────┘
                        │
                        ▼
                tied LM head
                        │
                        ▼
                next-token logits

Context: Configured Is Not the Same as Trained

The architecture is configured for sequences up to 4,096 tokens.

Phase I was intentionally trained at 256 tokens.

We do not claim 4,096-token context capability merely because the configuration allows it.

configured capacity ≠ trained capability

Long-context behavior was not trained in Phase I and will be trained and evaluated explicitly during continued pretraining.

The planned continued-pretraining system will use document-length-aware buckets rather than forcing every document through the largest context window.

Tokenizer and Language Coverage

CetinLM uses a custom 65,536-token multilingual tokenizer.

Current language coverage includes:

en, tr, de, fr, es, pt, it, nl, pl, ru, uk, ar, fa, hi, bn, ur, id, vi, th, zh, ja, ko

English and Turkish received elevated weighting in Phase I and remain first-class languages in continued-pretraining data design.

Special tokens

Token	ID	Role
`<pad>`	0	Padding
`<unk>`	1	Unknown token
`<bos>`	2	Beginning of sequence/document
`<eos>`	3	End of sequence/document

Language inclusion does not imply equal quality across every listed language. Language-specific evaluation will expand as the research progresses.

Training System

The completed Phase-I run was optimized for a single 16 GB GPU while preserving the intended optimization geometry.

Stable configuration

Setting	Value
Micro-batch size	8
Gradient accumulation	4
Sequence length	256
Effective tokens / optimizer step	8,192
Optimizer	AdamW8bit
Peak learning rate	2e-4
Minimum learning rate	2e-5
Schedule	Warmup + cosine decay
Warmup	2,000 optimizer steps
Adam betas	0.9 / 0.95
Weight decay	0.1
Gradient clipping	1.0
Precision	BF16
Activation memory	Per-block gradient checkpointing
DataLoader workers	0
Pinned memory	Enabled

Effective optimizer step

8 micro-batch
× 4 gradient accumulation
× 256 sequence length
= 8,192 tokens / optimizer step

Observed steady-state throughput is approximately:

~5,600 tokens / second

on the Phase-I single-GPU system.

Systems Optimization: Preserve the Math, Improve the Machine

The early training setup used the same effective token budget with a much smaller micro-batch and deeper accumulation.

Controlled batch/accumulation experiments preserved:

8,192 tokens / optimizer step

while changing how those tokens were presented to the GPU.

Approximate progression:

Geometry	Effective tokens/update	Observed training throughput
1 × 32 × 256	8,192	~1.9K–2.2K tok/s
2 × 16 × 256	8,192	~3.7K–3.9K tok/s
4 × 8 × 256	8,192	~4.7K–5.1K tok/s
8 × 4 × 256	8,192	~5.4K–5.6K tok/s
16 × 2 × 256	8,192	~4.3K tok/s / poor VRAM behavior

The stable winner is:

batch 8 × grad-accum 4 × seq 256

This produced roughly 2.7×–2.8× the throughput of the original geometry without changing the effective token count per optimizer update.

Engineering rule

Change the implementation only when the measurement says it wins.

Kernel-Level Profiling

The real training stack was profiled at operator level.

Representative hotspots included:

Operation / region	Observation
`aten::mm`	Dominant CUDA compute
checkpointed forward	Significant recompute cost
`aten::copy_`	Meaningful cumulative cost
pointwise `mul` / `add_`	High call volume
`aten::bmm`	Attention-related cost
AdamW8bit step	Relatively small fraction
gradient clipping	Small fraction
DataLoader	Negligible bottleneck

The profiler suggested attention deserved investigation.

That hypothesis was tested rather than assumed.

SDPA Backend Study

Environment at the time of the controlled study:

OS       : Windows
PyTorch  : 2.11.0 + CUDA 12.8
GPU      : NVIDIA RTX 4070 Ti SUPER
Precision: BF16
Shape    : batch 8 / seq 256 / 28 Q heads / 7 KV heads

Backend diagnostic

Native Flash SDPA was not built in the tested PyTorch/Windows environment.

For the actual native-GQA shape:

Q : [8, 28, 256, 64]
K : [8,  7, 256, 64]
V : [8,  7, 256, 64]

the available candidates were benchmarked on real training work.

A/B results

Candidate	Relative result	Decision
Math SDPA + native GQA	1.00×	KEEP
cuDNN SDPA + native GQA	~0.315×	Reject
Math SDPA + BF16 reduction switch	~0.552×	Reject
Efficient SDPA + explicit KV expansion	~0.518×	Reject
Flash SDPA	unavailable	Not testable

In other words:

the suspicious fallback
        ↓
was benchmarked
        ↓
and turned out to be the fastest available backend

The result was not glamorous.

It was useful.

No SDPA backend change was merged.

Scientific Diagnostics

Generation samples alone are a poor instrument for understanding a raw base model.

CetinLM tracks fixed next-token semantic probes across checkpoints and measures where the expected target appears in the full vocabulary distribution.

This lets us ask:

Is the model's internal probability mass moving toward the right semantic target?

Earlier checkpoint → Step 70K

Probe	Earlier rank	Step 70K	Movement
`The capital of France is` → `Paris`	~211	2	↑ 209 places
`Paris is the capital of` → `France`	2	2	stable
`The opposite of hot is` → `cold`	13	3	↑ 10 places
`Water freezes at` → `0`	17	13	↑ 4
`2 + 2 =` → `4`	5	4	↑ 1
`Türkiye'nin başkenti` → `Ankara`	6	1	↑ 5 places
`Ankara, Türkiye'nin` → `başkenti`	~10	36	regression on this phrasing

Aggregate target placement

Earlier checkpoint                 Step 70K

Top-1   0/7   ░░░░░░░              1/7   █░░░░░░
Top-5   2/7   ██░░░░░              5/7   █████░░
Top-20  6/7   ██████░              6/7   ██████░

The notable signal is not that Top-20 increased.

It did not.

The notable signal is that several known targets moved from weak visibility into the model's top few choices.

Example: France → Paris

Prompt: The capital of France is

Earlier target rank : ~211
Step 70K target rank: 2
Step 70K probability: ~5.5%

Example: Türkiye → Ankara

Prompt: Türkiye'nin başkenti

Earlier target rank : 6
Step 70K target rank: 1
Step 70K probability: ~9.7%

These observations do not prove general intelligence, reasoning ability, or benchmark leadership.

They do show that the learned distribution is becoming measurably sharper around several semantic relations.

Phase-I final diagnostic snapshot

Near the end of Phase I (999.424M processed tokens), the same small semantic probe set remained useful as a distribution-level sanity check:

Probe	Final target rank
`The capital of France is` → `Paris`	3
`Paris is the capital of` → `France`	2
`The opposite of hot is` → `cold`	2
`Water freezes at` → `0`	Top-20
`2 + 2 =` → `4`	3
`Türkiye'nin başkenti` → `Ankara`	1
`Ankara, Türkiye'nin` → `başkenti`	18

Aggregate placement:

Top-1   1 / 7
Top-5   5 / 7
Top-20  7 / 7

The final probe state is deliberately reported with the same caution as the earlier measurements: seven handcrafted next-token probes are not a benchmark suite. They are a compact instrument for detecting whether known semantic targets remain visible and whether training produces obvious regressions.

Validation Trajectory

Recent validation checkpoints:

Step	Tokens	Val Loss	PPL
58K	475.1M	3.753456	42.668
59K	483.3M	3.735000	41.888
60K	491.5M	3.711722	40.924
63K	516.1M	3.693981	40.205
67K	548.9M	3.677402	39.544
69K	565.2M	3.667538	39.155
70K	573.4M	3.650751	38.504
71K	581.6M	3.639504	38.073
72K	589.8M	3.626853	37.594
73K	598.0M	3.622009	37.413
80K	~655.4M	3.572560	35.608
122K	999.424M	3.380473	29.385

Visual trend

Val Loss
3.76 ┤●
3.70 ┤       ●
3.64 ┤              ●
3.58 ┤                    ●
3.52 ┤
3.46 ┤
3.40 ┤                                      ●
3.38 ┤                                        ●
     └────────────────────────────────────────────
      58K        70K      80K                 122K

Phase I ended with a substantially lower validation loss than the mid-run snapshots. Relative to the recorded 80K checkpoint, standalone perplexity fell from 35.608 to 29.374, a reduction of roughly 17.5%.

Base Benchmark v4

A fixed Base Benchmark is retained for historical comparison.

At step 70K:

Metric	Result
Validation loss	3.651050
Perplexity	38.515
English cloze	1 / 10
Turkish cloze	3 / 10

Compared with the previous recorded benchmark:

Val Loss Δ : -0.264498
PPL Δ      : -11.661

The tiny exact-match cloze sets are intentionally treated as noisy indicators rather than definitive capability measurements.

A 10-item exact-match score can remain flat while the full next-token distribution improves substantially.

That is why the project uses both:

historical benchmark
+
scientific target-rank diagnostics

Generation Behavior: Knowledge Emerging Before Assistant Behavior

CetinLM-1B is currently a raw next-token base model.

It has not yet been trained to interpret every question as an instruction.

Example:

Prompt:
The capital of France is

Greedy continuation:
The capital of France is the city of Paris.
The city of Paris is the city of Paris...

The interesting part is:

Paris is now retrieved.

The unfinished part is:

sequence-level behavior is still repetitive.

Other observed raw-base behaviors include:

local phrase loops,
repeating a question instead of answering it,
weak arithmetic,
factual inconsistency in long continuations,
sensitivity to prompt phrasing,
inconsistent stopping behavior under greedy decoding.

These are documented rather than hidden.

They are also separated from the later post-training goals:

base pretraining
      ↓
instruction SFT
      ↓
chat behavior
      ↓
reasoning / code specialization
      ↓
preference & alignment work

SFT is not expected to create missing world knowledge from nothing.

It is expected to shape how already-learned representations are used.

EOS / Document-Boundary Audit

A generation discussion raised a concrete engineering question:

Are document endings actually represented correctly in the binary training corpus?

The trainer reads pre-tokenized .bin shards and slices the stream into fixed-length sequences.

Therefore, the data-preparation pipeline — not the trainer — is responsible for writing correct BOS/EOS boundaries.

Rather than guessing, the full corpus was audited.

Full-corpus results

Metric	Training	Validation
Tokens	1,000,000,000	10,000,000
EOS tokens	1,884,722	18,952
EOS / 1M tokens	1,884.72	1,895.20
Approx. tokens / EOS	530.6	~527.6

Train and validation EOS rates are closely aligned.

Decoded windows confirmed that EOS tokens occur at real document boundaries.

Example pattern:

... end of document.<eos><eos><bos>Beginning of next document...

Technical debt discovered

Many inspected boundaries contain:

<eos><eos><bos>

The preferred future representation is:

<eos><bos>

This redundant second EOS is classified as technical debt, not a critical training failure.

Why the completed Phase-I run was left unchanged:

the semantic document boundary is correct,
EOS is present in both train and validation,
train/validation frequencies align,
validation had continued to improve,
scientific diagnostics had continued to improve,
modifying token shards halfway through v0 would change the data distribution mid-experiment.

The Phase-II corpus builder has since removed the redundant insertion and added explicit automatic boundary checks. Phase-II corpus construction remains under qualification, but pilot audits now enforce the canonical <eos><bos> document transition.

Planned builder invariants

[✓] special token IDs known
[✓] double-EOS count enforced by policy
[✓] EOS/BOS boundary correctness
[✓] whole-document quota accounting
[✓] special-token frequency report
[✓] missing / malformed boundary detection
[→] document-length and distribution diagnostics continue to expand

A Note on EOS Evaluation

A low EOS rank immediately after an unfinished prompt is not sufficient evidence that a model failed to learn stopping behavior.

For example:

The capital of France is

is incomplete.

High EOS probability at that position would not necessarily be desirable.

A better evaluation asks for EOS probability at actual completed boundaries:

The capital of France is Paris.
                                ↑
                          evaluate here

The stronger future method is teacher-forced evaluation on real held-out document-ending positions.

This is an example of the project's broader evaluation rule:

Fix the instrument before fixing the model.

What We Refuse to Hide

CetinLM is being developed as a research and engineering program first.

Public documentation includes:

optimizations that failed,
hypotheses that were rejected,
profiling results,
backend regressions,
generation failures,
diagnostic regressions,
data-pipeline technical debt,
reasons for deliberately making no change.

Example experiment ledger

Experiment	Hypothesis	Result	Action
cuDNN native-GQA SDPA	may outperform Math	~68.5% slower	Rejected
BF16 Math reductions	may improve speed	~44.8% slower	Rejected
Efficient SDPA + expanded KV	may beat native GQA Math	~48.2% slower	Rejected
Larger micro-batch geometry	better GPU utilization	8×4 wins	Kept
EOS boundary audit	possible missing EOS bug	EOS present; duplicate EOS found	Run kept; builder debt logged

Failed experiments are not deleted from the story.

They are part of the method.

Why We Did Not "Fix" the Healthy Phase-I Run

No architecture, optimizer, learning-rate, or attention-backend change was introduced after the 70K health check through the end of Phase I.

No instruction data was mixed into the base run.

No Phase-I binary shard was rewritten.

No decoding workaround was confused with a training improvement.

The evidence said:

validation          → improving
semantic ranks      → improving
throughput          → stable
gradients           → stable
corpus boundaries   → fundamentally intact

So the decision was:

KEEP THE EXPERIMENT STABLE
↓
COMPLETE PHASE I
↓
FREEZE AND EVALUATE

This was intentional.

A research run should not be modified simply because a generation sample looks strange.

Research Milestones

The initial 1B-token Phase I is complete.

CetinLM-1B Base
Phase I: 1.000B processed tokens  ✓
      │
      ▼
freeze + baseline evaluation
      │
      ▼
Phase-II corpus engineering / qualification
      │
      ▼
continued pretraining
      │
      ├── context curriculum
      ├── English / Turkish first-class coverage
      ├── multilingual retention
      ├── retention + factual + repetition gates
      └── controlled milestone evaluations

The model does not restart from random initialization at each milestone.

The frozen Phase-I checkpoint is the baseline; subsequent stages continue from validated checkpoints only when corpus and evaluation gates pass.

Scale remains a controlled variable rather than the experiment itself.

Dynamic-Length Continued Pretraining

The continued-pretraining trainer is planned around document length.

The model should not pay 4,096-token attention cost for a document that contains only 180 useful tokens.

Planned buckets

Natural document length	Training bucket
≤256	256
257–512	512
513–1,024	1,024
1,025–2,048	2,048
2,049–4,096	4,096

Conceptually:

180 tokens  ───────────────▶  256 bucket
430 tokens  ─────────────────────▶  512 bucket
900 tokens  ───────────────────────────▶  1024 bucket
1700 tokens ─────────────────────────────────▶  2048 bucket
3500 tokens ─────────────────────────────────────────▶ 4096 bucket

Planned components:

length bucketing,
EOS-aware sequence packing,
token-budgeted batch sampling,
dynamic micro-batch sizing,
minimal padding,
controlled long-context exposure,
hardware-specific VRAM benchmarking.

Packing example

Instead of:

doc A: 90 tokens  + padding
doc B: 70 tokens  + padding
doc C: 80 tokens  + padding

pack compatible short documents:

doc A <EOS> doc B <EOS> doc C <EOS>

and spend compute on real tokens rather than padding.

The objective is not merely:

max context = 4096

The objective is:

train 4096 capability
without making every sample pay 4096 cost

Post-Training Roadmap

After a sufficiently strong base checkpoint is frozen, planned post-training stages include:

Phase	Objective
General Instruction SFT	instruction following
Chat SFT	multi-turn conversational behavior
Turkish / English SFT	stronger bilingual interaction quality
Math / Reasoning	structured problem solving
Code	programming capability
Identity / Project Knowledge	CetinLM-specific behavior
Preference / Alignment	response quality and behavioral shaping
Decoding Evaluation	stopping, repetition, calibration

The exact ordering and datasets will remain evidence-driven.

Inference Engineering Roadmap

The current research runtime prioritizes correctness over serving optimization.

Major planned runtime work includes:

current autoregressive runtime
          │
          ▼
        KV cache
          │
          ▼
faster token-by-token decode
          │
          ▼
memory / kernel profiling
          │
          ▼
quantization research
          │
          ▼
API + production serving

Planned areas:

KV-cache implementation,
faster autoregressive decoding,
runtime memory optimization,
serving profiling,
deployment-oriented quantization,
API/runtime integration,
longer-context inference validation.

Intended Use

The current repository is intended primarily for:

language-model research,
training-systems research,
small-model efficiency research,
multilingual base-model experimentation,
reproducible engineering documentation,
continued-pretraining research,
future post-training experiments.

When weights are released, intended-use guidance will be expanded for the exact published checkpoint.

Current Limitations

The frozen Phase-I base checkpoint:

is not instruction tuned,
is not a finished chat assistant,
was trained on 256-token sequences during Phase I,
can produce repetitive greedy generations,
can hallucinate facts,
has weak arithmetic/reasoning relative to planned stages,
can behave inconsistently across languages,
has not yet undergone comprehensive safety/alignment post-training,
should not be used for high-stakes decisions.

No claim is made that a 1B model replaces frontier-scale systems.

The research question is about:

capability extracted per parameter, per token, and per unit of compute

and whether the resulting methodology remains valuable when scaled.

Release Status

Weights

Not released yet.

Phase I base pretraining is complete. The project is currently qualifying the data and evaluation pipeline for continued pretraining.

Weights will be released only after a defined evaluation and release-readiness pass rather than simply because Phase I reached its token target.

Hosted inference

Disabled for this research-preview repository.

The architecture currently uses a custom PyTorch implementation.

No claim is currently made about drop-in Hugging Face Transformers compatibility or hosted inference-provider support.

License

A model-weight license will be selected deliberately before the first public weight release.

No model-weight license metadata is asserted before that decision.

Research Principles

Measure first.

Change only when the evidence supports it.

The project follows several rules:

Lower validation loss
    ≠ every capability improved

One impressive generation
    ≠ benchmark evidence

Profiler suspicion
    ≠ optimization result

Theoretical speedup
    ≠ measured speedup

Configured context
    ≠ trained context

More parameters
    ≠ replacement for engineering

And the operating loop is simple:

OBSERVE
   ↓
MEASURE
   ↓
FORM A HYPOTHESIS
   ↓
A/B TEST
   ↓
KEEP ONLY WHAT WINS
   ↓
DOCUMENT THE RESULT

The Bigger Experiment

CetinLM-1B is deliberately small enough that the entire system can be interrogated.

The long-term question is larger:

If architecture, tokenizer, corpus construction, training systems, diagnostics, context strategy, post-training and inference are understood and controlled at 1B — how much of that advantage survives when the methodology is scaled?

That is why CetinLM-1B is better described as:

the first research instrument

than:

the final model

The project is not trying to hide scale.

It is trying to understand what deserves to be scaled.

Project Links

Resource	Link
Website	https://cetinlm.meforcetechnology.com
GitHub	https://github.com/xertxetin/CetinLM
Hugging Face	https://huggingface.co/meforce

The GitHub repository contains public engineering and research logs covering:

training optimization,
scientific diagnostics,
kernel profiling,
SDPA backend studies,
EOS/corpus audits,
milestone evaluations,
and continued-pretraining planning.

Citation

If you reference the CetinLM research program or its published engineering results:

@misc{cetinlm2026,
  title        = {CetinLM: From-Scratch Language Model Research Program},
  author       = {CetinLM Research Program, Me Force Technology},
  year         = {2026},
  howpublished = {\url{https://github.com/xertxetin/CetinLM}}
}

Provenance and Transparency

CetinLM is developed independently under Me Force Technology as a globally oriented language-model research program; the project originated in Türkiye and is being documented publicly from its earliest training stages.

Metrics in this card are observations from specific checkpoints and diagnostics from the completed Phase-I research run.

They should not be interpreted as claims of benchmark leadership.

As the research progresses, this card is expected to gain:

release-specific checkpoint bundles,
standardized benchmark suites,
data documentation,
long-context evaluations,
post-training evaluations,
model artifacts,
inference instructions,
release-specific safety notes,
and reproducibility details.

CetinLM-1B is the first instrument in the lab.
The larger project is the methodology behind what comes next.

_{Last documented research snapshot: Phase I complete · Step 122,071 · 1,000,005,632 processed tokens · 2026-09-01}

Downloads last month: -; Downloads are not tracked for this model. How to track