Какво тежи на GX10: сметката, преди да теглите модела

01Какво ще научиш

• Колко байта заема един параметър във FP16, FP8, FP4 и Q4_K_M — и защо „Q4 = половин байт“ подвежда.
• Как да изчислиш KV кеша от три числа в config.json.
• Колко режийни да заложиш и до колко от 128 GB да планираш.
• Защо MoE моделът иска паметта на всичките си параметри, но върви със скоростта на активните.
• Как да решиш „събира ли се“ с един калкулатор и да не забравиш да измериш.

02Преди да започнеш

• Нужна е само начална аритметика. Python 3 е по желание — за калкулатора в стъпка 5.
• Адрес на картата на модела (Hugging Face): там има общия брой параметри и файл config.json.
• Ориентир за машината — по NVIDIA:

03Стъпки

1. Теглата: параметри × байтове на параметър

   Теглата са основната част. Защо „Q4 = 0,5 байта“ не е точно? Четирибитовите формати пазят и мащабни коефициенти на всеки блок — те добавят бита. Ето реалните стойности:

   Формат	Байта на параметър	Откъде
   FP16 / BF16	2,0	16 бита
   FP8	1,0	8 бита
   NVFP4	0,5625	4 бита + един FP8 мащаб на 16 стойности = 4,5 бита
   MXFP4	0,531	4 бита + 8-битов мащаб на 32 стойности = 4,25 бита
   Q4_K_M (GGUF)	≈ 0,60	измерено: 4,82 и 4,86 бита на параметър по два истински файла

   Общият брой параметри четем от картата на модела (панелът „Safetensors“), а не от името. Резултатът за петте примерни модела — всички числа са изчислени, в GB:

   Модел	Общо параметри	FP16	FP8	~4 бита
   Llama-3.3-70B	70,6 млрд.	141,1	70,6	42,8 (истинският Q4_K_M файл: 42,5)
   Qwen3-30B-A3B (MoE)	30,5 млрд.	61,1	30,5	18,5 (файл: 18,6)
   gpt-oss-120b (MoE)	116,8 млрд.	233,7	116,8	доставя се в MXFP4: 65,2 (файловете на картата)
   Llama-4-Maverick (MoE)	401,6 млрд.	803,2	401,6	243,5
   DeepSeek-V3 (MoE)	684,5 млрд.*	1369	684,5 (доставя се във FP8)	415,0

   * 671 млрд. по картата на модела; файловете преброяват и допълнителен модул. Първо заключение: 70B във FP16 (141 GB) не се събира, във FP8 (70,6 GB) се събира със скромен запас, в Q4_K_M (42,8 GB) — удобно. Пълните Maverick и DeepSeek-V3 не се събират в нито един от форматите.

2. KV кешът: забравяният член

   Докато генерира, моделът помни ключове и стойности за всеки токен в контекста. Защо расте толкова? Пази се за всеки слой и всяка KV-глава, и расте линейно с дължината на контекста.

   формулакопирай

   KV байта = 2 × слоеве × KV-глави × размер_на_глава × токени × байта_на_елемент
              ↑
              ключове + стойности
   
   слоеве             = num_hidden_layers
   KV-глави           = num_key_value_heads
   размер_на_глава    = head_dim
   байта_на_елемент   = 2 за FP16 кеш, 1 за FP8 кеш

   Трите числа са в config.json на всеки модел. Пример за Llama-3.3-70B: 2 × 80 × 8 × 128 × 2 байта = 327 680 байта на токен. Всички числа в таблицата са изчислени (FP16 кеш; 32K = 32 768 токена):

   Модел (слоеве / KV-глави / глава)	На токен	32K	128K
   Llama-3.3-70B (80 / 8 / 128)	327 680 B	10,7 GB	42,9 GB
   Qwen3-30B-A3B (48 / 4 / 128)	98 304 B	3,2 GB	12,9 GB
   gpt-oss-120b (36 / 8 / 64)	73 728 B	2,4 GB	9,7 GB
   Llama-4-Maverick (48 / 8 / 128)	196 608 B	6,4 GB	25,8 GB

   ⚠️

   Тук се проваля повечето планиране

   Модел, който се зарежда, може да се срине при дълъг документ, защото сметката е правена само за теглата. Llama-3.3-70B в Q4_K_M при 128K има 42,5 GB тегла и 42,9 GB кеш — кешът е колкото модела. С FP8 кеш (ако програмата го поддържа ⚠️) половината, т.е. ~21 GB.
   💡

   Три начина, по които формулата лъже

   1. MLA (DeepSeek-V3): пази се компресиран вектор — 61 × (512 + 64) × 2 = 70 272 байта на токен, т.е. ~2,3 GB при 32K, докато наивната формула дава 131 GB. 2. Плъзгащ прозорец (gpt-oss-120b): половината слоеве (18 от 36) гледат само 128 токена — ако програмата го използва, кешът при 32K е 1,2 GB вместо 2,4. 3. Внимание на части (Maverick): конфигурацията има attention_chunk_size 8192 — при дълъг контекст реалният кеш е по-малък. Затова формулата е горна граница за стандартно внимание; за реалния случай мери ⚠️.

3. Режийни и работен таван

   Активации, фрагментация, самата програма: заложете 10–20% върху теглата и кеша (тук 15%). Не защото е точно толкова, а защото пълненето до последния байт е причина за откази, които после се търсят с часове.

   До колко от 128 GB да планираме? NVIDIA заявява 128 GB обща памет и не дава фиксирана използваема стойност; операционната система и другите програми ползват същия басейн. Като наша работна евристика ⚠️ планираме до ~109 GB (85%). Проверете реално свободното с free -h, преди да разчитате на числото.

   ✅

   Правилото

   общо = (тегла + KV кеш) × 1,15 < ~109 GB. Всяко число отляво е изчислено от реалните тегла и конфигурация, не от запомнена таблица.

4. Уловката при MoE: паметта брои всичко, скоростта — само активните

   Mixture-of-Experts моделите активират само част от параметрите на токен: Qwen3-30B-A3B — 3,3 от 30,5 млрд.; gpt-oss-120b — 5,1 от 117 млрд.; DeepSeek-V3 — 37 от 671 млрд. Изкушението е „3,3B се събира лесно“. Не е така. Кои експерти ще потрябват за следващия токен не се знае предварително, затова всички тегла трябва да са в паметта. Евтино е изчислението, не съхранението.

   Активните параметри определят скоростта: при генериране всеки токен чете активните тегла от паметта. Горна граница ≈ честотна лента ÷ байтове на токен. Изчислено с 273 GB/s (теория, реалното е по-ниско; не отчита кеша и вниманието):

   Модел и формат	Чете се на токен	Таван, токена/сек
   Llama-3.3-70B (плътен) · FP8	70,6 GB	~3,9
   Llama-3.3-70B (плътен) · Q4_K_M	42,8 GB	~6,4
   Qwen3-30B-A3B · FP8 (3,3B активни)	3,3 GB	~83
   Qwen3-30B-A3B · Q4_K_M	2,0 GB	~137
   gpt-oss-120b · MXFP4 (5,1B активни, приблизително)	2,7 GB	~101

   Изводът: MoE моделите от 30B до 120B дават няколко пъти по-висока горна граница на скоростта от плътен 70B при подобна или по-малка памет. Но 5,1B активни не правят 117B модел „малък“ — той пак изяжда ~65 GB.

5. Калкулаторът: всичко заедно

   Функцията по-долу смята теглата, кеша, режийните и сравнява с тавана. Резултатите, отпечатани отдолу, са получени с това изпълнение (Python 3); параметрите на слоевете са от config.json на всеки модел. Llama използва 4,82 бита — измерено от истинския файл; gpt-oss — 4,47 бита ефективно (65,2 GB ÷ 116,8 млрд.).

   python · plan.pyкопирай

   GB = 1e9
   
   def plan(name, params_b, bits, layers, kv_heads, head_dim, ctx_k,
            kv_bytes=2, overhead=0.15, budget_gb=109):
       """params_b = ОБЩИТЕ параметри в милиарди (при MoE: всички експерти)."""
       weights = params_b * bits / 8                                   # GB
       kv = 2 * layers * kv_heads * head_dim * ctx_k * 1024 * kv_bytes / GB
       total = (weights + kv) * (1 + overhead)
       print(f"{name:34s} W {weights:6.1f}  KV {kv:5.1f}  total {total:6.1f} GB  "
             f"-> {'fits' if total < budget_gb else 'DOES NOT FIT'} "
             f"(headroom {budget_gb - total:+.1f})")
   
   # слоеве / KV-глави / размер на глава — от config.json на всеки модел
   plan("Llama-3.3-70B  Q4_K_M  32K", 70.55, 4.82, 80, 8, 128, 32)
   plan("Llama-3.3-70B  FP8     32K", 70.55, 8.0, 80, 8, 128, 32)
   plan("Llama-3.3-70B  Q4_K_M 128K", 70.55, 4.82, 80, 8, 128, 128)
   plan("Qwen3-30B-A3B  BF16    32K", 30.53, 16.0, 48, 4, 128, 32)
   plan("Qwen3-30B-A3B  FP8     32K", 30.53, 8.0, 48, 4, 128, 32)
   plan("gpt-oss-120b   MXFP4   32K", 116.83, 4.47, 36, 8, 64, 32)
   plan("Llama-4-Maverick Q4_K_M 32K", 401.58, 4.85, 48, 8, 128, 32)
   
   Llama-3.3-70B  Q4_K_M  32K         W   42.5  KV  10.7  total   61.2 GB  -> fits (headroom +47.8)
   Llama-3.3-70B  FP8     32K         W   70.5  KV  10.7  total   93.5 GB  -> fits (headroom +15.5)
   Llama-3.3-70B  Q4_K_M 128K         W   42.5  KV  42.9  total   98.3 GB  -> fits (headroom +10.7)
   Qwen3-30B-A3B  BF16    32K         W   61.1  KV   3.2  total   73.9 GB  -> fits (headroom +35.1)
   Qwen3-30B-A3B  FP8     32K         W   30.5  KV   3.2  total   38.8 GB  -> fits (headroom +70.2)
   gpt-oss-120b   MXFP4   32K         W   65.3  KV   2.4  total   77.8 GB  -> fits (headroom +31.2)
   Llama-4-Maverick Q4_K_M 32K        W  243.5  KV   6.4  total  287.4 GB  -> DOES NOT FIT (headroom -178.4)

   Прочети резултата: 70B във FP8 при 32K влиза с 15 GB запас, но по горната таблица е около 4 токена/сек — „събира се“ не значи „удобно“. Maverick иска ~287 GB и отпада. 70B в Q4_K_M при 128K стига 98 GB — едва се събира и целият таван е кешът.

   💡

   Оценката не заменя измерването

   Формулата казва дали си струва да теглиш модела, не колко е бърз. Модел, който едва се събира, обикновено дава единични токени в секунда — технически работи, на практика не е за интерактивна работа. След зареждане мери: free -h за паметта и реални токени в секунда.

04Проверка

• Общите параметри са взети от картата на модела, не от името.
• За формата е ползван реалният брой байта, а не закръглено „0,5“ за 4 бита.
• KV кешът е изчислен от config.json за реалния контекст; проверен е видът внимание.
• Добавени са 15% режийни; сравнено е с ~109 GB, не със 128.
• При MoE паметта е от общите параметри, а таванът на скоростта — от активните.
• След зареждане са измерени паметта и токените в секунда.

Тест

05Какво следва

06Източници

1. NVIDIA DGX Spark: продуктова страница — 128 GB LPDDR5x, 256 бита, 273 GB/s, модели до 200 млрд. параметъра.
2. NVIDIA DGX Spark: хардуер · известни особености — обща памет, отчитане на паметта.
3. Карти на моделите и config.json — 🌐 глобален: Llama-3.3-70B · Qwen3-30B-A3B · gpt-oss-120b · Llama-4-Maverick · DeepSeek-V3 — общи и активни параметри, слоеве, KV-глави.
4. NVIDIA: NVFP4 — микроблокове от 16 стойности с FP8 мащаб.
5. Hugging Face: GGUF — типове квантуване (Q4_K = 4,5 бита на параметър); Q4_K_M измерен по файловете Llama-3.3-70B GGUF и Qwen3-30B-A3B GGUF.