# IBM Palette Explained: The Slide-Deck Model, Benchmarks and Deployment Limits

IBM's small-model slide research shows why design-specific training helps, but the public implementation is more than a single 20B model.

By Paras Madan | 2026-11-04


IBM Research described Palette on November 3, a system that fine-tunes a 20B model to generate slide decks in a particular design language. Its reported results are competitive on three PresentBench domains. The useful idea is separating content planning, slide construction and checking, rather than expecting one generation pass to do everything.

## What IBM's Palette research shows

The [research team's report](https://huggingface.co/blog/ibm-research/palette-deck-building) describes one LoRA adapter serving two roles. A designer produces a structured brief; a coder converts each slide into pptxgenjs JavaScript. Training used roughly 1,000 synthetic decks containing about 10,000 slides, shaped around IBM's design language.

Across 131 evaluated decks, the check-and-repair harness added 3.5 points on average. Palette ranked first in Economics and Education and third in Talk. Its three-domain mean was 59.7, compared with NotebookLM's 60.8.

These are IBM-reported results, not an independent reproduction. A separate frontier model prepared the input plans, and the comparison used baseline figures from the PresentBench paper. The benchmark also does not measure adherence to a particular brand's design language.

That last limitation matters. A deck can be clear and visually strong while still being unusable for a company with strict presentation standards. Brand consistency needs its own test.

## How the public Palette implementation works

IBM's [public project repository](https://github.com/IBM/project-palette) provides a chat interface and command-line workflow. A user can supply a request or reference documents, edit the resulting Markdown plan, build the deck and revise individual slides. The rendering stack uses Node, pptxgenjs and LibreOffice to produce PowerPoint output and previews.

The separation is practical. An editable plan gives a reviewer a place to catch missing arguments and unsupported claims before those mistakes become polished slides. Fixing the narrative after layout is complete usually means changing several slides together.

For example, a technical launch deck might need to distinguish a public API from a preview available only to selected customers. That distinction should be settled in the plan. A geometry checker cannot discover that the availability claim is wrong simply by measuring whether the text fits.

## The 20B research model is not the whole current stack

There is a configuration detail worth checking before treating Palette as a downloadable, self-contained 20B presentation model.

The repository's [current model configuration](https://github.com/IBM/project-palette/blob/main/config.py) defaults the designer and coder to a Qwen2.5-Coder-32B Palette adapter. It keeps the earlier gpt-oss-20b adapter as an option. The planner and repair editor use gpt-oss-120b in the default role setup.

**The research result and the current application defaults describe different configurations.** The 20B benchmark should not automatically be attached to a run of the repository's default settings, nor should the entire workflow's compute requirement be described as 20B.

The setup documentation also requires model backends. It describes IBM RITS access, which requires the IBM VPN, or a configured combination of a self-hosted Code Engine fleet and watsonx. Cloning the public application code alone does not provide those model endpoints. A public download for the evaluated adapter was not identified in the reviewed materials.

## What teams should evaluate before adopting it

Palette's most useful contribution is a workflow that makes parts of presentation quality inspectable. A team can separately ask whether the plan is faithful to the source, whether the slide expresses that plan and whether the rendered result fits.

Those checks should stay separate. A repair that improves spacing can still weaken the argument or omit a necessary qualification. Human review remains especially important for customer, investor and executive presentations, where a small wording change can materially change the claim.

For developers building document-generation products, the next useful comparison would include total pipeline cost, time spent on repairs and how often a reviewer must rewrite the plan. A strong model score becomes commercially useful only when the complete workflow reliably saves people work.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn complex product work into clear launch stories and content their audience can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).