The Invoice That Made the VP of Engineering Call an Emergency Meeting
Bedrock seemed ideal for document processing. Managed infrastructure, pay-per-use pricing, integration with S3 for document storage. A fintech company wired up a pipeline: invoices land in S3, a Lambda function triggers Bedrock’s Claude model to extract line items, amounts, and vendor details, and structured JSON flows into their accounting system. Clean architecture, everyone agreed. Then month-end processing hit — 180,000 invoices in a 72-hour window. The on-demand Bedrock endpoint throttled at 10,000 tokens per second. Processing that should have taken 6 hours stretched to 4 days. Worse, the burst consumed $23,000 in token charges. The VP of Engineering called a meeting at 7 AM on a Monday to discuss “our AWS AI cost problem.”
Document processing at scale demands dedicated compute, not pay-per-token APIs with opaque throttling. Here’s how to migrate your Bedrock document pipeline to a dedicated GPU that processes documents as fast as your storage can feed them.
Mapping the Bedrock Document Pipeline
Most Bedrock document processing setups follow a similar pattern. Map yours against this template to plan your migration:
| Component | Bedrock Architecture | Dedicated GPU Architecture |
|---|---|---|
| Document storage | S3 | S3 / local NVMe / network storage |
| Trigger mechanism | Lambda + S3 events | Queue (Redis/RabbitMQ) + worker |
| Text extraction | Textract + Bedrock | Textract or open-source OCR + self-hosted LLM |
| LLM processing | Bedrock InvokeModel | vLLM OpenAI-compatible API |
| Output storage | DynamoDB / RDS | Any database (same as before) |
| Monitoring | CloudWatch | Prometheus + Grafana |
Note that everything except the LLM component can remain exactly as-is. Your S3 storage, database layer, and downstream logic don’t change. You’re only replacing the Bedrock InvokeModel call with a self-hosted endpoint.
Step-by-Step Migration
Phase 1: Benchmark your current throughput. Measure how many documents per minute your Bedrock pipeline processes at peak, the average tokens per document, and the end-to-end latency. This baseline tells you exactly what your dedicated GPU needs to match.
Phase 2: Provision your GPU. For document processing, throughput matters more than single-request latency. An RTX 6000 Pro 96 GB from GigaGPU running Llama 3.1 70B through vLLM can process 30-50 documents per minute for typical extraction tasks — far exceeding Bedrock’s throttled throughput.
Phase 3: Replace the Bedrock SDK call. The code change is focused on a single integration point:
# Before: Bedrock
import boto3, json
bedrock = boto3.client("bedrock-runtime")
response = bedrock.invoke_model(
modelId="anthropic.claude-3-haiku-20240307-v1:0",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"messages": [{"role": "user", "content": doc_text}],
"max_tokens": 2048
})
)
result = json.loads(response["body"].read())
# After: Self-hosted
from openai import OpenAI
client = OpenAI(base_url="http://your-gigagpu:8000/v1", api_key="none")
response = client.chat.completions.create(
model="llama-70b",
messages=[{"role": "user", "content": doc_text}],
max_tokens=2048
)
result = response.choices[0].message.content
Phase 4: Implement a processing queue. Bedrock’s Lambda integration handles queuing implicitly. With self-hosting, set up a simple Redis queue that feeds documents to your GPU at maximum throughput. This is actually an improvement — you control backpressure, retries, and prioritisation.
Phase 5: Validate output quality. Run 1,000 previously processed documents through both pipelines and compare extracted fields. For structured extraction, use vLLM’s guided decoding to guarantee valid JSON output — something Bedrock doesn’t offer.
Handling Textract Integration
If your pipeline uses Amazon Textract for OCR before sending text to Bedrock, you have two options: keep Textract (it’s billed separately and works fine with a self-hosted LLM downstream), or replace it with open-source alternatives like PaddleOCR or docTR. For scanned documents, Textract remains excellent, but for digital PDFs, a simple text extraction library eliminates the Textract cost entirely.
Teams processing sensitive documents should consider private AI hosting to ensure no document content ever transits through AWS or any third-party service.
Cost and Throughput Comparison
| Metric | AWS Bedrock (On-Demand) | GigaGPU Dedicated RTX 6000 Pro |
|---|---|---|
| 10K docs/month | ~$1,200 | ~$1,800 (fixed) |
| 50K docs/month | ~$6,000 | ~$1,800 (fixed) |
| 200K docs/month | ~$24,000 | ~$1,800 (fixed) |
| Peak throughput | Throttled (unpredictable) | 30-50 docs/min (consistent) |
| Month-end burst capacity | Throttled exactly when you need it | Full capacity always available |
| Data residency | AWS region | UK data centres |
The breakeven is around 15,000-20,000 documents per month. Above that, dedicated GPU wins decisively. Model your exact numbers at GPU vs API cost comparison.
Eliminating the Throttling Problem
The core issue with Bedrock for document processing isn’t just cost — it’s the throughput ceiling. Document workloads are inherently bursty (month-end invoices, quarterly reports, annual audits), and Bedrock’s throttling hits exactly when you need capacity most. A dedicated GPU runs at full speed regardless of calendar date or time of day.
For related guides, see our Bedrock enterprise chatbot migration and the broader TCO analysis of dedicated vs cloud GPU. Explore open-source LLM hosting for model selection guidance, use the LLM cost calculator to project savings, and visit our tutorials section for more migration paths.
Process Documents at Full Speed, Every Day
No throttling, no per-document charges, no month-end surprises. Dedicated GPU servers from GigaGPU handle your document pipeline with consistent, predictable performance.
Browse GPU ServersFiled under: Tutorials