简介：这份PDF系统分析了在华为云昇腾云服务上部署DeepSeek大模型的技术特点与应用场景，面向人工智能工程师、云计算架构师以及需要将大模型能力落地的企业技术团队。内容从昇腾处理器的并行计算能力与算力调度优势讲起，详细介绍了灵活的算力调配机制、昇思MindSpore深度学习框架的自动并行和混合精度训练特性，并覆盖了操作系统兼容性、云服务集成能力、多层次安全防护以及高可用容错机制等关键方面，帮助读者理解昇腾云原生AI平台与大模型融合的实际路径。文档进一步结合智能客服、金融风控、医疗辅助诊断、智能写作与智能教育等典型业务场景，说明部署后的实际应用方式与带来的效率提升，也补充了当前面临的数据隐私与安全挑战及未来展望。资源为单个PDF文件，大小约298KB，结构完整、论述清晰，可作为大模型选型评估、云环境中部署方案设计以及技术交流分享的实用参考，帮助降低技术选型与落地实施中的不确定性。目前已有712人学习下载，适合关注国产化AI算力平台与DeepSeek集成实践的开发者、架构师和技术管理者阅读。
1. 先搞清楚：华为云昇腾云服务部署 DeepSeek，和普通 GPU 云服务器差在哪
最近好几个人拿着“华为云昇腾云服务部署 DeepSeek 的特点与应用场景.pdf”这个标题来问我。大家的实际诉求不是读文档，而是想确认一个事：DeepSeek 这种开源模型放到昇腾的 NPU 上，能不能稳定跑、成本是否划算、手里的代码要不要改。结论是能跑，而且对多数对话和 RAG 场景来说，昇腾云服务配合 MindIE 推理引擎的体验比想象中顺。它与普通 GPU 云服务器的区别不在“部署”两个字，而在算子适配、图优化和工具链差异。这篇笔记会按从原理到上手的路径，把特点、场景、参数和典型坑讲清楚，适合正在做选型的架构师，也适合准备把 DeepSeek 拉进生产环境的工程师。
2. 昇腾云服务的底牌：Ascend 硬件与 DeepSeek 的匹配逻辑
2.1 昇腾算力在 DeepSeek 推理里扮演什么角色
很多第一次摸昇腾的人，会把它想象成“一块不太一样的显卡”。实际上昇腾云服务给你的是一个完整的计算单元：底层是 Ascend 910 系列 NPU，上面是 CANN 工具链，再往上还有推理引擎和容器镜像。DeepSeek 不是一个可执行文件，而是一组 PyTorch 权重；部署 DeepSeek 的真正工作，是让这些权重在一套陌生的算子体系里跑出接近理论峰值的吞吐。
DeepSeek 的主体结构是 MoE（Mixture of Experts），同时还用了 MLA（Multi-head Latent Attention）。这两个结构都给部署带来了明确挑战。MoE 意味着每个 token 只激活一小部分专家，但专家分布在多张 NPU 上时，token 要在卡之间来回路由，通信开销很大；MLA 把注意力计算拆成低秩压缩和解压，常规的 attention 算子处理不了，必须用融合算子。昇腾上负责这类工作的并不只是驱动，而是 CANN 算子库和 MindIE 推理引擎的配合。CANN 把模型里的 PyTorch 算子映射到 NPU 指令，MindIE 再把整张计算图做优化，决定哪些算子合并执行、KV cache 怎么分配、多卡并行怎么切分。
所以你登录服务器后的第一件事，不是急着拉镜像，而是先确认你手里的 NPU 环境到底是什么状态。用一条命令就能看到：
npu-smi info这条命令和 N 卡上的 nvidia-smi 作用类似，会列出每张 Ascend NPU 的索引、HBM 总量、当前占用、使用率和温度。我一般会看三列：Memory Usage、Memory Total、温度。如果 HBM 已经占掉大半，说明这台机器上有残留进程，需要先排查再继续。
从这张表还能确认实例规格。昇腾云服务有不同档位，有的单实例只有 2 卡，有的是 8 卡。选型时不光看“几卡”，还要看单卡 HBM。DeepSeek 完整版模型对显存容量很敏感，如果单卡 HBM 不够，即使卡数多也需要用张量并行把权重拆到多张卡上，而张量并行会放大通信瓶颈。看 npu-smi 输出，就能对“当前配置能不能装下这个模型”有一个第一手判断。这块信息也是后面调 max_seq_len 和并发的依据，不能跳过。
2.2 为什么说 DeepSeek 在昇腾上不是“硬塞”而是“适配”
直接拿 DeepSeek 的 safetensors 权重往昇腾上塞，不是不能跑，而是跑不快。PyTorch 默认走 CUDA 这条路径，昇腾上用 torch_npu 插件把算子转发到 CANN，但如果没有针对模型结构的融合算子，每一步都会产生大量图节点和内存拷贝。DeepSeek 这种大模型跑起来会非常慢，慢到让你以为机器出故障。
常见做法是使用 MindIE 做推理。MindIE 是昇腾上的高层推理引擎，类似 GPU 世界的 TensorRT-LLM，它会把输入的 PyTorch 模型脚本转换成静态计算图。静态图的好处是启动时做一次图编译，后续每个 token 都按固定调度走，省掉动态图重复解释的开销。对 MoE 的路由和 MLA 的低秩压缩，MindIE 有专门实现，能够把部分操作融合进一个算子。
但这里有一个关键点：MindIE 并不能“自动”适配任何一个 DeepSeek 分支。适配工作的重点在版本匹配。我拿到一份新权重后，第一件事是查镜像里 MindIE 版本，再对照模型对应的适配说明。这一步省不得。很多“部署失败”的案例，最后都归因于 MindIE 版本太老，不认识模型里的新算子。检查命令如下：
# 查看 MindIE 版本 python -c "import mindie; print(mindie.__version__)" # 查看 CANN 驱动版本 cat /usr/local/Ascend/driver/version.infoMindIE 版本决定算子映射和量化能力，CANN 驱动版本决定底层指令集。两者不是越新越好，而是要与模型权重、镜像标签匹配。云服务商给的公共镜像一般会固定一套组合，所以我的经验是：优先使用公共镜像，而不是自己从零搭建。公共镜像里的 DeepSeek 权重通常是已经转换过的布局，加载速度也快得多。如果你手里是原始 safetensors，就需要走权重转换脚本，把模型权重按张量并行的切分方式重排。转换过程会消耗不少时间，但能避免在线推理时反复做权重布局切换。
这里我把适配拆成三层理解，排查时会比较快。第一层是算子层，模型里每个 PyTorch 算子是否能找到 CANN 实现；第二层是图优化层，MindIE 能不能把多个算子融合成静态图；第三层是权重布局层，模型权重是否按张量并行切好。三层都通，性能才正常。很多人只盯着算子层，忘了权重布局，结果启动时一切正常，一上多卡就卡死。
2.3 特点拆解：性能、成本、生态与部署形态怎么选
昇腾云服务部署 DeepSeek 的特点，可以用一张表概括，后面无论做选型还是做架构，都绕不开这些维度。
部署形态的影响最直接。如果只做私有化对话和 RAG，用标准推理镜像就够了；如果要频繁更新模型或做 LoRA 微调，需要 ModelArts 或容器服务提供的工作台，而不是一台裸机。性能维度上，MindIE 静态图在稳定负载下表现很好，但首次请求要等图编译，冷启动比 GPU 慢一些；成本维度上，实例费用只是一部分，OBS 存储和公网带宽也要计入；生态维度上，昇腾对常见模型的支持已经比较全，但个别依赖 CUDA 的 Python 库没法直接用，需要换方案。
我给选型时通常走三步。第一步确认模型规模：DeepSeek 完整版还是一个蒸馏小模型，不同规模对应的卡数和并行策略完全不同。第二步确认业务容忍度：如果要求低延迟对话，要选静态图 MindIE 路径；如果只是离线批量生成，vLLM-Ascend 也可以。第三步确认网络和存储：模型权重从 OBS 拉取，推理请求走内网，公网只保留 API 入口，这样成本和安全都可控。
选型原则很简单：能跑通不是目标，在预算内跑得稳才是。昇腾上的“稳”取决于你有没有按它的图优化思路走，而不是把 GPU 上的玩法原样搬过来。
3. 把 DeepSeek 部署到昇腾云服务：从开通到跑通的最小流程
3.1 开通昇腾云服务与镜像选择：先确认 MindIE 版本再动手
在华为云上开通昇腾云服务的入口有两个：一个是昇腾云服务的算力实例，另一个是 ModelArts 的训练/推理资源池。你如果是第一次跑，我建议走 ModelArts 的推理服务，因为它会自动把镜像、存储、日志串起来，省去自己装环境的时间。如果是企业生产环境，再考虑基于容器服务的自建方案。
如果你熟悉 Ollama 那套本地部署大语言模型的方式，在昇腾上会不太一样。Ollama 官方并没有把昇腾 NPU 当作默认后端，强行套用本地部署思维，往往会在设备枚举阶段就中断。这也是为什么昇腾路径总是强调镜像和推理引擎，而不是像 PC 一样“下载一个工具就开跑”。
开通实例时最重要的选择是镜像。很多第一次上手的人会选一个“看起来干净”的通用 PyTorch 镜像，结果进去发现没有 MindIE，也没有 torch_npu，CANN 版本也旧。这等于还没开始就给自己埋坑。正确做法是先看昇腾云服务镜像市场里有没有带 MindIE 的推理镜像，镜像说明里会标注支持的模型列表。如果列表里有 DeepSeek，直接用。如果没有，就要准备权重转换和手动装 MindIE 的时间。
镜像选好后，模型权重不要临时下载。DeepSeek 权重文件动辄几十 GB，在云服务器上直接走公网下载，既慢又不稳定。常见做法是先上传到 OBS，再用 obsutil 同步到实例本地目录。obsutil 是华为云对象存储的命令行工具，速度和断点续传都比浏览器好：
# 示例：把 OBS 桶里的模型同步到本地数据盘 ./obsutil cp obs://my-bucket/deepseek-r1/ /data/models/DeepSeek-R1 -r -f-r表示递归目录，-f表示强制覆盖，避免可能残留的旧文件干扰权重完整性。同步完成后再检查环境，确认 torch、torch_npu 和 MindIE 都已经工作：
npu-smi info python -c "import torch_npu; print('torch_npu ok')"注意这里不是机械地运行命令。你要看 torch_npu 能否被顺利导入，因为你后续所有模型加载脚本都依赖它。如果导入失败，说明镜像里缺少 CANN 的运行时库，或者环境变量没配对。常见的修法是用镜像自带的source /usr/local/Ascend/ascend-toolkit/set_env.sh初始化环境，再重新打开终端。
3.2 用 MindIE 拉起 DeepSeek 推理服务（首选路径）
为什么把 MindIE 放在首选而不是 vLLM？因为对 DeepSeek 这种 MoE 结构，MindIE 的算子融合和显存管理做得更早，尤其是 MLA 的低秩注意力。你在 GPU 上用 vLLM 跑得好，到昇腾上不一定能复用同样性能。MindIE 的配置本质上是一个模型描述文件，告诉它模型路径、张量并行数、上下文长度和数据精度。
我通常会先写一份最小配置，把服务先拉起来，再做参数调整。配置文件风格大致如下，具体 key 以你拿到的镜像样例为准：
{ "model_name": "deepseek-r1", "model_path": "/data/models/DeepSeek-R1", "tokenizer_path": "/data/models/DeepSeek-R1", "tensor_parallel_size": 4, "max_seq_len": 32768, "dtype": "bf16" }tensor_parallel_size是你启用几卡并行推理，我一般设为本机 NPU 数量；设太小每卡要放太多权重，设太大通信成本抵消算力收益。max_seq_len决定 KV cache 预分配，这个值要按业务实际文本长度设定，不是越大越好。dtype用 bf16 通常是精度和性能的平衡点，如果追求吞吐再做量化。
启动命令因镜像而异，常见的是一个启动脚本加配置路径：
# 不同镜像启动入口不同，以镜像说明为准 bash start.sh config.json启动后建议等服务日志出现“listen”或“ready”字样再测试，否则会误判服务已可用。MindIE 启动时要做图编译，首次准备可能花几分钟，这段时间里端口未必开放，属于正常现象。
启动成功的标志只有一个：你能在一个 OpenAI 兼容的 HTTP 接口上拿到聊天补全结果。MindIE 默认会监听一个端口，之后可以接任何兼容 OpenAI 协议的客户端。这比直接跑 Python 脚本内部测试要实用，因为业务系统接入时就是这样调用的。
3.3 vLLM 部署 DeepSeek 的备选方案：vllm-ascend 的启动参数
如果你已经在 GPU 上写了大量 vLLM 代码，不想为昇腾单独维护一套推理栈，可以考虑 vllm-ascend 插件。它让 vLLM 在 CANN 上跑起来，而不是只能用 CUDA。安装方式：
pip install vllm-ascend之后启动服务的命令和 vLLM 原版几乎一致：
python -m vllm.entrypoints.openai.api_server \ --model /data/models/DeepSeek-R1 \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --served-model-name deepseek-r1--tensor-parallel-size指定张量并行的卡数，和 MindIE 配置里的tensor_parallel_size是一个意思。--max-model-len控制最大上下文长度。--served-model-name是暴露给客户端的 model 名称，后面调用时填什么，这个参数就要写什么，不要自作主张换个别名。
vLLM-Ascend 的好处是生态兼容。LangChain、Dify 这类框架用它时都不需要改接口。但要注意，备选路径不等于同等性能。如果你发现 vLLM-Ascend 吞吐明显低于 MindIE，不要急着怀疑机器，大概率是算子没有融合，说明当前这个模型版本在 vLLM-Ascend 上还没有被深度优化。生产环境需要稳定性能时，我仍会切回 MindIE。
3.4 DeepSeek API 如何调用：curl 与 Python 验证
部署完成后的验证，我一般不用图形界面，而是直接用 curl 打一次 OpenAI 兼容接口。这样能排除前端干扰，确认核心链路：
curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1", "messages": [{"role": "user", "content": "用一句话介绍昇腾云服务"}], "max_tokens": 256, "temperature": 0.3 }'这里model必须与启动参数里的--served-model-name或 MindIE 配置里的model_name一致。temperature控制随机性：知识问答设到 0.3 左右比较稳，创意写作可以拉到 0.8。max_tokens要注意，如果你是 R1 这类带内部推理链的模型，模型可能先输出一段思考内容；max_tokens设太小会导致答复被截断在思考阶段，只看到“嗯，我来想想”就结束了。
用 Python 验证同样简单：
import requests resp = requests.post( "http://127.0.0.1:8000/v1/chat/completions", json={ "model": "deepseek-r1", "messages": [{"role": "user", "content": "你好"}], "temperature": 0.3, }, ) print(resp.json())看到正常返回 JSON 后，再去接上层业务。这一步在部署流程里最容易被跳过，但它决定了你后续排错时是先查模型还是先查网络。我自己的习惯是先用 curl 拿到一次 200 响应，再把同样的请求改成批量压测，确保不是在拿运气跑业务。
4. 应用场景拆解：什么业务适合把 DeepSeek 放在昇腾上
4.1 企业内部知识库与私有化助手：RAG 链路怎么接
最常见的一个落地场景，是把 DeepSeek 作为企业内部知识库的问答后端。部署在昇腾云服务上，最大的价值不是算力快，而是数据和模型都在云上的私有网络里跑，调用链路过 OBS、数据库和推理服务时不需要经过公网出站。对很多企业来说，这一点比性能更关键。
RAG 链路一般是这样：离线阶段把文档拆成片段，做 embedding，写入向量库；在线阶段拿到用户问题后先检索 Top-K 片段，再把片段拼进提示词，交给 DeepSeek 生成答案。昇腾云服务在这个链路里只负责最后一步生成，前面的文档解析和向量化通常不用模型算力，用 CPU 或者便宜的计算实例就能跑。
文档解析是这条链路里最容易被低估的环节。PDF 扫描件要先过 OCR，表格要转成 Markdown 或结构化文本，否则按纯文本切分后，检索结果里全是乱序数字。昇腾侧不要做太多文档处理，把这一步放在独立的数据预处理节点，能避免占用昂贵的 NPU。
部署时要注意几个参数：检索的 Top-K 决定模型能看到多少证据；提示词里是否明确要求“只根据资料回答”；生成阶段 temperature 最好控制在 0.1 到 0.3。这些参数和昇腾没有直接关系，但在昇腾上部署时特别容易让人误判模型好坏。如果答案编造严重，不代表模型差，往往是因为检索召回不足或温度太高。
架构上我建议把推理服务单独放在昇腾实例上，向量库放在另一台机器，两者之间用内网通信。昇腾实例的磁盘主要用于模型权重，不建议长时间堆积日志。日志放到 OBS 或集中日志服务，避免磁盘写满后影响推理。
4.2 高并发中文生成与代码辅助：并发和量化参数怎么调
第二个典型场景是高并发生成。客服摘要、代码补全、批量文案改写这类业务，单个请求不大，但并发上来后，显存和通信压力很快显现。DeepSeek 的 MoE 结构在并发场景里有一个特点：不同请求会路由到不同的专家，如果多卡并行，卡间通信量会明显上升。昇腾上的应对手段是限制并发、做好静态图、必要时做量化。
代码补全场景更看重低延迟，单请求响应时间要控制在几百毫秒到一两秒。这种情况下不要追求最大化吞吐，而要把max_seq_len调小，给显存留出更多空间给并发请求。批量摘要场景恰恰相反，可以接受较长的排队时间，更看重每秒处理多少请求，这时可以把 batch 调大，让静态图的批量计算能力发挥出来。
估算并发需求时，不要只看“每秒几个请求”。更准确的方法是算每秒处理 tokens 数：单请求平均输入加输出 tokens 乘以每秒请求数，得到业务总吞吐，再除以单实例能达到的吞吐，得出大致实例数。这样选型时不会被厂商的“并发会话数”宣传带偏。
量化是昇腾上优化并发的重要抓手。用 INT8 或 FP8 精度替换 bf16，能显著降低每请求显存占用，提高同卡并发承载能力。但量化不是无脑开，需要跑一遍校准集，同时检查生成质量是否明显下降。我的经验是先在 bf16 下摸到当前实例能支撑的并发上限，再做量化，对比同一并发下的延迟和准确率，而不是一上来就量化。
如果并发需求超过单实例能力，常见做法是横向加实例，前面加一层负载均衡。昇腾云服务这里要注意实例间的权重一致和会话亲和，否则同一个用户的上下文被打散到不同实例，多轮对话会断。业务侧可以在请求头里带用户 ID，让网关按 ID 哈希到固定实例。
4.3 多轮推理与 LoRA 微调：从对话到持续迭代
不是所有业务都用现成 DeepSeek 权重就够了。很多团队会在 DeepSeek 基座模型上做 LoRA 微调，让它更能理解行业术语。昇腾上的微调和 GPU 路径差异很大，你需要确认训练环境把设备指定为 NPU。简单示例：
import torch_npu import torch device = torch.device("npu:0") model = model.to(device)注意这里的torch_npu导入顺序要在模型创建之前，否则后面调用.to("npu:0")可能不识别设备。device名称是npu:0而不是cuda:0，很多代码库会在这一步直接报错。微调完成后，导出 LoRA 权重再合并回基座，重新走一遍 MindIE 的权重转换。这个迭代流程如果手动跑非常耗时，常见做法是把训练和转换都放到 ModelArts 的昇腾资源池里，用工作流串联起来。
多轮推理场景还有个隐形成本：对话历史的 KV cache 每一轮都要重新计算。MindIE 会尽量复用缓存，但前提是你把max_seq_len设置成能容纳历史长文的大小。如果发现长对话越聊越慢，不要怀疑昇腾性能，先看是不是历史记录被截断后反复重算。多轮里的 system prompt 和工具调用历史也要算进 max_seq_len，否则会被静默截断，客户端不报错，但模型会表现出“失忆”。
5. 避坑指南：昇腾上部署 DeepSeek 的 5 个血泪经验
5.1 启动即报“算子 not supported”
现象：用 vLLM-Ascend 启动 DeepSeek 权重，服务日志里出现类似not supported的算子错误，模型根本加载不出来。
原因：很常见于直接拿原始 PyTorch 权重部署，且 MindIE/CANN 版本没跟上模型结构。DeepSeek 里的自定义注意力算子在旧版本算子库里没有实现，CANN 无法完成算子映射。
解决：先检查当前环境里的 MindIE 版本，再对照权重发布时间。优先选择华为云昇腾公共镜像，因为公共镜像已经带上适配那一代模型的算子库；如果是老镜像，升级 CANN 和 MindIE 后再重新启动。不要在同一环境里混装多套 MindIE，环境变量会互相覆盖，错误信息会变得更难读。
5.2 并发一高就 OOM，服务直接重启
现象：单机上 4 张 NPU，测试时同时发 20 个请求，推理进程直接退出，日志显示内存分配失败。
原因：max_seq_len设得过大，MindIE 在启动时按最大长度预分配 KV cache，显存被静态占掉一大半；每个并发请求还要各自补充 KV cache，结果在请求峰值时超过 HBM 上限。
解决：先用npu-smi info记录空闲 HBM，然后根据业务最大文本长度设定max_seq_len，不要统一设 32768。小批量压测，观察 HBM 占用率快到 90% 时就降低并发或加卡。还有一个容易被忽略的点是：清理推理进程时要用kill整个进程组，否则残留进程会继续占着 NPU 显存。
5.3 用 vLLM 替换 MindIE 后吞吐不升反降
现象：在 GPU 上用 vLLM 性能很好，换到昇腾上同一配置，首 token 延迟和吞吐都比预期差一大截。
原因：vLLM-Ascend 对不同模型的算子融合覆盖度不一致，DeepSeek 的 MoE 路由和 MLA 还没有完全走到静态图优化；而 MindIE 对这两个结构做了专门处理。
解决：生产环境不要轻易替换推理引擎。如果坚持用 vLLM-Ascend，先把--enable-prefix-caching打开，并确认--tensor-parallel-size不超过物理卡数；再对比一次 MindIE 同样模型的延迟，用数据决定去留，不要凭习惯用 vLLM。
5.4 RAG 回答大量“编文档”
现象：知识库问答中，模型引用了一堆听起来合理但文档里根本不存在的数字和术语，而且回答语气非常笃定。
原因：生成参数 temperature 过高，或者检索返回的 Top-K 太少，模型没有足够证据，只能靠内部知识补全。昇腾部署在这方面没有黑匣子问题，但如果你只测模型忽略 RAG，会误判模型失败。
解决：把 temperature 调到 0.2 左右；在提示词中明确写“未在资料中找到的内容禁止编造”。检索侧把 Top-K 提高到 5 左右，加入一个重排步骤，把最相关的片段放到提示词靠前位置。改完后用同一组问题回归，观察答案是否还能从文本中找到依据。
5.5 模型权重从公网下载慢，还把磁盘占满
现象：在云服务器上直接执行wget下载模型，跑了几个小时失败，磁盘也被临时文件占满。
原因：DeepSeek 权重文件体积大且分片多，单线程下载没有断点续传；临时文件存放在系统盘而不是数据盘，系统盘被写满导致机器异常。
解决：先用对象存储传模型，再用 obsutil 在实例内下载到数据盘，指定目标路径为/data/models而不是/root。如果必须走公网，下载工具用多线程断点续传，并确认磁盘空间足够。下载完成后一定要校验文件完整性，检查 SHA256，否则中途出错会在权重转换时浪费更多时间。
6. 最后一步：验证部署效果的三个技巧
部署完成后，我最怕看到“聊天没问题就宣布上线”。大模型运行环境的隐性故障，往往在正常对话时看不出来。给你三个我现在还在用的验证技巧。
第一，做一个固定回归集。准备 20 个中文问题，包含短问答、长文本摘要、代码生成和少量多轮对话。每次修改配置后，把同一组问题重跑一遍，记录答案和时间。不要凭感觉说“好像变快了”，要用同一输入对比。
第二，同时看首 token 延迟和吞吐。对话体验和首 token 延迟关系更大；批量场景则看整体吞吐。用 curl 可以粗略量一次：
curl -w "time_total: %{time_total}\n" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1","messages":[{"role":"user","content":"你好"}],"max_tokens":64}' \ http://127.0.0.1:8000/v1/chat/completionstime_total 只是总时长，还要配合服务日志里的首 token 延迟看。首 token 小于 1 秒，对话体验基本可用；超过 3 秒，优先查图编译和并发抢占。
第三，用 NPU 监控修正瓶颈判断。运行压测时持续观察npu-smi info。如果 HBM 占用超过 90% 但算力利用率只有 30%，瓶颈在显存和带宽，优先降上下文或做量化。如果算力利用率接近 90% 但吞吐不高，说明模型切分或 batch 太保守，适当调大并发参数。
我早期总以为“能聊几句”就是部署成功，后来被一次长文档问答的延迟退化打了一巴掌，才把这三件事固定成上线前检查项。代码能跑只是开始，指标稳定才敢接业务。希望帮到你。
本文还有配套的精品资源，点击获取
