SOILEGPT.CHAT

Distributed AI Edge.
One client — one compute.

Орталық суперкомпьютер арқылы желіге тәуелді сервистің орнына: әр клиенттің өзінде локалды edge-есептеу. Нәтиже: детерминирленген қуат, нөлдік “кезек жұқтыруы”, минималды кідіріс, қауіпсіздік және құнның болжамдылығы.

No shared queues
Deterministic SLA
Local data sovereignty
Linear scale per site

Equivalence headline

~3,170
SOILEGPT.CHAT edge (1×RTX A6000) ≈ 1 central “super-edge” (496×H200)
$15,000
per client edge (hardware unit cost)
7+
clients/H200 where edge ≥ center per-client compute (proxy)
3 months
delivery-to-deployment window for on-prem edge rollout
Proof Pack 3,170 Equivalence Sharing Threshold Queues • Peaks • Network

Interactive calculator

Formulas Cost derivation

Кабельдік модельде бір H200 GPU-ға қанша клиент (k) бір уақытта отырады — соны беріңіз. Біз сол сәттегі “клиентке шаққандағы” қуатпен салыстырамыз.

Given: H200 FP16 Tensor = 1,979 TFLOPS RTX A6000 Tensor = 309.7 TFLOPS Cluster GPUs = 496 × H200 Ratio: a = 309.7 / 1,979 = 0.1565 (H200-equivalent per edge) Center per-client share: q_center = 1 / k Edge ≥ Center (per-client compute proxy) when: 0.1565 ≥ 1/k ⇒ k ≥ 6.39

Architecture comparison

Center → cable → client

PropertyImplication
Shared GPU poolКезек, шектеу, көп-арендалы жоспарлау; бір клиенттің пікі — басқаларына әсер етеді.
Network as part of SLAКідіріс пен тұрақтылық каналға тәуелді; QoS/резерв/маршрутизация міндетті.
Peak coupling“Noisy neighbor”: оқыс жүктемелерде деградация экспоненциалды сезіледі.
Operational stackТарификация/лимит/аудит, қауіпсіздік периметрі, NOC/monitoring, инциденттер.
Peripheral accessVPN/MPLS/edge gateways, identity, session control, encryption, compliance.

SOILEGPT.CHAT: one edge per client

PropertyImplication
Dedicated computeКлиенттің ресурсы тек соған арналған; кезек “жұқпайды”.
Local inferenceКідіріс төмен; интернет нашар болса да функционал сақталады.
Data sovereigntyДерек клиент периметрінен шықпайды; саясат/реттеу тәуекелі азаяды.
Linear scaling+1 клиент = +1 edge. Жоспарлау қарапайым, құны болжамды.
Deployment simplicityОрнату/жаңарту/қызмет көрсету жергілікті; “үлкен орталық” тәуелділігі жоқ.
Бұл салыстырудың өзегі: “клиентке шаққандағы” қамтамасыз ету. Орталықта бұл үлес әрқашан бөлінеді; edge-та ол тұрақты және алдын ала белгілі.

72B Kazakh multilingual LLM

Неге 72B маңызды

72B technical notes

72B — бұл 72 миллиард параметр. Параметр — модельдің “білімі” мен тілдік қабілетін кодтайтын салмақтар. Параметр саны артқан сайын: контекстті ұстау, семантикалық дәлдік, көптілді сәйкестік және домендік күрделілік жақсырақ болады.

Тақырып72B-тің практикалық мәні
КөптілділікҚазақша ↔ орысша ↔ ағылшынша аралас диалогта мағынаны жоғалтпайды; code-switch тұрақтылығы жоғары.
Күрделі тапсырмаларҰзын нұсқаулықтар, көп-қадамды reasoning, құжатпен жұмыс — сапа өседі.
Салалық білімМедицина/заң/өндіріс сияқты домендерде терминологияны сенімдірек ұстайды (дұрыс инференс стегімен).
“Super” әсерПайдаланушыға “ақылдырақ, тыныш, тұрақты” жауап беру — дәл осы масштабта сезіледі.
Model size concept: 72B params ≈ 72,000,000,000 learned weights. Quality drivers: (1) parameter count + (2) training data breadth + (3) inference stack + (4) latency stability. Edge advantage: stability of latency and isolation → perceived quality increases, even at same model.

Economics

Edge cost per client

Formulas

Берілген шарт: 1 edge = $15,000. Айырбас бағамы: 520 ₸ = $1.

$15,000
USD per client
₸7,800,000
KZT per client
KZT conversion: 15,000 USD × 520 = 7,800,000 KZT

What the center must still build

WorkstreamCost / complexity driver
Client access perimeterVPN/MPLS, gateways, IAM, session control, encryption, audit.
Multi-tenant schedulerQuota, fairness, isolation, batching policy, noisy-neighbor mitigation.
SLA engineeringCapacity planning, admission control, peak management, incident response.
Compliance & governanceData flows, retention, logging, legal constraints, change management.
Rollout lead-timeProcurement → integration → testing → onboarding → operations.
Edge-та бұл блоктардың көбі клиенттің өз периметрінде “табиғи түрде” шешіледі: дерек шықпайды, ресурс бөлінбейді, кезек жоқ.

Timeline: 3 months to production

Delivery plan

WeekOutcome
1–2Edge образ/құрастыру, модель стегі, локалды саясат, мониторинг минимум.
3–6Пилот 3–10 клиент: орнату стандарты, қашықтан жаңарту, fallback, периметр тесті.
7–10Масштабтау 10→N: өндірістік логистика, сервис регламенті, SLA “бір клиент — бір edge” қағидасы.
11–12Қорытынды қабылдау: құжаттау, білім базасы, партиялық жеткізу, тұрақты релиз циклі.
Core claim: Edge rollout is bounded by logistics and standardization. Center rollout is bounded by network + multi-tenant orchestration + governance + peak engineering.

Mathematical backbone

One number that matters

Derivation All formulas

“1 супер-edge” ретінде орталық кластерді (496×H200) алсақ, тензорлық FP16 прокси бойынша: 1×H200 ≈ 6.39×RTX A6000, сондықтан 496×H200 ≈ 3,170×A6000.

Definitions: H200_FP16 = 1,979 TFLOPS A6000_Tensor = 309.7 TFLOPS GPU_count = 496 Per-GPU ratio: r = H200_FP16 / A6000_Tensor = 1,979 / 309.7 = 6.39 Cluster equivalence: E = GPU_count × r = 496 × 6.39 = 3,170 (rounded) Per-client compute parity threshold under sharing: Edge_share = 309.7 / 1,979 = 0.1565 H200 Center_share = 1/k H200 Edge ≥ Center ⇔ 0.1565 ≥ 1/k ⇔ k ≥ 6.39
Бұл — “клиентке шаққандағы” есептеу үлесінің дәл логикасы. Ол кезек, пик, жоспарлау және желі әсерін модельдемейді; бірақ дәл осы факторлар орталықта тәуекелді күшейтеді, ал edge-та олар құрылымдық түрде жойылады.
Proof Pack
Барлық формулалар мен қорытындылар бір жерде. Бұл есептер — инженерлік “capacity proxy”: нақты LLM өнімділігі модель/контекст/стекке тәуелді. Бірақ орталықтағы тәуекелдер (кезек, пик, желі, көп-арендалы жоспарлау) дәл осы жерде басталады.
1) Кластер эквиваленті (compute proxy)
H200_FP16 = 1,979 TFLOPS
A6000_Tensor = 309.7 TFLOPS
GPU_count = 496

r = H200_FP16 / A6000_Tensor = 1,979 / 309.7 = 6.39
E = GPU_count × r = 496 × 6.39 = 3,170 (rounded)
2) “Клиентке шаққандағы” үлес (шеринг)
Edge_share = A6000 / H200 = 309.7 / 1,979 = 0.1565 H200
Center_share = 1 / k (k = clients per H200)

Edge ≥ Center ⇔ 0.1565 ≥ 1/k ⇔ k ≥ 6.39
3) Орталықтың бір сәттегі клиент сыйымдылығы
N_center = 496 × k
(бір уақытта белсенді сессиялар саны)
4) Edge бюджет (1 клиент = 1 edge)
N_edge = N_center = 496 × k
Cost_USD = N_edge × 15,000
Cost_KZT = Cost_USD × 520
Queue/peak math intuition (illustrative):

Total latency (center):
  L_total ≈ L_network + L_queue + L_infer

Local edge:
  L_total ≈ L_local_infer  (network is not in the critical path)

Queueing (M/M/1 approximation):
  ρ = utilization (0..1)
  Expected waiting factor grows ~ ρ / (1 - ρ)
  As ρ → 1, waiting → ∞  (superlinear blow-up)

Engineering consequence:
  Center must implement admission control + quotas + batching policy + fairness,
  otherwise p95/p99 latency becomes unpredictable under peaks.

Structural consequence:
  Edge removes shared queue coupling by design.
      
3,170 equivalence derivation
Бұл есеп “бірдей сапа” емес, “бірдей тензорлық есептеу потенциалы” (FP16 proxy). LLM сервингте жад, KV-cache, контекст, ядро оптимизациясы әсер етеді; сондықтан бұл — жоғарғы деңгейдегі салыстыру.
Given:
  H200 FP16 Tensor    = 1,979 TFLOPS
  RTX A6000 Tensor    =   309.7 TFLOPS
  Cluster size        = 496 × H200

Per-GPU ratio:
  r = 1,979 / 309.7 = 6.39  (H200 ≈ 6.39×A6000)

Cluster equivalence:
  E = 496 × 6.39 = 3,169.44  → 3,170 edge units (rounded)

Interpretation:
  1 central “super-edge” (496×H200) ≈ 3,170 distributed edges (1×A6000)
      
Sharing threshold proof
Орталықта бір GPU-ға бірнеше клиент отырады (k). Біз “сол сәттегі клиент үлесін” есептейміз. Бұл — кезек пен желінің әсерін қоспай-ақ, тек бөліну логикасын көрсететін ең таза салыстыру.
Definitions:
  k = concurrent clients per H200

Center per-client compute share:
  q_center = 1 / k    (in units of one H200)

Edge per-client compute share (proxy):
  q_edge = A6000 / H200 = 309.7 / 1,979 = 0.1565 H200

Parity condition:
  q_edge ≥ q_center
  0.1565 ≥ 1/k
  k ≥ 6.39

Meaning:
  If the center runs k ≥ 7 clients per H200 concurrently,
  then 1 local A6000 edge provides ≥ per-client compute proxy vs the center.
      
Cost formulas (USD & KZT)
Берілген шарт: 1 edge = $15,000. Валюта: 520 ₸ = $1. Бұл тек edge hardware; орталық модельде бұдан бөлек периферия мен операциялық шығындар бар.
Unit cost:
  C_edge_USD = 15,000
  FX         = 520 KZT per 1 USD

Per-client:
  C_edge_KZT = 15,000 × 520 = 7,800,000 KZT

To match center concurrency at sharing density k:
  N_center = 496 × k
  N_edge   = N_center

Total hardware budget:
  Budget_USD = N_edge × 15,000
  Budget_KZT = Budget_USD × 520
      
Queues • Peaks • Network: engineering reality
Орталық “кабель арқылы” жеткізілсе, SLA тек GPU-ға емес, бүкіл тізбекке тәуелді: желі, шлюздер, аутентификация, жоспарлау, кезек, admission control, мониторинг, инциденттер.
Noisy neighbor
Бір клиенттің пікі (ұзын контекст, көп сұрау, ауыр batch) басқа клиенттерге кідіріс қосады. Бұл “shared queue coupling” — архитектуралық құбылыс.
Admission control is mandatory
Орталықта әр сессияны қабылдау/қабылдамау саясаты болмаса, p95/p99 latency “ұшады”. Құралдар: quota, rate limit, priority, fairness, queue depth caps.
Network becomes part of inference
L_total ≈ L_network + L_queue + L_infer.
Канал вариациясы → жауап сапасының қабылдануы төмендейді.
Peripheral access stack
VPN/MPLS, gateway, IAM, session control, crypto, audit, logging, compliance — бұл “GPU сатып алудан” бөлек, ұзақ мерзімді инженерлік міндет.
Minimal deterministic claims:

Edge (one client — one compute):
  • No cross-client queue coupling
  • Predictable capacity per site
  • Local data perimeter by default
  • Scale is linear: +1 client → +1 edge

Center (shared pool over cable):
  • Capacity is divided by k (clients per GPU)
  • Queueing makes latency non-linear under peaks
  • Network + governance become SLA components
  • Requires continuous SRE/ops + multi-tenant policy engineering
      
72B multilingual model notes
72B = 72,000,000,000 параметр. Параметр саны — сапаның жалғыз факторы емес, бірақ көптілділік пен күрделі reasoning үшін негізгі масштаб.
What “72B parameters” means:

• A parameter is a learned weight.
• 72B params ≈ 72 billion learned degrees of freedom.
• More parameters generally increase:
    - multilingual alignment
    - instruction following capacity
    - semantic consistency across long contexts
    - robustness under code-switching (қазақша/русский/English)

Why perceived quality depends on architecture:

Quality (user perception) ≈ (model capability) × (latency stability) × (no interruptions)

Center risks:
  - variable latency from queueing + network jitter
  - batching policies that trade latency for throughput

Edge advantage:
  - stable latency profile (dedicated compute)
  - predictable KV-cache budget per client
  - no shared “noisy neighbor” behavior