GPU Compute Engine для 1С: как перестать ждать часами и начать считать на видеокарте

Меня зовут Андрей, я разрабатываю решения на стыке 1С и параллельных вычислений. Это статья о том, как и почему массовые расчёты в 1С нужно переносить на GPU. Не в облако, не на кластер серверов, а на обычную видеокарту в рабочем ПК. С конкретными цифрами, фрагментами кода шейдеров и результатами, которые можно проверить самостоятельно.

---

Введение. Точка кипения, или почему ждать — это неправильно

В любой компании, работающей в 1С, есть точка кипения. У бухгалтеров она наступает при закрытии месяца. У менеджеров по закупкам — когда нужно рассчитать потребности на тысячу товаров. У логистов — при построении отчёта по себестоимости. Все ждут.

Ждать — это неправильно. Не в том смысле, что неудобно. А в том, что сам факт ожидания — следствие архитектурного тупика, который мы почему-то считаем нормой.

Прогресс не стоит на месте. Искусственный интеллект считает миллиарды параметров на видеокартах. Научные симуляции, рендеринг, анализ больших данных — всё это давно живёт на GPU. А 1С до сих пор гоняет циклы на процессоре. Один за другим. Последовательно.

Это неправильно не потому, что «так не модно». А потому, что бизнес теряет деньги, пока система думает. 10 бухгалтеров × 30 минут ожидания в день = более 100 часов квалифицированного труда в месяц. Недогруженный склад из-за запоздалого MRP-расчёта. Срочные закупки по завышенным ценам, потому что вовремя не увидели дефицит.

Проблема не решается покупкой NVMe-диска или добавлением оперативной памяти. Она решается только сменой подхода к вычислениям.

Три статьи, написанные мной на Инфостарт, — это три шага по доказательству этой философии:

1. Авансы покупателей — простой, но показательный пример: можно ли вообще перенести типовой расчёт 1С на GPU и получить значимый результат?

2. Себестоимость тремя методами — усложнение: можно ли на GPU реализовать сложную логику с очередями, стеками и состоянием, а не только примитивную арифметику?

3. MRP с Монте-Карло — вершина: можно ли на GPU решать вероятностные задачи, которые в 1С считались бы часами даже на идеально оптимизированном коде?

Ответ во всех трёх случаях — да. И в этой статье я покажу этот путь целиком: от простого к сложному, от идеи к работающему инструменту.

Часть 1. Архитектура, или почему 32 ядра не помогут

Чтобы понять, почему видеокарта решает проблему, нужно сначала понять, в чём проблема.

Как считает процессор

Процессор — это универсал. У него несколько десятков мощных ядер, каждое умеет делать всё: сложную логику, ветвления, работу с памятью. Когда 1С выполняет типовой расчёт — например, авансы по контрагентам — она делает это последовательно. Один контрагент за другим. Внутри каждого контрагента — строка за строкой, по дате.

Вы можете купить сервер с 32 ядрами. Но конкретный цикл расчёта авансов использует 1–2 потока. Остальные ядра заняты другим или простаивают. Потому что распараллелить цикл с накоплением остатка нельзя — следующая итерация зависит от результата предыдущей.

Ускорение от более мощного процессора — линейное или хуже. Данных становится больше — время растёт прямо пропорционально.

Как считает видеокарта

Видеокарта — это узкий специалист. У неё тысячи небольших ядер, каждое из которых делает простые операции. Но все они работают одновременно.

Ключевая идея: один поток GPU — одна бизнес-сущность. Один контрагент. Один товар. Одна номенклатурная позиция.

Внутри потока логика остаётся последовательной: операции одного контрагента идут по дате, друг за другом, с накоплением остатка. Но таких потоков запускаются тысячи. И все они работают параллельно.

Пока CPU послушно перебирает контрагентов одного за другим, GPU обрабатывает их всех сразу.

Что такое GPU Compute Engine

Это мой движок — связующее звено между 1С и видеокартой. Никакой магии, чистая инженерия.

Как это работает:

1. 1С выгружает данные в промежуточную базу SQLite (или PostgreSQL). Это просто плоская таблица: одна операция — одна строка.

2. Движок читает данные, сортирует по группировочному признаку (например, по product_id) и определяет границы групп: строки 0-99 — товар 1, строки 100-249 — товар 2, и так далее.

3. Движок загружает данные в видеопамять тремя буферами: входные данные, диапазоны групп, и пустой буфер под результат.

4. Запускается шейдер — программа на GLSL, которая выполняется прямо на GPU. Потоков ровно столько, сколько получилось групп. Каждый поток получает свой диапазон строк и считает результат независимо.

5. Результат копируется обратно в базу данных. 1С забирает готовые цифры.

Ключевые принципы:

• Локально и безопасно. Данные не покидают инфраструктуру. Никаких облачных API, никаких внешних сервисов. Только ваша видеокарта и ваша база данных.

• Гибридный подход. Сложную бизнес-логику (обращения к справочникам, иерархии, нетривиальные условия) оставляем на CPU. Массовую арифметику и переборы отдаём GPU. Каждый делает то, в чём силён.

• Программируемость. Движок универсален. Под каждую задачу пишется свой шейдер и конфиг. Сегодня авансы, завтра себестоимость, послезавтра MRP.

• Без лицензий. Никаких ключей защиты, подписок, ограничений по числу пользователей или объёму данных. Берёте и используете.

Почему я выбрал Vulkan Compute Shaders?
Они кроссплатформенны и поддерживаются на всех современных видеокартах: NVIDIA, AMD, Intel Arc. Не нужно покупать специализированные серверные GPU. Подходит обычная рабочая станция с игровой или даже встроенной видеокартой последних лет.

Часть 2. Три примера использования GPU и 1С

I. Авансы покупателей: разрушаем миф

Это была первая задача — своего рода proof of concept. Я воспроизвел простую логику расчета авансов.

Суть задачи. В регистре накопления «Расчёты с контрагентом» хранятся оплаты и отгрузки. Нужно для каждой операции определить сумму аванса — денег, которые покупатель заплатил, но под которые товар ещё не отгружен.

Логика классическая: идём по операциям контрагента последовательно. Отгрузка увеличивает долг. Оплата сначала гасит долг, а если оплата больше долга — остаток становится авансом. Следующая операция зависит от состояния после предыдущей.

В 1С это цикл, который нельзя распараллелить внутри одного контрагента. Но разных контрагентов — тысячи. И они никак не связаны между собой.

Решение на GPU. Каждый поток получает своего контрагента. Внутри потока — та же последовательная логика, что и в 1С. Но потоков — тысячи, и все работают одновременно.

Вот фрагмент шейдера:

void main() {
    // Каждый поток = один контрагент
    uint gid = gl_GlobalInvocationID.x;

    uint row_start = ranges[gid * 2];
    uint row_end   = ranges[gid * 2 + 1];

    int remaining_sales = 0;

    for (uint i = row_start; i < row_end; i++) {
        uint base = i * pc.num_cols;

  int op_type = data[base + pc.col_indices[2]]; // индекс 2 = operation_type (3я колонка в конфиге)
int amount  = data[base + pc.col_indices[3]]; // индекс 3 = amount (4я колонка в конфиге)

        int avans = 0;

        if (op_type == 1) {
            // sale: накапливаем "покрытие" будущих платежей
            remaining_sales += amount;
        } else {
            // payment: вычитаем из накопленных продаж
            if (remaining_sales > 0) {
                if (amount <= remaining_sales) {
                    remaining_sales -= amount;
                    avans = 0;
                } else {
                    avans = amount - remaining_sales;
                    remaining_sales = 0;
                }
            } else {
                avans = amount; // нет продаж — весь платёж является авансом
            }
        }

        result[i] = avans;
    }
}

Результат. На 100 000 записей чистый расчёт на GPU оказался в 600–700 раз быстрее, чем последовательный цикл в 1С. При этом цифры в регистре накопления совпадают с точностью до копейки. Миф разрушен: GPU умеет считать 1С-задачи.

Полный разбор задачи, код обработки 1С и замеры — в первой статье: GPU Compute Engine for 1C: Ускоряем массовые расчёты авансов в сотни раз. ^[1]

II. Себестоимость тремя методами одновременно: доказываем гибкость

После авансов возник закономерный вопрос: это работает только для простой арифметики с одним накопителем? Или можно реализовать более сложную логику — с очередями, стеками и состоянием?

Я взял задачу, которая в 1С считается одной из самых тяжёлых: расчёт себестоимости списания. Но с одним условием: считать сразу три метода — FIFO, LIFO и среднюю — в одном проходе.

Почему это сложно. На CPU три метода — это три разных алгоритма. Для FIFO нужна очередь (забираем с головы). Для LIFO — стек (забираем с хвоста). Для средней — текущее среднее значение. На CPU они конфликтуют за память и время. В 1С это три последовательных запуска.

Решение на GPU. Каждый поток обрабатывает один товар. Внутри потока — один цикл по всем операциям товара. Приход — кладём партию одновременно в очередь FIFO, в стек LIFO и пересчитываем среднюю цену. Расход — списываем одновременно из трёх источников, получаем три себестоимости для одной операции.

Всё в одном потоке, на одном ядре GPU, без конфликтов. Тысячи товаров обрабатываются параллельно.

Результат. На 50 000 документов GPU дал ускорение в 300 раз. Но важнее не кратность ускорения, а доказательство гибкости: на видеокарту можно переносить не только примитивную арифметику, но и сложную логику с разными структурами данных.

Полный разбор, две демонстрационные базы (3 000 и 50 000 документов) и код обработки — во второй статье: GPU Compute Engine для 1С: FIFO, LIFO, средняя себестоимость — три метода одновременно на видеокарте. ^[2]

III. MRP с Монте-Карло: показываем настоящую мощь

Третья задача — вершина. Здесь речь идёт уже не просто об ускорении, а о возможности делать то, что на CPU занимает часы и поэтому просто не делается.

Суть задачи. Полный цикл планирования потребностей (MRP) для каждого товара:

1. Прогноз продаж, сигма, коэффициент вариации.

2. ABC-классификация (по доле в продажах).

3. XYZ-классификация (по стабильности спроса).

4. Динамический страховой запас и точка заказа.

5. Потребность в закупке.

6. Монте-Карло симуляция: 500 сценариев × 30 дней для каждого товара, чтобы оценить уровень сервиса и дни дефицита.

Шестой пункт — это 15 000 итераций на один товар. Для тысячи товаров — 15 миллионов итераций. На CPU это часы.

Решение на GPU. Каждый поток обрабатывает один товар. Внутри потока — полный цикл: статистика, классификация, точка заказа и 500 симуляций случайного спроса с генерацией нормального распределения методом Бокса-Мюллера.

Фрагмент шейдера (Монте-Карло):

for (int sim = 0; sim < 500; sim++) {
    float stock = current_stock;
    bool deficit = false;
    int deficit_days_sim = 0;

    for (int day = 0; day < 30; day++) {
        // Приход, если подошёл срок поставки
        if (days_to_arrival == 0.0) {
            stock += in_transit;
            in_transit = 0.0;
        }

        // Случайный спрос (нормальное распределение)
        float demand = forecast_day + sigma_day * box_muller();

        stock -= demand;
        if (stock < 0.0) {
            deficit = true;
            deficit_days_sim++;
            stock = 0.0;
        }

        // Заказ при достижении точки заказа
        if (stock <= order_point && days_to_arrival < 0.0) {
            in_transit = forecast_day * lead_time + dynamic_safety - stock;
            days_to_arrival = lead_time;
        }
    }

    if (!deficit) success++;
    total_deficit_days += deficit_days_sim;
}

service_level = float(success) / 500.0 * 100.0;
deficit_days = float(total_deficit_days) / 500.0;

Результат. На 243 товарах:

• Чистый расчёт на GPU: 0,06 секунды.

• Полный цикл (подготовка + GPU + агрегация): около 10 секунд.

• Классический расчёт в 1С: 160 секунд.

• Ускорение: более чем 2500 раз.

И это только 243 товара. С ростом ассортимента разрыв будет только увеличиваться, потому что GPU добавит ещё параллельных потоков, а CPU уйдёт в линейный рост времени.

Полный разбор, включая математический аппарат, скрипт оркестрации и тестовую базу — в третьей статье: GPU Compute Engine for 1C: Ускоряем массовые расчёты в MRP. ^[3]

Сводная таблица по всем трём задачам

Это не три разных инструмента. Это один движок, три разных шейдера и конфига. Философия одна: всё, что можно распараллелить по бизнес-сущностям, должно считаться на GPU.

Часть 3. Что нужно для запуска и где брать исходники

Железо

Никаких серверных стоек. Никаких облачных кластеров. Всё, что нужно — обычная рабочая станция с видеокартой, поддерживающей Vulkan Compute. Это все современные карты NVIDIA, AMD и Intel Arc за последние 5–7 лет.

Тестовый стенд, на котором я проводил все замеры:

Обратите внимание: это ноутбучная видеокарта. Не десктопная RTX 4090, не серверный ускоритель. Обычный игровой ноутбук. Результаты на десктопной карте были бы ещё выше.

Софт

Для запуска нужны:

1. Vulkan Runtime — бесплатно, одна установка, скачивается с сайта NVIDIA или AMD.

2. Драйвер для связки 1С с SQLite — поставляется в комплекте с решением, устанавливается один раз.

3. Python (для оркестрации в MRP-расчёте) — встроенная версия в комплекте, отдельно ставить не нужно.

Исходники на GitHub

Полный исходный код движка открыт и доступен в репозитории:

🔗 github.com/AndreyHhh/GPU-Compute-Engine-1C ^[4]

Что в репозитории:

• src/ — исходный код движка на C++/Vulkan

• CMakeLists.txt — сборка под Windows и Linux

• Документация по настройке и запуску

Сами статьи с полным кодом обработок 1С, шейдеров и тестовыми базами — на Инфостарт:

1. Авансы покупателей: ускорение в 600–700 раз ^[1]

2. Себестоимость тремя методами одновременно ^[2]

3. MRP с Монте-Карло: ускорение в 2500+ раз ^[3]

Что делать после прочтения

1. Скачать репозиторий с GitHub — собрать движок или взять готовый бинарник.

2. Скачать одну из демо-баз со статьёй на Инфостарт — открыть в 1С, запустить обработку, посмотреть на замеры своими глазами.

3. Сравнить цифры из GPU с классическим расчётом 1С — убедиться, что они совпадают.

4. Если в вашей конфигурации есть узкое место, которое похоже на описанные задачи — написать мне. Разберём задачу, оценим потенциал ускорения, обсудим варианты адаптации.

Заключение. Будущее наступило

То, что я показал в этих трёх статьях — не латание дыр в производительности 1С. Это смена подхода к вычислениям.

Последовательный перебор на CPU — это привычка, которая тянется десятилетиями. Она работала, пока объёмы данных были терпимы. Сегодня, когда в регистрах лежат миллионы и десятки миллионов записей, эта привычка стала тормозом. Бизнес теряет деньги, пока система думает.

Видеокарта в вашем компьютере — это тысячи вычислительных ядер, которые простаивают, пока вы ждёте закрытия месяца. Я создал инструмент, который позволяет задействовать эту мощь для задач 1С. Не в облаке, не в кластере, а локально — на том же ПК, где запущена платформа.

Три задачи — три победы:

• Авансы: 600–700 раз быстрее.

• Себестоимость тремя методами: 300 раз быстрее.

• MRP с Монте-Карло: 2500+ раз быстрее.

Это не предел. Дальше — распределение косвенных расходов, расчёт НДС, скользящие средние, план-фактный анализ. Всё, что можно распараллелить по бизнес-сущностям — контрагентам, товарам, документам — может и должно считаться на GPU.

Инструмент открыт. Исходники доступны. Примеры работают. Если вы 1С-разработчик и ваши расчёты тормозят бизнес — добро пожаловать в мир параллельных вычислений. Будущее наступило, и вы можете потрогать его руками.