AI offer writing for machine and plant builders: specifications, offer texts, own server

AI for offers in machine and plant building

Machine and plant builders can use a language model on their own server for two parts of a technical offer: it reads the customer's specification into a list of requirements with page references, a deviation list and clarification questions, and it assembles the technical part of the offer from earlier offers and approved text modules. The price, the delivery terms and the margin come from the ERP system or the calculation tool, never from the model, and the sales engineer checks and signs the offer.

For a sales department, one NVIDIA RTX PRO 6000 Blackwell Server Edition card carries this work; a server with two cards adds document conversion and search, and a four-card server runs offers next to the AI tasks of other departments. We wrote this for managing directors, heads of sales and the sales engineers who write offers of 30 to 100 pages for machines built to order. Terms are explained where they first appear, the hardware is in one section with a table, and the notes for IT come at the end.

How an engineer-to-order offer comes together

Machines and plants built to order, often called engineer-to-order, start with a request from the customer. In German-speaking industry that request often comes as a Lastenheft, the customer's specification of what the machine has to do; the supplier answers with an offer and, later in the project, with a Pflichtenheft that describes how it will meet each requirement. Between request and offer, the sales engineer does four things:

1. Reads the specification, often more than a hundred pages with annexes, standards and the customer's own terms.
2. Decides which standard machine, which options and which special designs fit.
3. Writes the technical description, the scope of supply and the list of deviations from the specification.
4. Gets the price from the calculation and the approvals for risky points.

Steps 1 and 3 are text work, and that is where a language model helps. Step 2 is engineering judgement, and step 4 belongs to the calculation and to the people who approve it. Shops that quote machined parts from drawings have a different process, which our guide to AI quoting from drawings for CNC job shops covers.

RFQ analysis: requirements from the customer's specification

The first task is to turn the specification into something a team can work through. The model goes through the document section by section and extracts every requirement into a table: the requirement in the customer's words, the page and clause, a category such as performance, safety, documentation or commercial terms, and a first mark of whether your standard machine meets it, meets it with an option, or deviates.

Our description of the workflow; the model drafts each output, the people in the third column release it.

The page reference is what makes the list usable: every line points back to the clause it came from, so a reviewer can check it in seconds. The model also helps with what people miss under time pressure, such as a requirement in an annex that contradicts the main text, or a standard named in a footnote. It will also miss things, so the list is a draft for the engineer, and the specification itself stays the binding document.

Length matters here. Tokens are the units in which a model counts text, and German needs more of them than English: the preprint quoted in our article on tokens per word in EU languages reports a mean of 1.76 tokens per word for German, 1.23 for English and 2.25 for Polish. A specification of 100 pages at 400 words a page, our example value, has 40,000 words: about 70,400 tokens in German and 49,200 in English by our arithmetic. Both fit into the 131,072-token context of gpt-oss-120b in one request, which lets the model check cross-references across the whole document after the section-by-section pass. Scanned specifications first go through OCR, the conversion of page images into text; by the method of our guide to vision-language models for document AI, one RTX PRO 6000 Server Edition converts about 0.69 pages a second with a 5B OCR model, so 100 pages take under three minutes on a whole card; a MIG instance is slower, and we found no published figure for it.

Generating offer text from previous offers

The second task is writing. A machine builder's earlier offers hold most of the text a new offer needs: the description of the standard machine, the texts for each option, the scope of supply, the documentation and training that come with it. The model works with retrieval, often called RAG: it searches the archive of earlier offers and approved text modules for the options in this request, and writes the technical description from what it found, with the source of each paragraph.

Three rules keep this useful.

• Approved modules first. Texts that sales and design have approved for an option are the preferred source; free text from old offers comes second and is marked as such in the draft.
• Current machine, current text. Each module carries the machine generation and the date it was approved, so the model does not describe an option that was changed two years ago.
• Won and lost offers. Notes on why an offer was won or lost, written by the sales team, help the model and the next engineer to see which arguments worked for which customer type.

The draft goes to the sales engineer, who edits it and adds the parts that need judgement. Our guides to RAG on company data and to preparing company documents for an AI assistant explain how to build such an archive. Public tenders follow formal rules of their own, covered in our guide to answering public tenders with an internal AI.

Why the price stays in the ERP

A language model writes plausible text, and a plausible price is a risk. The design therefore keeps every number with commercial weight out of the model's hands. The price, discounts, payment terms and delivery terms come from the ERP system or the calculation tool, through a tool call or as fields the offer template fills, and the model never writes them itself. The same applies to hourly rates and margins, which do not belong in the prompt at all.

The model can still help the calculation in a supporting role: it lists the options and special designs found in the specification, so the calculator works from a complete list, and it flags requirements that usually drive cost, such as an unusual material, a performance test at the customer's site or extended warranty terms. The calculator decides. Orders that arrive later as emails and PDFs are a separate task, which our guide to AI order entry from emails and PDFs into the ERP covers.

Through our Private AI/ML service we set up the models, the offer archive and the ERP connection and supply the server; send us a typical specification length, your offers per month and where your offer texts sit, and our team replies with a configuration.

Confidential requests and your own know-how

This is general information, not legal advice; your legal counsel confirms what your contracts allow. Customer specifications often come with a non-disclosure agreement, and some customers forbid any processing of their documents by third parties. Your own offers contain prices, margins, hourly rates and design know-how. Directive (EU) 2016/943 on trade secrets protects such information only if it is secret, has commercial value because it is secret, and "has been subject to reasonable steps under the circumstances" by the person in control of it to keep it secret (Article 2(1)).

A model on your own server keeps the specifications, the offers, the prompts and the drafts on hardware under your access rules, with no external service unless you switch one on. Access in the offer archive follows your sales organisation: a regional team sees its own customers' documents, and margins never enter the index. Our article on trade secrets, NDAs and AI tools goes into the contract side. Offers carry the names of customer contacts, so the GDPR applies to that personal data in the archive.

Which server, and why one server serves several departments

Two numbers size the hardware. The model has to fit into the memory of the graphics card, the GPU, and every request in progress needs extra memory for its context, the cache. Our users-per-card rule takes 90 per cent of the 95.6 GiB that the driver reports for a 96 GB card, less 3 GiB per card, less the weights: 83.0 GiB per card.

Reference configurations on our AI servers page; requests by our users-per-card rule with gpt-oss-120b (60.8 GiB) and a 16-bit cache; power by our estimate with the cards at 600 W, processors and 15 per cent for the rest of the server.

gpt-oss-120b is published under Apache 2.0, with 117B parameters of which 5.1B are active per token, and its files take about 65 GB, 60.8 GiB. That leaves 22.2 GiB of cache on one card. Its config.json gives 18 full-attention layers with 8 key/value heads of dimension 64, which by our arithmetic makes 36 KiB of 16-bit cache per token: 4.5 GiB for a full request of 131,072 tokens, 2.4 GiB for the German example specification and 1.125 GiB for a drafting request of 32K tokens. One card therefore holds four full-length requests at once, nine of the example specification, or 19 drafting requests.

A sales team of twenty engineers rarely has more than a few long requests running at the same moment, so the offer work alone needs one card. That is why it pays to run it on a company AI server: the two-card entry server with two AMD EPYC processors, 384 GB of DDR5 ECC and two NVMe drives carries offers, and its second card, split by MIG into four isolated 24 GB instances, runs OCR, the search models and tests. On the four-card inference node with 768 GB, the same model as a tensor-parallel pair keeps 2 × 83.0 − 60.8 = 105.3 GiB for the cache, 23 full-length requests, and serves sales, the service assistant, technical documentation and other departments from one platform. Our article on an AI server for a company of 10 to 100 people shows how such a shared server is planned.

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. By our estimate, the two-card server draws about 1.8 kW at the wall with two EPYC 9135 processors and fits one 230 V 16 A feed, which carries 2.94 kW at 80 per cent; the four-card server draws about 3.4 kW with the cards at 600 W and needs 32 A or three-phase, or about 2.7 kW with the cards capped at 450 W. Both belong in a server room or a data centre, as our guide to GPU server power on 16 A, 32 A and three-phase feeds explains.

Notes for the IT team

1. Engine and API. vLLM serves gpt-oss-120b through an OpenAI-compatible API, and the offer tool or a small web front end calls it behind an LLM gateway with keys and a query log. The gpt-oss-120b model card states that the model "should only be used with the harmony format", so use an engine release that supports it.
2. ERP and CRM. Give the platform read access to the offer archive and the product configurator, and fetch prices and terms only through a defined interface into the offer template. The model writes no data back into ERP or CRM.
3. Prefill time. A long specification spends most of its time being read in before the first word of the answer appears. We found no published prefill rate for gpt-oss-120b on these cards, so measure it with your own documents in the pilot, as our guide to what a private AI pilot should measure describes.
4. Network and versions. vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere, while routes such as /invocations and /metrics answer without the key (vLLM 0.32.0 security guide), so keep the engine on an internal network behind the gateway. Run vLLM 0.31.0 or later, the NVIDIA Container Toolkit 1.17.8 or later and a driver release that NVIDIA lists as fixed in its bulletin of 30 September 2026.
5. Software on delivery. The server arrives on request with the operating system, the NVIDIA driver, CUDA and a container runtime; our guide to RTX PRO Blackwell software support lists the engine versions for these cards.

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 two, four or eight RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered within 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. Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up the model, the offer archive with access per sales team and the connection to your ERP. Without a server room of your own, the same platform runs on dedicated hardware in a Tier-3 data centre in Lithuania, inside the EU. To start small, describe one recent request and the offer you wrote for it, and we propose a pilot and the server for it.

FAQ