GLM-OCR: локальное распознавание русских документов

Что такое GLM-OCR и кому он подходит?

zai-org/GLM-OCR — опубликованная модель класса image-to-text; в машинной конфигурации указана архитектура GlmOcrForConditionalGeneration. Автор описывает её как часть конвейера распознавания сложных документов с отдельным компонентом анализа макета PP-DocLayoutV3 и распознаванием областей. Заявленные «0,9 млрд параметров» и результаты OmniDocBench принадлежат автору; они не доказывают качество вашего русского счёта, акта или таблицы. s1 s2 s8

Карточка содержит тег языка ru. Это основание включить модель в кандидаты на тест, а не обещание точности русского OCR: разметка в карточке не является оценкой на ваших шрифтах, печатях и сканах. Для первички сначала определите выходные поля и проверку в сценарии распознавания документов для 1С, затем сравнивайте результат с оригиналом. s1

Маршрут решения: документ и обязательные поля → GLM-OCR как кандидат → память и окружение под выбранный runtime → Ollama или сервер vLLM/SGLang → сверка полей → только после неё интеграция. Из размера весовых файлов нельзя вывести необходимую RAM/VRAM: на неё влияют компоненты обработки изображения, контекст, параллелизм и конкретная конфигурация; аппаратный порог здесь не измерялся. s1 s3 s4

Модель, SDK и лицензии: что не смешивать?

Карточка весов GLM-OCR заявляет MIT; у проекта Python SDK в pyproject.toml указана Apache-2.0. Полный document-parsing pipeline дополнительно использует модель layout PP-DocLayoutV3, карточка которой помечена Apache-2.0. Проверьте тексты условий и используемые компоненты отдельно перед промышленным или коммерческим применением: здесь нет юридического заключения и «одной лицензии на весь стек». s1 s6 s7

Автор рекомендует SDK для разбора документа: он связывает layout-анализ и OCR и формирует Markdown/структурированный результат. Для извлечения конкретных полей карточка отсылает к прямому вызову модели со строго заданной JSON-схемой, а не обещает, что команда glmocr parse вернёт готовую запись 1С. Отдельно проверяйте наличие пустых, ошибочно распознанных и выдуманных полей. s1 s3

Как подготовить локальный путь, не отправив документ в облако?

У SDK есть облачный MaaS и self-host через vLLM/SGLang или Ollama. В закреплённом glmocr/config.yaml стоит pipeline.maas.enabled: true, хотя пример в README называет false значением по умолчанию. Не доверяйте слову «локально» в инструкции установки: явно задайте false в собственном конфиге и проверьте фактические сетевые обращения до работы с конфиденциальными файлами. pip install glmocr сам по себе не создаёт локальный сервер. s3 s4

Для одного тестового изображения автор отдельно описывает Ollama: ollama pull glm-ocr:latest, затем SDK с glmocr[selfhosted] и конфигурацией native /api/generate. Сначала убедитесь, что конкретный тег модели существует в вашем окружении и зафиксируйте его digest: latest может со временем указывать на иной артефакт. Ollama и SDK устанавливайте только на доверенной машине; сверяйте системные требования на своём устройстве. Следующий фрагмент не запускался Modelium и не доказывает отсутствия сети на вашей машине. s3 s5

ollama pull glm-ocr:latest
ollama list

После активации отдельного Python-окружения установите SDK для self-hosted конвейера: s3

python -m pip install 'glmocr[selfhosted]'

Создайте config.yaml с явным выключением облака и указанием локального адреса; не оставляйте ключ MaaS и не подставляйте клиентский документ в сторонний endpoint. Здесь использованы поля из официального примера Ollama. s4 s5

pipeline:
maas:
enabled: false
ocr_api:
api_host: 127.0.0.1
api_port: 11434
api_path: /api/generate
api_mode: ollama_generate
model: glm-ocr:latest

glmocr parse ./test-document.png --config config.yaml --output ./ocr-result/

Выбирайте обезличенный тестовый скан. Сохраните версию SDK, digest модели, версию Ollama, конфиг и исходное изображение для воспроизводимости. Если SDK обращается к облачному open.bigmodel.cn, остановитесь: значит не подтверждён локальный маршрут; если ответ не приходит, проверьте совпадение model, порта и api_mode. Автор отдельно предупреждает о возможных ошибках vision-запроса через OpenAI-совместимый endpoint Ollama и рекомендует native /api/generate. s3 s4 s5

Как проверить русский документ до решения о внедрении?

Подготовьте небольшой набор своих разрешённых к обработке сканов: печатный счёт, акт, таблицу с похожими символами и один проблемный снимок. Для каждого заранее внесите в эталон номер, дату, сумму, контрагента, табличные позиции и расположение на оригинале. Это предлагаемая методика сравнения на своих данных, не результат замера Modelium. s1

1. Проверьте, что запуск действительно локальный и исходный файл не уходит во внешний сервис: явная настройка maas.enabled: false, сетевой журнал и тест без выхода в интернет. Параметр в файле один не доказывает отсутствие иных соединений. s3 s4
2. Посмотрите извлечённый текст и структуру; отдельно сравните числа, десятичные разделители, кириллицу/латиницу и строки таблицы с оригиналом. В примерах SDK результат сохраняется в Markdown и JSON. s3
3. Для извлечения полей используйте отдельный прямой вызов модели с описанной автором JSON-схемой и валидируйте типы, обязательные поля и соответствие изображению. Нельзя считать правильно сформированный JSON доказательством правильных значений. s1
4. Зафиксируйте число верных/ошибочных полей на вашем наборе, вручную разберите ошибки и передавайте спорные случаи оператору. Не отправляйте результат автоматически в 1С, пока не определены права доступа и процедура сверки. s1

Если нужна только быстрая визуальная проба, гайд Ollama Vision API показывает передачу изображения; это проверка возможности мультимодального вызова, не замена разбора структуры документа. Если требуется контроль происхождения весов, начните с проверки файлов на Hugging Face. Основной следующий шаг — составить критерии проверки первички для 1С и подтвердить поля на собственном эталоне. s1 s2