Tetrate Product Chief Links AI Return to Gateway Infrastructure

ROI Maxxing Case Study: The Alchemy of Shipping Faster, Proving AI Value, and Controlling Token Cost — Ai4

Ai4

Enterprise AI ROI hinges on combining developer output metrics with centralized gateway architecture to curb unpredictable token spending.

AI-assisted summary of ROI Maxxing Case Study: The Alchemy of Shipping Faster, Proving AI Value, and Controlling Token Cost — original source. Check the original for full context.

Source published:

Detailed notes

## Background This talk by David Wang, Head of Product at Tetrate.io, was presented on YouTube by the Ai4 channel on August 18, 2026. According to the page description, the session addresses the critical challenge of proving AI ROI for engineering leaders, providing a practical playbook on defining ROI, selecting infrastructure choices, and controlling token costs through an end-to-end enterprise case study.

## TL;DR David Wang breaks down the AI ROI equation into organizational outcomes (the numerator) and aggregated inference spend (the denominator). He highlights developer productivity as the single largest area of AI token consumption and explains how unconstrained 'token maxxing' and custom proxy scripts lead to massive cost overruns. To fix this, he advocates for an AI Gateway layer—demonstrated live—to centralize multi-model visibility, enforce security guardrails, enable prompt caching, and provide granular usage analytics across engineering teams.

## Atmosphere & style The presentation is pragmatic, technical, and lightheartedly relatable, with Wang opening by warmly acknowledging the extreme Las Vegas conference weather. Using clever analogies like 'Schrodinger's cat' to describe uncertain AI projects and comparing homegrown proxy maintenance to 'adopting a puppy,' he maintains an engaging, conversational rhythm. The live dashboard demonstration shifts the mood from conceptual strategy to crisp, practical execution.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) AI initiatives exist in a 'Schrodinger's cat' superposition of being deployed and dead until ROI is questioned, yielding wildly inconsistent metrics across organizations. - [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) Tetrate leverages Envoy, the open-source proxy routing major global internet and AI traffic, as the architectural backbone for managing AI traffic and ROI. - [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) AI spend is shifting from predictable subscription models to volatile, rapidly compounding costs driven by autonomous agents and changing model provider pricing. - [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) Developer productivity is the primary focal point of enterprise AI token spend because software directly underpins revenue, customer experience, and OPEX. - [04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) The AI ROI equation divides developer-driven outcomes (the numerator) by aggregated inference spend (the denominator). - [04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) Defining the ROI numerator is an organizational leadership challenge, requiring top-down alignment on proxy metrics despite flawed or incomplete data. - [04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) Calculating the ROI denominator is a complex technical challenge due to fragmented token spend across multi-cloud providers, regions, and business units. - [06:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=404s) The AI Gateway serves as a crucial centralized control plane between AI consumers and AI resources, enabling visibility, policy enforcement, and compliance. - [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) Unregulated 'token maxxing' leads to loss of financial control, causing risk-averse executives to overcorrect with total AI lock downs. - [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) Building homegrown proxy layers creates significant engineering drag and inflates long-term infrastructure maintenance costs up to 5x initial estimates. - [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) A distributed AI Gateway architecture allows enterprises to enforce global compliance while maintaining local low-latency routing and model flexibility. - [14:35](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=875s) To drive developer adoption, AI Gateways must provide developer value through real-time spend visibility, semantic prompt caching, and system prompt debugging. - [14:35](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=875s) Granular user-level analytics empower engineering managers to spot usage anomalies, runaway agent loops, and cost disparities across teams.

## Detailed walkthrough Here is the detailed walkthrough of Part 1 of the transcript:

[00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) Defining AI ROI: The Theory, Practice, and Schrodinger’s Cat Problem

David Wang, Head of Product at Tetrate.io, opens his talk by setting the agenda for his session, which is split into three main segments: theory (the concept of ROI in the age of AI), practice (observations from working across regulated industries and startups), and a live demo showcasing the actual infrastructure tools. Addressing the audience at the conference in Las Vegas during the lunch hour, Wang acknowledges the extreme weather conditions—braving air traffic issues, extreme heat, and heavy indoor air conditioning—and asks the room a fundamental question: "How's that transformation going?"

He compares the current state of enterprise AI transformation to Quantum Mechanics' famous "Schrodinger's cat" thought experiment: at any given moment, an AI transformation project is simultaneously going well, deployed, and dead. You never actually know which state it is in until someone asks the inevitable question: "What am I getting out of it?" If you ask a room of 20 to 40 people that question, Wang notes you will receive 80 different answers. The responses range wildly in data types—they can be an integer (a hard number), a string (a sentence of pure "word salad"), or simply a string of curse words from stakeholders who have no idea how to quantify their results.

Wang introduces his personal background to explain why he finds this problem fascinating. Having previously worked as a management consultant at McKinsey serving major retail banks and retailers, and later at enterprise infrastructure platforms like Databricks and MuleSoft, he views solving AI ROI as both equal parts art and science. Now leading product at Tetrate, Wang benefits from a unique vantage point: Tetrate is the primary driving force behind Envoy, the open-source proxy project that routes a massive portion of the world's internet application traffic—and, increasingly, the majority of global AI traffic. Mastering this underlying traffic, Wang argues, gives teams the visibility and leverage needed to master AI ROI.

- **Speaker Background:** David Wang (Head of Product at Tetrate; ex-McKinsey consultant; former roles at Databricks and MuleSoft). - **Core Technology Platform:** Envoy (the open-source edge/service proxy project driven heavily by Tetrate that routes global application and AI traffic). - **The Schrodinger's Cat Metaphor:** An AI initiative exists in a superposition of being successfully deployed and completely dead until someone queries its ROI.

[02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) The Growth of AI Spend and the Primacy of Developer Productivity

Wang asserts that there are "37 billion reasons" to care about AI ROI today as AI spending accelerates rapidly across every sector. Historically, software and IT spending was small, slow, and highly predictable—primarily composed of flat, recurring user subscriptions for a trickling set of narrow use cases. In the modern AI paradigm, however, spend has become massive, unpredictable, and frequently doubles month-over-month. Wang attributes this explosion in costs to two primary factors: 1. **Changing Usage Patterns:** The shift from human users to autonomous AI agents. Agents operate continuously and consume tokens at a drastically higher rate than humans. 2. **Dynamic Pricing Models:** Frontier AI model labs (such as OpenAI and Anthropic) continuously tweak and restructure their pricing tiers to recover the exorbitant capital expenditure required to train next-generation foundation models.

Because AI spend scales unpredictably, technical leaders and executives inevitably face demands from their CFOs asking, "What did we get for the spend?" When evaluating where token spend is concentrated, Wang emphasizes that developer productivity is the single most critical area to monitor. The vast majority of enterprise AI tokens are currently spent on AI-assisted coding and software engineering.

Reflecting on the previous technology wave—digital transformation—Wang points out that software was placed directly at the intersection of every critical business function: driving revenue, shaping customer experience, and controlling operational expenditure (OPEX). Because modern businesses run fundamentally on software, making that software better, more reliable, and faster to deliver hinges directly on developer performance. As developers increasingly rely on AI to write and ship code, understanding and optimizing AI-driven developer productivity becomes the focal point of answering the overall ROI question.

- **Shift in AI Spend Characteristics:** Transformed from small, slow, predictable subscription costs to massive, volatile, month-over-month doubling usage. - **Drivers of Cost Volatility:** Autonomous AI agents (high token consumption) and frontier model lab pricing shifts. - **The Developer Spend Focus:** Software sits at the intersection of Revenue, Customer Experience, and OPEX; thus, AI token spend is heavily concentrated in developer tooling and code generation.

[04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) The AI ROI Equation: Leadership Challenges vs. Infrastructure Technical Barriers

At its most fundamental level, Return on Investment (ROI) is expressed mathematically as outcomes divided by spend. In the context of developer productivity, Wang defines this ratio as the business outcomes driven by developers divided by the aggregated inference spend required to power their AI tools:

$$\text{ROI} = \frac{\text{Outcomes Driven by Developers}}{\text{Aggregated Inference Spend}}$$

When Wang polls the room to ask how many organizations have attempted to measure this ratio, he notes that while almost everyone tries, most teams hit severe roadblocks. He breaks the measurement challenge into two distinct halves:

``` ┌─────────────────────────────────────────┐ │ AI ROI Equation │ └────────────────────┬────────────────────┘ │ ┌──────────────────────┴──────────────────────┐ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────┐ │ Numerator: RETURNS │ │ Denominator: INVESTMENT │ ├──────────────────────────┤ ├──────────────────────────┤ │ Leadership/Org Problem │ │ Technical/Infra Problem │ │ │ │ │ │ • Defining developer │ │ • Fragmented spend │ │ "outcomes" │ │ • Multiple providers │ │ • Disagreeing on metrics │ │ • Multi-geo business │ │ • Debating data flaws │ │ units │ └──────────────────────────┘ └──────────────────────────┘ ```

1. **The Numerator (Returns / Outcomes):** Wang argues that defining the numerator is less of a technical issue and far more of a leadership and organizational alignment problem. Teams struggle to agree on what constitutes a developer "outcome." Is it feature delivery speed, direct revenue generated by a feature, or intangibles like uptime and customer satisfaction? Furthermore, picking the right proxy metrics triggers endless debate: Should teams track Pull Requests (PRs), resolved Jira story points, ticket resolution time, or time-to-first-review? 2. **The Denominator (Investment / Aggregated Inference Spend):** The denominator presents a severe technical and infrastructure challenge. AI inference spend in large enterprises is deeply fragmented across various cloud providers, business units, geographic regions, and rapidly shifting model choices. Consolidating this raw data to get a single, accurate view of total token consumption is extremely difficult without centralized tooling.

- **Numerator Drivers:** Organizational consensus on feature delivery, customer satisfaction, or bug resolution/uptime metrics. - **Denominator Drivers:** Technical aggregation of multi-cloud, multi-model, multi-region token inference spend. - **Common Organizational Pitfall:** Teams get paralyzed arguing over the imperfections of data sources (e.g., whether PR count is a "flawed metric") rather than picking a proxy metric top-down and continuously improving its baseline.

[06:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=404s) Unpacking the Value Tree and the Essential Role of the AI Gateway

To solve the numerator challenge, Wang advises leaders to treat return measurement as a two-part decomposition process: separating overarching **value drivers** from tactical **proxy metrics**. Organizations must first select the primary business value driver that matters most to their current strategic goals—whether that is accelerating feature delivery, boosting customer satisfaction, or fixing bugs to maintain system uptime. Once the top-level driver is locked in, leadership must enforce top-down alignment around specific proxy metrics pulled from well-known operational data sources, such as version control systems (e.g., GitHub PRs) or customer support platforms (e.g., ticket resolution times).

Rather than wasting organizational energy arguing over the edge-case deficiencies of a specific metric, successful technical leaders "put their foot down," pick a baseline, and focus their effort on refining the quality of that measurement over time.

Turning to the denominator (tracking and controlling inference costs), Wang highlights the pivotal role of infrastructure. Just as API Gateways were fundamental to the digital transformation era by acting as centralized control planes for REST services, the **AI Gateway** has emerged as the critical architectural component for AI transformations.

``` ┌───────────────────────────┐ │ AI Consumers │ │ (Developers, AI Agents, │ │ Citizen Developers) │ └─────────────┬─────────────┘ │ ▼ ┌───────────────────────────┐ │ AI GATEWAY │ ◄── [ Single Control Plane ] │ • Aggregate Spend Data │ • Real-time Cost Allocation │ • Enforce Guardrails │ • Audit & Compliance Logging │ • Cache Frequent Prompts │ • Traffic & Policy Control └─────────────┬─────────────┘ │ ▼ ┌───────────────────────────┐ │ AI Resources │ │ (Azure OpenAI, Anthropic,│ │ Gemini, Open-Weights) │ └───────────────────────────┘ ```

Deployed directly between AI consumers (developers, autonomous agents, and citizen developers) and underlying AI resources (frontier LLMs, local models, and Model Context Protocol/MCP servers), an AI Gateway provides three indispensable enterprise capabilities: - **Centralized Visibility:** Aggregating usage and cost metrics across all teams and providers in a single pane of glass. - **Policy Enforcement:** Managing security, rate limits, access guardrails, and context windows. - **Auditing & Compliance:** Providing immutable logs, which are strictly mandatory for teams operating within regulated industries (such as banking and healthcare).

[10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) Synthetic Case Study: From "Token Maxxing" Chaos to Unified Infrastructure

Wang transitions from theory to practical application by sharing a case study drawn from a composite of Tetrate’s enterprise customers. In the early stages of their AI journeys, these organizations shared a common backdrop characterized by unconstrained "token maxxing." Developers across disparate business units were adopting any AI tool available, running queries against whatever models they could access, and charging expenses directly to corporate credit cards or isolated purchase orders.

This created an "any-to-any" chaotic environment with zero central control, leaving executives completely unable to track spend or measure business returns. In reaction to this loss of control, many risk-averse enterprise leaders overcorrected by locking down environments entirely, forbidding developers from using external models out of fear of data leakage or unchecked costs. In both extremes—unbridled chaos or total lockdown—developers suffered, losing either structural freedom or access to modern tooling.

``` EARLY CHAOTIC STATE TARGET UNIFIED STATE ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ Fragmented Developers │ │ Fragmented Developers │ └──────┬──────────────┬───────┘ └──────────────┬──────────────┘ │ │ │ ▼ ▼ ▼ ┌────────────┐ ┌────────────┐ ┌─────────────────────────────┐ │ Custom Glue│ │ Homegrown │ │ UNIFIED DISTRIBUTED │ │ Code / VIs │ │ Proxy Infra│ │ AI GATEWAY LAYER │ └──────┬─────┘ └──────┬─────┘ └──────────────┬──────────────┘ │ │ │ ▼ ▼ ▼ ┌────────────────────────────┐ ┌─────────────────────────────┐ │ Isolated Vendor Silos & │ │ Multi-Provider AI Resources │ │ Credit Card Procurement │ │ (Azure, Anthropic, Open- │ └────────────────────────────┘ │ Weight/Self-Hosted Models) │ └─────────────────────────────┘ ```

Furthermore, teams that attempted to build their own internal proxy layers quickly ran into a compounding infrastructure tax: - **Product Engineering Drain:** Engineers reassigned from building revenue-generating, customer-facing features to maintaining internal AI routing scripts, fixing CVE security vulnerabilities in homegrown proxies, and managing custom integrations. Wang compares building custom internal infrastructure to "adopting a puppy or a cat"—it requires continuous, long-term care and maintenance. - **The 5x Cost Multiplier:** The total long-term cost of maintaining a patchwork of custom internal infrastructure ultimately ballooned to over **5x initial estimates**, while locking the enterprise into specific vendor ecosystems.

To escape this trap, leading enterprises execute a deliberate strategic shift: they replace disparate, homegrown routing scripts with a single, globally distributed, centrally managed AI Gateway layer. This architecture allows multinational enterprises to maintain local low-latency routing across international regions while maintaining central control over policies, governance, and cost tracking. Additionally, it enables teams to flexibly blend proprietary frontier models (e.g., Azure OpenAI, Anthropic, Google Gemini) with self-hosted open-weight models (running on private hardware for strategic cost containment and vendor independence).

- **"Token Maxxing" Phase:** Unregulated tool adoption, credit-card purchasing, and lack of auditability. - **Homegrown Infra Pitfalls:** Heavy maintenance overhead, CVE patching, distraction from core product engineering, and a 5x cost overrun compared to initial build projections. - **Target Enterprise Architecture:** A distributed, centrally managed gateway layer capable of dynamically switching between commercial LLM APIs and private open-weight model clusters.

[14:35](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=875s) Live Demo: Developer Experience, System Prompts, and Manager Analytics

With seven minutes remaining in his presentation, Wang jumps into a live demonstration to show how an AI Gateway operates in practice across three distinct user perspectives: the developer, the admin/manager, and the executive.

#### The Developer View Demonstrating from his own laptop, Wang opens his local coding environment (Cloud Code / Cursor-style setup) where he has run several test prompts. He poses a fundamental question: Why would a developer willingly route their queries through an enterprise AI Gateway instead of bypassing it? Governance alone will not drive adoption; the gateway must provide tangible value back to the developer.

Switching to the gateway's personal developer console dashboard, Wang illustrates the immediate benefits: - **Cost & Token Transparency:** Real-time visibility into personal token counts, API request rates, and total dollar expenditure. - **Semantic Prompt Caching:** Clear metrics showing cache hit rates, allowing developers to structure repetitive queries to leverage cached context, saving both time and budget. - **System Prompt Inspection & Debugging:** The dashboard reveals the actual underlying system prompts injected by developer extensions—which are often massive in size. Wang notes that when upgrading an underlying model (e.g., moving from Claude 3.5 Sonnet or Opus 47 to a newer release), agents frequently break or behave unpredictably due to subtle system prompt interactions. Having full, self-service visibility into the exact system prompt payloads drastically simplifies prompt engineering and troubleshooting.

#### The Admin / Engineering Manager View Next, Wang switches to the engineering manager perspective. Using the admin dashboard, a team lead can monitor team-wide token consumption and usage trends over selected time windows. Filtering down to the "Agent Router Engineering Team," Wang inspects per-user token and cost distributions: - High-volume users (e.g., an engineer named Mr. Inas) are highlighted consuming a substantial portion of the team's token budget and overall spend. - Lower-volume users (e.g., an engineer named Aldi) are shown consuming roughly one-fifth of the tokens consumed by top-tier power users (like Ambari).

This granular, per-user breakdown allows engineering managers to identify training opportunities, optimize developer workflows, and catch runaway agent loops before they turn into unexpected monthly invoice shocks.

- **Developer Portal Capabilities:** Personal usage metrics, token costs, prompt caching hit-rates, and full system prompt payload inspection. - **Admin Portal Capabilities:** Multi-tenant usage tracking, team-level breakdowns, user-by-user token consumption comparisons, and cost-anomaly detection.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) How's that transformation going? — David Wang

> [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) What am I getting out of it? — David Wang

> [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) 37 billion reasons — David Wang

> [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) What did we get for the spend? — David Wang

> [06:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=404s) put their foot down — David Wang

> [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) adopting a puppy or a cat — David Wang

## Mentioned David Wang, Tetrate.io, McKinsey, Databricks, MuleSoft, Envoy, OpenAI, Anthropic, GitHub, Jira, Azure OpenAI, Google Gemini, Cloud Code, Cursor, Claude 3.5 Sonnet, Opus 47, Model Context Protocol

## Video description David Wang - Head of Product, Tetrate.io

Every AI initiative now has to answer one question: what did we get for the spend? That question is harder than it sounds: ROI is part measurement problem, part organizational problem, and many teams struggle with both. This talk gives AI engineering leaders and technical executives a working playbook: how to define AI ROI so it survives a budget review, which infrastructure choices actually move the number, and how to run initiatives that ship fast without becoming a token-cost surprise. We'll walk through a real, anonymized case study end to end to go beyond theory, and into actionable practice.

[Source](https://www.youtube.com/watch?v=MOOt9a6uy1g)

中文简报

Tetrate产品负责人将AI投资回报与网关基础设施挂钩 企业AI ROI取决于将开发者产出指标与集中式网关架构相结合,以遏制不可预测的Token支出。 David Wang将AI投资回报率公式拆解为组织成果(分子)与总计推理支出(分母)。他指出开发者生产力是AI Token消耗的最大单一领域,并阐述了无节制的“Token最大化(token maxxing)”和自定义代理脚本如何导致严重的成本超支。为解决该问题,他主张构建AI网关(AI Gateway)层——并在现场进行了演示——以实现多模型集中可见性、执行安全护栏、启用Prompt缓存,并为各工程团队提供细粒度的用量分析。 Tetrate 产品负责人 David Wang 将企业 AI 转型比作“薛定谔的猫”,在质询 ROI 之前往往处于既部署又停滞的叠加态;Tetrate 依托驱动全球核心流量的开源代理 Envoy,为量化和管理 AI 价值提供基础设施支撑。 (0:04) 受自主 Agent 普及与前沿模型动态定价驱动,企业 AI 支出正面临不可预测的剧烈激增;由于软件直接关联企业营收与运营支出,AI 辅助的开发者生产力成为 Token 监控与优化的核心重心。 (2:44) AI ROI 计算公式表现为“开发者业务成果(分子)除以聚合推理支出(分母)”:定义分子是需要自上而下选定代理指标的组织领导力挑战,统计分母则是涉及跨云、多区域碎片化支出的技术治理难题。 (4:46) 企业自建私有 AI 代理的长期维护成本往往高达初始预估的 5 倍,促使领先团队转向部署统一的分布式 AI Gateway,在集中管控安全策略、提示词缓存与审计合规的同时灵活调度各类商业及开源模型。 (10:08)

Reading summary

David Wang, Head of Product at Tetrate, argues that capturing enterprise AI return on investment requires decoupling organizational metrics from technical infrastructure, using a centralized AI Gateway to govern volatile inference costs and avoid costly custom proxy layers. Volatile Inference Costs and the Focus on Developers (2:44) Enterprise AI transformations frequently mirror a Schrödinger's cat paradox: initiatives exist in an indeterminate state of being deployed, functional, or failed until leadership demands proof of business value. Historically, enterprise software costs were predictable, recurring subscriptions. Modern AI expenditures, by contrast, frequently double month-over-month. Wang attributes this unpredictability to the emergence of autonomous agents that execute continuous queries, compounded by frontier model laboratories restructuring pricing tiers to offset model training capital expenditures. Because software engineering directly impacts revenue generation, operational expenditure, and customer experience, the vast majority of enterprise AI token consumption is concentrated in developer tooling and code generation. Consequently, evaluating AI ROI centers primarily on measuring developer performance and output against the infrastructure expenses required to power those tools. Deconstructing the AI Return on Investment Equation (4:46) Wang defines developer AI ROI mathematically as developer-driven business outcomes divided by aggregated inference spend. Measuring this formula exposes two distinct operational hurdles: an organizational alignment challenge in the numerator and an infrastructure fragmentation challenge in the denominator. The numerator requires executive leadership to establish strategic value drivers—such as release velocity, customer satisfaction, or system reliability—and assign concrete proxy metrics like pull request counts or ticket resolution times. Wang notes that organizations often stall by debating the flaws of specific metrics instead of setting a firm operational baseline. Conversely, the denominator is a technical problem: token expenditures are typically splintered across multiple cloud providers, regional business units, and disparate foundation models, making comprehensive cost accounting difficult without centralized infrastructure. The Compounding Overhead of Homegrown Routing Infrastructure (10:08) In response to early, unregulated 'token maxxing'—where staff expense unvetted models on corporate credit cards—enterprises often oscillate between total tool lockdowns and building internal proxy routing. Wang warns that building custom routing scripts, managing security CVEs, and maintaining bespoke model integrations distracts engineers from revenue-generating products, comparing the ongoing maintenance to adopting a pet. Tetrate's customer observations indicate that the long-term total cost of maintaining homegrown proxy infrastructure balloons to more than five times initial build estimates while locking organizations into rigid vendor setups. To prevent this overhead, enterprises adopt distributed AI Gateways based on proxy layers like Envoy. This architecture enforces centralized auditability, rate limits, and compliance across global business units while allowing dynamic traffic shifting between proprietary commercial APIs and private, self-hosted open-weight models. Operational Visibility for Engineers and Engineering Managers (14:35) Platform adoption depends on offering direct utility rather than pure compliance mandates. For individual software engineers, an AI Gateway console provides visibility into personal token burn rates, semantic prompt caching performance, and hidden system prompts injected by developer plugins. Wang highlights that inspecting system prompts is essential during model upgrades, as subtle changes between model versions frequently break autonomous coding agents. For engineering managers, multi-tenant administrative dashboards supply granular breakdowns of token consumption across teams and individuals. This visibility enables managers to allocate cloud costs accurately, identify skill disparities between high-volume and low-volume users, and detect runaway autonomous agent loops before they cause budget overruns. While deploying an AI Gateway provides the technical control plane necessary to consolidate fragmented token spend and enforce policies, Wang notes that calculating total ROI still depends on leadership enforcing consensus around developer outcome metrics rather than relying purely on automated tooling.

精炼阅读摘要

Tetrate产品负责人David Wang指出,企业衡量AI投资回报率(ROI)的核心在于平衡开发者产出与聚合推理成本,而通过集中式AI网关治理底层流量是解决成本失控与评估困境的关键路径。 AI投资回报率的双重结构与衡量瓶颈 (0:04) Wang将企业AI转型的现状比作“薛定谔的猫”,即在被质问实际收益之前,项目往往同时处于顺利推进与彻底停滞的叠加态。他提出ROI的数学定义为开发者带来的业务成果除以聚合推理支出。然而,企业在落地这一公式时普遍面临分子与分母的双重挑战:分子代表业务产出,其本质是管理与组织协同难题,团队往往陷入拉取请求(PR)数量、Jira故事点或工单解决时间等代理指标有效性的无休止争论中;分母代表推理投入,则属于技术与底层架构难题,由于各业务线分散采购不同的云厂商与模型,全公司层面的Token消耗数据极度碎片化。 Token支出激增与开发者生产力的核心地位 (2:44) 相较于传统IT支出小额、低速且可预测的订阅制模式,AI支出的月度增速频繁翻倍,表现出极高的波动性。Wang认为,驱动成本激增的诱因主要有两点:其一是自主AI智能体(Agent)的大量使用,其Token消耗率远高于人类操作;其二是前沿模型实验室(如OpenAI与Anthropic)为收回巨额研发资本支出而频繁调整定价。鉴于软件在收入创造、客户体验及运营成本中处于核心交叉点,绝大多数企业Token预算目前均集中于AI辅助编码与软件工程,因此优化开发者生产力成为证明AI业务价值的首要突破口。 自研基础设施代价与统一AI网关架构 (6:44) 许多企业初期经历了无序的“Token狂欢”,各团队自行调用模型并使用公司信用卡报销,促使管理层随后采取极端封锁手段。部分团队试图自研内部代理层,但面临严重的运维惩罚:工程师被迫脱离核心创收业务去维护路由脚本并修复CVE安全漏洞,长期维护成本最终膨胀至最初预估的5倍以上,同时锁定了单一技术栈。领先企业因而转向全球分布且集中纳管的AI网关,在各类模型消费者(开发者、AI智能体等)与底层异构模型(前沿商业API及私有开源模型)之间构建统一控制面,兼顾低延迟路由、全局策略、安全护栏以及金融和医疗等强监管行业的合规审计要求。 开发者赋能与管理者视角的落地实践 (14:35) 在实际部署中,AI网关若要避免被绕过,必须为终端开发者提供明确价值。通过专属控制台,开发者不仅能实时掌握个人Token消耗和成本,还能借助语义Prompt缓存降低调用开销;同时,系统对底层庞大系统提示词的透明化展示,有效解决了模型版本升级(例如切换至新版Claude)导致智能体行为异常的调试难题。从工程管理视角出发,管理后台可实现多租户细粒度监控,精确对比不同工程师间的Token使用梯度并识别异常高消耗用户,从而在避免月末账单冲击的同时,指导团队优化工作流并防范死循环调用。 利用AI网关统一管理推理流量为量化和控制开发成本提供了可行的工程路径,但分子端针对开发者实际产出的业务度量标准仍需企业自上而下确立,如何建立长期稳定的综合评估基线仍留待组织层面的持续探索。

Detailed notes — zh

## Background 本视频由 Ai4 频道于 2026 年 8 月 18 日发布在 YouTube 平台,内容为 Tetrate 产品负责人 David Wang 的主题演讲。演讲针对企业在预算审查中必须回答的“AI 投入到底换来了什么”这一核心质询,为技术高管和工程负责人提供了一套兼顾快速交付、价值度量与 Token 成本控制的落地实操指南。 ## TL;DR 演讲系统性地拆解了破解“薛定谔式 AI 转型”的方法论,将 ROI 核心聚焦于开发者生产力,并划分为业务产出(分子)与聚合推理成本(分母)两大部分。在业务价值层面,主张通过自上而下的决策确立关键代理指标以消除组织内耗;在成本控制层面,推荐引入统一分布式 AI 网关层取代高维护成本的自建碎片管道,实现跨供应商与混合算力的动态路由、配额管控与链式降级。最终通过将底层网关计量数据与 PR 提交量、支持工单时效等业务研发系统打通,实现了单 PR 与单工单维度的 AI 成本精准核算与价值闭环。 ## Atmosphere & style 整体氛围务实、幽默且充满工程实战气息,开场以“薛定谔的猫”风趣化解了企业面对高昂 AI 账单时的迷茫与焦虑。演讲者融合了麦肯锡管理咨询与底层基础设施架构的双重视角,语言干练犀利,直击企业自建管道的隐形“维护税”痛点。随着现场 Demo 从开发者端 Prompt 排错、管理者预算策略下发再到自然语言多维数据关联分析的层层演进,展现出一种从理论混沌走向严密数据实证的从容与说服力。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) 企业 AI 转型普遍面临“薛定谔困境”,即项目看似正常运转,却难以明确回答“巨额投入究竟换来了什么业务收益”。 - [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) 全行业 AI 支出正从早期小规模、可预测的固定订阅模式,演变为以 Agent 驱动、按量消耗且难以预测的爆发式增长。 - [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) 现代企业运转深度依托软件,而开发者群体消耗了大部分 AI Token,因此“提升开发者生产力”是评估 AI ROI 最核心的突破口。 - [04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) AI ROI 公式可拆解为分子(开发者驱动的业务产出)与分母(聚合的推理计算支出),两部分分别面临组织协同与基础设施层面的挑战。 - [06:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=404s) 衡量业务收益(分子)时切忌陷入指标精确度的无休止争论,管理层应自上而下拍板核心价值驱动因子与代理指标并迅速启动测量。 - [08:54](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=534s) AI 网关(AI Gateway)是控制推理成本(分母)的核心基础设施,提供统一计量、策略执行与合规审计三大关键能力。 - [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) 早期内部临时拼凑自建基础设施会导致严重的厂商锁定与高昂维护税,企业应演进为集中管理且支持分布式部署的统一全局网关层。 - [14:35](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=875s) 网关应为开发者提供反哺价值,通过用量透视、缓存优化以及底层 System Prompt 可视化排错,形成管控与提效的正向循环。 - [18:43](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1123s) AI 网关可作为控制层实施动态干预,支持按团队/个人配置预算上限、超额自动降级回退,以及在私有 GPU 集群与商业模型间做混合算力调度。 - [20:09](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1209s) 通过将网关层采集的 Token 消耗数据与工程运维系统指标(如 PR 数量、工单解决时效)交叉关联,能够精准核算单 PR 或单工单的 AI 成本闭环。 - [22:51](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1371s) 成功落地企业级 AI ROI 的四大法则:聚焦开发者生产力、自上而下打破指标争议惯性、汇聚统一数据链路,以及采用集中管控结合分布式部署的架构。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) AI 转型与投资回报率(ROI)的薛定谔困境 本次演讲分为三个核心部分:首先探讨 AI 时代的 ROI 理论概念;其次结合在大型受监管行业及初创公司中的实际落地经验,剖析真实实践;最后通过现场 Demo 演示具体工具的应用。演讲者 David Wang 幽默地感谢大家在正午午餐时间顶着空中交通管制延误、拉斯维加斯室外的酷暑与室内强劲的冷气来到现场。 开场抛出了一个直击所有技术负责人的问题:“你们的 AI 转型目前进展如何?”AI 转型在很大程度上就像“薛定谔的猫”——在任意给定时刻,你的转型项目似乎既进展顺利、成功部署上线,但同时又可能已经走向失败。直到有人真正提出那个关键问题:“我们从这些投入中到底得到了什么?”如果在一个二三十人的房间里抛出这个问题,大概会收到七八十种截然不同的回答;这些答案可能是一个具体的数字(整数),可能是一段不知所云的词语拼盘(Word salad),甚至可能是一连串因为不知道如何作答而脱口而出的咒骂。 - 演讲者背景:David Wang 目前负责 Tetrate 的产品管理工作,此前曾在麦肯锡(McKinsey)担任管理顾问(主要服务银行和零售企业),随后在 Databricks 和 MuleSoft 等公司深耕企业级服务。 - 独特视角:Tetrate 是开源代理 Envoy 项目背后的核心驱动力,如今全球绝大多数互联网应用流量及日益增长的 AI 流量都运行在 Envoy 之上,这为观察 AI 流量形态与掌握 ROI 提供了独特的技术视角。 ### [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) 为什么开发者群体是 AI ROI 衡量的核心 企业关注 AI ROI 有“370 亿个理由”,全行业的 AI 支出正在以至少三倍的速度狂飙,且支出的形态正在发生深刻改变。最初的 AI 支出规模小、增长慢且可预测,主要表现为少数特定场景下的固定订阅费用;而如今则转变为规模庞大、月度翻倍且难以预测的按量消耗。这种爆发式增长主要由两方面驱动:一方面是使用模式的变化,企业开始构建各类自主 Agent(智能体),而 Agent 消耗 AI Token 的能力远超人类;另一方面是前沿大模型实验室(Frontier Model Labs)由于昂贵的训练成本,在持续调整和改变其收费策略。随着支出水涨船高,来自 CFO 或管理层关于“这笔钱到底换来了什么”的质询便不可避免。 在所有的 AI 支出池中,最核心的监控对象是**开发者支出**。绝大多数 AI Token 支出都集中在代码编写上。回顾上一轮数字化转型浪潮,软件已经深深嵌入到所有关键业务职能的交汇点——它驱动着收入增长、客户体验以及运营成本(OpEx)。简而言之,现代企业的运转依托于软件,而让软件变得更优质、更可靠、更易用则依赖于开发者。开发者如今高度依赖 AI 来更快、更好地构建软件,因此“AI 如何重塑开发者生产力”成为了评估 ROI 时最具决定性的课题。 ```mermaid flowchart TD accTitle: AI 支出演变与开发者核心驱动力 subgraph S1["支出形态转变"] A["早期:固定订阅 / 小规模 / 可预测"] --> B["当前:Agent 驱动 / 月度倍增 / 不可预测"] end subgraph S2["业务价值链路"] B --> C["软件重塑关键业务<br/>(营收 / 客户体验 / 运营成本)"] C --> D["开发者利用 AI 加速软件构建"] D --> E["开发者 Token 消耗成为 ROI 核心考量"] end ``` ### [04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) ROI 公式拆解:分子(业务收益)与分母(基础设施成本) 从数学公式来看,ROI 即投资回报率(Return on Investment)。在开发者生产力的场景下,可以拆解为: $$\text{ROI} = \frac{\text{开发者驱动的业务产出(Outcomes)}}{\text{聚合的推理计算支出(Aggregated Inference Spend)}}$$ 这个看似简单的公式在实际衡量中却面临着完全不同维度的挑战: 1. **分子(Return / 收益):管理与组织协同难题** - 分子的挑战本质上不是纯技术问题,而是领导力与组织对齐的问题。 - 业内很难对开发者的“最终产出”达成唯一定义:究竟是功能交付数量、功能带来的直接业务收入,还是客户满意度等无形指标? - 衡量指标本身充满争议:到底看 Pull Request(PR)数量、Story Points(故事点),还是一种难以量化的“感觉(Vibe)”?团队极易陷入指标是否精确的无休止争论中。 2. **分母(Investment / 投入):技术与基础设施层面的挑战** - AI 支出日益碎片化,企业内部往往存在不同的模型供应商(Azure OpenAI、Anthropic、Gemini 等)、跨地域的业务部门以及多种模型选择。 - 随着调用量激增,汇总、监控并治理这些支出的物理形态变得极其复杂,需要强大的底层基础设施来抓取与控制。 ### [06:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=404s) 分子衡量:价值驱动因子与代理指标的自上而下对齐 在确定分子(业务收益)时,最常见的误区是将其视为单一问题,而实际上需要拆分为“价值驱动因子(Value Drivers)”与“代理指标(Proxy Metrics)”两个层级进行树状分解。价值驱动因子用于界定问题边界并在组织内达成共识,对于开发者而言,核心驱动因子通常聚焦于**新功能交付(Feature Delivery)**、**客户满意度(Customer Satisfaction)**或**缺陷修复与可用性(Bug Fixes / Uptime)**。各企业必须根据自身的业务优先级挑选出最重要的一项。 明确价值驱动因子后,需要将其映射为具体的代理指标,例如 PR 提交量、工单解决耗时(Ticket Time Resolution)或平均首次代码审查耗时(Time to First Review / MTTR)。虽然版本控制系统和支持工单系统中拥有现成的数据源,但团队往往会陷入对数据有效性的内耗(例如争论“PR 数量并不能完全代表真实产出”)。优秀组织的解法是采取自上而下的决策方式:管理层必须拍板定调,全员达成一致并迅速启动测量;团队应当将精力花在“如何让指标更有意义(例如规范 PR 的交付粒度)”上,而不是无休止地争论现有指标的缺陷。 | 层级 | 核心关注点 | 常见指标 / 示例 | 核心挑战与应对策略 | |:--- |:--- |:--- |:--- | | **价值驱动因子 (Value Drivers)** | 业务战略对齐与问题收敛 | 功能交付、客户满意度、系统可用性/Bug修复 | 需结合企业当前业务优先级确立核心目标 | | **代理指标 (Proxy Metrics)** | 具体落地执行与数据抓取 | PR 数量、工单解决时长、平均代码审查时间 | 依托代码仓库与工单系统,自上而下推动,先启动再持续优化 | ### [08:54](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=534s) 分母衡量:AI 网关在集中管控中的关键角色 为了准确衡量并控制分母(AI 推理成本),基础设施的选择起着决定性作用。正如上一代数字化转型中 API 与 API 网关扮演了枢纽角色一样,在当下的 AI 架构中,**AI 网关(AI Gateway)**是抓取数据和实施控制的核心基础设施。 AI 网关被部署在“AI 消费者”(如专业开发者、低代码公民开发者)与“AI 资源”(大模型服务、MCP 资源等)之间。将网关作为流量入口能够带来三大关键价值: - **统一计量(Single Place to Measure)**:全面汇聚跨团队、跨供应商的 Token 用量与推理成本。 - **统一策略执行(Single Place to Enforce Policies)**:实施访问控制、限流与路由优化。 - **统一审计合规(Single Place to Audit)**:为金融、医疗等受监管行业的合规审查提供全局审计日志,同时也为非监管行业提供极佳的成本优化操作切入点。 ### [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) 落地实践案例:从散乱自建到统一分布式网关层 在真实的客户案例中(综合多个典型客户的普遍痛点),初期往往经历过盲目追求“Token Maxing”的混乱阶段:各业务部门开发者自行使用各种工具和模型随意调用,导致出现“任意对任意(Any-to-Any)”且完全失去管控的局面。面对失控风险,许多大型跨国企业的管理层出于恐惧,往往会采取一刀切式的严厉限制,剥夺开发者的工具选择权;这导致团队陷入两难困境——要么处于缺乏治理的混乱中,要么因过度限制而丧失技术自由度。 在这种初期状态下,各部门各自为政,用信用卡报销或单独走采购流程,导致可用供应商极其受限,只能在内部临时拼凑自建基础设施(Homegrown Infrastructure)。这带来了严重的“双重打击”: - **选择受限与厂商锁定**:受制于仓促过审的少数供应商,且容易被前沿模型实验室深度绑定。 - **高昂的维护隐形成本**:本应负责面向客户开发业务功能的工程团队,沦为内部管道的“维修工”。他们把大量时间耗费在修复内部自建系统的安全漏洞(CVE)上,根本无法支持业务规模化扩张。自建基础设施就像“领养了一只小狗或小猫”,后续的维护成本往往达到初始预期的 5 倍以上。 最终,成熟企业选择将分散修补的路由设施统一替换为**单一的全局网关层**。该架构具备分布式部署与集中化管理能力,能够适配跨国多云环境,并灵活接入 Azure OpenAI、Anthropic、Gemini 以及企业自建硬件运行的开放权重模型(Open-weight Models),在规避供应商锁定的同时有效控制算力成本。 ```mermaid flowchart LR accTitle: 从分散自建架构向统一 AI 网关演进 subgraph Old["初期混乱阶段 (Any-to-Any)"] D1["分散开发团队"] -->|"信用卡采购 / 脚本自建"| M1["多供应商模型 (缺乏管控 / 高维护税)"] end subgraph New["统一演进架构"] D2["开发者 / Agent / 内部应用"] --> G["统一分布式 AI 网关层<br/>(集中管控 / 策略分发 / 审计)"] G --> R1["前沿商业模型<br/>(OpenAI / Anthropic / Gemini)"] G --> R2["私有化开源/开放权重模型<br/>(自建硬件算力)"] G --> R3["MCP 资源与工具链"] end ``` ### [14:35](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=875s) 现场演示:开发者视角与系统提示词(System Prompt)洞察 要让治理策略顺利推行,网关绝不能只做单向的管控,而必须为开发者提供切实价值,形成正向交换。David 在现场演示了开发者在使用 Claude Code(Cloud Co-work)等日常编码工具时的后端联动体验。 - **用量与成本透视**:开发者可以在个人控制面板中实时查看自己的请求数、Token 消耗量以及具体费用支出。 - **缓存(Caching)优化**:直观展示查询缓存命中情况,帮助开发者优化 Prompt 结构以降低调用成本。 - **系统提示词(System Prompt)可视化与排错**:开发 Agent 时经常遇到模型小版本迭代(如从 Opus 4.7/4.8 升级至 5)后系统突然失效的问题。通过网关控制台,开发者能够直接洞察底层庞大的 System Prompt 细节,快速定位细微差异并完成自助排错(Troubleshooting)。 ### [17:39](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1059s) 现场演示:管理者视角下的团队 Token 消耗与成本透视 切换到团队管理者或管理员视角,AI 网关则提供了全局透视与资源调配能力。管理者需要清晰了解团队整体以及成员个体的实际使用状况。 通过控制台仪表盘,管理者可以精准过滤并调取特定团队(如 Agent 路由工程团队)在过去一段时间内的使用数据。系统支持下钻至每位成员的消耗细节(例如直观比对出团队中 Mr. Inas 消耗了大量 Token 和预算,而另一位成员 Aldi 的消耗量仅为 Ambari 的五分之一左右),为资源分配、成本归集与效能评估提供了精确的数据支撑。 ### [18:43](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1123s) AI 网关的治理能力:动态路由、预算控制与回退策略 AI 网关不仅能够提供透明的可视化监控,更能作为控制层直接干预底层的推理决策。通过在网关层配置策略,团队可以轻松实现预算控制和智能回退机制。例如,许多团队希望限制个人或小团队的开销上限,设定一个“例如不超过 200 美元”的阈值(相当于一个固定席位订阅费用的标准)。一旦触达阈值,网关即可触发链式回退(fallback)策略:在预算充足时优先调用昂贵的前沿模型(Frontier Model),一旦超出配额便自动降级切换至轻量且低成本的模型。 对于基础设施更成熟的大型企业客户,网关策略还能实现更为复杂的本地混合路由——例如优先调用在自有私有 GPU 集群上托管的开源模型,只有在特定复杂场景下才路由至外部前沿商业模型 API。这种策略不仅能立竿见影地削减 Token 成本,还能确保模型调用的服务质量与业务效果。 ```mermaid flowchart TD accTitle: AI Gateway Intelligent Routing and Fallback Architecture subgraph ClientLayer["客户端与开发者请求"] Dev["开发者 / 业务应用"] end subgraph GatewayLayer["Tetrate AI 网关控制层"] PolicyCheck{"预算与策略检查\n(例如: 是否超 $200 预算)"} RouteLocal["本地 GPU 优先策略"] end subgraph ModelLayer["模型提供方"] Frontier["昂贵前沿模型\n(Frontier Model API)"] BudgetModel["低成本备用模型\n(Cheaper Model)"] LocalModel["本地私有化部署模型\n(Private GPU Model)"] end Dev --> PolicyCheck PolicyCheck -- "预算充裕 / 高复杂度" --> Frontier PolicyCheck -- "超出预算上限" --> BudgetModel PolicyCheck -- "私有化路由规则" --> RouteLocal RouteLocal --> LocalModel ``` - **灵活的预算阈值控制**:支持按团队或个人维度配置支出上限,防止意外的高额 Token 账单。 - **自动降级与链式回退**:在高价值模型超额或故障时无缝降级至平价模型,保障业务连续性。 - **混合算力路由调度**:支持在自建私有 GPU 算力集群与外部前沿商业 API 之间根据成本、隐私及性能规则灵活分流。 --- ### [20:09](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1209s) 关联业务产出与 Token 消耗:高管层面的真实 ROI 闭环 从个体开发者的提效,到运维管理者的全局策略与预算管控,高管层面最关心的问题始终是:“如何将业务产出(Outcome)与资金消耗(Spend)精准关联起来?”解决这一难题的关键在于,将 AI 网关/路由层采集的底层消耗数据,与业务顶层的核心效能指标(Numerator Metrics)进行融合分析。 为了证明这一闭环的可行性,团队展示了一个内部数据分析项目(已作为产品方案交付给大型企业客户)。该工具提供了基于自然语言的 Chat 交互界面,允许管理者直接对网关日志与工程研发系统的数据进行交叉查询: ```mermaid flowchart LR accTitle: Executive ROI Data Correlation Workflow subgraph Inputs["数据采集源"] GWData["AI 网关调用与 Token 成本\n(API Key, Cost, Model)"] DevData["工程研发与运维指标\n(PR, Support Tickets)"] end subgraph CorrelationEngine["统一关联分析引擎"] MetricLink["数据聚合与业务归因\n(关联 API Key 与 业务产出)"] end subgraph Insights["高管洞察输出"] CostPerPR["单 PR 平均 AI 成本"] TicketReduction["工单解决时效缩短幅度"] CostPerTicket["单个工单解决平均成本"] end GWData --> MetricLink DevData --> MetricLink MetricLink --> CostPerPR MetricLink --> TicketReduction MetricLink --> CostPerTicket ``` - **模型单次请求成本分析**:支持查询“过去 30 天的总体支出及每个模型的单次请求成本(Cost per Request)”,并输出直观的模型性价比排行。 - **PR 维度研发效能与成本核算**:通过追踪过去 30 天内提交 PR 数量前 10 名的核心开发者,系统可直接计算出“每个 PR 消耗的 AI 成本(Cost per PR)”,量化重度 AI 使用者的产出效率。 - **客户支持工单(Support Tickets)降本增效分析**:支持工单处理是研发组织中最消耗生产力的高昂成本项之一。通过将 AI 网关中的 API Key 使用日志与客服工单数据关联,可以直接回答两个关键问题:“AI 究竟缩短了多少工单平均解决时间?”以及“每个成功解决的工单消耗了多少 AI 成本(Cost per Resolved Ticket)?”数据证明,引入内部支持 Agent 后,工单解决时间出现了实质性的显著下降。 --- ### [22:51](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1371s) 总结:破解“薛定谔的 AI 转型”与落地四大法则 在演讲的最后阶段,讲者给出了推行企业级 AI 项目必须带回实践的四个关键原则,呼吁管理者走出理论分歧,进入可执行的落地实践: 1. **聚焦开发者生产力(Focus on Developer Productivity)**:这是目前 AI 投资回报率(ROI)最高、最立竿见影的价值突破口。 2. **摆脱指标争议的组织惯性(Overcome Organizational Inertia)**:不要在指标的定义上无休止地争论。必须由高层自顶向下直接敲定一套基准指标,立刻开始测量。 3. **汇聚统一数据链路(Consolidate All Metrics in One Path)**:将所有 Token 消耗、模型交互与业务产出指标整合在同一条监控链路上。 4. **集中化控制与分布式部署(Centralized Control with Distributed Deployment)**:在架构上维持统一的策略与网关管控,同时支持业务端灵活分布式的部署与调用。 讲者幽默地总结道,所谓的“薛定谔的 AI 转型”——即处于既存在又无法被证实的叠加态问题——是完全可以被系统化解决的:“大家现在可以回去告诉薛定谔,AI 转型不仅活着,而且活得很好,我们已经找到了衡量和证明它的方法。” ## Notable quotes > [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) 你们的 AI 转型目前进展如何? — David Wang > [00:04](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=4s) 在任意给定时刻,你的转型项目似乎既进展顺利、成功部署上线,但同时又可能已经走向失败。直到有人真正提出那个关键问题:我们从这些投入中到底得到了什么? — David Wang > [02:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=164s) 企业关注 AI ROI 有“370 亿个理由”,全行业的 AI 支出正在以至少三倍的速度狂飙,且支出的形态正在发生深刻改变。 — David Wang > [04:46](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=286s) 分子的挑战本质上不是纯技术问题,而是领导力与组织对齐的问题。 — David Wang > [06:44](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=404s) 管理层必须拍板定调,全员达成一致并迅速启动测量;团队应当将精力花在“如何让指标更有意义”上,而不是无休止地争论现有指标的缺陷。 — David Wang > [10:08](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=608s) 自建基础设施就像“领养了一只小狗或小猫”,后续的维护成本往往达到初始预期的 5 倍以上。 — David Wang > [14:35](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=875s) 要让治理策略顺利推行,网关绝不能只做单向的管控,而必须为开发者提供切实价值,形成正向交换。 — David Wang > [22:51](https://www.youtube.com/watch?v=MOOt9a6uy1g&t=1371s) 大家现在可以回去告诉薛定谔,AI 转型不仅活着,而且活得很好,我们已经找到了衡量和证明它的方法。 — David Wang ## Mentioned David Wang, Tetrate, Envoy, McKinsey, Databricks, MuleSoft, Azure OpenAI, Anthropic, Gemini, Claude Code, Opus ## Video description David Wang - Head of Product, Tetrate.io Every AI initiative now has to answer one question: what did we get for the spend? That question is harder than it sounds: ROI is part measurement problem, part organizational problem, and many teams struggle with both. This talk gives AI engineering leaders and technical executives a working playbook: how to define AI ROI so it survives a budget review, which infrastructure choices actually move the number, and how to run initiatives that ship fast without becoming a token-cost surprise. We'll walk through a real, anonymized case study end to end to go beyond theory, and into actionable practice. [Source](https://www.youtube.com/watch?v=MOOt9a6uy1g)

Source quotes

[0:04] David Wang: 你们的 AI 转型目前进展如何? [0:04] David Wang: 在任意给定时刻,你的转型项目似乎既进展顺利、成功部署上线,但同时又可能已经走向失败。直到有人真正提出那个关键问题:我们从这些投入中到底得到了什么? [2:44] David Wang: 企业关注 AI ROI 有“370 亿个理由”,全行业的 AI 支出正在以至少三倍的速度狂飙,且支出的形态正在发生深刻改变。 [4:46] David Wang: 分子的挑战本质上不是纯技术问题,而是领导力与组织对齐的问题。 [6:44] David Wang: 管理层必须拍板定调,全员达成一致并迅速启动测量;团队应当将精力花在“如何让指标更有意义”上,而不是无休止地争论现有指标的缺陷。 [10:08] David Wang: 自建基础设施就像“领养了一只小狗或小猫”,后续的维护成本往往达到初始预期的 5 倍以上。 [14:35] David Wang: 要让治理策略顺利推行,网关绝不能只做单向的管控,而必须为开发者提供切实价值,形成正向交换。 [22:51] David Wang: 大家现在可以回去告诉薛定谔,AI 转型不仅活着,而且活得很好,我们已经找到了衡量和证明它的方法。

Source quotes

[0:04] David Wang: How's that transformation going? [0:04] David Wang: What am I getting out of it? [2:44] David Wang: 37 billion reasons [2:44] David Wang: What did we get for the spend? [6:44] David Wang: put their foot down [10:08] David Wang: adopting a puppy or a cat

Original transcript

[0:04] Today I'll be going through roughly three  sections. I'll have a bit of theory. So [0:08] the concept behind what ROI means in the age  of AI, a bit of practice what I see amongst [0:15] u the folks I work with which are you know a  pretty big range of regulated industries as [0:19] well as startups. And then finally a bit of a live  demo just to show you the tools of what I mean. So [0:23] we'll tie those three things together in this uh  next bit of like fun maxing hopefully. But first, [0:29] I want to thank you for coming. It is kind of  middle of the day, lunch hour. Uh, thank you for [0:33] braving air traffic control issues, uh, extreme  heat and extreme AC. Um, and meet me in Las Vegas. [0:39] I really do appreciate it. Um, so start with a  question. So, I'm assuming uh, everybody here has [0:46] some kind of initiative happening. So, how's that  transformation going? Uh, so here's what I find [0:53] interesting about that question. AI transformation  is a little bit like the Schroinger's cat problem. [0:58] At any given moment, your transformation is both  going well and deployed and also dead. And you [1:03] won't really know which one until somebody  asks the question, what am I getting out of [1:07] it? And if you do, I'm like a reasonable room  with let's say 20 40 people. You probably get [1:13] 80 different answers. And not only that, the  answers you get can be an integer, which could [1:18] be a number. It could be a string, a sentence  of word salad or just like curse words because [1:23] you don't know how to answer that question. So,  uh it is a difficult question to answer and it's [1:29] one I am very interested in talking more about. Uh  PDF's a little wonky. So, a little bit about me. [1:37] I look after product management for Tedrate.  Um, previously uh I worked with uh McKenzie [1:44] um as a management consultant serving primarily  banks and retailers and I subsequently worked with [1:49] companies such as data bricks and mulesoft really  working with enterprises and that's what I'm [1:55] really excited to uh uh solve like the question  about both our ROI and um AI and that is because [2:01] both equal part art and science. So let's get into  it. I have a unique vantage point u for AI because [2:11] I work for Tetrate uh and we our our contributions  really run the world's AI traffic. Um we are the [2:18] primary driving force behind the envoy project and  most of what you see today as internet application [2:24] traffic runs through envoy and increasingly  most of what you see is AI traffic runs through [2:29] envoy. So that gives me a unique view of um how AI  traffic is shaped and how that uh how mastering AI [2:38] traffic gives you the ability to master ROI. So  first question why do we even care about AI ROI [2:44] at all? Well the first thing I would say is that  you know you probably have 37 billion reasons to [2:49] care. Uh everybody knows that AI spending is  increasing. It's at least uh tripling but it's [2:56] uh the shape of AI uh spending is also changing.  So the firstly is like it's gone from slow [3:01] uh small slow and predictable which is everybody  have subscriptions um and it's a trickle of a [3:07] limited set of use cases to something pretty  massive like big growing sometimes doubling [3:12] month over month and unpredictable and that's  driven both by usage patterns people build agents [3:19] and agents are much better at consuming AI than  people and also pricing you know Frontier model [3:26] labs are changing and tweaking how they charge for  frontier models which are very expensive to train. [3:32] So inevitably the spend goes up and inevitably you  get the question either from your CFO or from your [3:38] manager what did we get for the spend and that is  a very difficult question to answer that question [3:44] the most important pool to look after is probably  developer spend why is that well uh that's where [3:52] it all started uh most of the AI token is spent on  building code today well why code why why is why [4:00] why is it such a big spend so in the last hype  cycle of transformation if you all were there. [4:05] It's the digital transformation. What that meant  is that software now lies at the intersection of [4:11] all kinds of critical business functions. It  drives revenue, it drives customer experience [4:16] and it drives opex and cost. So in other words,  most of uh the business is run on software and [4:24] making software better, more reliable and easier  to use for your customers is driven by developers. [4:30] So developers today rely on AI to build the  software faster and better. So that is why [4:36] um developer productivity and how AI shapes that  is an important ROI question to answer. So you [4:46] know simple math let's get into it. ROI is return  on investment simply but in the case of developer [4:53] productivity it is outcomes that developers  drive um and the aggregated inference spend. So, [4:59] how hard is that to measure? I'm curious how  many people actually tried to do that in your [5:05] organization? Anybody? I'm curious. Yes. All  right. Well, everybody gives it a shot. So, [5:09] I'd love to talk to you more about what you did,  but I'm let me tell you what I see first. Um, [5:14] okay. So, there are two different challenges. The  numerator, the return, it's actually I would argue [5:20] it's actually less of a technical challenge. It's  more of a leadership and organization challenge. [5:25] And it's just around what to measure. um you know  nobody could truly agree on what is the definition [5:31] of outcome for developers. Is it about feature  delivery? Is it about the revenue the feature [5:36] drives or is about something intangible like  customer satisfaction which people are always [5:40] trying to measure. And the second thing is the  metrics can be hard um to really even agree upon. [5:46] So how do you measure feature delivery? Is it PRs?  Is it story points? Is it something in intangible [5:52] like a vibe? But I'd argue that it's ultimately  about uh leadership and organization because [5:57] people get trapped into arguments about what is  the right outcome measure. But the really the [6:03] most important thing is that for in the context  of our eyes probably just need to get started. [6:06] I'll get into that a little bit more. The second  part is the investment and there this is more of [6:13] uh more of a technical challenge. So now AI spend  is increasingly fragmented. So you have different [6:19] providers, you have different business units  probably across different geos and you have [6:23] a lot of different model choices and the volumes  increasing. So it is very difficult to consolidate [6:28] or get a view of your spend and it's even  harder to shape how that spend takes shape. So [6:34] uh you have two different types of problems both  equally hard. One is a leadership organizational [6:38] challenge and second one is a technical sort  of infrastructure meas measurement challenge. [6:44] So what I see is that let's tackle the numerator  first on returns. Um what I see is in order to [6:51] determine like returns the common mistake is  people treat it as a one part problem whereas [6:56] in fact it's really a two-part problem. Uh the  way to disagregate it and this is something like [7:02] I've seen a lot even in my management consulting  uh experience is you got to break down the the [7:08] tree of value drivers versus proxy metrics. Um  because value drivers is really the thing that [7:13] helps you to constrain the problem and help you  to get uh your organization aligned and in the [7:17] case of developers it really is around feature  delivery, customer satisfaction or just bug fixes [7:23] which is which relates to uptime and these things  you kind of have to pick the one that matters the [7:28] most to your business because every business have  a slightly different prioritization and then I [7:32] think the important thing is to map these to proxy  metrics which at some point as a leader folks will [7:38] just have to put their foot down and convince  the restaurant the rest of the organization [7:41] to go along. Um, so for some of the ones I've  seen out in the wild, it's about pull requests, [7:47] ticket time resolution or time to first  review internally, mean timing review. Um, [7:52] and the data sources for these things are well  known. It could be your version control. It could [7:56] be your support ticket system. Uh, all kinds  of this stuff. You have the data, but people [8:01] tend to get wrapped up in arguing the accuracy of  the data. You kind of get into this argument of, [8:06] yeah, that's kind of true, but what about XYZ?  So I would argue that for organization I've seen [8:12] most successful is um leadership and it's more  of a top- down problem. Everybody have to agree [8:16] you have to measure something and the energy  should be spent in um making the measurement [8:23] better instead of arguing over the deficiencies  um of what you have. So people would say like [8:27] well a pull request doesn't really quite measure  an outcome but then sometimes the question is like [8:31] well maybe a pull request should be more shaped  like something meaningful versus random. So that [8:37] is a a leadership ch leadership and organization  challenge. I see great organizations get rallied [8:43] around. It's more of a top down decision. Um but  ultimately lending at the few metrics that matter [8:49] internally and get every degree and being able to  at least pull the data out of these systems is the [8:54] important first step. Uh the second thing on how  to measure the denominator and here's where the [9:00] infrastructure matters more. Um, so you would  need something to aggregate a lot of AI spend, [9:06] a lot of AI information. And I would argue at this  stage, just as in the past digital transformation [9:11] where APIs played a key role and API gateways  played a key role, AI gateways is really the key [9:18] player here. And so you know from my experience  the best way uh the AI gateway basically is can [9:26] be a simple quick way to get the data you want and  you would deploy it between the AI consumers which [9:32] could be your developers or even your citizen AI  developers and your AI resources which could be [9:39] the models and your MCP resources. Um the benefit  of having something like that in AI just as API [9:46] and previous generation is that you have a single  place where you can measure a single place you can [9:51] enforce policies and a single place you can  audit. So if you are in a regulated industry [9:56] this is something you definitely need and even  if you're not it's just a convenient place for [10:00] optimization. So that's kind of like the theory.  I want to transition a little bit into practice. [10:08] So to make this a little bit more concrete, that  was a very complicated picture that doesn't show [10:12] up very well on the faintly lit screen. So I'll  talk a little bit about a particular case study [10:18] u or maybe it's a blend of a couple of customers  that we have um of what actually happened and as [10:25] an example. So this is a sort of like a synthetic  set of uh customers. they all share this the same [10:33] sort of like backdrop which is um there was this  push for token maxing. So all the developers were [10:40] using as many tokens with as many tools as they  can and they were building anything they could [10:47] uh internally. So um that created this any to  any sort of like no control situation and the [10:54] enterprise really can't get any handle on any kind  of a measure. what they ultimately transition to [11:01] is having this global layer that allows them  to count and allows them to control. I should [11:06] add that the left hand side where it's any to  any no controls like it's actually more nuanced [11:11] than that because um sometimes the enterprises go  through they're afraid of that state of many to [11:17] many and they actually prevent the developer from  doing anything in fear of having that state. So [11:23] like what you end up with is a big multinational  can be in this uh state where they have too much [11:27] chaos but also then they start to like really  clamping down hard on choices. So developers [11:33] kind of lose either way. They either don't have uh  they either get their freedom taken away because [11:39] um it's too uh there's like this fear of uh chaos  or it's too chaotic and they don't really like get [11:45] the options they want. So here's a here's like a  kind of a stack that I've seen people typically [11:50] start off initially is they have this really  heterogeneous set of constituents and they're [11:56] really like tribal. So they pretty much put a  lot of things on credit cards or on individual [12:00] POS. What you ended up with is they have a small  selection based on the vendors that they could [12:06] rush through procurement. Um they end up building  a lot of homegrown infrastructure to support it. [12:13] um then they get hit with this double whammy  of problems. The first problem is that your [12:17] choices are limited basically to the vendors they  could get through procurement and the second one [12:20] is just that uh they ended up with a lot of tax  over time in terms of maintenance and on top of [12:27] it they kind of saddled themselves a little bit  with a locking potential of the frontier models [12:32] uh in the frontier labs but most of all what I see  is that a lot of these teams are supposed to be [12:38] product engineering teams they're supposed to be  building customerf facing features and improving [12:43] customer experience when there's too much  infrastructure you're build internally. Um they're [12:47] really not able to do that. It's like a slow drain  on productivity. So uh three ways like instead of [12:55] innovating they're basically repairing. Um instead  of uh upr runninging the product they're supposed [13:00] to run they're fixing CVE on something they've  built and all that for something they probably [13:05] cannot scale in the future. So the total cost of  building something internally and maintaining this [13:10] patchwork of custom infrastructure really becames  like 5x or even more of what they anticipated. So [13:16] the it's kind of like building infrastructure  is less like building it's more like adopting [13:20] the puppy or a cat. Um so the feature state  what they uh ended up doing is uh most of our [13:30] customers make resolution to unify their disparate  patchwork of routing infrastructure into a single [13:36] layer. Um this single layer it's important that it  can be um deployed in a distributed manner because [13:42] most enterprises are international and most of  their constituents are international and have [13:47] different providers environments. So having this  unified layer that is distributed but centrally [13:53] managed is really important. Once you have that  what you can do is you can bring in different [13:59] uh inference uh and MCP resources whether  it's from Azure OpenAI anthropic Gemini and [14:05] most importantly recently what we're seeing  is the interest in open weight models people [14:09] buying their own hardware and running it for  both cost control and also just for strategic [14:14] reasons of not having vendor locking. So this  common pattern of starting out uh experimenting [14:22] fast with your sort of homegrown infrastructure  and then gradually replacing it with a unified [14:26] layer that is uh singularly managed and maintained  is one that I see the industry moving towards. [14:35] Um so what does this mean? So that was like  the practice part it right. So what does it [14:40] actually look like? Like you know I talked  about infrastructure and gateway it can be a [14:43] bit abstract. So I thought you know we have seven  minutes left we can I can show you a bit of what [14:48] it means from you know the users experience u the  admins experience and then also just like what it [14:55] means for executives. So three parts. So the first  thing I want to kind of like show you guys what [15:00] it looks like you know if I so let's say I'm a  developer I do still do some development what [15:05] does it look like you know when I'm starting out  with cloud co-work like um from my perspective. [15:11] So let's get started. So here I have cloud co-work  on my laptop. I kind of started with already some [15:17] uh uh just in preparation for this talk. I uh  had some seed questions. Um and I was actually [15:24] just like kind of like just give you some example  of like some prompts I might run that probably in [15:28] your example it might be more like coding but  in my instance I just kind of wanted to like [15:33] um ask some basic questions. So sure I'm using  haiku. It gives me some answers but the real [15:38] question is what does this look like in the  back end? How how can I get if I have the gate [15:43] AI gateway as a developer what do I get right  that's an important bargain to trade because a [15:49] lot of conversation starts with governance but  really you're not going to get adoption unless [15:52] you offer value to the developer so what is the  value to the developer so here uh what I'm going [15:58] to show you is um what is the view of I'm sorry  of a developer view so if you had an AI gateway [16:08] and if it's got a great developer er experience  what you can end up with something like this. Um [16:15] as a developer I can see what is my usage, how  much things are costing me, how many tokens, [16:20] how many requests. For me like one of the most  important thing I look at is just caching, [16:26] you know, how can I optimize my queries um to  save more money with caching. And another point [16:32] of interest a lot of times that I find is what is  actually underneath the hood of my requests. Um [16:38] so one thing that uh like I like to watch look at  sometimes is just the size of the system prompts. [16:48] It is massive. It's very important as developer  for me to understand it. For me it has huge value. [16:53] Here's why. Um have you ever built an agent and  then some sometimes it stops working well after [16:59] you change the model like from opus 4 48 or 47  to five. It happens all the time. So these subtle [17:06] differences are extremely difficult to debug.  You don't really understand what happened and [17:10] having something that's accessible by you that  you can self-service to understand what the [17:14] system prompt is um it helps you to understand  what's going on, helps you to troubleshoot. [17:20] So between the the cloud co-work or cloud  code that I use day-to-day and my personal [17:28] sort of like console developer dashboard  that I can look at to help me troubleshoot [17:33] like the value of an AI gateway sort of is very  it's a very good trade for me as a developer. [17:39] The second question I have is like if I were to  put put on my admin or manager hat so I have a [17:44] team of developers like the question then becomes  it's just not what like the AI gateway can help me [17:50] to answer what is my team doing how can they uh do  better similarly uh a great gateway will give you [17:59] that information as well so um the kind of stuff  you should be able to get out of a gateway is what [18:08] is everybody using for the past x number of days.  So for example, I could say that I wonder what is [18:16] the agent router engineering team doing uh when  it comes to per user. So uh you know like I can [18:28] see that Mr. Inas uses a ton of tokens, uses a  lot of money. Uh, and I can tell that Aldi is a [18:36] lot uses about a fifth of the uh, consumes a fifth  of the token that Ambari uses. So, these are just [18:43] examples uh, you know, and this is actually an  internal team data. This is not customer data. So, [18:47] this is like our our internal teams. Um, it's an  example of like how we monitor and improve our [18:55] own AI use. Um so this is just visibility having  a a gateway layer also allows you to impact um [19:03] what is the the inference choice made underneath.  So a simple example is budgeting. So uh we like I [19:10] imagine a lot of people would like to be able to  maintain some kind of a budget control over their [19:15] teams or themselves and a gateway allows you to  set policies as simple as budget and fallback. So [19:21] maybe there's a magic number somewhere that says  I really don't want to exceed $200 um because [19:27] that's how much a subscription cost. So you can  set up, you know, interesting chaining fallback [19:32] policy such as either use an expensive model until  you hit some budget limit and then use a cheaper [19:37] one. Or if you're more sophisticated like some of  our customers, you might prefer a locally hosted [19:43] model that runs on your GPUs instead of a frontier  model. So you can set these sophisticated policies [19:49] and it'll work and it'll help you to save money  and get better outcomes. So that is you know what [19:55] at a glance an AI gateway can do for you um as  an administrator. Um so I sorry I told you the [20:03] budget control. The last thing I'll quickly talk  over in the two minutes I've left is u the premise [20:09] of ROI. So I've showed you what's the value of a  gateway to me as an as an individual developer. [20:15] I've shown you what it looks like for an  administrator to set policies and see the [20:20] global view. Now finally as an executive then  how can I correlate correlate outcome with spend [20:26] and that answer lies in if you're to be able to  extract all the metrics and all the information [20:31] out of the II router layer a gateway layer and  if you're able to marry that with some of the [20:37] u numerator sort of like top down metrics I talked  about at the start of the presentation you would [20:42] have something very interesting and let me show  you what that looks like. [clears throat] So this [20:47] is a an internal project that we uh we work on and  this is an example. So this is not something like [20:54] you know necessarily um every like you can have  something similar you can build in house. This is [21:00] a product that we you we offer for our uh large  customers. But what um this does is it gives you [21:08] a chat interface sort for you to query a lot of  the the gateway data. So here I'll just show you [21:14] some of the example questions. So take a look  at our spend last 30 days. What does each cost [21:20] per request? So this is actually like you know a  simple inter like ranking of the models we have. [21:27] Um another one is you can look at the top 10 PR  contributors last three days. What's the cost [21:33] per PR? So these are sort of like some of our  internal folks uh who are really eager adopters [21:39] of AI and we can get a sense of their cost per PR.  And on the flip side I want to show you something [21:46] a little bit interesting which is uh support  tickets. So if you run an engineering organization [21:52] the cost of support tickets is probably one of  the most expensive things because of productivity. [21:56] um we've like many folks built internal um support  agents and one interesting question is like well [22:03] does the does AI actually help with decreasing  uh resolution times. So one question you can ask [22:11] uh with uh using the data from an AI gateway is  like how much time does u how much time does AI [22:19] actually reduce tickets by looking at the API  keys and um marrying that with ticket data. So [22:25] this is this shows us for us at least there is a  really material reduction in uh ticket resolution [22:32] time and more importantly uh it can if you can  ask the additional draw down question like how [22:38] much is the cost per resolve ticket. So these are  interesting data that you could answer uh with [22:45] the right infrastructure with the right metrics uh  if you can bring it all together. I am just about [22:51] at time. So I'll kind of close out by just saying  that you know the four things to take back to your [22:56] AI program. Uh focus on developer productivity  that is where the big returns are. Um and uh you [23:03] have to sort of get past the initial organization  inertia of debating over metric to just pick some. [23:08] This has to be top down and you have to be able  to consolidate all the metrics in one path. And [23:14] most importantly when you do that you have to have  centralized control with distributed deployment. [23:19] And to come full circle uh this Schroinger's  AI transformation problem can be solved and [23:24] uh you can go back and tell Schroinger that AI  transformation is live and well and we're going [23:30] to find them. That's it. Thank you. So happy  to talk more. You'll find me at a booth 565.