# pdf-to-podcast: an NVIDIA blueprint that turns documents into a spoken briefing > The pdf-to-podcast blueprint is a reference implementation that extracts text from PDFs, asks a Llama model to write a two host podcast script, and speaks it with ElevenLabs, orchestrated across a set of microservices on Docker Compose. It is a sample to adapt rather than a product, and the sample PDFs it ships are bank earnings reports. **NVIDIA-AI-Blueprints/pdf-to-podcast** — Transform PDFs into AI podcasts for engaging on-the-go audio content. - Repository: https://github.com/NVIDIA-AI-Blueprints/pdf-to-podcast - Website: https://build.nvidia.com/nvidia/pdf-to-podcast - Stars: 884 · Forks: 243 - Language: Python - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/nvidia-ai-blueprints-pdf-to-podcast ## A target PDF plus optional context PDFs, and a guide prompt The blueprint accepts a Target PDF and optionally multiple Context PDFs. The Target PDF is the main source of information for the generated transcript, while the Context PDFs are used as additional reference for the agent. That three input design is the interesting modelling decision. A single document is a poor input for a spoken summary, because a transcript of one document has no frame of reference. Give the agent the document you want discussed and a set of documents it should be discussed against, and the output can be a conversation rather than a reading of one file. The user can also optionally specify a guide prompt, which gives a focus for the agent generated transcript, with the example given being to focus on the key drivers for an earnings report. This is the difference between a blueprint and a product, in one line. The blueprint does not decide what the conversation is about, the person running it does. The sample PDFs in the repository make the intended use case obvious, since they are earnings and investor documents: investorpres-main.pdf is the target, and there are context files for Bank of America, Citi, Deutsche Bank, Goldman Sachs, HSBC, JPMorgan Chase and KeyCorp. The samples directory is a complete worked example of the input shape, which is a reasonable thing to include in a blueprint. The README also points at a mermaid diagram in the docs directory for the PDF, agent and text to speech service flows, and an architecture diagram image at the top level. The documentation explicitly says it is there to explain the flows, and the flows are the deliverable. ## Five components, and the ones you can swap out The software component list is short and each entry is a replaceable part. The response generation is handled by NVIDIA NIM microservices, with three named models: NIM for meta/llama-3.1-8b-instruct, NIM for meta/llama-3.1-70b-instruct, and NIM for nvidia/llama-3.3-nemotron-super-49b-v1.5. Document ingest and extraction is Docling, from the DS4SD project. Text to speech is ElevenLabs. Redis handles the queue. And MinIO provides object storage. And the README says the important thing about them directly. Since NVIDIA blueprints are adaptable to your specific business use case and infrastructure, the above software components are configurable. The example given is to decrease the amount of GPU memory required, you can use a smaller Llama 3.1 8B NIM and disable GPU usage for Docling in docker-compose.yaml. So the blueprint is not a claim that you must run those exact pieces. It is a working arrangement of them, with the substitution points named. That is the difference between a sample and a framework, and it is why the compose file and the models.json are in the repository rather than hidden behind a packaging step. The three Llama options are a size ladder. The 8B model is the one that fits on a smaller GPU or on a CPU-only box, the 70B is the quality option, and the Nemotron Super 49B sits between them. The models.json file is mounted into the agent service by the compose file, which means the model choice is a configuration file you edit rather than a code change. ## Four services and two queues, and what each one owns The docker-compose.yaml is the clearest description of the architecture, and it is more revealing than the prose. There are four application services built from the repository, each with its own Dockerfile under services/: api-service on port 8002, agent-service on port 8964, pdf-service on port 8003 and tts-service on port 8889. Alongside them sit redis on 6379 and minio on 9000 with a console on 9001, and jaeger for tracing, which the CORE_SERVICES list in the Makefile confirms. The api-service is the front door and it knows the others by URL: PDF_SERVICE_URL, AGENT_SERVICE_URL and TTS_SERVICE_URL, plus REDIS_URL. The agent-service has NVIDIA_API_KEY, REDIS_URL and MODEL_CONFIG_PATH, with models.json mounted in. The pdf-service has REDIS_URL and a MODEL_API_URL that defaults to an internal pdf-api, and an extra_hosts entry mapping host.docker.internal to the host gateway so that a locally hosted model API can be reached from inside the container. The extra_hosts entry is a small but telling detail. It means the intended development loop includes running the model locally on your workstation and having the container call it, which is the same idea as the MODEL_API_URL default and the comment in the Makefile about a dev target that does not locally run and build Docling. Redis is doing the work of a job queue between the stages, and MinIO is holding the extracted and generated artefacts. Neither is mentioned as optional, and both are in the CORE_SERVICES list that the dev target tears down and restarts. The API service is a FastAPI application, and the requirements file gives the rest of the Python picture: websockets, uvicorn with the standard extras, pydantic, redis, asyncio, minio, httpx, jinja2 for templating, ujson, and then the ones that reveal the development workflow, ruff for linting, jupyterlab and gradio for the interactive pieces. ## The quick start is four commands and two API keys The Quick Start Guide is the part of the documentation that is genuinely usable, and it is short. The system requirements for the Docker Compose path are an Ubuntu 20.04 or 22.04 based machine with sudo privileges, Docker Engine and Docker Compose with the plugin version 2.29.1 or higher, and git. The NVIDIA Container Toolkit is needed to configure Docker for GPU accelerated containers. The keys are the interesting prerequisite, because there are two different vendors involved. For NIM you sign in to the NVIDIA Build portal with your email, click any model, then click Get API Key and Generate Key, or you go through the NGC portal, where you must select an organisation that has NVIDIA AI Enterprise enabled, and generate a personal key. That key goes into the NVIDIA_API_KEY environment variable. Separately you need an ElevenLabs key. The repository is cloned and the environment variables are written to a .env file: ```bash #Create env file with required variables in /home//.local/bin/env echo "ELEVENLABS_API_KEY=your_key" >> .env echo "NVIDIA_API_KEY=your_key" >> .env echo "MAX_CONCURRENT_REQUESTS=1" >> .env ``` The MAX_CONCURRENT_REQUESTS setting has an explanation attached: the ElevenLabs API key can handle concurrent requests, but for local development set it to 1 to avoid rate limiting issues. That is a small piece of advice that saves a debugging session, because a rate limit error in the middle of a pipeline is easy to misread as a service bug. The dependency step is one target, and the documentation says what it does: ```bash make uv ``` It installs UV if it is not present, creates the virtual environment and installs the project dependencies, and the note says that running make uv again in a new terminal will reuse the same environment. Then the development server is started with: ```bash make all-services ``` That target verifies the environment variables are set, creates the necessary directories and starts all services using Docker Compose in build mode. The warning attached to it matters: the first time you run make all-services, the docling service may take 10 to 15 minutes to pull and build, and subsequent runs will be much faster. ## The hardware bill is bigger than the code The hardware requirements are given as two deployment paths, and the numbers in the first one are the ones to read carefully. The default path uses the NVIDIA API catalog NIM endpoints, and it can run on any non GPU accelerated machine or VM. The requirements for that are 8 CPU cores, 64 GB of memory, 100 GB of disk space, and a public IP address. 64 GB of memory and 100 GB of disk for a service that turns a PDF into an audio file is a lot, and the reason is that the default path still runs the document extraction locally. Docling is a heavy component, and the first run pulling and building the docling service for 10 to 15 minutes is a hint of the size of the artefact involved. The second path is to host the NIM yourself, and the documentation links the support matrices for Meta Llama 3.1 8B Instruct, Meta Llama 3.1 70B Instruct and Meta Llama 3.1 405B Instruct. The note is that to run the blueprint at scale and for faster preprocessing of PDFs, a GPU is recommended for the PDF ingest and extraction pipeline. The prerequisites then add a commercial gate that is easy to miss. An NVIDIA AI Enterprise developer licence is required to host NIM locally, and you need API catalog keys from either the NVIDIA API catalog or NGC, plus an ElevenLabs key for the text to speech side. So the picture is: a blueprint that can run without a GPU if you use hosted model endpoints and accept the memory and disk cost, and one that needs a GPU and an AI Enterprise licence if you want the models on your own hardware. There is also a note that users running the blueprint with NVIDIA AI Workbench should skip to the quickstart section in the workbench directory, which tells you the same pipeline can be driven from a notebook-oriented workflow instead of the compose files. ## Where a blueprint is the wrong deliverable Three situations rule it out, and the first one is the nature of the artefact itself. The first is if you need a product. The README is explicit that this shows developers how to build an application, that Docker Compose scripts are provided to spin up the microservices on a single node, and that the blueprint contains sample use case PDFs but developers can build upon it with their own PDFs. There is one tagged release, 1.0.0 from 2025-01-15, and the last push to the repository was on 2026-10-14. That is a reference implementation with a maintenance cadence, not a supported service. The second is if you cannot use hosted APIs. The default path is the NVIDIA API catalog plus ElevenLabs, and hosting NIM yourself requires an AI Enterprise developer licence. If neither is available to you, the agent and speech stages have nowhere to run, and rewriting both is no longer adapting a blueprint. The third is a content problem rather than a technical one, and it is the one worth taking seriously. A spoken summary of a document is a derivative work that anyone can listen to. The blueprint gives you a pipeline for producing one, and it is designed for earnings reports and investor documents, which is public information. Pointed at an internal document, a document under embargo, or anything with a distribution restriction, the pipeline would produce an audio file that reproduces the substance of a document whose circulation was meant to be controlled. Nothing in the pipeline prevents that, and the fact that the samples are all public financial documents is a description of the intended use rather than a safeguard. The licence is Apache-2.0, with a separate LICENSE_3rdparty file in the repository root for the bundled third party components. The blueprint code is permissively licensed, which is generous, and that licence covers the code and not the documents you feed it or the audio it produces. ## Conclusion pdf-to-podcast fits a team that wants to understand how a document to audio pipeline is put together, and a team that genuinely needs spoken briefings of financial or research documents and is prepared to adapt a reference implementation. It is the wrong choice if you need a finished application, because it is a blueprint with sample content and no service level commitment, and it is the wrong choice if you cannot use hosted APIs, since the text to speech step depends on ElevenLabs and the agent step defaults to NVIDIA hosted endpoints. Before you build on it, read the models.json in the repository root to see which models the agent service is configured to use, and confirm the licence position of the PDF content you intend to feed it, since the blueprint is Apache-2.0 but your documents are not covered by that. ## FAQ ### What is the NVIDIA pdf-to-podcast blueprint? It shows developers how to build an application that transforms PDFs into audio content, using NVIDIA NIM for response generation, Docling for document ingest and extraction, ElevenLabs for text to speech, Redis and MinIO for the queue and storage. It runs as microservices on Docker Compose and is designed to run on a private network. ### What inputs does the pdf-to-podcast blueprint take? A Target PDF, which is the main source for the generated transcript, optionally multiple Context PDFs used as additional reference for the agent, and optionally a guide prompt that gives the transcript a focus. The repository ships sample files including an investor presentation as the target and context files for several banks. ### How do I run the pdf-to-podcast blueprint locally? You need an Ubuntu 20.04 or 22.04 machine with Docker Engine and Docker Compose 2.29.1 or higher, an NVIDIA_API_KEY, an ElevenLabs key, and a MAX_CONCURRENT_REQUESTS value. Then run make uv to set up the Python environment, make all-services to start the services, and be aware the docling service may take 10 to 15 minutes to build on the first run. ### What hardware does the pdf-to-podcast blueprint need? Using the NVIDIA API catalog endpoints it runs on any non GPU accelerated machine or VM, needing 8 CPU cores, 64 GB of RAM, 100 GB of disk space and a public IP address. Hosting the NIM locally instead needs an NVIDIA AI Enterprise developer licence, and a GPU is recommended for the PDF ingest and extraction pipeline at scale. ### Can I change the models the pdf-to-podcast blueprint uses? Yes. The documentation states that blueprints are adaptable to your business use case and infrastructure, and that the listed components are configurable, giving the example of using a smaller Llama 3.1 8B NIM and disabling GPU usage for Docling in docker-compose.yaml. The agent service reads its model configuration from models.json, which the compose file mounts into the container. ## Sources - [License: Apache-2.0](https://github.com/NVIDIA-AI-Blueprints/pdf-to-podcast/blob/main/LICENSE) - [NVIDIA-AI-Blueprints/pdf-to-podcast on GitHub](https://github.com/NVIDIA-AI-Blueprints/pdf-to-podcast) - [Project website](https://build.nvidia.com/nvidia/pdf-to-podcast) - [README](https://github.com/NVIDIA-AI-Blueprints/pdf-to-podcast/blob/main/README.md) - [Releases](https://github.com/NVIDIA-AI-Blueprints/pdf-to-podcast/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nvidia-ai-blueprints-pdf-to-podcast