尧图网站建设 
范式智能拟出资超10亿元采购华为昇腾950芯片用于大模型落地的消息给许多正在做大模型工程化的团队提了一个非常具体的问题真的要把大模型放进生产环境时算力投入和部署框架应该怎么选、怎么验证。这类“拟采购”往往还处于商务和规划阶段报价、型号参数、最终能否成单都有可能变化。对研发团队来说更值得关注的不是新闻里的金额而是新闻背后被压缩掉的工程链路从模型选型、显存估算、推理部署、微调数据准备到服务压测、问题排查和采购验收这条链路如果没有跑通“只要买够算力就能落地大模型”是一个很容易被证伪的假设。接下来会从需求拆解开始逐步走到一台或者一组服务器上真正把模型跑起来的最小闭环再讨论评估、压测、排错和采购前验收。读完后你可以拿同一套思路去评估自家的场景而不是在“买多少卡”和“跑什么模型”之间来回摇摆。1. 大模型落地先拆需求别让算力预算替业务决策1.1 “拟采购”消息背后研发应该先响应什么公开信息里的“拟出资超10亿元采购AI芯片”只是一个资金计划。站在工程侧这个计划落地前必须回答一系列问题大模型要支撑的业务是内部知识问答、客服、内容生成还是代码辅助每次请求允许几秒钟返回还是必须在几百毫秒内给出首个 token高峰期并发是多少平均并发和峰值并发差多少这些问题是否真的需要从头训练大模型还是通过本地部署开源模型 检索增强就能满足回答正确率如何定义谁来标注评测集这些问题的结果会直接影响硬件规模。一个只服务内部 50 人的文档问答场景与一个对外提供每天百万次推理接口的场景算力需求可能差一到两个数量级。如果业务还没有定义清楚先拍一个硬件采购金额很容易出现两类错误模型买大了导致推理成本过高或者模型规模不够导致业务质量无法验收。1.2 算力预算拆成四个用途不要混在一个池子里实际项目中至少应该把算力预算拆成四部分实验探索算力做 prompt 调试、RAG 效果验证、量化评估、小样本 LoRA 实验。这部分负载波动大不需要 7x24 小时稳定运行。在线推理算力承载真实业务请求需要关注可用性、延迟、吞吐和持续压测。训练或微调算力用于全量微调、LoRA 微调或继续预训练。训练任务结束后这批卡可以转做推理也可以在硬件形态上与推理设备不同。容量预留和灰度算力用于新模型版本上线前的灰度验证避免新模型直接打爆生产环境。不同用途对硬件的要求不同。推理服务通常需要低延迟、高并发对内存带宽和模型并行能力敏感训练任务则更依赖高带宽互联和大批量矩阵运算。把预算全部混在一个“AI 芯片”类别里后续扩缩容和调优会很难做。1.3 用一张业务需求清单把选型指标固定下来在还没有选定任何硬件之前研发团队可以先输出下面这张表。它能避免各角色在评审会上各说各话。决策问题技术含义判断方式研发应该给到的结论业务是离线还是在线决定容错要求和并发模型看用户等待时长和服务 SLA设定 P95 响应时间目标是否需要最新领域知识决定 RAG 优先级统计知识更新频率明确是否需要知识库检索是否需要固定输出格式决定是否要微调收集真实调用样本给出格式遵循率指标高峰期并发多少决定推理实例数量看业务预估或接口日志给出每卡并发容量估计是否允许低精度推理决定量化和显存占用做量化前后评测对比给出精度损失报表是否需要本地私有部署决定数据外发约束对照数据合规要求明确外呼与本地边界这份表最好由业务产品、算法工程师、运维工程师一起填。千万不能只在售前交流会上由硬件厂商代为填写因为厂商默认假设通常是“算力越多越好”。1.4 先出候选模型表再谈采购金额大模型落地不是“买芯片”的下一跳而是“选模型”的下一跳。一个更可执行的顺序是把业务场景拆成可评测的任务例如“从企业制度中抽取答案并给出出处”。选择 2 到 3 个候选开源模型放在同一批评测集上做效果对比。在同一块硬件或同一个云环境上记录每个模型的显存占用、生成速度、首 token 延迟。把结论填进候选模型表再估算需要几台设备。候选模型表可以包含这些列模型名称、参数量、精度、权重显存、最大上下文、部署框架、单卡能否推理、P95 延迟、评测集得分。填完这张表后采购预算已经不是一个拍脑袋的金额而是一个由业务指标推导出来的工程产物。2. 显存账算不明白再贵的算力也会被低效占住2.1 模型权重只是显存的第一项很多人评估模型能不能跑习惯于看“参数量多大显卡显存多大”。这是一个起点但不是全部。模型推理时的显存占用可以粗略表示为权重显存约等于参数量 × 每个参数占用的字节数以常见的 7B 模型为例FP32 下权重约 7B × 4 字节 28GB。FP16/BF16 下权重约 7B × 2 字节 14GB。INT8 下权重约 7B × 1 字节 7GB。INT4 下权重约 7B × 0.5 字节 3.5GB。这些只是权重部分实际加载过程中还会有框架内部的临时 buffer、激活值、KV Cache、请求队列等额外开销。也就是说一张 24GB 显存的卡并不是“能放下 14GB 权重就能稳定推理”还需要为请求上下文和并发预留空间。2.2 KV Cache 和并发请求才是隐藏的显存黑洞LLM 推理是逐 token 生成的。为了不重复计算 Transformer 每一层的历史 Key 和 Value推理框架会把已经生成过的 KV 值缓存在显存里。这个缓存被称为 KV Cache。KV Cache 有几个直接影响采购决策的特点随上下文长度增长上下文越长缓存越大。随并发请求数量增长每个请求都有自己的 KV Cache。随模型层数和隐藏层维度增长层数越多缓存越大。开启权重量化后KV Cache 不一定按同样比例缩小。因此在采购评估中不能只算“模型权重能不能塞进去”还要确认“在目标并发和目标上下文下KV Cache 是否还能放得下”。一个常见现象是本地单用户跑一个 7B 模型很流畅一旦压测到 20 个并发显存被 KV Cache 占满服务开始排队甚至 OOM。2.3 训练、微调和推理的显存构成完全不同训练比推理更消耗显存原因是训练需要保存反向传播所需的梯度、优化器状态和激活值。以全参数微调为例一块卡不仅要放下模型权重还要放下梯度、Adam 优化器的动量状态、前向计算产生的激活值。这也是为什么同样一个模型训练时的单卡最小显存往往数倍于推理。LoRA 微调专门解决了优化器状态过大带来的问题。它冻结原模型权重只训练注入的小规模低秩矩阵。这样优化器状态和梯度都只针对 LoRA 参数计算显存需求大幅下降。阶段主要显存压力硬件建议适用场景在线推理权重、KV Cache、并发缓存关注显存容量和内存带宽生产 API、对话、批量生成LoRA 微调原模型权重 LoRA 参数梯度中等显存多卡可扩展领域格式微调、风格微调全参微调权重、梯度、优化器、激活需要大显存和高带宽互联领域变化较大、数据量大从零预训练权重、梯度、优化器、海量数据大型训练集群极少有企业需要自主从头训练理解了这些差异再看“超 10 亿元采购 AI 芯片”时就应该进一步问这批算力是为训练准备还是为推理服务准备两者的峰值利用方式不同后续部署框架和运维体系也不同。3. 从模型文件到在线服务部署链路要分层验证3.1 大模型部署不是“执行一个二进制文件”一个可用的大模型服务至少包含三层模型权重与 tokenizer从模型仓库下载或者通过微调导出。推理引擎负责加载权重、调度请求、管理 KV Cache、完成采样和生成。对外 API 层把引擎能力包装成标准 HTTP 或 gRPC 接口包含鉴权、限流、日志和监控。很多团队把模型文件一放一个curl能返回结果就认为部署完成。实际上生产级部署还需要考虑并发排队、显存碎片、超时重试、模型版本回滚和日志链路。下面以常见开源部署工具为主线说明通用路径。需要强调在昇腾硬件上能否使用这些工具、镜像 tag 和 API 是否一致必须对照硬件厂商和框架官方支持矩阵去核对。3.2 工具选型先按使用场景选而不是按流行度选工具/框架常见用途适合阶段说明Ollama本地快速跑通模型学习和原型验证命令简单适合先确认模型效果llama.cpp本地或边缘设备推理CPU / 小卡环境常用 GGUF 量化格式vLLM在线推理服务生产级高并发有 PagedAttention显存利用率高OpenAI 兼容服务快速接入已有应用原型与生产切换将模型封装成标准 APIXinference 等平台私有化多模型管理企业内部平台提供 UI 和接口适合小团队如果公司刚开始验证业务不建议直接上几十台机器的编排系统。先把一个小模型跑通用真实请求验证 API再逐渐增加并发和规模。3.3 环境检查驱动、加速库和 Python 版本必须一致进入部署前先做一遍环境检查。这里以两层环境示例说明# CUDA 类环境的常规检查 python --version nvidia-smi # 昇腾环境示例具体命令以实际厂商软件栈文档为准 npu-smi info python -c import torch, torch_npu; print(torch.__version__, torch_npu.__version__)这段命令的意义不在于背诵而在于建立“先确认基础层版本”的检查习惯。大模型推理不只是安装一个 pip 包它依赖操作系统、Python 版本、深度学习框架和硬件加速库之间的版本匹配。很多启动报错都来自驱动版本与框架版本不对齐而不是模型代码错误。生产环境里建议把基础镜像版本写死在发布脚本中避免latest依赖。3.4 用 vLLM 启动一个最小在线服务以下命令是 CUDA 环境下 vLLM 启动模型的通用思路。昇腾环境下需要替换成厂商适配过的镜像和底层算子库这里先说明参数含义。docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:版本号 \ vllm serve /models/qwen2-7b-instruct \ --served-model-name local-llm \ --max-model-len 8192 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --dtype bfloat16代码中的尖括号版本号需要替换成你核对过的真实镜像 tag。生产环境不要使用latest否则镜像更新可能导致重启后行为不一致。启动后可以用下面的请求验证接口是否可用curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer EMPTY \ -d { model: local-llm, messages: [{role: user, content: 用一句话解释 RAG}], max_tokens: 128, temperature: 0.3 }如果返回内容包含choices字段说明最基础的服务链路已经打通。接下来要做的是用真实业务问题替换这段简单请求并开始记录延迟与返回质量。3.5 关键参数速查表参数含义配置过大的影响配置过小的影响--max-model-len最大上下文长度预留 KV Cache 过多长输入被截断--gpu-memory-utilization推理框架可用显存比例上限可能没有足够系统缓冲模型加载失败--tensor-parallel-size张量并行使用的显卡数量显存分摊但通信开销增加单卡放不下模型--dtype权重和激活的精度类型数值更稳定但显存占用更高可能引入精度损失--served-model-name对外暴露的模型名下游调用与模型仓库名不匹配客户端找不到模型这些参数在不同推理框架中的叫法可能不同但核心思想一致不要用默认值蒙头跑尤其是max-model-len和显存利用率几乎每个生产项目都要按实际请求长度和并发量重新调整。4. 模型效果提升不等于“再买几块卡”RAG、微调和评估4.1 先做 RAG还是先做微调大模型落地时经常被问到为什么效果不好是不是需要更多算力做微调这个问题的答案不一定是算力。RAG 通过检索外部知识库把相关文档拼进提示词让模型在生成时引用新的上下文。它适合知识频繁更新、答案需要给出处、或领域数据量较大的场景。微调和继续训练则更适合改变模型输出格式、稳定语风、或把少量垂直数据内化到参数中。方案知识更新成本答案可溯源性数据需求量对算力的压力RAG低替换知识库即可强可返回引用需要建索引门槛较低主要是检索和推理LoRA 微调中重新训练并发布弱输出没有引用需要数百到数千条高质量样本训练会占用一定算力全参微调高需要完整训练流程弱需要更大规模数据算力消耗最高从零预训练极高基本不推荐弱需要海量语料只有极少数团队具备条件实际项目中最常见的组合是 RAG 为主LoRA 微调为辅。先把真实业务问题变成评测集测出效果短板再决定是否需要微调。避免还没有评测集就先发起一轮大规模微调训练否则很难判断效果提升来自数据还是来自算力。4.2 LoRA 微调的最小实现骨架下面是一段 LoRA 微调的骨架代码用来说明数据预处理和训练启动的主流程。不同框架版本对 API 的影响很大落地前要锁定 transformers、peft、trl 版本。from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model from datasets import load_dataset from trl import SFTTrainer from transformers import TrainingArguments model_path your-model-path model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypeauto) tokenizer AutoTokenizer.from_pretrained(model_path) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filestrain.jsonl) def preprocess(example): text f用户{example[instruction]}\n模型{example[output]} return {text: text} train_dataset dataset[train].map(preprocess, remove_columnsdataset[train].column_names) trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasettrain_dataset, dataset_text_fieldtext, max_seq_length2048, argsTrainingArguments( output_dir./lora-out, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs1, logging_steps10, save_steps100, report_to[], ), ) trainer.train() trainer.save_model(./lora-final)这段脚本演示的是主流程不是一次复制就能跑通的全量工程生产代码。实际生产中必须检查 chat template。模型在训练阶段通常需要按模型的模板拼接系统提示词、多轮对话历史和 assistant 回复不能只是简单拼一个用户和模型前缀。更稳妥的做法是调用 tokenizer 提供的apply_chat_template并在训练数据中保留原始 prompt、response 和来源。4.3 微调和上线前都要做一轮安全与质量评测大模型在开放对话和知识问答中可能出现幻觉、格式错乱和越界输出。上线前建议至少执行一轮评测而不是只跑一两条测试用例。评测类别目的样例做法单轮指令遵循确认模型能按要求完成任务构造 50 到 100 条真实指令检索引用与幻觉确认回答是否基于知识库内容让回答携带来源编号人工核对多轮稳定性确认模型不会在上下文中丢失目标设计多轮对话任务长文本处理确认长输入下输出不漂移超过目标上下文一半的内容测试内容合规确认模型拒绝敏感违规输出依据内部合规制度设计边界用例这轮评测的数据量可以不大但必须来自真实业务。不要只拿 5 条精选问题做演示那样的通过率没有统计意义。5. 从“能返回结果”到“服务稳定”压测要看四个指标5.1 别只看整体响应时间大模型服务是流式生成一次请求可能包含多个 token。整体响应时间无法区分网络排队、首 token 计算和后续生成速度。判断推理框架优化效果时至少要看以下指标指标含义为什么重要TTFT首 Token 延迟从请求发出到第一个 token 返回的时间影响用户首屏等待体验TPOT每个 Token 生成间隔后续每生成一个 token 的耗时影响整体生成速度吞吐量单位时间生成的 token 数决定成本和服务容量请求成功率成功响应占总请求比例反映服务是否稳定如果 TTFT 很高通常和模型排队、预填充阶段过长有关如果 TPOT 很高可能是显存带宽不足、批大小不合理或模型并行方式有问题。5.2 一个最小快速压测脚本下面的 Python 脚本只用于基础连通性和延迟观察不算是专业压测。它用并发请求快速观察服务在 10 并发下的表现真实生产压测应使用 Locust、wrk 等工具。from openai import OpenAI import concurrent.futures import time client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, ) def call_once(_): start time.time() resp client.chat.completions.create( modellocal-llm, messages[{role: user, content: 用两句话解释大模型推理的 KV Cache。}], max_tokens128, temperature0.3, ) return time.time() - start, resp.choices[0].message.content with concurrent.futures.ThreadPoolExecutor(max_workers10) as pool: results list(pool.map(call_once, range(30))) latencies sorted(item[0] for item in results) p50 latencies[15] p90 latencies[27] print(request_count30 p50%.2fs p90%.2fs % (p50, p90)) print(sample_output:, results[0][1][:200])注意脚本中的 p90 索引是简化的正式压测需要用完整分位数计算函数。这个脚本的价值在于快速发现“模型可以启动但接口在并发下不可用”的问题。5.3 服务日志和资源监控要同时看推理服务的故障经常不是直接抛异常而是表现为越来越慢、时好时坏。因此除了业务日志还要持续采集这些指标GPU 或 NPU 利用率判断算力是否被真正使用。显存占用率判断是否接近容量上限。排队请求数判断负载是否超过实例能力。token 吞吐判断整体生成效率。错误率和超时率判断代码或配置是否在特定条件下失败。排查顺序一般遵循“从底层到上层”请求是否到达服务端有没有被网关或负载均衡丢弃。模型服务进程是否存在端口是否监听。显存是否充足有没有 OOM 记录。是否存在排队时间过长超时阈值是否合理。框架日志是否出现算子不支持或版本不匹配。若以上均正常再看模型本身是否进入重复生成或无意义输出。这个链路能覆盖大多数部署后问题。不要一看到接口延迟高就直接怀疑 大模型落地要过工程关：算力采购、显存估算与部署压测全解析
范式智能拟出资超10亿元采购华为昇腾950芯片用于大模型落地的消息给许多正在做大模型工程化的团队提了一个非常具体的问题真的要把大模型放进生产环境时算力投入和部署框架应该怎么选、怎么验证。这类“拟采购”往往还处于商务和规划阶段报价、型号参数、最终能否成单都有可能变化。对研发团队来说更值得关注的不是新闻里的金额而是新闻背后被压缩掉的工程链路从模型选型、显存估算、推理部署、微调数据准备到服务压测、问题排查和采购验收这条链路如果没有跑通“只要买够算力就能落地大模型”是一个很容易被证伪的假设。接下来会从需求拆解开始逐步走到一台或者一组服务器上真正把模型跑起来的最小闭环再讨论评估、压测、排错和采购前验收。读完后你可以拿同一套思路去评估自家的场景而不是在“买多少卡”和“跑什么模型”之间来回摇摆。1. 大模型落地先拆需求别让算力预算替业务决策1.1 “拟采购”消息背后研发应该先响应什么公开信息里的“拟出资超10亿元采购AI芯片”只是一个资金计划。站在工程侧这个计划落地前必须回答一系列问题大模型要支撑的业务是内部知识问答、客服、内容生成还是代码辅助每次请求允许几秒钟返回还是必须在几百毫秒内给出首个 token高峰期并发是多少平均并发和峰值并发差多少这些问题是否真的需要从头训练大模型还是通过本地部署开源模型 检索增强就能满足回答正确率如何定义谁来标注评测集这些问题的结果会直接影响硬件规模。一个只服务内部 50 人的文档问答场景与一个对外提供每天百万次推理接口的场景算力需求可能差一到两个数量级。如果业务还没有定义清楚先拍一个硬件采购金额很容易出现两类错误模型买大了导致推理成本过高或者模型规模不够导致业务质量无法验收。1.2 算力预算拆成四个用途不要混在一个池子里实际项目中至少应该把算力预算拆成四部分实验探索算力做 prompt 调试、RAG 效果验证、量化评估、小样本 LoRA 实验。这部分负载波动大不需要 7x24 小时稳定运行。在线推理算力承载真实业务请求需要关注可用性、延迟、吞吐和持续压测。训练或微调算力用于全量微调、LoRA 微调或继续预训练。训练任务结束后这批卡可以转做推理也可以在硬件形态上与推理设备不同。容量预留和灰度算力用于新模型版本上线前的灰度验证避免新模型直接打爆生产环境。不同用途对硬件的要求不同。推理服务通常需要低延迟、高并发对内存带宽和模型并行能力敏感训练任务则更依赖高带宽互联和大批量矩阵运算。把预算全部混在一个“AI 芯片”类别里后续扩缩容和调优会很难做。1.3 用一张业务需求清单把选型指标固定下来在还没有选定任何硬件之前研发团队可以先输出下面这张表。它能避免各角色在评审会上各说各话。决策问题技术含义判断方式研发应该给到的结论业务是离线还是在线决定容错要求和并发模型看用户等待时长和服务 SLA设定 P95 响应时间目标是否需要最新领域知识决定 RAG 优先级统计知识更新频率明确是否需要知识库检索是否需要固定输出格式决定是否要微调收集真实调用样本给出格式遵循率指标高峰期并发多少决定推理实例数量看业务预估或接口日志给出每卡并发容量估计是否允许低精度推理决定量化和显存占用做量化前后评测对比给出精度损失报表是否需要本地私有部署决定数据外发约束对照数据合规要求明确外呼与本地边界这份表最好由业务产品、算法工程师、运维工程师一起填。千万不能只在售前交流会上由硬件厂商代为填写因为厂商默认假设通常是“算力越多越好”。1.4 先出候选模型表再谈采购金额大模型落地不是“买芯片”的下一跳而是“选模型”的下一跳。一个更可执行的顺序是把业务场景拆成可评测的任务例如“从企业制度中抽取答案并给出出处”。选择 2 到 3 个候选开源模型放在同一批评测集上做效果对比。在同一块硬件或同一个云环境上记录每个模型的显存占用、生成速度、首 token 延迟。把结论填进候选模型表再估算需要几台设备。候选模型表可以包含这些列模型名称、参数量、精度、权重显存、最大上下文、部署框架、单卡能否推理、P95 延迟、评测集得分。填完这张表后采购预算已经不是一个拍脑袋的金额而是一个由业务指标推导出来的工程产物。2. 显存账算不明白再贵的算力也会被低效占住2.1 模型权重只是显存的第一项很多人评估模型能不能跑习惯于看“参数量多大显卡显存多大”。这是一个起点但不是全部。模型推理时的显存占用可以粗略表示为权重显存约等于参数量 × 每个参数占用的字节数以常见的 7B 模型为例FP32 下权重约 7B × 4 字节 28GB。FP16/BF16 下权重约 7B × 2 字节 14GB。INT8 下权重约 7B × 1 字节 7GB。INT4 下权重约 7B × 0.5 字节 3.5GB。这些只是权重部分实际加载过程中还会有框架内部的临时 buffer、激活值、KV Cache、请求队列等额外开销。也就是说一张 24GB 显存的卡并不是“能放下 14GB 权重就能稳定推理”还需要为请求上下文和并发预留空间。2.2 KV Cache 和并发请求才是隐藏的显存黑洞LLM 推理是逐 token 生成的。为了不重复计算 Transformer 每一层的历史 Key 和 Value推理框架会把已经生成过的 KV 值缓存在显存里。这个缓存被称为 KV Cache。KV Cache 有几个直接影响采购决策的特点随上下文长度增长上下文越长缓存越大。随并发请求数量增长每个请求都有自己的 KV Cache。随模型层数和隐藏层维度增长层数越多缓存越大。开启权重量化后KV Cache 不一定按同样比例缩小。因此在采购评估中不能只算“模型权重能不能塞进去”还要确认“在目标并发和目标上下文下KV Cache 是否还能放得下”。一个常见现象是本地单用户跑一个 7B 模型很流畅一旦压测到 20 个并发显存被 KV Cache 占满服务开始排队甚至 OOM。2.3 训练、微调和推理的显存构成完全不同训练比推理更消耗显存原因是训练需要保存反向传播所需的梯度、优化器状态和激活值。以全参数微调为例一块卡不仅要放下模型权重还要放下梯度、Adam 优化器的动量状态、前向计算产生的激活值。这也是为什么同样一个模型训练时的单卡最小显存往往数倍于推理。LoRA 微调专门解决了优化器状态过大带来的问题。它冻结原模型权重只训练注入的小规模低秩矩阵。这样优化器状态和梯度都只针对 LoRA 参数计算显存需求大幅下降。阶段主要显存压力硬件建议适用场景在线推理权重、KV Cache、并发缓存关注显存容量和内存带宽生产 API、对话、批量生成LoRA 微调原模型权重 LoRA 参数梯度中等显存多卡可扩展领域格式微调、风格微调全参微调权重、梯度、优化器、激活需要大显存和高带宽互联领域变化较大、数据量大从零预训练权重、梯度、优化器、海量数据大型训练集群极少有企业需要自主从头训练理解了这些差异再看“超 10 亿元采购 AI 芯片”时就应该进一步问这批算力是为训练准备还是为推理服务准备两者的峰值利用方式不同后续部署框架和运维体系也不同。3. 从模型文件到在线服务部署链路要分层验证3.1 大模型部署不是“执行一个二进制文件”一个可用的大模型服务至少包含三层模型权重与 tokenizer从模型仓库下载或者通过微调导出。推理引擎负责加载权重、调度请求、管理 KV Cache、完成采样和生成。对外 API 层把引擎能力包装成标准 HTTP 或 gRPC 接口包含鉴权、限流、日志和监控。很多团队把模型文件一放一个curl能返回结果就认为部署完成。实际上生产级部署还需要考虑并发排队、显存碎片、超时重试、模型版本回滚和日志链路。下面以常见开源部署工具为主线说明通用路径。需要强调在昇腾硬件上能否使用这些工具、镜像 tag 和 API 是否一致必须对照硬件厂商和框架官方支持矩阵去核对。3.2 工具选型先按使用场景选而不是按流行度选工具/框架常见用途适合阶段说明Ollama本地快速跑通模型学习和原型验证命令简单适合先确认模型效果llama.cpp本地或边缘设备推理CPU / 小卡环境常用 GGUF 量化格式vLLM在线推理服务生产级高并发有 PagedAttention显存利用率高OpenAI 兼容服务快速接入已有应用原型与生产切换将模型封装成标准 APIXinference 等平台私有化多模型管理企业内部平台提供 UI 和接口适合小团队如果公司刚开始验证业务不建议直接上几十台机器的编排系统。先把一个小模型跑通用真实请求验证 API再逐渐增加并发和规模。3.3 环境检查驱动、加速库和 Python 版本必须一致进入部署前先做一遍环境检查。这里以两层环境示例说明# CUDA 类环境的常规检查 python --version nvidia-smi # 昇腾环境示例具体命令以实际厂商软件栈文档为准 npu-smi info python -c import torch, torch_npu; print(torch.__version__, torch_npu.__version__)这段命令的意义不在于背诵而在于建立“先确认基础层版本”的检查习惯。大模型推理不只是安装一个 pip 包它依赖操作系统、Python 版本、深度学习框架和硬件加速库之间的版本匹配。很多启动报错都来自驱动版本与框架版本不对齐而不是模型代码错误。生产环境里建议把基础镜像版本写死在发布脚本中避免latest依赖。3.4 用 vLLM 启动一个最小在线服务以下命令是 CUDA 环境下 vLLM 启动模型的通用思路。昇腾环境下需要替换成厂商适配过的镜像和底层算子库这里先说明参数含义。docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:版本号 \ vllm serve /models/qwen2-7b-instruct \ --served-model-name local-llm \ --max-model-len 8192 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --dtype bfloat16代码中的尖括号版本号需要替换成你核对过的真实镜像 tag。生产环境不要使用latest否则镜像更新可能导致重启后行为不一致。启动后可以用下面的请求验证接口是否可用curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer EMPTY \ -d { model: local-llm, messages: [{role: user, content: 用一句话解释 RAG}], max_tokens: 128, temperature: 0.3 }如果返回内容包含choices字段说明最基础的服务链路已经打通。接下来要做的是用真实业务问题替换这段简单请求并开始记录延迟与返回质量。3.5 关键参数速查表参数含义配置过大的影响配置过小的影响--max-model-len最大上下文长度预留 KV Cache 过多长输入被截断--gpu-memory-utilization推理框架可用显存比例上限可能没有足够系统缓冲模型加载失败--tensor-parallel-size张量并行使用的显卡数量显存分摊但通信开销增加单卡放不下模型--dtype权重和激活的精度类型数值更稳定但显存占用更高可能引入精度损失--served-model-name对外暴露的模型名下游调用与模型仓库名不匹配客户端找不到模型这些参数在不同推理框架中的叫法可能不同但核心思想一致不要用默认值蒙头跑尤其是max-model-len和显存利用率几乎每个生产项目都要按实际请求长度和并发量重新调整。4. 模型效果提升不等于“再买几块卡”RAG、微调和评估4.1 先做 RAG还是先做微调大模型落地时经常被问到为什么效果不好是不是需要更多算力做微调这个问题的答案不一定是算力。RAG 通过检索外部知识库把相关文档拼进提示词让模型在生成时引用新的上下文。它适合知识频繁更新、答案需要给出处、或领域数据量较大的场景。微调和继续训练则更适合改变模型输出格式、稳定语风、或把少量垂直数据内化到参数中。方案知识更新成本答案可溯源性数据需求量对算力的压力RAG低替换知识库即可强可返回引用需要建索引门槛较低主要是检索和推理LoRA 微调中重新训练并发布弱输出没有引用需要数百到数千条高质量样本训练会占用一定算力全参微调高需要完整训练流程弱需要更大规模数据算力消耗最高从零预训练极高基本不推荐弱需要海量语料只有极少数团队具备条件实际项目中最常见的组合是 RAG 为主LoRA 微调为辅。先把真实业务问题变成评测集测出效果短板再决定是否需要微调。避免还没有评测集就先发起一轮大规模微调训练否则很难判断效果提升来自数据还是来自算力。4.2 LoRA 微调的最小实现骨架下面是一段 LoRA 微调的骨架代码用来说明数据预处理和训练启动的主流程。不同框架版本对 API 的影响很大落地前要锁定 transformers、peft、trl 版本。from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model from datasets import load_dataset from trl import SFTTrainer from transformers import TrainingArguments model_path your-model-path model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypeauto) tokenizer AutoTokenizer.from_pretrained(model_path) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filestrain.jsonl) def preprocess(example): text f用户{example[instruction]}\n模型{example[output]} return {text: text} train_dataset dataset[train].map(preprocess, remove_columnsdataset[train].column_names) trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasettrain_dataset, dataset_text_fieldtext, max_seq_length2048, argsTrainingArguments( output_dir./lora-out, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs1, logging_steps10, save_steps100, report_to[], ), ) trainer.train() trainer.save_model(./lora-final)这段脚本演示的是主流程不是一次复制就能跑通的全量工程生产代码。实际生产中必须检查 chat template。模型在训练阶段通常需要按模型的模板拼接系统提示词、多轮对话历史和 assistant 回复不能只是简单拼一个用户和模型前缀。更稳妥的做法是调用 tokenizer 提供的apply_chat_template并在训练数据中保留原始 prompt、response 和来源。4.3 微调和上线前都要做一轮安全与质量评测大模型在开放对话和知识问答中可能出现幻觉、格式错乱和越界输出。上线前建议至少执行一轮评测而不是只跑一两条测试用例。评测类别目的样例做法单轮指令遵循确认模型能按要求完成任务构造 50 到 100 条真实指令检索引用与幻觉确认回答是否基于知识库内容让回答携带来源编号人工核对多轮稳定性确认模型不会在上下文中丢失目标设计多轮对话任务长文本处理确认长输入下输出不漂移超过目标上下文一半的内容测试内容合规确认模型拒绝敏感违规输出依据内部合规制度设计边界用例这轮评测的数据量可以不大但必须来自真实业务。不要只拿 5 条精选问题做演示那样的通过率没有统计意义。5. 从“能返回结果”到“服务稳定”压测要看四个指标5.1 别只看整体响应时间大模型服务是流式生成一次请求可能包含多个 token。整体响应时间无法区分网络排队、首 token 计算和后续生成速度。判断推理框架优化效果时至少要看以下指标指标含义为什么重要TTFT首 Token 延迟从请求发出到第一个 token 返回的时间影响用户首屏等待体验TPOT每个 Token 生成间隔后续每生成一个 token 的耗时影响整体生成速度吞吐量单位时间生成的 token 数决定成本和服务容量请求成功率成功响应占总请求比例反映服务是否稳定如果 TTFT 很高通常和模型排队、预填充阶段过长有关如果 TPOT 很高可能是显存带宽不足、批大小不合理或模型并行方式有问题。5.2 一个最小快速压测脚本下面的 Python 脚本只用于基础连通性和延迟观察不算是专业压测。它用并发请求快速观察服务在 10 并发下的表现真实生产压测应使用 Locust、wrk 等工具。from openai import OpenAI import concurrent.futures import time client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, ) def call_once(_): start time.time() resp client.chat.completions.create( modellocal-llm, messages[{role: user, content: 用两句话解释大模型推理的 KV Cache。}], max_tokens128, temperature0.3, ) return time.time() - start, resp.choices[0].message.content with concurrent.futures.ThreadPoolExecutor(max_workers10) as pool: results list(pool.map(call_once, range(30))) latencies sorted(item[0] for item in results) p50 latencies[15] p90 latencies[27] print(request_count30 p50%.2fs p90%.2fs % (p50, p90)) print(sample_output:, results[0][1][:200])注意脚本中的 p90 索引是简化的正式压测需要用完整分位数计算函数。这个脚本的价值在于快速发现“模型可以启动但接口在并发下不可用”的问题。5.3 服务日志和资源监控要同时看推理服务的故障经常不是直接抛异常而是表现为越来越慢、时好时坏。因此除了业务日志还要持续采集这些指标GPU 或 NPU 利用率判断算力是否被真正使用。显存占用率判断是否接近容量上限。排队请求数判断负载是否超过实例能力。token 吞吐判断整体生成效率。错误率和超时率判断代码或配置是否在特定条件下失败。排查顺序一般遵循“从底层到上层”请求是否到达服务端有没有被网关或负载均衡丢弃。模型服务进程是否存在端口是否监听。显存是否充足有没有 OOM 记录。是否存在排队时间过长超时阈值是否合理。框架日志是否出现算子不支持或版本不匹配。若以上均正常再看模型本身是否进入重复生成或无意义输出。这个链路能覆盖大多数部署后问题。不要一看到接口延迟高就直接怀疑