#使用编码智能体和本地部署 LLM 运行 MLOps

#简介

一旦将编码智能体连接到 Alauda AI 上的自托管模型（参见 在本地部署的推理服务中使用编码智能体），同一个智能体就可以驱动平台上的日常 MLOps。由于模型和运维目标都位于同一个集群中，提示词、清单、训练数据引用和基准测试结果都不会离开你的环境——这正是自托管智能体对受监管工作具有吸引力的原因。

本文介绍了四种编码智能体最有用的工作流：

• 编写和管理 InferenceService 和 LLMInferenceService 资源。
• 配置推理流量网关——通过 Alauda Build of Envoy AI Gateway 实现认证和速率限制。
• 迭代调优推理服务性能，使其适配特定硬件。
• 规划微调任务，并基于结果生成结构化报告。

本文假定你已经在运行该智能体，并且它可以访问一个启用了 tool calling 的本地部署 OpenAI-compatible 端点。如果没有，请先阅读上面的前置条件文档。

#设置智能体的工作环境

在委派 MLOps 工作之前，先为智能体提供一个小而可靠的上下文环境。每个项目通常只需做好三件事：

1. 限定集群访问范围。 创建一个专用 namespace（例如平台示例中使用的 mlops-demo-ai-test），并创建一个 ServiceAccount / kubeconfig，将权限限制在智能体应当接触的资源上——通常包括 InferenceService、LLMInferenceService、TrainJob、TrainingRuntime、AIGatewayRoute、AIServiceBackend、BackendSecurityPolicy、SecurityPolicy、BackendTrafficPolicy，以及它们引用的 secrets/configmaps。避免获得集群级写权限。
2. 固定默认硬件配置文件。 平台 Hardware Profiles 编码了 GPU 类型、taint、toleration 和节点选择器。提前选定正确的配置文件并告诉智能体使用它——这样可以避免智能体自行编造 affinity 块。参见 Hardware Profiles。
3. 提交一个智能体上下文文件。 大多数编码智能体都会读取项目级指令文件（例如 AGENTS.md、CLAUDE.md 或 opencode.md）。可用它记录集群名称、目标 namespace、本地模型端点、命名规范、"始终先运行 kubectl apply --dry-run=server" 以及智能体应遵循的内部链接。一旦这个文件存在，后续每个提示词都会更短、更准确。

#管理 InferenceService 和 LLMInferenceService

该平台支持两种相关资源用于模型服务化：

• InferenceService（serving.kserve.io/v1beta1）——在 使用 CLI 创建 Inference Service 中使用的标准 KServe predictor。最适合单容器模型服务（vLLM、Triton、自定义 runtime）。
• LLMInferenceService——KServe 更高层级的 LLM 资源，用于多组件 LLM 服务化（协调 predictors、可选的 prefill/decode disaggregation，以及 gateway/inference-extension 集成）。平台功能可以识别它，例如 Hardware Profiles 会将其与 InferenceService 一起提及（参见 Hardware Profiles）。当单容器 InferenceService 已不足以满足需求时，请使用它。

对于这两种资源，一个高效的智能体循环是相同的：

draft YAML  →  kubectl apply --dry-run=server  →  apply  →  poll status  →  smoke test  →  iterate

可用于启动的提示词示例：

• "使用 aml-vllm runtime、硬件配置文件 single-a30-24g、namespace mlops-demo-ai-test，为模型 Qwen3.6-35B-A3B 生成一个 InferenceService。启用 prefix caching 和 tool calling，并使用与 Qwen3.6 匹配的 parser。运行 kubectl apply --dry-run=server，并在应用之前向我展示与任何现有对象的 diff。"
• "将这个 InferenceService 转换为用于 prefill/decode disaggregation 的 LLMInferenceService；保持相同的模型、硬件配置文件和 served-model 名称。向我展示哪些内容发生了变化，以及原因。"
• "列出 mlops-demo-ai-test 中所有 InferenceService 和 LLMInferenceService 对象、它们的 READY 状态，以及每个对象所服务的模型。标记任何已 NotReady 超过 10 分钟的对象，并汇总最近的 predictor pod 事件。"

对于智能体需要复现的 YAML 字段以及平台特定的 labels/annotations，请将 使用 CLI 创建 Inference Service 作为规范示例。若要对外暴露新服务，请参考 为 Inference Services 配置外部访问。

#管理网关：认证和速率限制

Alauda Build of Envoy AI Gateway 是 Alauda Build of KServe 的必需依赖，用于承载推理流量，并提供 OpenAI-compatible API 形态、面向 AI 的路由以及按模型策略（参见 Envoy AI Gateway 简介）。Envoy AI Gateway 由 Alauda AI 通过 default AmlCluster 中的 envoyAIGateway 组件管理；参见 安装 Alauda AI。智能体非常适合编写这些 CRD，因为它们通常较为冗长：

一个实用的智能体工作流如下：

1. 先用业务语言说明你的意图。 例如："在 https://ai.example.internal 后面暴露 qwen-2 和 deepseek-v4，统一使用一个 OpenAI-compatible 端点。要求从名为 ai-gateway-keys 的 Kubernetes Secret 中提供 Authorization: Bearer API key。限制每个 key 为 60 次请求/分钟和 200k 令牌/小时。将 qwen-2 流量发送到 mlops-demo-ai-test 中的 qwen-2 InferenceService，将 deepseek-v4 发送到同名的 LLMInferenceService。"
2. 让智能体起草 CRD。 在你的 infra 仓库下创建一个目录，每个资源一个文件，并在注释中标明每项策略决策。
3. 应用前先验证。 要求智能体运行 kubectl apply --dry-run=server -f ./gateway/，并总结将会发生哪些变化。只有在你审查通过后再应用。
4. 对新策略做冒烟测试。 让智能体发送一个有效请求、一个未认证请求，以及一个超出速率限制的请求，并确认预期的 200 / 401 / 429 响应。将测试保存为一个小脚本，与清单文件放在一起，以便未来的变更可以重新验证。

关于每个 CRD 的精确字段结构，请参考下面链接的上游文档——版本会变化，智能体应读取实时 spec，而不是自行编造字段。

#根据硬件调优服务性能

本节重点介绍如何让智能体驱动调优，而不是由你手工操作。服务器端可调参数会因 runtime 而异——对于 vLLM，请参见 最佳实践：调优推理服务性能；对于 llama.cpp（GGUF），相关参数包括 --cache-type-k/--cache-type-v（KV cache 量化）、--ctx-size（上下文窗口）、--parallel（并发）以及 --reasoning/--reasoning-budget（reasoning 控制）。

一个高产的循环如下：

关于模型大小与 GPU 内存的选择，请参见前一篇文档中的 选择适合你硬件的模型 部分。关于 autoscaling 和冷启动权衡，请参见 为 Inference Services 配置扩缩容。关于交互式低延迟收益，请参见 vLLM Inference Services 的 Speculative Decoding。

#规划微调并生成报告

微调有两种失败模式，而编码智能体特别擅长防止它们：跳过规划步骤（"直接跑 SFT"）以及跳过报告步骤（"loss 看起来不错"）。智能体的任务是把这两步都显式化。

#为任务选择正确的工具

#可复用的微调计划模板

在提交任何 job 之前，让智能体填写此模板，并将结果与训练代码一起提交。这样可以将“我们打算做什么”和“我们实际做了什么”分离开来，而这正是后续报告所需要比较的内容。

# Fine-tuning plan: <run-id>

## Objective
- Business goal:
- Success metric (what improves; how it's measured):
- Acceptance threshold (minimum acceptable score on the metric):

## Base model
- Model and revision:
- Why this base (capability, license, context window, tool-calling support):

## Dataset
- Source(s) and license:
- Size (examples / tokens):
- Format (e.g., JSONL chat messages):
- Splits (train / eval / held-out):
- Known biases or contamination risks:

## Method
- Approach (SFT / LoRA / QLoRA / OSFT / continued pre-train):
- Justification vs. the alternatives:
- Tool (Training Hub / Kubeflow Trainer v2 / Notebook / LlamaFactory):

## Compute budget
- Hardware (GPU type, count, hours):
- Hardware Profile to use:
- Estimated cost / wall-clock:

## Hyperparameters
- Effective batch size, max_tokens_per_gpu, lr, epochs, scheduler, seed:
- Checkpoint cadence and retention:

## Evaluation plan
- Benchmarks (public + internal):
- Eval harness and seed:
- Comparison baselines (the base model, prior runs):

## Risks and rollback
- What could go wrong (catastrophic forgetting, tool-calling regression, license conflict):
- How we'll detect it:
- Rollback (which model artifact to revert to):

可用的提示词："读取 plan.md。在 namespace mlops-demo-ai-test 中，起草一个精确实现该计划的 Kubeflow Trainer v2 TrainingRuntime 和 TrainJob（或一个 Training Hub notebook）。如果计划中有任何字段含义不明确，请在猜测之前先标出来并问我。"

#可复用的微调报告模板

作业完成后，让智能体读取训练日志、评估输出和资源指标，并填写此报告。将其提交到计划文件旁边。

# Fine-tuning report: <run-id>

## Provenance
- Plan: link to plan.md and its commit SHA
- TrainJob / Notebook: name, namespace, start/end time
- Hardware actually used (vs. planned):
- Model artifact location (PVC / model repo path / OCI image):

## Training summary
- Steps / epochs completed:
- Final training loss; loss trend (link to TensorBoard / MLflow run):
- Throughput (tokens/sec, samples/sec):
- Wall-clock and GPU-hours:
- Anomalies (loss spikes, restarts, OOMs):

## Evaluation results
- Headline metric vs. baseline and acceptance threshold:
- Per-benchmark scores table (this run, base model, prior best):
- Tool-calling sanity check (pass/fail with example):
- Qualitative samples (3–5 prompts; this run vs. base, side by side):

## Cost
- GPU-hours, $ (if applicable), $/percentage-point of improvement:

## Decision
- Promote / re-run / abandon:
- If promote: which `InferenceService` to update and how (image, storageUri, runtime flags):
- If re-run: what to change in the next plan.md:

## Next actions
- Owner / date:

可用的提示词："为 mlops-demo-ai-test 中的 TrainJob qwen-coder-sft-2026-05-29 生成 report.md。从 MLflow run <id> 中提取指标，从 pod 中提取训练日志，从 s3://aml-evals/<run-id>/ 中提取评估结果。与上一次运行 qwen-coder-sft-2026-05-15 进行对比。如果某个部分无法从现有数据中填充，请标记为 TODO，不要编造数值。"

对于实验跟踪和运行元数据，Kubeflow 上的 MLflow 是平台原生方案；请让智能体在训练代码内部将其记录到那里，这样报告就有真实的事实来源。

#每日 MLOps 循环

在完成上面的设置后，智能体可以驱动一个有用的端到端流程：

1. 分诊。 "列出我 namespace 中的推理服务，找出任何 NotReady 或意外缩容到零的资源，汇总最近的网关 4xx/5xx 比例。"
2. 调优。 "qwen-2 的 P95 已超出预算。提出一个变更，应用，重新基准测试，并给出报告。"
3. 更新。 "有一个新的模型产物 qwen-coder-sft-2026-05-29。起草 YAML，将其替换到 qwen-2 InferenceService 中，先将发布限制为 1 个副本，并编写冒烟测试。"
4. 规划。 "起草一个微调计划，用于修复我们在上周评估中看到的 tool-calling 回归。说明方法选择的理由。"
5. 报告。 "昨晚的 job 已完成。生成报告，并告诉我是否可以推进到生产。"

每一步都是独立的提示词，并且各自有需要审查的 diff。智能体负责敲字；你仍然是最终负责的工程师。

#最佳实践与防护措施

• 先只读，后写入。 每个新任务都先让智能体读取状态（get、describe、日志、metrics），并在变更前先描述它会做什么。
• 始终使用 --dry-run=server。 将其写入智能体上下文文件作为固定规则；在任何涉及 kubectl apply 的提示词中都要提及它。
• 每次迭代只做一个变更。 尤其是在性能调优中，混合两个变更会掩盖到底是哪一个起作用。
• 绝不允许智能体伪造指标。 要求它注明每个数值来自哪个文件、日志或 run ID；在数据缺失时必须标记为 TODO。
• 考虑 reasoning 开销。 在对启用了 reasoning 的模型做基准测试时，要同时报告总 token 数以及 reasoning 与内容的拆分。一旦模型在 50 个内容 token 之前先生成了 8,000 个 reasoning token，其开销就是 160:1 ——这会主导延迟和 TPS。对于 llama.cpp，请使用服务端 --reasoning-budget 将其限定；对于其他 runtime，只使用你部署的服务所接受且已有文档说明的请求时控制参数。
• 保持循环完全在本地环境内。 确认任何智能体配置中的 fallback 模型都没有指向托管提供商（有关需要检查的每个智能体设置，请参见 连接你的编码智能体）。
• 全部提交到 Git。 计划、报告、生成的 YAML 和基准测试脚本都应进入 Git，这样下一个人——或者下一个智能体——就能从你离开的地方继续。

#参考资料

• 在本地部署的推理服务中使用编码智能体
• 使用 CLI 创建 Inference Service
• 为 Inference Services 配置外部访问
• 为 Inference Services 配置扩缩容
• vLLM Inference Services 的 Speculative Decoding
• 扩展推理 runtimes
• Envoy AI Gateway — 简介
• Hardware Profiles
• 使用 Kubeflow Trainer v2 进行微调
• 使用 Training Hub 微调 LLM
• 使用 Notebooks 进行微调
• Alauda AI 的 LLM Compressor
• Kubeflow 上的 MLflow
• Envoy AI Gateway 上游文档
• Envoy Gateway 上游文档
• KServe LLMInferenceService
• vLLM benchmarking