AI server for archives and libraries: handwriting recognition, OCR and cataloguing

What an AI server does for an archive or library

An AI server for archives and libraries turns scanned holdings into searchable text and draft catalogue records on hardware the institution controls. It runs handwritten text recognition (HTR) on letters, registers, minutes and manuscripts, OCR on printed books, newspapers and forms, and a language model that suggests titles, dates, names and subject terms from the recognised text. A server with two or four NVIDIA RTX PRO 4500 Blackwell Server Edition cards suits an HTR team that trains its own models; four RTX PRO 6000 Blackwell Server Edition cards suit a digitisation programme that runs OCR over millions of pages.

We wrote this for the director of a national, regional or city archive, a research library or a museum, and for the digitisation and IT staff who plan the platform. Figures are published measurements with their source, or our estimates, labelled as such. Our guide to vision-language models for document AI sizes OCR for business documents such as invoices and contracts, and our guide to an AI server for media covers transcripts of audio and video archives; this page covers handwriting, historical print and heritage law.

Three jobs with different loads

Our summary; kraken and eScriptorium documentation read 24 October 2026; OCR models as listed in our document AI guide.

Handwriting is the hard part. A model that reads one clerk's hand in a nineteenth-century register can fail on the next volume, written by someone else, so archives train or fine-tune models per collection and per hand, check the result on a sample and train again. That is iterative GPU work that a transcription team starts several times a week. Printed pages are a throughput problem: the models exist, and the GPU decides how many weeks a project takes. Metadata is the smallest load, because the model reads text that has already been recognised and writes a short record.

Handwritten text recognition with kraken and eScriptorium

kraken is published on GitHub under Apache 2.0 and describes itself as "a turn-key OCR system optimized for historical and non-Latin script material". It trains three kinds of model: segmentation, "finding lines and regions in images", reading order, and recognition, which turns line images into text. It supports right-to-left, bidirectional and top-to-bottom scripts and writes ALTO, PageXML, abbyyXML and hOCR. Training data can come from ALTO and PAGE XML files, and its documentation says that binary datasets compiled with ketos compile allow "saturation of most GPUs with minimal computational overhead". Existing models are shared through a public repository on Zenodo and fetched with kraken get, and the --load option fine-tunes such a model on your own lines instead of training from scratch.

The GPU is a command-line choice. The ketos training tool takes -d or --device with values such as cpu or cuda:0, and its documentation states that "On GPU, bfloat16 (bf16-true or bf16-mixed) can lead to considerable speedup." The documentation gives no GPU memory figure and no number of lines a model needs, so time a training run with your own material and set the batch size from it.

eScriptorium, under the MIT licence, is the web application many institutions put in front of kraken; its documentation says "The application uses Kraken as a segmentation/transcription engine". Its getting-started page calls Docker containers "the easiest way to deploy eScriptorium", asks for at least 8 GB of RAM and 16 GB or more for training, and states that "A Nvidia GPU is not obligatory but will greatly accelerate model training." Transcribers correct lines in the browser, the corrections become training data, and a new model is trained on the server overnight. On a shared server each training job gets a card of its own, so a team of several transcribers working on different collections can train in parallel.

The RTX PRO 4500 Server Edition fits this pattern. NVIDIA's product page lists 32 GB of GDDR7 at 800 GB/s, 165 W, a passive single-slot full-height card, PCIe 5.0 x16 and up to two MIG instances of 16 GB. Server makers list four of these cards in several 2U chassis and up to eight in 3U to 5U chassis, as our guide to buying a four-card RTX PRO 4500 Server Edition server sets out. Our RTX PRO 4500 Server Edition article covers the card and its driver requirements.

We supply the RTX PRO 4500 Server Edition and build servers with two, four or eight of them; send us your collections, scripts and the size of your transcription team, and our team replies with a configuration.

OCR of printed pages at scale

Printed books, newspapers and typed files run through open OCR models, of which our document AI guide lists several between 0.9B and 8.3B parameters with weights of 2.7 to 10.6 GB, among them GLM-OCR under MIT and DeepSeek-OCR-2 and olmOCR-2 under Apache 2.0. Throughput figures are scarce. Datalab reports 1.44 pages a second for its 5B chandra-ocr-2 on one H100 80GB with vLLM; scaled by memory bandwidth, that is about 0.69 pages a second on one RTX PRO 6000 Server Edition by the method of our document AI guide. On the RTX PRO 4500 Server Edition, with 800 GB/s, the same scaling gives at most about 0.34 pages a second, an upper bound by our estimate, because we have no published compute figure to check whether the card is limited by its arithmetic first.

Our estimates, not measurements: Datalab's 1.44 pages per second for chandra-ocr-2 on one H100 80GB (model card, undated), scaled by memory bandwidth to each card (3.35 TB/s for the H100 SXM, 1,597 GB/s and 800 GB/s from NVIDIA's pages), one copy of the 5B model per card; the RTX PRO 4500 figures are upper bounds.

Historical print is harder than a modern invoice. Fraktur, worn type, bleed-through and two-column layouts can lower the quality, and a model trained on modern documents may need a kraken model or a fine-tuned model for the collection. Measure the character error rate on a few hundred pages that staff have transcribed by hand before you choose the model or the server, and read the licence: chandra-ocr-2 comes under a modified OpenRAIL-M licence with a revenue threshold, as our document AI guide quotes.

Catalogue metadata from the recognised text

Once a file or volume has text, a language model can draft the descriptive record: a title, the date range, the persons and places named, and subject terms from the institution's own vocabulary, returned as a JSON schema with vLLM's structured outputs so that the archive's software can import it. An archivist then checks and corrects the draft. By our users-per-card rule, Qwen3-14B in FP8 takes 15.2 GiB and leaves 10.5 GiB of cache on one RTX PRO 4500 Server Edition, room for 16 sequences of 8K tokens with an FP8 cache, as our guide to four RTX PRO 4500 Server Edition cards in 2U works out.

The load is small next to OCR. Take 200,000 archival units with a record of 300 output tokens each as an example, 60 million tokens. MLPerf® Inference v6.1 entry 6.1-0050 lists 50,965.3 tokens per second offline for Llama 3.1 8B on eight RTX PRO 6000 Server Edition, about 6,371 per card by our division. At half that rate, our planning margin, four such cards produce the 60 million tokens in about 1.3 hours. We found no published figure for the RTX PRO 4500 Server Edition, so on those cards time a sample first. Our guide to batch LLM inference on-premise explains the queue.

MLPerf® Inference: Datacenter v6.1, closed division, available category, Llama 3.1 8B, offline scenario, entry 6.1-0050, HPE ProLiant Compute DL380a Gen12 with eight RTX PRO 6000 Blackwell Server Edition, retrieved from mlcommons.org on 24 October 2026. Result verified by MLCommons Association. Per card is our division of the system result, not an MLPerf metric. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Search over the text is the next step. An embedding model indexes the recognised pages for search in plain language, as our guide to embedding and reranker servers sizes, and pages where text recognition fails, such as maps, can be retrieved from their images, as our guide to ColPali visual document retrieval describes.

Copyright and data protection for heritage institutions

Directive (EU) 2019/790 on copyright in the Digital Single Market defines a cultural heritage institution as "a publicly accessible library or museum, an archive or a film or audio heritage institution" (Article 2(3)) and text and data mining as "any automated analytical technique aimed at analysing text and data in digital form" to generate information such as patterns, trends and correlations (Article 2(2)). Article 3 requires Member States to provide an exception for reproductions and extractions by research organisations and cultural heritage institutions, for text and data mining of works to which they have lawful access, for scientific research; copies are stored with "an appropriate level of security" and may be retained for research purposes. Article 4 adds a general exception that applies only where rightholders have not reserved their rights, for example by machine-readable means. Article 6 lets cultural heritage institutions make copies of works "permanently in their collections" for preservation.

Records about people bring in the GDPR. Article 5(1)(b) does not treat further processing for archiving purposes in the public interest as incompatible with the original purpose, and Article 5(1)(e) allows longer storage for such purposes, both subject to the safeguards of Article 89(1). Article 9(2)(j) allows the processing of special categories of data where it is necessary for archiving purposes in the public interest on the basis of EU or national law. Recognised text makes personal data in a collection searchable for the first time, so access rules for the search index matter as much as for the reading room.

This is general information on EU law as of October 2026, from the texts on EUR-Lex. The directive applies through national copyright law, which may differ, and national archive laws set their own rules; your legal counsel and data-protection officer confirm how they apply to a project.

Configuration options by card count

The options follow NVIDIA's guide for certified systems: two processors, at least six cores per GPU and system memory of twice the GPU memory; the four-card RTX PRO 6000 build is the inference node on our AI servers page.

Power by our estimate: cards at full power plus processors (2 × EPYC 9135 for two cards, 2 × EPYC 9355 for four) plus 15 per cent for the rest of the server; four and eight RTX PRO 4500 Server Edition and four RTX PRO 6000 Server Edition as in our buying guides.

Two RTX PRO 4500 Server Edition. Two AMD EPYC processors, at least 128 GB of DDR5 ECC by the twice-the-GPU-memory rule, and NVMe drives for the working set. One card trains, the other serves recognition requests from eScriptorium and the metadata model. At about 0.84 kW by our estimate, (2 × 165 W + 2 × 200 W) × 1.15, it fits an ordinary server room.

Four RTX PRO 4500 Server Edition. The four-card build with two EPYC 9355 and 384 GB, at about 1.4 kW by our estimate, lets three teams train at the same time while a fourth card runs OCR. The cards can be capped between 100 and 165 W, per NVIDIA's product brief as quoted in our card article.

Four RTX PRO 6000 Server Edition. For a digitisation programme that has to work through millions of printed pages, this node with 768 GB and four NVMe drives handles about 79,000 pages in an 8-hour window by our estimate, and its 96 GB cards also hold a general vision-language model for difficult pages. It draws about 3.4 kW and needs 32 A or three-phase.

The RTX PRO 6000 Max-Q is the workstation card, a 300 W blower card; in a rack it belongs only in a chassis whose maker lists it, and for continuous operation we recommend the Server Edition. Our Private AI/ML service sets up the recognition pipeline, the models and search; describe the collection you would digitise first, and we propose the server and a pilot.

Notes for the IT team

1. Driver and CUDA. All RTX PRO Blackwell cards are compute capability 12.0, and CUDA 12.8 was the first toolkit to compile for it, as our guide to RTX PRO Blackwell software support explains. The PyTorch build under kraken has to support these cards; check it before the first training run.
2. eScriptorium workers. Deploy eScriptorium with Docker and give the GPU workers their own containers; the getting-started page points to the project wiki for GPU configuration and separate workers.
3. Formats. Keep ALTO or PAGE XML as the exchange format, since kraken reads both for training and writes both for results, and your repository software can store them next to the images.
4. Storage. Image masters stay on the institution's storage; the GPU server needs fast NVMe for the pages of the current job and the training data, as our guide to NVMe storage for an LLM server discusses.
5. Tender. Public archives and libraries usually buy through a tender; our guide to the GPU server tender specification shows how to write memory, power and partitioning as measurable requirements.
6. Software on delivery. The server arrives on request with the operating system, the NVIDIA driver, CUDA and a container runtime installed.

Power and room

By our estimate, two RTX PRO 4500 Server Edition with two EPYC 9135 draw about 0.84 kW at the wall, four with two EPYC 9355 about 1.4 kW and eight about 2.2 kW, so even the eight-card server stays within one 230 V 16 A feed, which carries 2.94 kW at 80 per cent. Four RTX PRO 6000 Server Edition draw about 3.4 kW at 600 W per card and need 32 A or three-phase, or about 2.7 kW capped at 450 W. Plan the feeds on the maker's figure; the estimate is confirmed by a measurement on the delivered system, and our guide to GPU server power on 16 A, 32 A and three-phase feeds works through the options.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build the servers to order with RTX PRO 4500 Server Edition or RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. We also supply the cards for a server you already run, after a compatibility check. Our Private AI/ML service, with engineering by our partner Vixen.UNO, deploys the recognition and metadata models and search. The professional GPU page lists the cards.

FAQ