Запуск 32B ИИ модели на старом Xeon: 64 ГБ RAM против RTX 4070

Скринкаст эксперимента: YouTube · продолжение истории про Forth и ИИ

Недавно я хотел локально запустить квантованные модели на 19–20 ГБ — на своем рабочем ноутбуке. Параметры системы RTX 4070, Windows, LM Studio. Возможно, я что-то не так настроил. Ожидал, что модель "размажет" между VRAM+RAM+NVME но получилось только наглухо заблокировать систему.

Тогда я вспомнил про свой старый сервер 2008 года на 2× Intel Xeon E5440, 64 Гб RAM, без GPU. Склонировал актуальную llama.cpp, скомпилировал без каких-либо сложностей и запустил в чисто CPU-режиме.

Модель: deepseek-r1-distill-qwen-32b-q4_k_m.gguf

Промпт: написать факториал на Forth

Цель: не скорость, а ответ на вопрос: может ли старое железо с достаточным объёмом памяти запустить модель, которая по качеству недоступна на моём ноутбуке?

Две машины, один класс моделей

	Ноутбук	Сервер
CPU	современный ноутбук	2× Xeon E5440
RAM	16 Гб	64 Гб
GPU	RTX 4070 8 Гб	—
Стек	LM Studio (Windows)	llama.cpp (CPU)
Результат	зависание	грузится, работает

Сервер достаточно долго стартует с такой моделью. Скорость генерации примерно ~0.01 токена в секунду.

Эксперимент стартовал — около 23:56. После я включил запись скринкаста и ушел спать. Пару раз просыпался, проверить результаты. В принципе, к утру получилось два варианта ответа. В записи я включил ускоренную перемотку, за исключением тех моментов, где я проверяю работу кода.

Семь часов, два варианта вычисления факториала, ни одного правильного

В 05:48 модель всё ещё не закончила цепочку рассуждений, но фрагмент, похожий на Forth, уже был. Я скопировал вариант 1, запустил в gforth — не сработало: ошибка стека или синтаксиса.

Но поток ещё шёл. Поэтому я подождал.

В 06:51 появилась вторая попытка факториала. Запустил и её. Снова fail.

Full output

llama-ui
New chat
MCP Servers
Settings
Recent conversations

Write a program to calculate the factorial. On GForth language

Okay, so I need to write a factorial program in GForth. I'm not super familiar with GForth, but I know it's a version of Forth, which is a stack-based programming language. Let me think about how to approach this.

First, I remember that factorial of a number n is the product of all positive integers up to n. So, for example, 5! is 54321 = 120. That makes sense.

Now, in Forth, programs are written in a way that uses a stack. So, I need to think about how to structure this using a stack-based approach. I'll probably need a loop that multiplies the numbers from 1 up to n.

I should start by defining a word, let's say 'factorial', which will take a number from the stack and return its factorial. So, the syntax would be something like : factorial ... ;

Next, I'll need to handle the case where n is zero or one because the factorial of both is 1. So, maybe I can have a conditional check at the beginning. If n is zero or one, just return 1.

For the loop, I'll need to initialize a counter and a product variable. Since we're using a stack, maybe I can push the initial value onto the stack and then iterate, multiplying each time.

Wait, but in GForth, how do I handle loops? I think there's a loop structure like begin ... while ... repeat, or maybe using a counted loop. Let me think. Since I need to multiply from 1 to n, perhaps using a loop that starts at 1 and goes up to n, multiplying each time.

But how do I accumulate the product? Let's see. I can initialize the product as 1, then for each number i from 2 to n, multiply the product by i.

So, the steps would be:

Check if n is 0 or 1. If yes, return 1.
Otherwise, initialize product to 1.
Loop from 2 to n:
a. Multiply product by i.
After the loop, return the product.

Now, translating this into GForth code. Let's outline it:

: factorial
dup 0 = if
drop 1
else
1
1
dup 1 = if
drop 1
else
begin
2dup * >r
r> 1+
dup 1 > while
r> 2dup * >r
r> 1+
repeat
r> drop
end
then
then
;

Wait, that seems a bit complicated. Maybe there's a simpler way. Alternatively, I could use a local variable to keep track of the product.

Wait, GForth supports local variables with the 'var' keyword. So, maybe I can define a variable to hold the product.

Let me try another approach:

: factorial
dup 0 = if
drop 1
else
1 >r ( r: product )
1
begin
2dup *
r> * >r ( multiply and store back )
1+
dup n > while
repeat
r> drop
then
;

Wait, no, that doesn't seem right. Maybe I should use a loop that runs from 2 to n, multiplying each time.

Alternatively, I can use a recursive approach. Factorial can be defined as n * factorial(n-1), with the base case of factorial(0) = 1.

But recursion
Context: 787/131072 (1%)Output: 772/∞0.0 t/s
Chat 16.06.2026, 23:56:42 - llama-ui

: factorial
dup 0 = if
drop 1
else
1 >r
1
begin
2dup *
r> * >r
1+
dup n > while
repeat
r> drop
then
;

Новый вывод: модель, не обученная специально на какой-то язык программирования (например Forth) не способны "программировать" на нем, даже если используется большая модель.

Лебединая песнь Xeon'а

Практической ценности от таких экспериментов с железом 2008 года, практически сложно найти. Что может такой старичек в эпоху LLM? Да почти ничего. Если только целью не ставится отапливать помещение.

Для запуска крупных Q4-моделей 64 Гб системной RAM на моём сервере обыгрывают 16 Гб + 8Гб GPU. Но это только факт запуска. Комфортной работой это (0.01 t/s) не назвать. Я думаю, мне нужно просто сделать пару настроек в LM Studio и все заработает.

А вот для моей задачи по созданию рабочего кода Forth большая модель не помогла. Нужен «завод»: алгоритм в удобной для модели IR, детерминированный transpile, gforth как проверка результата. Это то, что я собираю вокруг Cursor — rules, skills и MCP.

Платформа E5440 по современным меркам слабая — я бы не брал её и для PCIe GPU offload. Здесь объём RAM был единственным условием победы.

Выводы

1. VRAM — не единственный барьер. Системная RAM важна, когда вся модель живёт в памяти хоста на CPU. Но в этом случае - она очень медленная.
2. Медленный inference — тоже inference. 0.01 tok/s — это больше как прикол; но на вопрос «запустится ли вообще?» — мы получили ответ.
3. Не покупай стойку GPU, чтобы что-то выяснить. У себя я уже записал правило: железо покупаю после эксперимента, а не чтобы наконец начать эксперимент — иначе и у вас в чулане будут жить такие же монстры - "старые но не бесполезные" (или все-таки бесполезные?).
4. Fail format. Чтож, в итоге я получил два сломанных факториала за семь часов. Плохо. Но этот урок оказался дешевле, чем месяц Opus thinking loops (пока не посчитаешь, сколько ушло на сборку Xeon).

Update

Сделал некоторые замеры llama-bench c параметрами -r 1 -p 16 -n 16

Это коротский тест

Model	Params	File size	pp16 (t/s)	tg16 (t/s)
TinyLlama 1.1B Q6_K	1.1B	861 MiB	13.20	6.57
Gemma 4 E2B Q4_K_M	4.7B	3.2 GiB	8.08	3.37
Qwen2.5-Coder 7B Q4_K_M	7.6B	4.4 GiB	2.51	1.25
Gemma 4 E4B Q4_K_M	7.5B	5.0 GiB	3.89	1.72
Qwen2.5-Coder 14B Q4_K_M	14.8B	8.4 GiB	1.22	0.65
Qwen2.5-VL 32B Q4_K_M	32.8B	18.5 GiB	0.52	0.29
DeepSeek-R1 Distill Qwen 32B Q4_K_M	32.8B	18.5 GiB	0.52	0.29

llama-bench показывает потолок на коротком контексте (~0.29 tok/s для 32B). Реальный чат с reasoning и тысячами токенов на CPU Xeon даёт среднюю ~0.03 tok/s — не потому что модель другая, а потому что каждый токен дорожает по мере роста контекста.