Cost-Optimal Foundation Model Deployment Portfolio for Transportation Management
06:00 · July 16, 2026 · arXiv cs.AI RSS

Foundation models, including large language models (LLMs) and vision-language models (VLMs), are increasingly used for transportation management center (TMC) tasks such as anomaly detection, incident reporting, and traveler information. Deploying multiple such models across TMC functions raises a portfolio question: which model should serve each function, in which deployment mode, and under what shared hardware budget? We formulate this as the Foundation Model Deployment Portfolio (FMDP) problem, a mixed-integer program minimizing total cost of ownership (TCO) subject to per-function quality, latency, and safety constraints over shared GPU capacity. We prove the problem NP-hard by reduction from the 0-1 knapsack problem and propose a polynomial-time greedy heuristic. In an illustrative case study with five TMC functions and 19 candidate (model, mode) pairs, FMDP identifies a mixed portfolio costing $34/mo (97% below the cheapest feasible all-closed-API baseline) by routing four functions to open-source APIs and the one function whose quality floor no open-source model meets to a closed API. Break-even analysis shows that on-premise GPU investment becomes reasonable only above approximately 309 vision queries/hour or if API prices double.
Summary
Transportation management centers run continuous operations that include incident detection from CCTV feeds, report drafting, traffic-state prediction, and traveler-information services. These tasks increasingly draw on foundation models such as large language models and vision-language models, yet agencies must decide which model serves each function and in which deployment mode—closed-source cloud APIs, open-source hosted APIs, rented cloud GPUs, or on-premise hardware—while sharing a finite GPU budget.
The Foundation Model Deployment Portfolio (FMDP) problem formalizes this choice as a mixed-integer program. It minimizes monthly total cost of ownership across all functions subject to per-function lower bounds on quality, upper bounds on latency, and, for safety-critical tasks, upper bounds on domain-specific error rates such as false-negative rate. Shared GPU memory capacity couples the decisions: loading one large model can force another function onto a more expensive API. The formulation distinguishes four deployment modes that differ in variable per-token pricing, fixed rental or amortization costs, and data-sovereignty properties.
The authors prove NP-hardness by reduction from the 0-1 knapsack problem and supply a polynomial-time greedy heuristic that respects the capacity and quality constraints. In an illustrative instance with five TMC functions and nineteen candidate (model, mode) pairs, the optimizer selects a mixed portfolio whose monthly cost is $34—97 percent below the cheapest feasible all-closed-API baseline—by routing four functions to open-source APIs and reserving a closed API only for the single function whose quality floor no open-source model satisfies. Break-even analysis indicates that purchasing on-premise GPUs becomes attractive only above roughly 309 vision queries per hour or if API prices roughly double.
Why it matters
This research provides a rigorous, mathematically grounded framework for cost-optimal AI deployment, which is highly relevant for Dutch researchers and practitioners in smart mobility and AI infrastructure. The focus on balancing on-premise (sovereign) and cloud deployments aligns with EU data strategies and Dutch public sector AI adoption goals.






