#使用编码智能体与本地部署 LLM 开展 MLOps

#简介

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

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

• 编写和管理 InferenceService 与 LLMInferenceService 资源。
• 配置推理流量网关——通过 Alauda Build of Envoy AI Gateway 实现身份验证和速率限制。
• 反复调优推理服务的性能，使其适配特定硬件。
• 规划微调运行，并根据结果生成结构化报告。

本文假设您已经在运行智能体，并且它可以访问启用了工具调用的本地 OpenAI 兼容端点。如果尚未满足，请先阅读上面的先决条件文档。

#设置智能体的工作环境

在委派 MLOps 工作之前，请为智能体提供一个小型、可靠的操作上下文。每个项目通常都值得一次性完成以下三件事：

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

#管理 InferenceServices 和 LLMInferenceServices

平台支持两种用于提供模型服务的相关资源：

• InferenceService（serving.kserve.io/v1beta1）——使用 CLI 创建 Inference Service 中的标准 KServe predictor。适用于单容器模型服务器（vLLM、Triton、自定义运行时）。
• LLMInferenceService——KServe 的更高层 LLM 资源，用于多组件 LLM 服务（编排 predictor、可选的 prefill/decode 分离，以及网关/推理扩展集成）。Platform Hardware Profiles 等功能会识别它，并将其与 InferenceService 并列提及（请参阅Hardware Profiles）。当单容器 InferenceService 已无法满足需求时使用它。

对于任一资源，良好的智能体循环都是相同的：

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

可作为起点的实用提示词：

• “为模型 Qwen3.6-35B-A3B 生成一个 InferenceService，使用 aml-vllm 运行时、硬件配置 single-a30-24g 和命名空间 mlops-demo-ai-test。启用 prefix caching 和工具调用，并使用与 Qwen3.6 匹配的 parser。运行 kubectl apply --dry-run=server，在应用之前向我展示与现有对象的差异。”
• “将此 InferenceService 转换为支持 prefill/decode 分离的 LLMInferenceService；保留相同的模型、硬件配置和 served-model 名称。展示变更内容及原因。”
• “列出 mlops-demo-ai-test 中所有 InferenceService 和 LLMInferenceService 对象、它们的 READY 状态以及各自提供服务的模型。标记任何已 NotReady 超过 10 分钟的对象，并总结最新的 predictor pod 事件。”

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

#管理网关：身份验证和速率限制

Alauda Build of Envoy AI Gateway 是 Alauda Build of KServe 的必需依赖，通过 OpenAI 兼容的 API 表面、AI 感知路由和按模型配置来处理推理流量（请参阅Envoy AI Gateway 简介）。Envoy AI Gateway 由 Alauda AI 通过 envoyAIGateway 组件在 default AmlCluster 中进行管理；请参阅安装 Alauda AI。智能体非常适合编写其 CRD，因为这些 CRD 通常较为冗长：

实际的智能体工作流如下：

1. 用业务术语告知智能体您的意图。 例如：“在 https://ai.example.internal 暴露 qwen-2 和 deepseek-v4，使其位于同一个 OpenAI 兼容端点之后。要求使用来自 Kubernetes Secret、名称为 ai-gateway-keys 的 Authorization: Bearer API key。将每个 key 限制为每分钟 60 个请求、每小时 200k 个令牌。将 qwen-2 流量发送到 mlops-demo-ai-test 中的 qwen-2 InferenceService，并将 deepseek-v4 发送到同名的 LLMInferenceService。”
2. 让智能体起草 CRD。 在基础设施仓库下的目录中为每个资源创建一个文件，并添加注释说明每项策略决策。
3. 应用前进行验证。 要求智能体运行 kubectl apply --dry-run=server -f ./gateway/ 并总结将发生的变更。仅在审查后应用。
4. 对新策略执行冒烟测试。 让智能体发送有效请求、未经身份验证的请求以及超出速率限制的请求，并确认预期的 200 / 401 / 429 响应。将测试作为小型脚本与清单放在一起，以便今后的变更能够重新验证。

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

#调优服务性能以适配硬件

本节重点介绍如何让智能体驱动调优，而不是由您手动完成。服务器端旋钮因运行时而异——对于 vLLM，请参阅最佳实践：调优推理服务性能；对于 llama.cpp（GGUF），相关标志包括 --cache-type-k/--cache-type-v（KV cache 量化）、--ctx-size（上下文窗口）、--parallel（并发）和 --reasoning/--reasoning-budget（推理控制）。

高效的循环如下：

关于模型大小与 GPU 内存的选择，请参阅前一篇文档中的选择适合硬件的模型部分。关于自动扩缩容和冷启动的权衡，请参阅配置 Inference Services 的扩缩容。关于交互式延迟优化，请参阅vLLM Inference Services 的推测解码。

#规划微调并生成报告

微调有两种失败模式，编码智能体尤其擅长防止它们：跳过规划步骤（“直接运行 SFT”）以及跳过报告步骤（“loss 看起来没问题”）。智能体的任务是让这两步都明确化。

#为任务选择正确工具

#可复用的微调计划模板

在提交任何作业之前，让智能体填写此模板，并将结果与训练代码一同提交。这样可以将“我们打算做什么”与“我们实际运行了什么”分开，而这正是报告稍后所需的比较。

# 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。起草一个 Kubeflow Trainer v2 TrainingRuntime 和 TrainJob（或 Training Hub notebook），在命名空间 mlops-demo-ai-test 中严格执行此计划。突出显示计划中含糊的字段，并在猜测前询问我。”

#可复用的微调报告模板

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

# 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 (S3 URI / PVC URI / OCI image URI):

## 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 运行 <id> 获取指标，从 pod 获取训练日志，并从 s3://aml-evals/<run-id>/ 获取评估结果。与之前的运行 qwen-coder-sft-2026-05-15 进行比较。如果某个部分无法根据现有数据填写，请标记为 TODO，不要编造数字。”

对于实验跟踪和运行元数据，Kubeflow 上的 MLflow是平台原生选项；告诉智能体在训练代码内部将日志记录到那里，使报告拥有真实的数据来源。

#每日 MLOps 循环

在完成上述设置后，智能体可以驱动以下端到端流程：

1. 分类处理。 “列出我的命名空间中的推理服务，找出任何 NotReady 或意外缩放到零的服务，并总结近期网关 4xx/5xx 比率。”
2. 调优。 “qwen-2 的 P95 超出预算。提出一项变更，应用、重新进行基准测试并报告。”
3. 更新。 “qwen-coder-sft-2026-05-29 有新的模型构件。起草 YAML，将其换入 qwen-2 InferenceService，先将发布限制到一个 Replica，并编写冒烟测试。”
4. 规划。 “起草一个微调计划，修复我们在上周评估中发现的工具调用回归问题。说明方法选择的理由。”
5. 报告。 “昨晚的作业已完成。生成报告，并告诉我是否应晋级。”

每一步都是一个独立提示词，并有自己的差异供审查。智能体是打字员；您仍然是记录在案的工程师。

#最佳实践与防护措施

• 先只读，后写入。 每项新任务都先要求智能体读取状态（get、describe、日志、指标），并在进行变更前描述它将采取的操作。
• 始终执行 --dry-run=server。 将其作为智能体上下文文件中的长期规则；在涉及 kubectl apply 的每个提示词中都提及它。
• 每次迭代只进行一项变更。 尤其是性能调优时，同时进行两项变更会掩盖究竟是哪一项发挥了作用。
• 绝不允许智能体编造指标。 要求它引用获取每个数字所依据的文件、日志或运行 ID，并在数据缺失时标记 TODO。
• 考虑推理开销。 对启用推理的模型进行基准测试时，同时报告 token 总数以及推理与内容的细分。一个模型在 50 个内容 token 之前输出 8,000 个推理 token，即产生 160:1 的开销——这会主导延迟和 TPS。对于 llama.cpp，使用服务器端 --reasoning-budget 对其进行限制；对于其他运行时，仅使用已部署服务接受且有文档说明的请求时控制项。
• 让循环保持在本地。 确认任何智能体配置中的备用模型都没有指向托管提供商（有关需要检查的每个智能体设置，请参阅连接编码智能体）。
• 提交所有内容。 计划、报告、生成的 YAML 和基准测试脚本全部提交到 Git，以便下一位人员——或下一个智能体——从当前进度继续工作。

#参考

• 将编码智能体与本地部署推理服务结合使用
• 使用 CLI 创建 Inference Service
• 配置 Inference Services 的外部访问
• 配置 Inference Services 的扩缩容
• vLLM Inference Services 的推测解码
• 扩展 Inference Runtime
• 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 基准测试