Token经济学驱动架构：混合模型与AKS Kata MicroVM深度评测

账单揭晓的时刻

2024年至2025年期间，“Agent”多半停留在演示阶段。到了2026年，它已化作云账单里一项独立开支。

当下，几乎全部主流模型厂商——包括OpenAI、Anthropic、Google、Mistral、DeepSeek，乃至部署在Kubernetes集群内部的开源权重推理服务——都统一采用Token计费方式。输入Token、输出Token、缓存Token、推理Token、工具调用Token……无一例外都要计费。尽管单位Token价格持续走低，但自主智能体所消耗的Token总量却猛增了一个数量级。

反复引用的参考材料，是Enterprise Agent Workshop的第二个模块——《Token经济学与成本控制》。核心观点可精炼为一句话：智能体系统绝非聊天应用。聊天应用中，用户每次交互通常仅触发一次模型调用。智能体则截然不同：一次调用用于制定计划，一次用于选择工具，一次用于解读工具返回结果，一次用于决策下一步动作，一次用于生成总结——并且它会不断循环。若工具自身又调用模型，成本会进一步叠加。再加上重试与反思机制，调用次数持续攀升。

因此，当前需要厘清的问题已不再是：“模型每百万Token的价格是多少？”而是：“我的系统架构，每处理一次用户请求，实际开销是多少？”

本文要介绍的，正是一套专为解答这个问题而设计的架构。同时，它也不会牺牲企业级场景所必需的安全能力。这套参考架构源自BYOT_Dev项目仓库：一个由四个智能体组成的软件开发生命周期（SDLC）流水线：需求分析 → 代码生成 → 测试 → 部署，运行在AKS之上，每个Agent被隔离在独立的Kata MicroVM中，每个Agent通过MCP向GitHub Copilot Chat暴露工具接口，所有Agent共享一个集群内部的小语言模型服务端点，模型服务由AI Runway提供。

Agent工作负载如何迅速推高Token成本

三个因素叠加放大了成本。

1. 自主性引发调用次数激增。用户在IDE中输入：“帮我构建一个URL缩短服务”，看似一次简单请求，但对于一个由四个Agent组成的流水线而言：澄清需求、生成代码、编写测试、生成Kubernetes部署清单，整个过程中可能已触发：30～200次模型调用，其中大多数对用户完全透明。
2. 推理能力消耗大量输出Token。现代推理模型在回答前会先“思考”。这些隐藏的推理过程同样需要计费。因此：一个最终只输出5行内容的回复，背后可能已消耗：3000个推理Token。
3. 上下文膨胀。每一次工具执行的结果，都会被重新注入到下一轮模型调用中。例如：一次代码审查产生了50 KB的结果。接下来进行代码重构时，这50 KB内容又会成为新上下文。随着会话深入，成本增速往往不是线性，而是超线性的。

你无法通过提示词优化来突破这些限制。唯一可持续的解决方案是：架构优化。而这种优化主要依赖三个杠杆。

本文介绍的架构同时利用了这三个杠杆。

心智模型：前沿模型负责思考，小模型负责执行

请看这张图：

spec:
  image: ghcr.io/kaito-project/aikit/llama3.2:1b
  model:
    id: "kaito/llama3.2-1b"
    source: huggingface
  engine:
    type: llamacpp
  provider:
    name: kaito
    overrides:
      resource:
        instanceType: Standard_D4s_v3
  resources:
    cpu: "2"
    memory: "4Gi"

• 随后，AI Runway会自动完成以下工作：

• 选择推理引擎

  • CPU场景使用llama.cpp
  • GPU场景使用vLLM或Dynamo

• 选择模型提供方

  • 当前支持KAITO
  • 后续将支持更多Provider
• 从AIKit模型目录拉取镜像
• 在http://llama3-2-1b-cpu.airunway-models.svc:80/v1开放兼容OpenAI规范的服务。

关于仅使用CPU示例的说明。需要明确，本仓库刻意采用了CPU + Llama-3.2-1B的组合，目的是证明这套架构能运行在成本最低的节点规格上。但在生产环境中，不应默认CPU一定是最佳选择。真正合理的部署方案，应当根据具体场景来决定：

AI Runway将这些部署选择简化为一次YAML配置修改，而不是一次系统重构。这种抽象层设计的核心价值在于可选择性——它赋予你根据不同阶段的Token成本策略灵活调整架构的能力，而无需重写已有的Agent系统。

混合扩展：推理运行在AKS上，规划使用你已经付费的Copilot Token

当前企业在Token成本控制方面最容易犯的错误，就是将模型部署方式视为非此即彼的选择：“全部部署在集群内部”或者“全部使用按Token计费的云端API”。真实世界的工作负载并非如此。真正能够节省成本的模式包含两个组成部分，而且这两部分其实都已经出现在你的账单中：

1. 你已经部署好的AKS。一个用于承载常驻工作负载的小型CPU节点池。再加上一个能自动扩容的GPU节点池，用于在CPU池无法满足需求时提供额外算力。它们运行在同一个Kubernetes集群，相同的Kata隔离机制，以及同一份Azure账单中。
2. 开发者已经购买的Copilot订阅席位。Copilot Chat所使用的前沿模型已包含在Copilot Seat的Token配额中。因此：不要再额外部署新的推理服务来负责规划任务，而应该利用这部分已付费的Token配额，通过MCP驱动运行在AKS上的廉价Worker Agent。

这就是“混合模式”。不需要：额外的Azure AI Foundry Endpoint，第二套按Token计费的推理服务，只需要：按需扩缩容的AKS计算资源，以及一个你已经付费的前沿模型“大脑”。

Agent的调用流量大致如下：

1. 大约85%的调用通常：简短、范围明确、行为可预测。例如：“扩展这个需求”，“格式化这段YAML”，“总结这个代码差异”。对于这些任务：部署在CPU节点上的1B～3B小模型即可在数秒内完成。此时成本来自节点费用，而不是Token费用。
2. 大约15%的调用属于更重型任务：多文件代码重构、长上下文推理、生成数百行代码（例如400行FastAPI应用）。这些场景需要7B～14B参数规模的GPU模型。
3. 整个流程中的规划和决策工作，都由Copilot订阅席位所包含的前沿模型完成——无论你是否构建BYOT，这部分费用其实都已包含在用户已支付的Copilot订阅中。

杠杆A —— 在同一个AKS集群中部署可从0扩展到N的GPU节点池

保持原有的始终运行的tiny-cpu ModelDeployment。同时增加一个运行在GPU节点池上的中型模型部署。GPU节点池创建时大小为0，并由AKS Cluster Autoscaler管理。

az aks nodepool add 
  --cluster-name $CLUSTER 
  --resource-group $RG 
  --name gpupool 
  --node-vm-size Standard_NC24ads_A100_v4 
  --node-count 0 
  --min-count 0 
  --max-count 4 
  --enable-cluster-autoscaler 
  --node-taints sku=gpu:NoSchedule 
  --workload-runtime KataVmIsolation

# airunway/modeldeployment-mid-gpu.yaml (sketch)
spec:
  image: ghcr.io/kaito-project/aikit/qwen2.5:7b
  engine: { type: vllm }
  provider:
    name: kaito
    overrides:
      resource:
        instanceType: Standard_NC24ads_A100_v4
  nodeSelector: { agentpool: gpupool }
  tolerations: [{ key: sku, operator: Equal, value: gpu, effect: NoSchedule }]
  resources: { cpu: "4", memory: "32Gi", nvidia.com/gpu: "1" }
  scaling: { replicas: 0, maxReplicas: 4 }

这里最关键的技巧是：replicas: 0，配合autoscaler min-count = 0。意味着当没有任何请求需要使用中型模型时，GPU Pod不运行，GPU节点不存在，GPU不产生任何费用。当第一条请求到来时，AI Runway将副本数扩展到1，Cluster Autoscaler创建GPU节点，Kata Sandbox Pod被调度到该节点。当流量消失后，Replica再次缩容到0，GPU节点回收至0。整个过程全部发生在AKS内部。Agent不需要离开集群寻找GPU资源。

杠杆B —— 复用你已经付费购买的Copilot Frontier Token

这是大多数Token成本分析文章忽略的关键点。所有使用BYOT的开发者本身已经拥有Copilot Seat。而Copilot Seat已包含Frontier Model的Token配额。用户在Copilot Chat中输入内容时，这些Token已经开始被消费。例如docs/workflow.md中的编排循环——决定调用哪个工具，读取工具输出，汇总结果。这些操作消耗的Token全部来自Copilot Seat配额，而非来自新的推理服务。

这意味着：

• 无需额外部署OpenAI或Foundry云端Endpoint作为“智能模型”。负责规划与决策的Frontier Model已集成在开发者正在使用的Copilot中。
• 无需在Agent → Frontier的调用路径上引入新的按Token计费机制。实际上，调用方向恰好相反：Frontier Model位于整个工作流的上游，通过MCP调用各个Agent完成任务，而不是Agent去请求Frontier Model。
• 这套架构唯一新增的Token消耗来自Copilot Seat自身的使用，而这一成本不会随着部署BYOT Agent数量的增加而增加。

最终的效果是：那些按Token计费成本较高的任务（如规划与决策），运行在企业已购买的Copilot Token配额上；而那些计算成本较低但生成内容较长的任务，则运行在企业已经按节点时长付费的AKS计算资源上。

Agent如何在两个AKS后端之间进行选择

位于https://github.com/kinfey/Multi-AI-Agents-Cloud-Native/blob/main/code/BYOT_Dev/agents/app/airunway_client.py的Agent Framework客户端，会从ConfigMap中读取base_url和model配置。这里提供了三种策略，复杂度依次递增：

1. 按角色进行静态绑定。byot-requirements和byot-test（成本低、任务单一）使用AIRUNWAY_BASE_URL=tiny-cpu。byot-code和byot-deploy（生成任务更重）使用AIRUNWAY_BASE_URL=mid-gpu。只需修改一个ConfigMap，再执行一次Rollout即可完成切换。
2. 在工具内部采用“先尝试，再升级”策略。每个工具都会首先尝试调用tiny-cpu；如果回答过短、未通过质量检查，或发生超时，则自动重试mid-gpu。小模型负责处理简单的85%请求；GPU资源池只处理真正需要更强能力的15%请求。
3. 在两者前面增加AI Gateway。将Azure API Management作为AI Gateway部署在两个AI Runway服务之前。Agent始终只访问一个URL；Gateway负责执行语义缓存、Token预算控制以及根据负载情况在tiny-cpu与mid-gpu之间进行智能路由。两个后端始终运行在你的AKS集群中——Gateway只负责路由，不参与推理。

一个粗略的Token成本估算

假设一次Copilot Chat会话，通过BYOT Tower触发了底层Agent共30次模型调用。如果这30次调用全部发送到外部Frontier API，例如按照每百万输出Token收费5美元，并且每次调用平均输出2K Token，那么：每次会话将额外产生约0.30美元的底层模型成本——而这还要叠加在Copilot Chat已经为规划所消耗的Seat Token成本之上。

采用AKS + Seat Tokens混合模式之后：

1. 25～26次调用（约85%）→ 由已为常驻Agent持续运行的CPU节点上的tiny-cpu模型处理 → 边际成本约为0美元
2. 4～5次调用（约15%）→ 由mid-gpu模型处理，仅在AI Runway扩容后按GPU节点运行时长计费，并且该成本会被落到同一节点上的所有并发BYOT用户共同分摊 → 成本约为0.02～0.05美元
3. 规划 / 判断→ 已包含在开发者已购买的Copilot Seat Token配额之中 → 新增成本为0美元

原本每次会话约0.30美元的按Token计费成本，将下降到约0.02～0.05美元的纯AKS计算成本。同时，当无人提出复杂问题时，GPU节点会自动缩容到零，因此GPU成本也会回归为零。这就是整个架构的关键杠杆。之所以能做到这一点，是因为：AI Runway为所有Agent提供了统一的集群内部入口；AKS提供了闲置时无需付费的弹性GPU计算能力；Copilot Chat自带开发者已预付费用的Frontier“大脑”。

Kata MicroVM：为Agent代码戴上一顶“硬件级安全头盔”

成本只是Agent工作负载问题的一半。另一半，则是Agent所运行的那个“盒子”里到底发生了什么。

今年早些时候，曾发表过一篇文章：《使用AKS上的Kata MicroVM，为Copilot SDK Agent戴上一顶“硬件级安全头盔”》。其核心观点可概括为：

传统容器就像一间共享屋顶的公寓——那个屋顶就是宿主机的Linux内核。对于一个由人工编写的服务而言，租户是可预测的。但对于一个Agent来说，真正的住户是模型本身，它会在运行时决定：执行哪个Shell命令，读取哪个文件，安装哪个npx包。这构成了一种全新的威胁模型。容器Namespace并不是为这种场景设计的。你真正需要的是：每个Pod都拥有自己独立的Guest Kernel——也就是一个MicroVM。

Kata Containers是Kubernetes获得MicroVM能力的集成层。AKS通过基于Hyper-V的kata-vm-isolation RuntimeClass，将其以Pod Sandboxing的形式提供出来。当Node Pool使用--workload-runtime KataVmIsolation创建时，这一能力会自动启用。

在BYOT_Dev中，每一个Agent Pod都配置了：

spec:
  runtimeClassName: kata-vm-isolation
  containers:
    - name: agent
      securityContext:
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
        seccompProfile:
          type: RuntimeDefault

随后，其余工作全部由AKS完成。Pod会在容器真正启动之前，先启动一个真正的Hyper-V MicroVM，并拥有自己独立的Guest Kernel。验证方式只需一条命令：

kubectl -n agents exec deploy/byot-requirements -- uname -r
# compare with the kernel on the node — they differ → microVM confirmed

该仓库还通过kubernetes.io/hostname上的podAntiAffinity策略，实现了每个节点只部署一个Agent。因此，这四个Agent分别运行在四台物理隔离的Kata Host上。即使其中一个Agent发生了模型逃逸，它也无法通过共享宿主机Kernel影响其他Agent——因为这里根本不存在共享的宿主机Kernel。

这与Token经济学的联系在于：当你开始信任一个廉价的集群内模型，让它去执行真实客户代码上的Agent循环时，你的安全边界必须比普通容器更强，而不是更弱。Kata正是那个让“低成本”与“高安全”不再互相冲突的关键技术。同时，由于AKS Pod Sandboxing在CPU Pool、GPU Pool，以及未来新增的任何Burst Node Pool上都采用完全一致的机制，因此，上文介绍的混合部署策略并不会削弱整体隔离能力。无论Pod部署在哪一个层级，它始终都会启动属于自己的Guest Kernel。

MCP：GitHub Copilot Chat如何真正驱动这座Agent Tower

最后一块拼图是协议。运行在Kata MicroVM中的Agent，如果没有外部能够调用它们，就毫无意义。而这个已存在于用户工作流中的“调用者”，就是VS Code中的GitHub Copilot Chat。Model Context Protocol（MCP）是Copilot Chat（以及几乎所有成熟的Agent IDE）用于与远程工具服务器通信的标准协议。在本仓库中，每一个角色都通过FastMCP over Streamable HTTP对外暴露自己的工具能力，具体实现可以参考agents/app/main.py和agents/app/roles/下各个角色对应的工具集合。

服务暴露虽然只是一个小细节，却非常重要。本仓库为每个角色对应的Service都采用了type: LoadBalancer（见k8s/services.yaml），原因如下：

• kubectl port-forward无法用于Kata Pod（监听器运行在MicroVM内部，而不是宿主机Sandbox的网络命名空间中）。
• kubectl proxy虽然可以工作，但会把Copilot固定到localhost，并且需要持续运行一个本地进程。
• LoadBalancer可以为每个Agent分配一个公网Azure IP，使IDE能够直接访问。

当四个LoadBalancer的IP地址写入.vscode/mcp.json之后，Copilot Chat在Agent模式下就会识别出四个MCP Server：

• byot-requirements
• byot-code
• byot-test
• byot-deploy

此时，用户只需输入：

“使用byot tower，将这个想法——一个带点击统计功能的短链接服务——从需求分析一直完成到部署。”

背后实际发生了什么（docs/workflow.md）

1.Copilot的Frontier模型负责规划整个执行流程。消耗Frontier Token：很少，但承担的是高价值推理。
2.它首先通过MCP调用：

byot-requirements.gather_requirements({
    "idea": "URL shortener…"
})

这里不会消耗Frontier推理资源，真正执行工作的，是集群内运行的Llama-3.2-1B小模型。

3.随后调用：

byot-code.implement_from_requirements({...})

同样如此——由集群内部的小模型完成代码生成。

4.接着调用：

byot-test.generate_test_plan({...})

依旧由集群内的小模型执行。

5.最后调用：

byot-deploy.generate_k8s_manifest({...})

6.最后，Copilot的Frontier模型读取四个Agent返回的结果，并向用户输出一份完整、一致的总结。消耗Frontier Token仍然很少。

昂贵的大模型一共只负责了5次决策。廉价的小模型则完成了4次长文本生成。这正是Token Economics所带来的收益，也是这种架构能够避免厂商锁定的原因——MCP是开放标准。

将架构看作一份成本预算表

把整张架构图转换成一张单位成本表，并明确混合部署的成本来源：

这里有三个值得注意的地方。

第一，大部分按请求变化的成本已经从Token计费转移到了节点计费。CPU节点小时数，比按调用Token消耗更容易预测、更容易做成本分摊，也更容易设置预算上限。你知道自己购买了多少个D4s_v3 CPU核心。但你无法提前知道，一个Frontier模型最终会决定消耗多少Token。

第二，GPU容量不再是一项固定投入，而且始终留在AKS内部。GPU Node Pool默认保持0个节点。只有AI Runway真正需要时，它才会自动扩容，并且是在同一个集群、同一个Kata RuntimeClass下完成调度。无需第二个Region。无需第二个租户。也无需第二份按Token计费的账单。

第三，Frontier Brain被复用了，而不是重新购买。驱动整个Agent Tower的规划和判断全部运行在开发者已购买的Copilot Seat Token配额之上。BYOT并没有额外部署一个“智能模型”云端Endpoint。因此，也就不存在第二个需要持续关注的按Token收费计量器。

另外，由于Kata AKS Pod Sandboxing已经包含在AKS中，并且对CPU Pool与GPU Pool的工作方式完全一致，因此，在计算成本之外，额外增加的安全成本为零。

这正是为什么，这套架构能够同时做到：成本可感知，弹性可扩展，安全可保障。而过去，这三者通常只能三选二。如今，它们可以同时成立。

六条命令，完成全部部署

为了完整起见，下面是仓库README.md中给出的部署顺序。

# 0. 一次性准备：az login、kubectl、helm、docker、aks-preview
az login

# 1. 创建启用Kata、ACR、AzureLinux的AKS集群
bash infra/01-create-aks-kata.sh

# 2. 安装AI Runway Controller与KAITO Provider（固定v0.5.0）
bash infra/02-install-airunway.sh

# 3. 通过AI Runway ModelDeployment在CPU上部署Llama-3.2-1B
bash infra/03-deploy-qwen.sh

# 4. 构建并推送统一Agent镜像到ACR
bash infra/04-build-push-agents.sh

# 5. 部署4个采用Kata隔离的MCP Agent
bash infra/05-deploy-agents.sh

# 6. 输出GitHub Copilot使用的MCP公网Endpoint
bash infra/06-show-mcp-endpoints.sh

将输出的IP地址写入.vscode/mcp.json，打开Copilot Chat，你就拥有了一套完整可运行的Agent Tower：

• • 采用硬件级隔离
• 具备成本感知能力
• 由CPU上的小模型提供推理
• 由开发者已购买Seat的Frontier模型负责整体驱动

当业务规模增长时，只需在旁边增加一个支持Scale-to-zero的mid-gpu ModelDeployment即可。Agent本身无需修改。Copilot集成无需修改。整个推理过程依然全部留在AKS集群内部。

总结：贯穿始终的设计思路

让我们再把整条思路梳理一遍：

1. Token经济学已成为新的SLO（服务等级目标）。Agent化工作负载会成倍增加模型调用次数，而每一次调用都有成本。真正能够改变成本曲线的，不是Prompt，而是架构设计。
2. 对模型进行分层，对部署位置进行分层。将Frontier模型用于最高层的推理与决策；将小模型用于绝大多数实际工作；稳定态任务运行在集群内CPU上，而较重的约15%工作负载则运行在集群内GPU上。
3. 将AKS的计算资源与已购买的Copilot Token配额结合起来使用。不要为了推理能力再额外增加一个按Token计费的云端推理Endpoint。真正需要大量计算的任务应该交给支持Scale-from-zero的AKS GPU节点池；而规划工作则交给开发者已拥有的Copilot Seat Token配额。这种组合既节省了Token（无需新增按Token计费器），又具备弹性扩展能力（只有AI Runway发出请求时，集群才会扩容）。
4. AI Runway将模型部署位置的切换变成了一次YAML修改。今天运行的是CPU上的Llama，明天可以切换成同一集群GPU上的Qwen。Agent代码完全无需修改。
5. 对于Agent代码来说，Kata MicroVM是不可妥协的。租户已不再是应用，而是模型本身。屋顶必须属于自己。AKS Pod Sandboxing将这一能力变成开箱即用，并且对CPU Pool与GPU Pool的工作方式完全一致。
6. MCP是连接两端的桥梁。GitHub Copilot Chat本身已经是一个MCP Client。只需将那些成本低廉的小模型Worker作为MCP Tool暴露出来，Frontier Brain就能够直接调用它们——消耗的是Copilot Seat已包含的Token，而非新增的Token。
7. 本文介绍的参考实现已全部包含在这个仓库中。仅需六条命令，即可完成：四个Agent，一个运行在CPU上的小模型，完整的MicroVM硬件级隔离，真正可用的GitHub Copilot Chat集成。同时，还预留了一条无需修改Agent、无需离开AKS即可逐步扩展的混合部署路径。

在Agent时代，一个容器不再只是应用程序的运行盒子。它同时也是一个承载不确定性和Token成本的盒子。MicroVM负责加固这个盒子；AI Runway负责让模型能够在同一个集群内的CPU节点与GPU节点之间自由切换，而无需重写任何代码；MCP则让用户所使用的昂贵IDE，从盒子外部驱动这个低成本Worker，并且消耗的是已预付费用的Token。这就是整篇文章贯穿始终的核心思路。

构建属于你的Agent Tower，也持续关注它的成本账单。

延伸阅读

1. 示例代码
2. 使用AKS上的Kata MicroVM为Copilot SDK Agent戴上一顶“硬件级头盔”
3. AI Runway与KAITO
4. Kata Containers · AKS Pod Sandboxing
5. Model Context Protocol（MCP）· GitHub Copilot Chat MCP支持