Product catalog enrichment: e-commerce's quiet AI bill

E-commerce catalogs are bigger than people realize.

A mid-sized online retailer has tens of thousands of SKUs. A marketplace platform — Amazon, Etsy, Faire, Shopify-style aggregators — has millions to hundreds of millions. Each product in each catalog needs: a title, a description, structured attributes, category assignments, SEO-optimized variations, alternate-language versions for international markets, and increasingly, AI-generated images or video content.

A lot of this is done by AI now. Some of it has to be — the human alternative doesn't scale. And the cloud LLM bill for this work, at any serious e-commerce operation, is one of the higher line items in the technology budget.

The math

A representative mid-sized retailer with one hundred thousand SKUs.

Each SKU gets a description generated or refined by AI. Each SKU gets structured attributes extracted from supplier data. Each SKU gets SEO-optimized title variations. Each SKU gets translated into target market languages — say, five languages on average. Each SKU gets refreshed when supplier data changes (frequent for fast-moving categories).

A reasonable token budget per SKU per pass is six thousand input tokens (supplier data, category context, brand voice) and one thousand output tokens (the description, attributes, SEO variants). At frontier pricing, about $0.033 per SKU per pass.

Multiply by five languages: $0.165 per SKU per pass.

Now factor in passes per year. Catalog content gets refreshed when supplier data changes (a few times per year for stable products, monthly for fast-moving ones). Average four passes per SKU per year.

Across a hundred thousand SKUs: $66,000 per year, for one mid-sized retailer.

For a larger retailer — a million SKUs — the bill is $660,000 per year. For a marketplace platform with ten million products, the math is sobering: $6.6 million per year, just for the catalog enrichment layer.

These numbers are not hypothetical. We have talked to e-commerce operators whose cloud LLM bill for catalog work is the largest line item in their AI budget, and where the line item is growing faster than the catalog because the AI workflows keep getting richer.

Why this is a strong local-SLM workload

The standard properties are all present, and several are unusually strong in retail.

The work is narrow. The model needs to know one retailer's catalog conventions — the product categories the retailer carries, the description style the retailer prefers, the brand voice across the catalog, the SEO patterns that have historically performed. A model trained on the retailer's own catalog will outperform a general model on the retailer's own work.

The work is repetitive in an extreme way. The same shape of input (supplier data), the same shape of output (a product listing), repeated tens or hundreds of millions of times across the catalog. This is the kind of repetition where specialization produces dramatic quality improvements.

The volume is enormous and grows with catalog growth. The cloud LLM bill scales linearly with SKU count, which scales with the retailer's expansion. The bill never stops growing.

The privacy story is less acute than in regulated industries, but the commercial sensitivity is real. Supplier data, pricing patterns, category strategy — sending all of this to a third-party cloud LLM is a posture not every retailer is comfortable with. For retailers that have proprietary supplier relationships or unique product categorization frameworks, the competitive intelligence the AI is touching is real intellectual property.

The latency story is real in the live-catalog case. When a new product is being onboarded and the AI is producing the listing for review, fast response keeps the operator in flow. For products being onboarded at scale (a few thousand per day at a busy retailer), the cumulative latency cost is meaningful.

What changes with local inference

A catalog enrichment workflow on a local SLM looks like this.

A model is fine-tuned on the retailer's existing catalog — historical listings, brand voice, category taxonomy, SEO patterns that have driven traffic. The fine-tune captures the retailer's specific approach to listing creation.

The model runs on infrastructure the retailer controls. Supplier data flows in, structured listings flow out. The output goes into the catalog management system, the storefront, the marketplace integrations.

The cost flips from per-SKU to fixed. Catalog growth — new categories, new geographic markets, new supplier integrations — can happen without the bill spiking.

The brand consistency improves dramatically. A general model writes listings that sound like generic AI-generated e-commerce copy. A fine-tuned model writes listings that match the retailer's voice across the entire catalog.

The SEO performance often improves too. A model trained on the retailer's historical performance data — which listings drove traffic, which variations converted — produces SEO content that is genuinely better-tuned to the retailer's specific search-traffic patterns.

What gets unlocked at zero marginal cost

The interesting thing about catalog enrichment on a local model is what becomes possible once the per-SKU cost drops to electricity.

Continuous catalog optimization. Every listing can be revisited, re-evaluated against current performance data, and updated. With a cloud LLM, this is too expensive to do often. With a local model, it can run continuously.

Long-tail SEO at full coverage. Every SKU can have dozens of SEO variations generated and tested. The long tail of search traffic, which is hard to monetize without per-listing investment, becomes economically accessible.

Multi-modal enrichment at scale. Generating alternate images, video snippets, or 3D views for every product becomes affordable when the inference is local. The catalog becomes richer for the customer.

Real-time inventory-driven content updates. As prices, availability, or promotions change, the listings update in near-real-time. The catalog becomes more accurate without the cost of cloud inference at every update.

These capabilities are all infeasible in a cloud-LLM-first architecture because the cost scales too aggressively. A local-SLM architecture unlocks them.

When the cloud LLM is still the right call

A few cases.

For very small catalogs (under a few thousand SKUs) where the infrastructure investment doesn't pay back. The threshold is lower than people guess — a few thousand SKUs is enough if the refresh rate is high — but it isn't zero.

For brand-new retailers without enough catalog history to fine-tune on. The cloud LLM helps in the first six to twelve months.

For specialized content categories where the model needs reasoning beyond catalog patterns — say, AI-generated styling advice or comparison content that draws on cultural context outside the catalog. A frontier model's breadth helps for these.

For everything else — the recurring, scale-driven, brand-voice-relevant catalog work that constitutes most of the AI in modern e-commerce — the local-SLM case is strong.

The pattern, in retail

Avery NXR scaffolds Next.js applications. It does not enrich e-commerce catalogs. The architectural pattern repeats.

Product catalog enrichment is a narrow, repetitive, extreme-volume, brand-sensitive workload. The economics that favor a specialized local model for code scaffolding are the same economics that favor a specialized local model for catalog enrichment. The cost scale here is among the largest in this series — at marketplace scale, the savings are in the millions per year.

The retail AI vendors that build excellent catalog tooling on local infrastructure — with appropriate fine-tuning, integration with the major commerce platforms, and sensible business models — will find willing buyers across the e-commerce stack. The cloud-LLM-default products will hold the market until the bills get loud enough to force the conversation.

The pattern continues. Retail is one of the workflows where the case for local is unusually clean — the cost scale is enormous, the brand-voice quality story is real, and the implementation patterns are well-understood. The architectural shift here may happen faster than in other operational categories.