AI/ML 平台与 LLMOps¶

Kubernetes 中 GPU 调度、隔离和利用率如何治理？¶

技术说明

在 Kubernetes 中，GPU¹ 通常由设备插件把扩展资源暴露给调度器，Pod request 与 limit 对这类资源一般相同，调度器只知道数量，不天然理解显存、拓扑或利用率。节点标签/污点、RuntimeClass 和调度扩展用于区分型号、驱动、CUDA 与拓扑；MIG² 可将支持的 GPU 硬件分片，time-slicing 则共享时间但隔离和性能可预测性不同。训练的 gang scheduling、跨节点高速网络与本地数据需要额外队列/拓扑调度。

驱动、容器 runtime、固件和框架形成兼容矩阵，升级先做节点金丝雀。监控设备健康、显存、SM 利用、温度、ECC/Xid 错误、队列等待、作业吞吐及单位任务成本；低 GPU 利用可能在等 CPU、数据加载或网络，不能只增加批次。多租户需限制设备、共享内存、宿主权限和数据访问，不可信任务考虑更强节点隔离。

实践经验

某训练队列显示 GPU 紧缺，但节点 SM 利用仅 25%。profile 与 I/O 指标显示数据从远端小文件串行加载，增加 GPU 反而闲置。团队先缓存数据、提高 loader 并发并调 CPU request，吞吐提升后再扩容。缓存增加本地盘和数据治理风险，因此加密、生命周期和数据集版本校验；长期以每 GPU 小时有效样本数而非分配率衡量效率。

面试回答要点

企业级 AI/ML 平台应覆盖哪些生命周期能力？¶

技术说明

AI/ML³ 平台覆盖数据发现与权限、特征/数据准备、实验追踪、可复现训练、超参任务、模型注册、评估审批、部署、在线/批量推理、监控与退役。每次运行绑定代码 revision、不可变环境、数据版本、参数、随机种子、硬件和输出 digest；编排任务幂等、可恢复且有资源配额。模型 registry 管生命周期和批准状态，但制品仍放受控对象存储并签名。

开发、验证、生产身份与数据隔离，训练数据最小权限，敏感数据有审计和保留。发布按模型风险分层：影子、离线回放、金丝雀/A-B、回滚；验证不仅技术延迟，还包括质量、公平性、安全和业务指标。CPU/GPU 队列具备优先级、公平性与成本预算。平台抽象常见路径，但允许研究阶段灵活沙箱，进入生产前收敛为可复现流水线。

实践经验

某模型在笔记本效果优秀，生产重训后无法复现，原因是数据快照与依赖未记录。团队暂停自动晋级，从日志和对象版本恢复近似训练集；长期强制运行清单、锁定环境、数据版本和评估签名，只有注册模型可部署。记录完整 lineage⁴ 增加存储与流程时间，因此研究草稿可短期保留，候选生产运行必须满足完整门禁。

面试回答要点

模型制品、数据版本和 lineage 如何做到可复现与可审计？¶

技术说明

模型版本不能只用文件名；以内容 digest 标识权重，并附架构/代码 revision、框架与环境、训练参数、数据集快照或查询版本、特征定义、评估结果和批准记录。数据量巨大时可记录不可变表版本、对象 manifest 与 checksum，而非复制全部。lineage 图连接原始数据—特征—训练运行—模型—部署—预测，标识每个节点的 owner 和保留策略。

数据会因迟到修正、删除请求和权限变化而演进，可复现需区分“精确比特复现”和“语义复现”，并记录随机性/非确定算子边界。制品签名、访问控制和不可变存储防篡改；部署记录模型 digest 而非可变 alias，alias 仅作受审计指针。删除敏感训练数据时要有模型影响评估与法规流程。

实践经验

某线上质量回退只知道模型名 latest，无法定位训练数据。部署日志与对象时间戳勉强确认候选版本后先回滚上一 digest；长期 registry 强制 lineage manifest，生产部署保存模型/容器/配置 digest 与数据 snapshot ID。不可变版本增加存储成本，因此对中间 checkpoint 分级保留，但已发布模型及其关键 lineage 满足审计周期。

面试回答要点

LLMOps 如何管理 Prompt、评测、RAG 与安全风险？¶

技术说明

LLMOps⁵ 中，Prompt⁶、系统指令、工具 schema、检索配置、模型与采样参数都应版本化，发布形成不可变组合。离线评测集覆盖典型、边界和对抗样本，指标包含任务正确性、 groundedness/引用、拒答、安全、延迟和成本；LLM-as-judge 有偏差和漂移，应校准人工标注并固定 judge 版本。在线用金丝雀/A-B、用户反馈和回归检测补充，不能只凭少量 demo。

RAG⁷ 需管理文档来源、权限、切片、embedding、索引版本和新鲜度，检索结果继承原始 ACL，防跨租户泄露。Prompt injection⁸ 按不可信输入处理，工具调用使用 allowlist、参数校验、最小权限、确认和审计；输出做结构校验与敏感数据过滤。第三方模型版本可能无通知变化，因此记录 provider/model 标识、探测基线和回退路由。

实践经验

某客服机器人更新检索切片后幻觉投诉升高，但平均相似度正常。版本对照显示关键政策段落被拆散，离线集又缺长文档问题。团队先回滚索引 manifest、限制高风险回答为引用式，并扩充人工评测；长期把 prompt+模型+索引作为单一发布单元。更严格拒答降低覆盖率，因此与业务共同设风险分层，而非只追求回答率。

面试回答要点

推理服务如何优化延迟、吞吐、可靠性和可观测性？¶

技术说明

推理延迟拆为排队、预处理、prefill、逐 token decode、工具/检索和网络；观察 TTFT⁹、inter-token latency、端到端 p50/p95/p99、tokens/s、batch、队列、拒绝和取消。动态 batching 提高 GPU 吞吐却增加排队，KV cache 提速但占显存并有租户隔离风险；量化降低成本/显存但可能损伤质量。自动扩缩要用队列、token 负载与启动时间，而非只看 GPU 利用率。

可靠性设计有 admission control、每租户配额、超时/取消传播、模型预热、健康探测、降级模型和跨区容量。流式响应开始后难以透明重试，需在首 token 前后区分策略。可观测数据记录模型/提示/索引版本、token 数、结束原因和错误类别，但不默认记录原始 prompt；质量漂移、拒答、安全、单位 token/成功任务成本与系统 SLO 联合看。

实践经验

某聊天服务流量翻倍后 GPU 利用率仍 60%，TTFT 却达 20 秒。队列和 batch trace 显示单个超长上下文拖住批次，且取消请求仍继续 decode。团队先限制上下文、传播取消并为长请求分池，随后按 token 预算公平排队。分池降低总体合批效率，却保护交互 p99；长期用成功会话单位成本、TTFT 和质量评测共同验收，而非单追 tokens/s。

面试回答要点