前阵子连续做了几个华为云ModelArts上的大模型项目从部署到微调都踩了一遍回头再看这类需求其实非常典型模型开源了、API也有无数家但真要落到自己的业务场景里自己部署一套可用服务再把模型往自己的数据上微调一版很多人都卡在第一步。ModelArts这个平台我实际用下来个人感觉在“大模型部署”和“微调”这两件事上比从零搭K8s集群、自己管GPU要省心得多。这篇文章我不打算写成官方文档就按实际动手的顺序来讲先讲清楚部署和微调分别要解决什么问题然后讲环境与算力评估再讲部署实操、微调实操最后把我在ModelArts上遇到的几个高频问题列出来。内容会涉及vLLM、Llama-Factory、LoRA、量化这些常用技术但都会用大白话解释目标是让一个没怎么碰过大模型部署的人跟着走也能把自己的模型跑起来、微起来。1. 动手前先想清楚部署和微调分别要解决什么问题很多人一上来就问“ModelArts怎么部署大模型”“怎么微调”但这两个问题其实是两条完全不同的事。如果目的只是把开源模型比如Qwen、Llama跑成一个可调用API的服务这叫部署如果是要让模型更懂你的业务比如让它按你的格式输出、学会你的领域术语这叫微调。两者有交集但目标、资源消耗、数据要求都不一样。1.1 部署为什么难难点在哪先说部署。大模型部署的本质是把一个几十GB甚至上百GB的模型文件加载到GPU显存里然后启动一个推理服务对外提供HTTP接口。看起来简单实际难点集中在几个地方一是显存。一个7B模型BF16精度下光权重就要14GB左右如果是70B模型就要140GB以上单卡根本装不下得做模型并行。很多人第一次部署就是在这一步翻车的模型能下载但一加载就OOM。二是推理框架。同样的模型用不同的推理框架性能和并发能力差很多。比如HuggingFace原生的Transformers推理慢且吃显存换成vLLM用PagedAttention吞吐量能提升好几倍。ModelArts这类平台本身不会替你选框架这个决定得自己做。三是配置和联网。模型从哪来本地上传还是ModelArts内部镜像、推理服务怎么暴露端口、并发怎么控制、如何在API里接入你的现有系统这些都需要一点一点配。ModelArts的优势在于它把底层容器、GPU调度、弹性扩缩容、负载均衡这些脏活累活包掉了你聚焦在模型和框架上就行。1.2 ModelArts上大模型两条主路线华为云ModelArts实际用下来做部署和微调大致有两条路。第一条是ModelArts Lite。它本质上给你一个K8s集群支持GPU裸金属、Ascend NPU自由度最高。你可以自己在里面用vLLM、Ollama、TGI或者Llama-Factory折腾只要你有Docker和K8s基础基本跟在本地服务器上操作没有区别。第二条是ModelArts Studio和AI应用部署这类托管能力你只需要上传模型或者镜像平台来帮你托管推理服务带自动伸缩、监控告警适合不想管运维的团队。我的经验是如果你是想快速验证、或者团队没有专职运维直接用托管推理服务如果你要做微调、同时跑多个实验、要精细控制推理参数那就用Lite自己搞。这篇文章后面讲的部署和微调基本都能在这两条路线里跑通。个人的建议是不要一上来就追求“既要又要”。先把模型部署起来、把API调通再考虑微调。部署是微调的前提因为微调完之后你还是要部署一版两个流程串起来才完整。2. 环境与算力评估先把家底盘清楚不管是部署还是微调第一件事都是搞清楚我手头有多少GPU、什么型号、显存多大、能跑多大的模型。这一步如果算错了后面全是白干。ModelArts上有按需付费的GPU实例也有包周期的资源型号覆盖了常见的V100、T4、A100、Ascend 910等。2.1 GPU显存到底要多大给一个能直接套用的计算公式我在选显卡之前一定会先做一道显存估算题。这里分享一个简单粗暴但实用的估算方式。对于推理场景显存需求约等于模型权重大小 KV Cache 激活值。模型权重大小的算法是参数量Billion× 2字节BF16/FP16或 × 4字节FP32。比如7B模型BF16精度7 × 2 14GB权重加上KV Cache和激活值单卡24GB能跑但有点紧40GB就非常从容。如果显存不够可以量化到INT8或INT4权重分别约7GB和3.5GB但精度会略有损失。对于微调场景显存需求比推理大得多。微调时除了权重还要存梯度、优化器状态。比如Adam优化器对每个参数要额外存两份状态。如果是全参微调7B模型显存轻松超过50GB单卡基本没戏所以大家才偏爱LoRA这类参数高效微调。LoRA只把很小一部分参数变成可训练的显存需求主要在“加载一份完整的基座模型权重”上。算下来7B模型做LoRA微调全精度下需要30~50GB用QLoRA把基座模型4bit量化再LoRA可以压到16~24GB这就是为什么QLoRA格外受欢迎。我自己的选型经验任务类型推荐GPU适合模型规模7B模型推理单张24GB如A10/40907B/8B可配合量化7B模型LoRA微调单张40GB如A100-40GB7B/8B全精度7B模型QLoRA微调单张24GB7B/8B70B模型推理多张40GB/80GB70B需张量并行70B模型LoRA微调8×80GB70B在ModelArts上选实例时重点看显存型号和个数。如果你是用Ascend NPU则要注意模型的算子兼容性多数用MindSpore或MindIE框架后面微调也会更依赖ModelArts上昇腾生态的适配。2.2 ModelArts准备事项镜像、OBS、开发环境ModelArts上做部署和微调前置准备基本是三件事镜像、存储、代码。镜像大模型推理和训练都建议用自定义镜像因为官方镜像未必带最新版本的vLLM、Transformers、FlashAttention。你可以在本地或用ModelArts的开发环境拉一个基础镜像比如pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime然后装依赖再推到ModelArts的容器镜像服务SWR里。这个过程其实和平时做Docker镜像一样区别只是最后推到了华为云的仓库。存储大模型的文件动辄十几个GB肯定不能塞进镜像里。常见做法是传到OBS对象存储然后在推理或训练时ModelArts会自动把OBS里的模型文件下载到本地磁盘。如果你用的是Lite集群可以挂载SFS或OBS并行文件系统避免每次启动都下载一遍模型能省不少时间。代码微调代码建议放在ModelArts的Notebook开发环境里调试调试通了再提交训练任务。Notebook可以直接使用GPU实例也能直接访问OBS非常方便。2.3 容器化与Notebook怎么选现在的ModelArts有ModelArts Studio这种图形界面很多操作可以点选完成也有开发环境Notebook、训练任务、推理服务这些经典模块。我个人的经验是如果目标是快速部署一个开源模型可以从ModelArts的AI应用或者ModelArts Studio直接选预置模型省事如果要微调建议一定用开发环境Notebook 训练任务代码灵活方便调试如果对框架熟悉且要极致性能就用Lite建集群完全自定义。不要一上来就全用图形界面。图形界面适合一锤子买卖但大模型开发和迭代通常都是反复调参数、改数据代码化的流程要好维护得多。这也是为什么后面我给的实操示范大多以命令行和脚本为主。3. 大模型部署从模型文件到可用API的全过程部署这件事目标很明确把一个模型变成可以被外部系统调用的服务。在ModelArts上我推荐的做法是“自定义镜像 推理框架 端口配置”这套组合既能复用到不同项目也方便迁移。3.1 两种部署姿势托管推理服务与Lite自由部署先讲托管推理服务。路径大致是在ModelArts的“AI应用”里创建应用指定镜像地址和模型路径然后部署为在线服务。平台会自动拉镜像、启动容器、配好负载均衡和健康检查。启动后你会拿到一个API地址然后就能访问了。这个方式的好处是平台管运维缺点是黑盒程度高想调底层参数比如vLLM的调度参数不太方便。另一种是Lite自由部署。你在ModelArts Lite里创建一个K8s集群然后把推理框架以Deployment方式部署进去自己写Service、Ingress。自由度最高但需要K8s基础。如果团队里没人懂K8s托管服务更稳妥。我自己倾向于“托管为主、Lite为辅”常规项目全部托管遇到需要自定义调度、多模型切换、streaming这类特殊需求再上Lite。3.2 自定义镜像实战用vLLM起一个Qwen推理服务下面给一个具体例子用vLLM部署Qwen2.5-7B-Instruct。整个过程分三步写Dockerfile、构建镜像推到SWR、在ModelArts上创建推理服务。Dockerfile可以这样写FROM pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime RUN pip install vllm transformers accelerate WORKDIR /app COPY serve.py /app/serve.py EXPOSE 8000 CMD [python, /app/serve.py]serve.py里用vLLM的OpenAI兼容服务核心代码大概是这样from vllm import LLM, SamplingParams from fastapi import FastAPI, Request import uvicorn app FastAPI() llm LLM(model/models/qwen2.5-7b-instruct, tensor_parallel_size1) app.post(/v1/chat/completions) async def chat(request: Request): payload await request.json() messages payload.get(messages, []) prompt tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) outputs llm.generate([prompt], SamplingParams(max_tokens512, temperature0.7)) return {choices: [{message: {role: assistant, content: outputs[0].outputs[0].text}}]} uvicorn.run(app, host0.0.0.0, port8000)这里模型文件放在容器内的/models/qwen2.5-7b-instruct实际使用中这个目录往往是ModelArts从OBS自动下载的。推理服务创建时关键配置有几项模型来源可以选OBS路径平台启动时会拉取模型文件到容器端口设置为8000对应镜像里暴露的端口资源根据模型规模选GPU规格健康检查可以配置成/health路径vLLM默认有让平台知道服务是否就绪。构建镜像推到SWR的命令和平常一样docker build -t swr.cn-north-4.myhuaweicloud.com/your-namespace/qwen-vllm:latest . docker push swr.cn-north-4.myhuaweicloud.com/your-namespace/qwen-vllm:latest推完之后在ModelArts创建推理服务时选择这个镜像即可。3.3 部署参数与并发控制要点部署不只是“把模型跑起来”生产环境尤其要关注并发和性能。这里说几个我实测下来很关键的参数。第一个是max_num_seqsvLLM的并发序列数。这个参数控制了同时有多少个请求被处理。开大了提升吞吐但显存占用会上升开小了并发低很多请求排队。一般7B模型可以设32或64大模型建议从32起步调。第二个是max_model_len。这个决定了模型最大的输入输出长度。很多人默认值会用模型的原始上限比如32768但实际场景未必需要那么长调小这个值可以节省大量KV Cache显存换来更高的并发。第三个是gpu_memory_utilization。vLLM默认会占满GPU显存如果你希望留一些显存给同一块卡上的其他任务可以设成0.85或0.9。推理任务一般建议直接给满省心。我自己常用的一组7B模型生产参数是max_model_len8192max_num_seqs64gpu_memory_utilization0.9tensor_parallel_size1。在这个配置下24GB显存跑Qwen2.5-7B-Instruct比较稳定单卡QPS大约在20~40视具体prompt长度和max_tokens而定。3.4 轻量部署与端侧场景有些人问“能不能把大模型部署到嵌入式板子上”这个问题在大模型领域很常见。答案是看模型规模和硬件。如果你要跑的是7B模型那不算嵌入式至少需要一个像样的游戏显卡或推理卡但如果你愿意用4bit量化模型可以压到4~6GB一部分边缘设备比如带16GB内存的Jetson Orin也能跑起来。ModelArts本身面向云端但云端训练/量化好的模型可以导出成ONNX、MIndIR或者GGUF格式再拿去边缘设备跑推理。比如想把Qwen小模型端侧化可以在云端用vLLM把推理流程验证好再在本地用Ollama或llama.cpp跑量化版本。这和ModelArts的配合方式是云端做开发和评估端侧做部署。4. 大模型微调跑通LoRA这条性价比最高的路部署解决了“能用”的问题微调解决的是“好用”的问题。基础模型虽然知识量大但不会天然理解你的业务格式、术语和风格。微调的本质就是用你自己的数据把模型往你的方向掰一掰。微调有很多路线全参微调、LoRA、QLoRA、 prefix tuning等。我最推荐新手上手的是LoRA成本低、速度快、效果也可控。4.1 数据微调真正花钱花时间的地方微调的数据质量直接决定效果。很多人拿着几百条数据就开始微调结果模型反而变笨了这不是LoRA的问题是数据的问题。指令微调的数据格式最常用的是这样的JSON结构[ { instruction: 请判断以下评价是正面还是负面, input: 这个产品太差了用了三天就坏了, output: 负面 }, { instruction: 请写一份请假申请, input: 我要请三天假原因是我感冒了, output: 尊敬的领导由于感冒严重需请假三天望批准。 } ]有些框架也支持ShareGPT格式messages数组里面是role和content。无论哪个格式关键是“指令-输入-输出”的对应关系要明确。数据量方面我的经验是100~500条可以让模型学会一种输出格式但泛化能力弱1000~3000条效果稳定适合垂直场景指令遵循5000条以上已经接近一次“像样”的领域适配但要注意数据去重和清洗。如果数据量少可以先用大模型生成一批合成数据再人工筛选。合成数据质量参差但作为冷启动已经够用。数据清洗时一定要去掉包含敏感身份信息、广告、脏话等脏数据这点我在项目里吃过亏。4.2 LoRA参数怎么配一组可直接上手的默认值LoRA的核心思路是冻结原来的模型参数额外训练两个低秩矩阵A和B用它们去近似参数的更新量。训练时只更新这两个小矩阵显存占用大幅降低。下面这组参数是我一般在7B模型上起步用的可以当模板直接抄model_name_or_path: /models/qwen2.5-7b-instruct dataset: custom_dataset template: qwen finetuning_type: lora lora_rank: 64 lora_alpha: 128 lora_dropout: 0.05 learning_rate: 1e-4 num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 4 save_strategy: steps save_steps: 100 logging_steps: 10 warmup_ratio: 0.03 lr_scheduler_type: cosine bf16: true参数怎么理解lora_rank是低秩矩阵的维度越大表示可学习的容量越大但不是越大越好rank过大容易过拟合rank过小欠拟合。我一般从16到128试7B模型常用64。lora_alpha是缩放系数和rank配合通常设成rank的1到2倍。learning_rate用1e-4左右太大容易训飞太小收敛慢。另外几个关键变量per_device_train_batch_size单卡batch size显存不够就调小gradient_accumulation_steps梯度累积步数等于把batch size变大但显存不加bf16: true混合精度训练20系及以上NVIDIA显卡都支持能省显存。4.3 在ModelArts上跑Llama-Factory微调微调框架我推荐Llama-Factory它对新手太友好了支持的模型多数据格式兼容性好。在ModelArts上跑有两种方式一是在Notebook里直接跑二是用训练任务提交脚本。Notebook方式适合调试。先创建一个GPU Notebook然后安装Llama-Factorygit clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .数据放到项目里的data目录然后在data/dataset_info.json里注册自己的数据集接着就可以启动了llamafactory-cli train config.yaml如果训练时间较长建议把脚本打包成训练任务在ModelArts的训练任务页面里指定镜像、数据集和输出路径跑完会自动把模型保存到OBS。训练过程中注意看日志里的loss变化我见到的正常情况是loss稳步下降最终在0.3~1.0之间波动具体取决于任务难度和数据量。训练完之后LoRA权重可以单独保存也可以merged到原模型里导出。部署时如果只要LoRA权重需要在推理脚本里先加载base model再加载lora adapter这个环节容易出错我后面会单说。4.4 微调效果怎么评估微调完之后不能直接上线一定要做效果评估。我自己一般做三件事第一跑一遍训练集里的典型样本看是否学会了格式和内容。第二跑一批训练集之外的测试样本看泛化能力防止过拟合。第三和微调前的基座模型做A/B对比。如果发现微调后模型只会机械复述训练集而普通问题反而回答变差那就是过拟合了可以降低epoch数或增加数据多样性。也可以把loss曲线拉出来看一眼。如果训练loss降得很低但评测集效果不好基本就是过拟合或者数据分布单一。另外模板也很重要微调时用的对话模板要和推理时保持一致否则模型输出的格式会莫名其妙变乱。5. 实战问题与排查技巧这一段写我在ModelArts上做部署和微调时实际遇到的坑。基本都是正规文档里不太会写、但很容易卡住你的问题。5.1 OOM显存不足最典型的表现是容器一启动就退出或者训练跑到一半报OOM。先说推理侧。如果用的是vLLM注意看gpu_memory_utilization不要追求100%尤其在部署多实例时。另外max_model_len设得太长也会吃大量显存我之前把7B模型的max_len从32768调到8192并发能力直接提高了一倍。微调侧OOM优先做三件事调小per_device_train_batch_size开启gradient_accumulation_steps开启gradient_checkpointing。如果还不行就把基座模型量化到4bitQLoRA或者把LoRA rank调小。5.2 dtype不一致报错这个报错很经典expected m1 and m2 to have the same dtype, but got: c10: Half and c10: Float。一句话解释就是模型某个模块是半精度另一个模块是单精度矩阵乘法时对不上。出现这个问题的根本原因通常是模型在加载时精度不一致。比如有的模块被显式转成了float16有的保持float32推理时前向传播就炸了。解决办法在加载模型后统一精度或者在推理前加一行model model.half().to(device)。如果是在LoRA推理时报的检查一下基座模型和LoRA的dtype是否一致。# 以transformers为例统一dtype from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypetorch.float16)5.3 vLLM相关问题vLLM更新很快有些老版本和transformers的新版本会不兼容启动时报算子无法解析。我的应对策略是把vLLM和transformers版本锁在镜像里不要每次都用latest。比如vLLM 0.6.x配transformers 4.44.x是一套比较稳的组合。另一个常见问题是流式输出。vLLM本身支持streaming但如果你在ModelArts中转服务里自己包了一层FastAPI记得设置streamTrue并处理SSE格式否则前端会一直等不到结束。5.4 排查速查表现象常见原因处理建议容器启动后立即退出OOM / 启动命令错误看日志先调小显存占用参数确认启动命令正确推理结果乱码或空白模板不一致 / tokenizer加载错误确认推理使用了和微调一致的template和tokenizer训练loss不降学习率过大或过小 / 数据太杂调学习率到1e-5~2e-4区间检查数据标注质量LoRA加载后无效果adapter未生效检查推理脚本里是否调用了load_adapter显存占用长期过高并发参数过大 / 未释放调max_num_seqs必要时重启服务还有一些小技巧ModelArts的日志页面是排查问题的第一现场容器启动、推理调用、模型加载的日志都在那里。不要只看是否有报错还要看是否卡在某个环节比如等待模型下载。如果模型每次启动都重新下载建议把模型放到SFS或OBS并行文件系统里挂载启动速度能快好几倍。写在最后的一点经验最后再分享一个我沉淀下来的实操习惯不管部署还是微调从一开始就把模型路径、数据路径、输出路径全部统一到OBS这类对象存储上不要临时在容器里手动拷贝文件。这样每次任务启动都是可复现的出了问题也容易排查。ModelArts本身对OBS的集成度很高训练和推理都能自动对接这个习惯能帮你省掉大量“脏手”操作。希望这篇指南能帮你在华为云ModelArts上少走点弯路早点把自己那个大模型真正跑起来。