MLOps-Basics：从数据到监控，一条完整的 NLP 模型生产化流水线实战指南

示例工程【免费下载链接】MLOps-Basics项目地址https://gitcode.com/GitHub_Trending/ml/MLOps-Basics点击查看免费下载本文基于开源仓库 MLOps-Basics 的顶层 README.md 展开系统梳理了一条从 0 到 9 的 MLOps 学习路径以 BERT 二分类CoLA 句子可接受性判断为统一实验载体逐周覆盖项目搭建、实验监控、配置管理、数据版本控制、模型打包、容器化、CI/CD、镜像仓库、无服务器部署与在线预测监控。读完本文你将掌握一套可复制、可落地的模型全生命周期工程化方案并能在仓库每个 week_* 目录中找到对应的可运行源码与配置文件。该仓库的目标非常明确理解 MLOps 的基础——模型构建、监控、配置、测试、打包、部署、CI/CD 等而非追求 SOTA 效果各子目录 README 均声明 The purpose of the project to explore the libraries and learn how to use them. Not to build a SOTA model.。全项目以 Google 的 BERT tiny 模型google/bert_uncased_L-2_H-128_A-2在 GLUE CoLA 数据集上做句子可接受性二分类为主线每一周在上一周基础上叠加一项 MLOps 能力最终形成从训练到监控的闭环。仓库整体结构与 10 周学习路径从仓库根目录看项目按周组织为 10 个平级目录每目录内部结构随周次逐步复杂化目录核心主题关键技术week_0_project_setup项目搭建Huggingface Datasets / Transformers、PyTorch Lightningweek_1_wandb_logging实验监控Weights Biases、torchmetricsweek_2_hydra_config配置管理Hydra、OmegaConfweek_3_dvc数据/模型版本控制DVCweek_4_onnx模型打包ONNX、ONNX Runtimeweek_5_docker容器化部署Docker、Docker Compose、FastAPIweek_6_github_actionsCI/CDGitHub Actionsweek_7_ecr容器镜像仓库AWS S3 / ECRweek_8_serverless无服务器部署AWS Lambda、API Gatewayweek_9_monitoring预测监控CloudWatch Logs、ElasticSearch、Kibana各周之间保持强连续性week_0的train.py到week_2的train.py是同一份训练主入口的逐步演进引入 Hydra 配置注入week_4开始新增convert_model_to_onnx.py与inference_onnx.py后续 Docker、Lambda 均以 ONNX Runtime 推理为服务底座。Week 0项目搭建——数据、数据加载器、模型、训练与推理的最小闭环Week 0 的目标是搭建一个最简单的文本分类工程聚焦五个问题如何获取数据、如何处理数据、如何定义 DataLoader、如何声明模型、如何训练与推理。对应源码在 week_0_project_setup 目录共四个核心文件data.py、model.py、train.py、inference.py。数据模块Huggingface Datasets LightningDataModuleweek_0_project_setup/data.py 用pl.LightningDataModule封装了数据生命周期核心设计点prepare_data()中通过load_dataset(glue, cola)下载 CoLA 数据并拆分为train_data与val_datatokenize_data()使用AutoTokenizer对句子做截断truncationTrue和定长填充paddingmax_length, max_length512setup(stage)按阶段对数据批量map分词并用set_format(typetorch, columns[input_ids, attention_mask, label])转换为 PyTorch 张量格式提供train_dataloader()shuffleTrue与val_dataloader()两个标准方法。注意tokenize_data的max_length512是 BERT 类模型的上限CoLA 句子通常很短这个取值偏向保守week_2 之后该参数被下移到配置文件中max_length: 128。模型模块LightningModule 封装 BERT 分类头week_0_project_setup/model.py 定义ColaModel(pl.LightningModule)默认模型名google/bert_uncased_L-2_H-128_A-22 层、hidden size 128 的小模型训练快、适合教学save_hyperparameters()自动记录超参model_name、lr1e-2forward()取 BERT 输出的[CLS]向量outputs.last_hidden_state[:, 0]过一个nn.Linear(hidden_size, 2)得到二分类 logitstraining_step/validation_step分别计算交叉熵损失并记录train_loss、val_loss、val_accprog_barTrue使指标显示在进度条中configure_optimizers()返回 Adam学习率从self.hparams[lr]读取。训练与推理入口week_0_project_setup/train.py 组装了训练闭环ModelCheckpoint(dirpath./models, monitorval_loss, modemin)保存验证损失最小的权重EarlyStopping(monitorval_loss, patience3, modemin)防过拟合pl.Trainer配置gpus(1 if torch.cuda.is_available() else 0)、max_epochs5、loggerTensorBoardLogger(...)同时挂载两个回调。week_0_project_setup/inference.py 定义ColaPredictor通过ColaModel.load_from_checkpoint(model_path)加载 checkpoint 并eval()freeze()复用DataModule().tokenize_data()完成同一套预处理保证训练/推理输入一致predict(text)对 logits 做Softmax(dim0)输出[{label: unacceptable/acceptable, score: ...}]格式。运行方式与子目录 README 一致Python 3.8 下conda create --name project-setup python3.8 conda activate project-setup然后pip install -r requirements.txt安装依赖pytorch-lightning1.2.10、datasets1.6.2、transformers4.5.1、scikit-learn0.24.2见 requirements.txt最后python train.py训练、更新 checkpoint 路径后python inference.py推理。若在 Jupyter 中运行还需先conda install ipykernel并将虚拟环境注册为内核python -m ipykernel install --user --name project-setup。Week 1实验监控——Weights Biases 全量接入Week 0 的指标只落在 TensorBoard 和终端Week 1 的目标是系统性地用 WB 追踪每一次实验解决“超参怎么调、模型怎么比、数据和模型之间的关联怎么看”的问题。对应源码在 week_1_wandb_logging。训练侧WandbLogger 替换 TensorBoardweek_1_wandb_logging/train.py 相比 Week 0 的关键改动引入WandbLogger(projectMLOps Basics, entityraviraja)直接作为pl.Trainer的logger指标命名改为分组式train/loss、valid/loss、valid/acc等方便 WB 面板按前缀聚合log_every_n_steps10、deterministicTrue保证可复现并预留了limit_train_batches0.25/limit_val_batches0.25的快速验证开关。指标计算torchmetrics 全面替代手写week_1_wandb_logging/model.py 把 Week 0 用sklearn.metrics.accuracy_score手算准确率的方式升级为torchmetrics模块化指标并首次使用AutoModelForSequenceClassification输出自带 logits 与 loss训练/验证准确率torchmetrics.Accuracy()F1、宏平均/微平均精确率与召回率torchmetrics.F1(num_classes2)、Precision(averagemacro/micro)、Recall(...)每个验证 step 通过self.log(...)记录 6 类指标loss、acc、precision_macro、recall_macro、precision_micro、recall_micro并区分on_step与on_epoch两种聚合粒度。三种图表上报方式validation_epoch_end中演示了往 WB 记录混淆矩阵的三种途径其中主力是wandb.plot.confusion_matrix(probslogits.numpy(), y_truelabels.numpy())其余两种wandb.sklearn.plot_confusion_matrix与 seaborn 热力图、ROC 曲线以注释形式保留可按需切换。数据样本可视化回调SamplesVisualisationLogger(pl.Callback)是一个重要工程模式在on_validation_end时取一个验证 batch把原始句子、真实标签、预测标签组装成pandas.DataFrame筛出预测错误的样本df[df[Label] ! df[Predicted]]再通过trainer.logger.experiment.log({examples: wandb.Table(...)})上传为表格。这让你在 WB 面板里直接查看模型“哪里错了”建立数据与模型表现的直观关联。训练结束后终端会输出wandb: Synced ... runs/xxx形式的同步信息见 week_1_wandb_logging/README.md跟进链接即可在 Dashboard 查看全部图表。至此实验可追溯性超参、指标、样本全部打通。Week 2配置管理——Hydra 把硬编码参数全部外置Week 2 解决的是 Week 0/1 中参数散落在代码里的问题模型名、tokenizer、batch size、max length、epochs、日志频率、是否确定性、batch 限制比例等全部进入 Hydra 配置体系实现配置与代码分离。对应源码在 week_2_hydra_config配置目录为configs/。配置目录结构configs/ ├── config.yaml # 入口配置声明 defaults 与日志覆盖 ├── model/default.yaml # 模型名、tokenizer ├── processing/default.yaml# batch_size、max_length └── training/default.yaml # max_epochs、log_every_n_steps 等入口文件 configs/config.yaml 使用defaults列表组合各分组配置并override hydra/job_logging: colorlog与override hydra/hydra_logging: colorlog启用彩色日志defaults: - model: default - processing: default - training: default - override hydra/job_logging: colorlog - override hydra/hydra_logging: colorlog三个分组配置文件的具体内容model/default.yamlname与tokenizer均指向google/bert_uncased_L-2_H-128_A-2processing/default.yamlbatch_size: 64、max_length: 128相比 Week 0 的 512 更贴合 CoLA 短句训练更快training/default.yamlmax_epochs: 1、log_every_n_steps: 10、deterministic: true、limit_train_batches: 0.25其中limit_val_batches: ${training.limit_train_batches}演示了Hydra 变量插值Variable Interpolation——验证 batch 比例直接引用训练配置的值。代码侧如何消费配置week_2_hydra_config/train.py 用hydra.main(config_path./configs, config_nameconfig)装饰main(cfg)函数签名接收cfg对象logger.info(OmegaConf.to_yaml(cfg, resolveTrue))把解析后的完整配置打印出来便于排查DataModule(cfg.model.tokenizer, cfg.processing.batch_size, cfg.processing.max_length)、ColaModel(cfg.model.name)、max_epochscfg.training.max_epochs、log_every_n_stepscfg.training.log_every_n_steps、deterministiccfg.training.deterministic、limit_train_batchescfg.training.limit_train_batches全部由配置驱动。命令行覆盖与批量实验无需改任何代码即可在命令行覆盖配置并开展多组参数实验这正是 Hydra 的核心价值# 覆盖单个参数 python train.py processing.batch_size32 # 覆盖模型名跑不同的预训练模型 python train.py model.namebert-base-uncased # 覆盖训练轮数 python train.py training.max_epochs10 # 覆盖插值来源让训练与验证 batch 比例解耦 python train.py training.limit_val_batches0.5由于配置文件被拆分为 model / processing / training 三个维度组合不同参数即可系统化扫参如「模型 × batch size × epochs」每次运行 Hydra 还会自动生成独立输出目录配合week_1的 WB 记录实验对比与回溯变得非常轻松。Week 3数据版本控制——DVC 管理模型文件Week 3 解决 Git 无法高效管理大文件的问题经典代码版本控制不是为处理大文件设计的克隆和存储历史会变得不切实际而机器学习中模型、数据集又恰恰是大文件。对应源码与配置在 week_3_dvc。学习路径上的关键动作README 列出的 Week 3 主题为DVC 基础、初始化 DVC、配置远端存储、保存模型到远端、模型版本化。仓库中保留了可直接研读的产物——dvcfiles/trained_model.dvcwdir: ../models outs: - md5: c2f5c0a1954209865b9be1945f33ed6e size: 17567709 path: best-checkpoint.ckpt这份.dvc文件说明了 DVC 的工作模型真正的模型二进制约 17.5 MB 的best-checkpoint.ckpt不进 Git只把它的md5校验和、文件大小与wdir相对路径记录成一个小文本文件提交到 GitDVC 通过 md5 判断内容是否变化通过远端存储如 Google Drive、AWS S3保存实际对象。对应命令流程为dvc init # 初始化 DVC dvc remote add name url # 配置远端存储如 Google Drive / S3 dvc add ../models/best-checkpoint.ckpt # 跟踪模型文件并生成 .dvc 文件 dvc push # 把模型对象上传到远端 # 切换版本时 git checkout commit # 切换 .dvc 文件的版本 dvc pull # 拉取对应版本的模型对象通过「Git 管元数据 DVC 管二进制」模型版本与代码版本一一绑定复现历史实验只需同时 checkout 代码与模型即可。Week 4模型打包——ONNX 与 ONNX Runtime 跨框架推理Week 4 回答“为什么需要模型打包”模型可能用 sklearn / TensorFlow / PyTorch 等任意框架训练却要部署到移动端、Web、树莓派等不同环境甚至希望“PyTorch 训练、TensorFlow 推理”。一个统一的、可被多种框架、工具、运行时和编译器消费的文件格式至关重要这就是社区项目 ONNX。对应源码在 week_4_onnx。转换脚本torch.onnx.exportweek_4_onnx/convert_model_to_onnx.py 演示了完整的 PyTorch → ONNX 导出hydra.main复用 Week 2 的配置体系cfg.model.tokenizer、cfg.processing.batch_size、cfg.processing.max_length证明配置管理与模型打包可以无缝衔接从models/best-checkpoint.ckpt加载训练好的ColaModel从训练 DataLoader 取一个真实样本作为导出用的 dummy 输入input_ids、attention_mask各加 batch 维度核心调用torch.onnx.export关键参数export_paramsTrue导出训练好的权重opset_version10指定 ONNX 算子集版本input_names[input_ids, attention_mask]、output_names[output]为模型输入输出命名dynamic_axes把第 0 维声明为动态batch_size使导出模型支持变长 batch 推理输出保存为models/model.onnx。ONNX Runtime 推理week_4_onnx新增的 inference_onnx.py后被week_5~week_9复用定义ColaONNXPredictor通过onnxruntime.InferenceSession加载.onnx模型session.run(output_names, {input_names: tensors})完成推理并沿用 Week 0 的 tokenize 预处理与 softmax 后处理输出与ColaPredictor一致的 label/score 结构。这意味着推理服务从此不再依赖 PyTorch 与 Transformers 运行时仅需 ONNX Runtime 即可为后续 Docker 精简镜像、Lambda 冷启动优化奠定基础。Week 4 的学习主题还包括“Comparisons”——即对比 PyTorch 原生推理与 ONNX Runtime 推理在延迟、依赖体积、跨平台能力上的差异仓库代码结构inference.pyvsinference_onnx.py并存即为可复现对照实验的两个入口。Week 5容器化——FastAPI Docker Docker Compose 一键部署Week 5 解决经典难题——“It works on my laptop/system”。他人运行你的应用时常因依赖或操作系统差异失败手动配置主机环境既繁琐又易错。容器技术将应用连同环境一起打包可在任意云平台获得托管服务、自动扩缩容与高可靠性而最主流的工具就是 Docker。对应源码在 week_5_docker。FastAPI 推理服务week_5_docker/app.py 用 FastAPI 封装 ONNX 推理from fastapi import FastAPI from inference_onnx import ColaONNXPredictor app FastAPI(titleMLOps Basics App) predictor ColaONNXPredictor(./models/model.onnx) app.get(/) async def home_page(): return h2Sample prediction API/h2 app.get(/predict) async def get_prediction(text: str): return predictor.predict(text)两个端点/提供健康检查页/predict?text...接受文本并返回[{label: ..., score: ...}]。由于推理层已切换到 ONNX Runtime服务不再依赖训练框架。Dockerfile 与 Docker Composeweek_5_docker/Dockerfile 采用分层构建FROM huggingface/transformers-pytorch-cpu:latest COPY ./ /app WORKDIR /app RUN pip install -r requirements_prod.txt ENV LC_ALLC.UTF-8 ENV LANGC.UTF-8 EXPOSE 8000 CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8000]基础镜像选用 CPU 版 Transformers/PyTorch 镜像避免携带 GPU 驱动与 CUDA 库COPY全部代码后RUN pip install -r requirements_prod.txt安装推理专用依赖注意是requirements_inference.txt这一精简清单见 week_5_docker/requirements_inference.txtEXPOSE 8000声明端口CMD直接以uvicorn app:app启动服务。week_5_docker/docker-compose.yml 把编排简化到一行命令version: 3 services: prediction_api: build: . container_name: inference_container ports: - 8000:8000使用方式docker build -t mlops-basics-app . # 构建镜像 docker-compose up # 或直接编排启动 curl http://localhost:8000/predict?textThe boy is sitting on a bench至此模型被封装成一个可随处运行的标准 HTTP 服务为后续 CI/CD 与云部署提供统一交付物镜像。Week 6CI/CD——GitHub Actions 自动训练、测试与部署CI/CD 是一套编码理念与实践集合持续构建、测试并部署迭代中的代码变更从而降低“基于错误旧版本开发新功能”的风险并最大限度减少人工干预。对应目录为 week_6_github_actions。学习要点与配套工具README 列出的 Week 6 主题包括GitHub Actions 基础、第一个 Action、创建 Google Service Account、授权 Service Account、配置 DVC 使用该账号、配置 GitHub Action。仓库为此新增了 week_6_github_actions/parse_json.py——一个把下载的凭据文本如 Google Service Account 的 key 文件内容解析为 JSON 的小工具用于在 CI 中把 DVC 远端Google Drive凭据注入为环境变量/文件。在仓库中的落地形态week_6_github_actions目录与 Week 5 结构完全一致含app.py、Dockerfile、docker-compose.yml、ONNX 相关文件说明 CI/CD 阶段复用并持续集成此前全部成果。典型工作流逻辑为代码 push 触发 workflow使用 Service Account 凭据配置 DVC 远端dvc pull拉取被版本控制的模型运行测试/构建检查构建 Docker 镜像并推送供后续部署消费。basic_flow.png中的流程即可作为设计 CI 流水线的参照事件 → JobSetup → DVC Pull → 构建 → 推送→ 部署。Week 7容器镜像仓库——AWS S3 与 ECRWeek 7 引入容器镜像仓库概念镜像仓库是存放容器镜像的地方镜像由多层文件构成可单实例执行应用集中托管让用户能随时提交、识别和按需拉取镜像。同时引入 S3——面向互联网的大容量低成本存储服务。对应目录为 week_7_ecr。README 列出的主题为S3 基础、S3 编程访问、配置 AWS S3 为 DVC 远端、ECR 基础、配置 GitHub Actions 使用 S3 与 ECR。仓库内该目录保留了 Week 5/6 的完整交付物Dockerfile、app.py、docker-compose.yml、parse_json.py等说明这一周的核心是把已有能力绑定到 AWS 基础设施上S3 作为 DVC 远端与 Week 3 的dvc remote add流程一致只是 URL 指向 S3如s3://my-bucket/dvc-storeAWS 访问密钥经环境变量AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY或 IAM 角色注入ECR 托管镜像docker build后用aws ecr get-login-password登录、docker tag打上 ECR 仓库地址、docker push上传CI 联动在 GitHub Actions 中配置 AWS 凭据让流水线自动完成 S3 拉模型 → 构建镜像 → 推送 ECR 的完整链路。Week 8无服务器部署——AWS Lambda API GatewayWeek 8 引入无服务器架构无需管理基础设施即可构建和运行应用——应用仍运行在服务器上但所有服务器管理交给 AWS开发者不再需要预置、扩缩容和维护服务器可聚焦核心产品。对应目录为 week_8_serverless。Lambda Handler 实现week_8_serverless/lambda_handler.py 是推理服务的无服务器封装inferencing_instance ColaONNXPredictor(./models/model.onnx) def lambda_handler(event, context): if resource in event.keys(): # 经 API Gateway 触发从 body 中解析句子 body json.loads(event[body]) response inferencing_instance.predict(body[sentence]) return {statusCode: 200, headers: {}, body: json.dumps(response)} else: # 直接调用测试event 本身即输入 return inferencing_instance.predict(event[sentence])设计要点在模块顶层实例化ColaONNXPredictor复用 Week 4 的 ONNX Runtime 推理器这样 Lambda 容器被复用时无需重新加载模型显著降低冷启动开销处理两种调用形态resource in event.keys()判断是否为 API Gateway 代理触发解析event[body]并返回标准 HTTP 响应否则视为直接调用返回裸预测结果__main__中提供{sentence: ...}的本地冒烟测试便于不登录 AWS 也能验证 handler 逻辑。学习路径上的主题README 列出的动作包括Serverless 基础、AWS Lambda 基础、用 API Gateway 触发 Lambda、用 Lambda 部署容器、用 GitHub Actions 自动化部署到 Lambda。这一周同时展示了两种部署形态直接把 handler 打包上传或沿用 Week 5 的镜像走「容器部署」。自动化层面CI 中把镜像推送到 ECR 后即可触发 Lambda 函数更新aws lambda update-function-code完成从提交到上线的全自动链路。Week 9预测监控——CloudWatch ElasticSearch KibanaWeek 9 回答“生产环境中模型预测出问题怎么办”。监控系统能让我们确信系统平稳运行并在故障时快速定位根因。训练与推理阶段的监控关切点不同训练时关心 loss 是否下降、模型是否过拟合推理时则要确信模型在做正确预测。对应目录为 week_9_monitoring。模型预测失败的三类典型原因README 明确列举了推理阶段模型“有效但无用”的三种场景数据分布漂移底层数据分布随时间变化推理数据特征与训练数据特征不再一致模型已过时边缘情况推理数据流包含训练时未见过的边角样本模型表现差甚至报错生产配置错误模型在生产部署中被误配置配置问题很常见。在上述任一场景下模型从服务角度仍可能“成功”返回预测但预测结果基本不可用。监控的价值在于及早发现这类情况并介入如触发重训练/重部署流水线这正是训练监控Week 1与预测监控Week 9的分工。监控链路的搭建步骤README 列出的主题为CloudWatch Logs 基础、创建 ElasticSearch 集群、配置 CloudWatch Logs 对接 ElasticSearch、在 Kibana 创建 Index Patterns、创建 Kibana 可视化、创建 Kibana Dashboard。典型数据流为Lambda 预测日志 → CloudWatch Logs → Logstash/订阅流 → ElasticSearch 集群 → Kibana 索引与可视化CloudWatch LogsWeek 8 的 Lambda 每次推理都会写入日志如Got the input: ...与预测结果这些日志进入 CloudWatch Log GroupElasticSearch 集群创建一个 ES 集群作为日志的聚合与检索后端对接配置将 CloudWatch Logs 通过订阅/流式传输配置到 ES让结构化日志句子、预测标签、分数、时间戳可被全文检索与聚合Kibana Index Patterns定义索引模式把日志字段句子、label、score、timestamp映射为可查询、可聚合的字段Kibana Visualisations 与 Dashboard基于索引构建图表如预测标签分布、不可接受句子的比例随时间变化、各分数段的计数拼装成 Dashboard用于监控预测质量与数据漂移信号。从 Week 0 到 Week 9 的完整闭环把各周串联起来即是一条完整的模型生产化流水线Week0 数据/模型/训练/推理 → Week1 WB 实验监控 → Week2 Hydra 配置管理 → Week3 DVC 数据/模型版本控制 → Week4 ONNX 跨框架打包 → Week5 Docker 容器化服务 → Week6 GitHub Actions CI/CD → Week7 S3/ECR 存储与镜像仓库 → Week8 Lambda 无服务器部署 → Week9 Kibana 预测监控生产侧服务与监控依赖 ONNX Runtime 推理器inference_onnx.py与模型产物models/model.onnx、DVC 跟踪的 checkpoint开发侧依赖 Hydra 配置configs/与 WB 记录——这正是「配置 → 训练 → 版本化 → 打包 → 部署 → 监控」可复现、可审计、可回滚的工程化范式。快速开始从本仓库起步若想从零跑通这套流水线推荐按周递进操作克隆仓库后进入 week_0_project_setup创建 Python 3.8 虚拟环境并pip install -r requirements.txtpython train.py完成首个训练闭环依次进入后续目录每个目录都是上一周的增量版本观察train.py如何逐步引入 WB、Hydrainference.py如何演进为inference_onnx.pyapp.py/lambda_handler.py如何复用同一个推理器需要联网能力的周WB、DVC 远端、AWS、Kibana请按对应 README 配置凭据与环境变量仅做代码研读时week_4之前的所有步骤在本地 CPU 即可完成各周目录内均附带experimental_notebooks/data_exploration.ipynb探索性笔记与完整requirements.txt可在 Jupyter 中对照学习。需要注意的是本项目定位是 MLOps 基础教学明确声明 Not to build a SOTA model所有周次均使用小规模 BERT 模型与受限训练轮数/数据比例如max_epochs: 1、limit_train_batches: 0.25保证可复现、低门槛运行将同一套工程模式迁移到生产项目时应根据数据规模与算力资源调整这些配置。赞分享示例工程【免费下载链接】MLOps-Basics项目地址https://gitcode.com/GitHub_Trending/ml/MLOps-Basics点击查看免费下载相关推荐MLOps-Basics 项目教程从零到生产部署的完整指南MLOps Basics 项目教程从零到生产部署的完整指南 还在为机器学习项目的手工部署和版本管理而烦恼吗MLOps Basics 项目为你提供了一个从模型示例工程把B站搬上游戏主机一只手柄追番看直播的大屏体验把B站搬上游戏主机一只手柄追番看直播的大屏体验 窝在沙发里手柄一按下一集番剧就在电视上播起来——这是B站游戏主机客户端wiliwili带来的日常。作为一款音视频桌面应用ClearML MLOps编排从实验到生产的自动化流水线ClearML MLOps编排从实验到生产的自动化流水线 本文详细介绍了ClearML平台的MLOps编排能力重点阐述了其远程任务执行与资源调度策略、KubMLOpsLLMOps人工智能上一篇nas-tools 重复文件检测3分钟扫完1000个文件重复空间一次清出来下一篇ToastFish 通知栏背单词3步设置把等待时间变成单词量创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考