Enterprise Challenges and Opportunities in Large-Scale LLM Deployment
barclays · Tech · 2024 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Large-scale enterprise LLM deployment
The Barclays/West Group talk explains why large organizations struggle to industrialize LLM and GenAI deployments: cost per task, emerging infrastructure, data-layer changes, monitoring, human evaluation, and organizational standardization all differ from classic MLOps.
Constraints:
- Model choice must be evaluated by task cost, latency, throughput, and business value rather than leaderboard rank.
- Enterprise GenAI stacks add vector databases, prompt hubs, application databases, orchestration, monitoring, logging, caching, and new data fabrics.
- Pre-training and fine-tuning can be expensive and should be justified by core business value.
- Monitoring needs objective ground truth, subject-matter expertise, human evaluation, and LLM evaluation.
- Large teams need common process and architecture despite rapidly changing tools.
Architecture
The recommended architecture is an industrialized GenAI platform: choose foundation models by task economics, avoid pre-training unless core to the business, fine-tune only through scalable frameworks, use off-the-shelf storage/latency optimizations, build reusable architectures, augment the data layer with vector databases and prompt hubs, and coordinate teams through centers of excellence and architecture functions.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR use-case-portfolio["Use case portfolio"] --> model-selection-layer["Model selection layer"] model-selection-layer --> orchestration-and-optimization["Orchestration and optimization"] orchestration-and-optimization --> data-fabric["Data fabric"] data-fabric --> monitoring-and-evaluation["Monitoring and evaluation"] monitoring-and-evaluation --> center-of-excellence["Center of excellence"] center-of-excellence --> architecture-team["Architecture team"]
Components
| Component | Role | Interacts with |
|---|---|---|
Use case portfolio |
Collection of GenAI tasks evaluated for value, cost, and production readiness. | Model selection layer |
Model selection layer |
Chooses foundation models, fine-tuning, or off-the-shelf approaches by task cost and fit. | Orchestration and optimization |
Orchestration and optimization |
Uses orchestration, monitoring, logging, caching, quantization, memorization, and latency optimization. | Data fabric |
Data fabric |
Adds vector databases, prompt hubs, application databases, and metadata tracking to existing data platforms. | Monitoring and evaluation |
Monitoring and evaluation |
Combines ground truth, SME review, human evaluation, and LLM evaluation. | Center of excellence |
Center of excellence |
Shares learnings and standardizes practice across large teams. | Architecture team |
Architecture team |
Keeps dynamic GenAI architecture coherent as tools evolve. | — |
Data flow
Use cases flow through task-specific model selection, orchestration and data-layer services, monitoring and evaluation workflows that combine ground truth, SMEs, humans, and LLMs, then feed learnings back through centers of excellence and architecture teams.
Why this architecture
The speaker argues that enterprise LLMOps must adapt MLOps learnings to a new stack while controlling cost, latency, monitoring, and team standardization at enterprise scale.
Models used: LLMs · GenAI · LangChain · LlamaIndex · Griptape · Vector databases · Prompt hubs
Scale
- The West Group team has 500 data scientists and engineers.“at that West group where I work we have 500 data scientists and engineers”transcript, stated
- The talk says 80-90% of organizations struggled to put solutions into production when data science took off.“science took off 80 to 90% of organizations couldn't put Solutions in production”transcript, stated
- The speaker frames costs by query, user, response, and day.“I want to think what's the cost per user per response per day Etc”transcript, stated
Alternatives considered (roads not taken)
Select models by leaderboard ranking.
Rejected because: Enterprise leaders need task economics, latency, throughput, and problem fit.
Pre-train an enterprise-specific model by default.
Rejected because: The speaker recommends avoiding pre-training unless it is core to the business value proposition.
Let each team invent its own LLMOps process.
Rejected because: A 500-person data/engineering organization needs shared scripts, centers of excellence, and architecture teams.
Patterns
cost-aware-routing (model-ops)
The talk prioritizes model/task decisions by cost per query, user, response, and day.
eval-driven-development (evaluation)
Monitoring combines objective ground truth, subject-matter expertise, human evaluation, and LLM evaluation.
rag-retrieval (retrieval)
The enterprise data layer expands to include vector databases and large RAG systems.
semantic-caching (optimization)
Caching is part of the adapted enterprise stack for cost and latency optimization.
Tradeoffs
Industrialize GenAI using MLOps lessons.
Chose Reuse MLOps practices with LLM-specific caveats. over Treating GenAI as entirely separate from prior production ML practice..
Rationale: The speaker expects LLM practice to mature similarly to MLOps after early production confusion.
Use reusable portfolios of tools and architectures.
Chose Reusable tools, architectures, and optimization techniques. over One-off infrastructure per use case..
Rationale: Enterprise scale requires budget justification and shared standards.
Gotchas (what bit them)
Enterprise GenAI stacks change faster than large-company budgeting cycles.
Root cause: New infrastructure and tools emerge while enterprises have long intake and budget processes.
Resolution: Use nimble architectures and centers of excellence that reuse learning across teams.
Pre-training and fine-tuning can become unjustified cost centers.
Root cause: Models, storage, large RAG systems, and latency optimization all cost more at enterprise scale.
Resolution: Avoid pre-training unless core, use scalable fine-tuning frameworks, and reuse off-the-shelf optimizations.
Monitoring cannot be only automated.
Root cause: LLM systems require subjective and domain-specific judgment as well as ground truth.
Resolution: Combine objective ground truth, SMEs, human evaluation, and LLM evaluation.
Evaluation
The talk evaluates enterprise readiness through cost per task, latency, throughput, ROI, human/SME evaluation workflows, and organization-wide standardization.
Metrics: Cost per query · Cost per user/response/day · Speed/latency · Throughput · ROI · Human evaluation workflow · Standardized practice across 500 data scientists and engineers
Outcomes
- The talk produces a practical LLMOps strategy for large enterprises: avoid default pre-training, optimize storage/latency/cost, build reusable architecture, and standardize across teams.
- The organization-level recommendation is to industrialize GenAI development using centers of excellence and architecture teams.
The source references a 500-person data/engineering group and cost units per query, user, response, and day.