Жалеза для лакальных LLM у 2026: VRAM, прапускная здольнасць памяці, квантызацыя

Каб запусціць open-weight моўную мадэль лакальна, прыладзе, якая выконвае вылічэнні, патрэбна дастаткова хуткай памяці для трох рэчаў: квантызаваных вагаў, KV-кэша пад вашу даўжыню кантэксту і колькасць адначасовых запытаў, а таксама запасу для асяроддзя выканання. Аб'ём памяці вызначае, якія мадэлі змесцяцца, прапускная здольнасць памяці вызначае хуткасць генерацыі тэксту, а вылічальная магутнасць вызначае хуткасць чытання доўгіх промптаў. Спрошчана: GPU на 16 ГБ добра спраўляецца з мадэлямі класа 8B, 24–32 ГБ хапае для мадэляў класа 32B у 4-бітнай квантызацыі, а мадэлям класа 70B трэба прыкладна 48 ГБ і больш, гэта значыць карта для працоўнай станцыі, два GPU або машына з адзінай памяццю.

Формула памяці

Любы разлік пачынаецца з адной сумы:

memory ≈ weights + KV cache + runtime overhead

weights  = parameters × bits per weight / 8
KV cache = 2 × layers × kv_heads × head_dim × bytes per element × tokens in flight

Мадэлі з 70,6 млрд параметраў трэба каля 141 ГБ пад вагі пры 16 бітах і каля 42 ГБ пры 4,8 біта на вагу.

KV-кэш захоўвае ключы і значэнні ўвагі для кожнага токена, які мадэль трымае ў кантэксце, таму ён расце з кожным токенам промпта і адказу. Множнік 2 улічвае ключы і значэнні, а астатнія велічыні бяруцца з config.json мадэлі: num_hidden_layers, num_key_value_heads і head_dim. Большасць сучасных мадэляў выкарыстоўвае grouped-query attention, дзе KV-галоў значна менш, чым галоў запытаў.

Накладныя выдаткі асяроддзя выканання ўключаюць кантэкст CUDA, ROCm або Metal і вылічальныя буферы. Закладвайце 1–2 ГіБ на прыладу для llama.cpp, чыё аўтаматычнае размяшчэнне па змаўчанні пакідае запас 1024 МіБ на прыладу, і больш для сервераў, якія загадзя рэзервуюць памяць пад вялікія батчы. На машынах з адзінай памяццю пакіньце месца і для аперацыйнай сістэмы.

KV-кэш расце з кантэкстам і паралельнасцю

Кошт аднаго токена непасрэдна вынікае з канфігурацыі:

Llama 3.1 8B:   2 × 32 layers × 8 kv_heads × 128 head_dim × 2 bytes = 128 KiB per token
Qwen3-32B:      2 × 64 layers × 8 kv_heads × 128 head_dim × 2 bytes = 256 KiB per token
Llama 3.3 70B:  2 × 80 layers × 8 kv_heads × 128 head_dim × 2 bytes = 320 KiB per token

Пры 32 768 токенах гэта 4, 8 і 10 ГіБ для 16-бітнага кэша. Пры 131 072 токенах кэш мадэлі 70B дасягае 40 ГіБ, гэта значыць столькі ж, колькі яе 4-бітныя вагі.

Паралельныя запыты памнажаюць кэш: чатыром карыстальнікам з дыялогамі па 16K токенаў трэба столькі ж, колькі аднаму дыялогу на 64K. vLLM фармуе пул KV з памяці, якая засталася пасля загрузкі вагаў, а llama-server дзеліць адзін бюджэт кантэксту (-c) паміж слотамі (--parallel). У кіраўніцтве па серверах лакальнага інферэнсу LLM разабрана, як кожны сервер размяркоўвае гэты пул.

Паменшыць кэш можна двума спосабамі. 8-бітны кэш, -ctk q8_0 -ctv q8_0 у llama.cpp або --kv-cache-dtype fp8 у vLLM, скарачае яго прыкладна ўдвая, а абмежаванне кантэксту рэальна патрэбнай даўжынёй нічога не каштуе. Sliding-window, гібрыдная ўвага і multi-head latent attention захоўваюць менш даных на токен, таму правярайце памер KV-буфера, які llama.cpp выводзіць пры загрузцы мадэлі.

Разлік для мадэляў 8B, 32B і 70B

Дакументацыя llama.cpp па квантызацыі прыводзіць колькасць бітаў на вагу, вымераную на Llama 3.1 8B: Q8_0 — 8,50, Q6_K — 6,56, Q5_K_M — 5,70, Q4_K_M — 4,89, IQ4_XS — 4,46 і Q3_K_M — 4,00. У большых мадэляў значэнні крыху ніжэйшыя: апублікаваныя файлы Q4_K_M для Qwen3-32B і Llama 3.3 70B даюць каля 4,8. Гэты скрыпт ужывае формулу для кантэксту 32K і накладных выдаткаў 1,5 ГіБ:

GiB = 2**30

def weights_gib(params, bits_per_weight):
    return params * bits_per_weight / 8 / GiB

def kv_gib(layers, kv_heads, head_dim, tokens, bytes_per_elem=2):
    return 2 * layers * kv_heads * head_dim * bytes_per_elem * tokens / GiB

models = {
    "Llama 3.1 8B": (8.03e9, 32),
    "Qwen3-32B": (32.76e9, 64),
    "Llama 3.3 70B": (70.55e9, 80),
}

for name, (params, layers) in models.items():
    kv = kv_gib(layers, 8, 128, 32768)
    for quant, bpw in (("BF16", 16.0), ("Q8_0", 8.5), ("Q4_K_M", 4.85)):
        w = weights_gib(params, bpw)
        print(f"{name:14} {quant:7} weights {w:6.1f} GiB  KV@32K {kv:5.1f} GiB  total {w + kv + 1.5:6.1f} GiB")

Llama 3.1 8B   BF16    weights   15.0 GiB  KV@32K   4.0 GiB  total   20.5 GiB
Llama 3.1 8B   Q8_0    weights    7.9 GiB  KV@32K   4.0 GiB  total   13.4 GiB
Llama 3.1 8B   Q4_K_M  weights    4.5 GiB  KV@32K   4.0 GiB  total   10.0 GiB
Qwen3-32B      BF16    weights   61.0 GiB  KV@32K   8.0 GiB  total   70.5 GiB
Qwen3-32B      Q8_0    weights   32.4 GiB  KV@32K   8.0 GiB  total   41.9 GiB
Qwen3-32B      Q4_K_M  weights   18.5 GiB  KV@32K   8.0 GiB  total   28.0 GiB
Llama 3.3 70B  BF16    weights  131.4 GiB  KV@32K  10.0 GiB  total  142.9 GiB
Llama 3.3 70B  Q8_0    weights   69.8 GiB  KV@32K  10.0 GiB  total   81.3 GiB
Llama 3.3 70B  Q4_K_M  weights   39.8 GiB  KV@32K  10.0 GiB  total   51.3 GiB

Мадэль 8B у Q4_K_M змяшчаецца на карту 12 ГБ, а ў Q8_0 — на карту 16 ГБ, так што на 16 ГБ няма прычын праз аб'ём апускацца ніжэй за Q6_K. Мадэлі 32B у Q4_K_M з поўным кэшам на 32K патрэбна карта 32 ГБ; на 24 ГБ яна змяшчаецца з кантэкстам 16K і 8-бітным кэшам, займаючы каля 22 ГіБ. Мадэлі 70B у Q4_K_M трэба каля 51 ГіБ: два GPU па 32 ГБ, карта для працоўнай станцыі на 72 або 96 ГБ ці 64 ГБ адзінай памяці і больш. Карта на 48 ГБ запускае яе з кантэкстам каля 8K, а для Q8_0 патрэбна карта на 96 ГБ або 128 ГБ адзінай памяці.

Фарматы квантызацыі і іх кошт

Квантызацыя захоўвае вагі меншай колькасцю бітаў плюс маштабы для кожнага блока. Яна эканоміць памяць і паскарае генерацыю, але дадае хібнасць.

K-quants і I-quants у GGUF

GGUF — фармат файлаў llama.cpp, яго таксама выкарыстоўваюць Ollama і LM Studio. K-quants, напрыклад Q4_K_M і Q6_K, квантызуюць вагі блокамі і пакідаюць адчувальныя тэнзары ў больш дакладным тыпе. I-quants, напрыклад IQ4_XS, пакуюць вагі шчыльней. Абедзве сям'і выйграюць ад матрыцы важнасці (imatrix), разлічанай на каліброўчным тэксце, а дакументацыя llama.cpp вымярае іх страты праз perplexity і дывергенцыю Кульбака — Лейблера. GGUF працуе на CUDA, ROCm, Vulkan, Metal і CPU, таму гэта самы пераносны варыянт.

8 бітаў і FP8

Q8_0 — 8-бітны тып GGUF. На GPU-серверах стандартны 8-бітны фармат — FP8. Паводле дакументацыі vLLM па FP8, вылічэнні FP8 патрабуюць NVIDIA compute capability 8.9 або вышэй (Ada Lovelace, Hopper, Blackwell), старэйшыя GPU пераходзяць на weight-only ядры W8A16, а FP8 удвая скарачае памяць мадэлі пры росце прапускной здольнасці да 1,6 раза і мінімальным уплыве на дакладнасць.

AWQ, GPTQ і 4-бітная рухомая коска

AWQ і GPTQ — 4-бітныя weight-only метады для GPU-сервераў, такіх як vLLM і SGLang. Яны каліброўваюць маштабы для груп вагаў, пакідаюць актывацыі ў 16 бітах, і шмат аўтараў мадэляў публікуюць такія версіі самі, напрыклад Qwen/Qwen3-32B-AWQ. GPU Blackwell дадаюць апаратную матэматыку FP4, а мадэлі gpt-oss ад OpenAI захоўваюць вагі экспертаў у MXFP4.

Колькі якасці вы губляеце

8-бітныя фарматы звычайна цяжка адрозніць ад BF16. Q6_K і Q5_K_M даюць невялікі, але вымерны рост perplexity і застаюцца бяспечным выбарам, калі дазваляе памяць. 4 біты — звыклы кампраміс: страты вымерныя, і найбольш прыкметныя яны там, дзе важныя дробныя памылкі: у кодзе, матэматыцы і дакладным выманні фактаў з доўгага кантэксту. Ніжэй за 4 біты хібнасць хутка расце, прычым малыя мадэлі пакутуюць мацней за вялікія. Большая мадэль у 4 бітах часта пераўзыходзіць меншую ў 8 бітах пры тым жа аб'ёме памяці, але правярайце гэта на сваіх задачах, як апісана ў кіраўніцтве па ацэнцы AI-агентаў.

Прапускная здольнасць задае хуткасць генерацыі, вылічэнні — хуткасць промпта

Генерацыя аднаго токена шчыльнай мадэллю чытае кожную вагу адзін раз, плюс KV-кэш бягучага кантэксту. Пры памеры батча 1 перамяшчэнне даных дамінуе, таму столь лічыцца проста:

decode tokens/s ≤ memory bandwidth / bytes read per token
bytes read per token ≈ weight bytes (dense) or active-expert bytes (MoE) + KV cache bytes at current depth

Файл Llama 3.3 70B Q4_K_M займае 42,5 ГБ, таму столь складае каля 42 токенаў у секунду пры 1792 ГБ/с, 14 пры 614 ГБ/с і 6 пры 256 ГБ/с. Файл 8B Q4_K_M (4,9 ГБ) атрымлівае каля 91 токена ў секунду пры 448 ГБ/с. Рэальныя асяроддзі выканання працуюць ніжэй за гэтыя столі і запавольваюцца з ростам кантэксту: на 32K кэш мадэлі 70B дадае каля 10,7 ГБ чытання на кожны токен.

Табліца квантызацыі llama.cpp паказвае гэтую заканамернасць на адной машыне з Llama 3.1 8B: генерацыя расце прыкладна з 29 токенаў у секунду ў F16 да 51 у Q8_0 і 72 у Q4_K_M, а апрацоўка промпта для ўсіх тыпаў застаецца ў дыяпазоне прыкладна ад 700 да 920 токенаў у секунду.

Апрацоўка промпта ідзе батчамі па сотні токенаў, таму кожнае чытанне вагі абслугоўвае шмат токенаў, і абмежаваннем становіцца матрычная прадукцыйнасць. Аб'ём працы — прыкладна 2 × parameters × prompt tokens аперацый, гэта значыць каля 5 × 10^14 для промпта на 8000 токенаў у мадэлі 32B. Ад гэтага залежыць час да першага токена ў retrieval-augmented generation, дзе промпт нясе знойдзеныя фрагменты, як у схеме гібрыднага пошуку на pgvector, і ў агентаў для кода, якія адпраўляюць вялікія файлы. Глядзіце на абедзве характарыстыкі: у NVIDIA DGX Spark сціплая столь генерацыі пры 273 ГБ/с, але NVIDIA ацэньвае яе чып GB10 да 1 PFLOP разрэджаных вылічэнняў FP4.

Батчынг абслугоўвае шмат паслядоўнасцей за адно чытанне вагаў, таму прапускная здольнасць сервера расце, пакуль не скончацца вылічэнні або кэш. Цыклам агентаў, наадварот, важная затрымка аднаго запыту, бо кожны крок чакае папярэдні выклік, як апісана ў кіраўніцтве па архітэктуры production AI-агента.

Мадэлі mixture-of-experts (MoE) раздзяляюць гэтыя абмежаванні: памяць вызначаецца агульнай колькасцю параметраў, а хуткасць генерацыі — колькасцю актыўных. У gpt-oss-120b 117 млрд параметраў, з іх 5,1 млрд актыўных, і ў яе картцы мадэлі сказана, што яна змяшчаецца на адзін GPU з 80 ГБ; яе файл MXFP4 GGUF займае 63,4 ГБ. gpt-oss-20b працуе ў межах 16 ГБ. Таму машыны з вялікім аб'ёмам і ўмеранай прапускной здольнасцю застаюцца карыснымі.

Варыянты абсталявання паводле магчымасцей

GPU NVIDIA паводле класаў VRAM

GPU NVIDIA маюць найшырэйшую падтрымку з боку асяроддзяў выканання, бо vLLM, SGLang, TensorRT-LLM і llama.cpp лічаць CUDA эталоннай платформай. Спачатку параўноўвайце аб'ём, потым прапускную здольнасць унутры класа: карты GeForce на 16 ГБ запускаюць тыя самыя мадэлі, але ў RTX 5080 прапускная здольнасць больш чым удвая вышэйшая, чым у RTX 5060 Ti. RTX PRO 6000 Blackwell змяшчае мадэль 70B у 8 бітах на адной карце. Карты GeForce RTX 50 не падтрымліваюць NVLink, таму абмен паміж некалькімі GPU ідзе праз PCIe.

Адзіная памяць: Apple Silicon, Ryzen AI Max, DGX Spark

Сістэмы з адзінай памяццю даюць CPU і GPU агульны пул LPDDR: значна больш памяці пад мадэль, чым у спажывецкіх GPU, але з меншай прапускной здольнасцю, чым у хуткай карты GDDR7, за выключэннем старэйшага чыпа Apple. Для Mac Studio Apple прапануе M5 Ultra ад 96 ГБ, паведамляе, што канфігурацыя на 512 ГБ з'явіцца ў канцы кастрычніка, і падтрымлівае кластарызацыю праз Thunderbolt 5 з RDMA; сярод асяроддзяў выканання — llama.cpp на Metal і MLX. Ryzen AI Max+ 395 ад AMD выкарыстоўвае 256-бітны інтэрфейс LPDDR5x-8000, што дае 256 ГБ/с, а Ryzen AI Max+ PRO 495 пераходзіць на LPDDR5x-8533, і сістэмы OEM заяўлены на трэці квартал 2026 года; llama.cpp працуе на абодвух праз ROCm або Vulkan. NVIDIA DGX Spark выкарыстоўвае стэк CUDA і мае порт ConnectX-7 на 200 Гбіт/с для аб'яднання прылад.

Паводле формулы столі такія машыны запускаюць шчыльныя мадэлі 70B з хуткасцю ад адзінак да некалькіх дзясяткаў токенаў у секунду, а мадэлі MoE — значна хутчэй. Іх GPU працуюць у значна меншым бюджэце магутнасці, чым карта на 575 Вт, таму вымярайце час да першага токена на рэальных промптах.

Платформа	Памяць для мадэлі	Прапускная здольнасць	Магутнасць	Шчыльная мадэль пры кантэксце 32K
GeForce RTX 5060 Ti 16 GB	16 ГБ GDDR7	448 ГБ/с	180 Вт	8B у Q8_0
GeForce RTX 5070 Ti / 5080	16 ГБ GDDR7	896 / 960 ГБ/с	300 / 360 Вт	8B у Q8_0
GeForce RTX 5090	32 ГБ GDDR7	1792 ГБ/с	575 Вт	32B у Q4_K_M
RTX PRO 4000 / 4500 Blackwell	24 / 32 ГБ GDDR7 ECC	672 / 896 ГБ/с	145 / 200 Вт	32B у 4 бітах
RTX PRO 5000 Blackwell	48 або 72 ГБ GDDR7 ECC	1344 ГБ/с	300 Вт	32B у Q8_0, 70B у Q4_K_M на 72 ГБ
RTX PRO 6000 Blackwell	96 ГБ GDDR7 ECC	1792 ГБ/с	600 Вт або 300 Вт (Max-Q)	70B у Q8_0
DGX Spark	128 ГБ LPDDR5x	273 ГБ/с	блок жыўлення 240 Вт	70B у Q8_0
Ryzen AI Max+ 395	128 ГБ, да 96 ГБ для графікі	256 ГБ/с	45–120 Вт	70B у Q6_K
Ryzen AI Max+ PRO 495	192 ГБ, да 160 ГБ для графікі	каля 273 ГБ/с	45–120 Вт	70B у Q8_0
Mac Studio, M5 Max	да 128 ГБ	да 614 ГБ/с	максімум сістэмы 480 Вт	70B у Q8_0
Mac Studio, M5 Ultra	да 512 ГБ	1,2 ТБ/с	максімум сістэмы 480 Вт	70B у BF16

Апошняя калонка вынікае з разлікаў вышэй для аднаго карыстальніка. Табліца апісвае магчымасці, а не суадносіны цаны і якасці.

Некалькі GPU і выгрузка на CPU

Два GPU падвойваюць аб'ём, але хуткасць залежыць ад спосабу падзелу. Пры падзеле па слаях, рэжыме llama.cpp па змаўчанні, кожны GPU захоўвае дыяпазон слаёў і іх KV-кэш, а пры батчы 1 GPU працуюць па чарзе: аб'ём большы, хуткасць генерацыі тая ж. На кожны токен праз PCIe праходзяць толькі невялікія актывацыі, таму лінкаў x8 або x4 дастаткова. Пры тэнзарным паралелізме (--tensor-parallel-size 2 у vLLM) абодва GPU адначасова чытаюць сваю долю кожнага слоя, што падымае столь, але кожны слой сінхранізуецца праз PCIe. Тэнзарны паралелізм vLLM разлічаны на аднолькавыя GPU, а колькасць GPU павінна дзяліць колькасць галоў увагі мадэлі.

Выгрузка на CPU пакідае частку слаёў у сістэмнай памяці, і іх выконвае працэсар. Час на токен становіцца сумай: байты на GPU, падзеленыя на прапускную здольнасць VRAM, плюс байты на CPU, падзеленыя на прапускную здольнасць RAM. Двухканальная DDR5-6000 тэарэтычна дае 96 ГБ/с (2 каналы × 8 байт × 6000 MT/s), а ў кіраўніцтве па памяці DDR5 разабрана, як спалучаюцца каналы і частоты. Мадэль 70B Q4_K_M, у якой 24 ГБ на GPU і 18,5 ГБ у RAM, не перавысіць 5 токенаў у секунду. Выгрузка вырашае праблему аб'ёму, а не хуткасці.

Мадэлі MoE выгружаюцца значна лепш. --cpu-moe і --n-cpu-moe N трымаюць вагі экспертаў у RAM, а ўвага і KV-кэш застаюцца на GPU, і на кожны токен чытаюцца толькі актыўныя эксперты. Свежыя зборкі llama.cpp самі падбіраюць колькасць слаёў, калі -ngl не зададзены (--fit уключаны па змаўчанні); задавайце яго яўна, калі патрэбныя ўзнаўляльныя вынікі. Каманды ніжэй паказваюць часткова выгружаную шчыльную мадэль, мадэль MoE з экспертамі ў RAM і падзел па слаях з перавагай на карысць большага GPU:

llama-server -m Llama-3.3-70B-Instruct-Q4_K_M.gguf -c 16384 -ngl 48 -fa on

llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 32768 -ngl all --n-cpu-moe 24 -fa on

llama-server -m Qwen_Qwen3-32B-Q8_0.gguf -c 32768 -ngl all --split-mode layer --tensor-split 3,2

Жыўленне, астуджэнне, лініі PCIe і сістэмная памяць

Для GeForce RTX 5090 NVIDIA пазначае 575 Вт графічнай магутнасці і 1000 Вт патрэбнай магутнасці сістэмы. Версія RTX PRO 6000 Max-Q на 300 Вт захоўвае той жа аб'ём памяці, што і мадэль на 600 Вт, і гэта важна, калі ў адным корпусе будзе некалькі карт. Паколькі генерацыя чакае памяць, праверце паніжаны ліміт праз nvidia-smi -pl і пакіньце значэнне, пры якім хуткасць генерацыі амаль не змяняецца.

Інферэнс — працяглая нагрузка, а дзве карты з адкрытым астуджэннем у суседніх слотах ганяюць адна адной гарачае паветра. Правярайце частоты, тэмпературу і магутнасць падчас 30-хвіліннага прагону.

Карты GeForce RTX 50 і RTX PRO Blackwell выкарыстоўваюць PCIe 5.0 x16. Спажывецкія настольныя платформы звычайна даюць адзін графічны лінк x16, які некаторыя платы дзеляць на x8/x8, а слот ад чыпсэта часта працуе ў рэжыме x4. Падзел па слаях гэта вытрымлівае; тэнзарнаму паралелізму і загрузцы мадэляў лепш x8 і шырэй, што даюць платформы працоўных станцый. Паказанае пакаленне лінка можа зніжацца, пакуль GPU прастойвае, таму правярайце яго пад нагрузкай.

Сістэмнай памяці павінна быць не менш, чым найбольшы файл мадэлі, які вы загружаеце, плюс месца для АС, і значна больш, калі вы выгружаеце слаі. Файлы мадэляў займаюць ад 5 ГБ да больш чым 100 ГБ, таму хуткі назапашвальнік скарачае час загрузкі; пра гэты сцэнарый расказвае кіраўніцтва па выбары NVMe SSD.

nvidia-smi --query-gpu=name,pcie.link.gen.current,pcie.link.width.current,power.draw,memory.used --format=csv -l 1

nvidia-smi dmon -s pucvmt -d 1

sudo nvidia-smi -pl 450

Вымерайце ўласную хуткасць

Апублікаваныя лічбы рэдка супадаюць з вашым файлам мадэлі, кантэкстам, драйверам і версіяй асяроддзя выканання, таму вымярайце самі і параўноўвайце з формулай столі. У llama-bench параметр -p задае даўжыню промпта, -n — колькасць згенераваных токенаў, а -d загадзя запаўняе KV-кэш да зададзенай глыбіні і паказвае, як падае хуткасць з ростам дыялогу. Другая каманда параўноўвае 16-бітны і 8-бітны кэш:

llama-bench -m Qwen_Qwen3-32B-Q4_K_M.gguf -p 512,4096 -n 128 -d 0,16384 -fa on -r 3 -o md

llama-bench -m Qwen_Qwen3-32B-Q4_K_M.gguf -p 4096 -n 128 -d 16384 -ctk f16,q8_0 -ctv f16,q8_0 -fa on

Потым праверце паралельную нагрузку. vllm bench serve працуе з OpenAI-сумяшчальнымі endpoint і паказвае час да першага токена, час на выхадны токен, затрымку паміж токенамі і агульную прапускную здольнасць:

vllm serve Qwen/Qwen3-32B-AWQ --max-model-len 32768

vllm bench serve --backend openai --base-url http://127.0.0.1:8000 --model Qwen/Qwen3-32B-AWQ --dataset-name random --random-input-len 4096 --random-output-len 256 --num-prompts 200 --max-concurrency 8

Падзяліце вымераную хуткасць аднаго патоку на столь. Калі суадносіны незвычайна нізкія, шукайце слаі, непрыкметна выгружаныя на CPU, лінк PCIe са зменшанай шырынёй, тротлінг або павольны backend.

Чэкліст падбору

• Выпішыце з config.json колькасць параметраў, слаёў, KV-галоў і памернасць галавы.
• Выберыце квантызацыю: 8 бітаў, калі змяшчаецца, потым Q6_K або Q5_K_M, потым 4 біты, а ніжэй толькі пасля праверкі.
• Задайце кантэкст і колькасць паралельных запытаў, падлічыце KV-кэш і вырашыце, ці прымальны 8-бітны кэш.
• Дадайце 1–2 ГіБ на прыладу і запас для АС на адзінай памяці.
• Адкіньце платформы, у якіх столь генерацыі ніжэйшая за патрэбную вам хуткасць.
• Для доўгіх промптаў з RAG або агентаў для кода ўлічвайце вылічэнні і вымярайце час да першага токена.
• Для MoE лічыце памяць па агульнай колькасці параметраў, а хуткасць па актыўных.
• Праверце жыўленне, астуджэнне, лініі PCIe, RAM і назапашвальнік да пакупкі другога GPU.
• Правядзіце замеры і скараціце разрыў са столлю, перш чым дадаваць абсталяванне.