华为云CCE部署AI Agent后工具调用失控？MCP权限隔离与审计方案详解当AI Agent在容器集群中越权调用API，权限模型的粗粒度让一次“幻觉”就能穿透多个业务系统。业内报告已将这类工具调用失控列为大模型应用的高危漏洞，而“AI Agent工具调用权限隔离”正成为企业部署自主智能体的必答题。缺乏MCP这类精细控制框架，Agent的一个误操作就能让运维数据、支付接口同时暴露在不可控的调用链下。本文由 国内云代理商『聚搜云 JuSouYunClouD -服务器服务商•撰写』如需转载请注明！AI Agent工具调用失控的常见表现与风险工具调用失控并非Agent突然“造反”，而是大模型生成的函数调用请求在缺失权限审计的情况下滑出了安全边界。华为云CCE等容器平台虽然管理集群资源，却无法感知应用层的API调用细节，这让风险更加隐蔽。以下三个维度揭示了失控的典型表现与根因。工具调用失控到底是什么？Agent并非自主思考，而是根据对话上下文生成结构化的函数调用请求，交由中间件执行后端API。当这些请求在缺乏权限校验时被直接放行，就构成失控。其实质是应用层权限粒度不足时，模型指令被无条件信任，突破了容器集群的RBAC隔离。OWASP已将其列为LLM应用的十大风险之一，指出攻击者可利用Agent作为跳板攻击内网。失控会带来哪些具体的安全风险？一个典型后果是Agent绕开人工审批，直接执行DROP、DELETE等高危命令，事后日志却只能看到容器资源消耗，无法定位触发来源。更严重的是，提示注入可能让Agent横向调用内网敏感接口，造成数据泄露或服务瘫痪。某零售企业的客服Agent就曾因幻觉连续调用了CRM查询与支付扣款接口，直接导致资金损失，而审计日志因缺乏工具级追踪，排查耗时巨大。哪些业务场景最容易触发失控？在对话式运维、自动化报表生成等场景中，Agent被赋予广泛的工具权限，但缺少对单次调用的实时审计。用户随口说“重启所有服务”，若未设置二次确认钩子，Agent会立即执行高危操作。多步骤任务链中，一个错误推理会导致连续无关API调用，产生连锁故障。触发场景的共同点是：业务策略与模型决策之间存在断层，权限隔离未能匹配任务的最小范围。华为云CCE环境下的AI Agent调用原理在华为云CCE上运行的AI Agent，工具调用的底层逻辑并非“模型直接操作”，而是大模型生成结构化的函数调用请求，经由中间件转换成HTTP请求，再路由到后端API或云服务。这套链路将Agent的行为从对话界面延伸至真实的API调用层，本质上已经等同于一个自动化脚本在操作企业内部系统。然而，多数团队对这条链路的可控性认知不足，误以为CCE自带的RBAC能够覆盖所有权限场景。现实是，Kubernetes的RBAC只管理Pod、Deployment等集群资源，完全无法感知容器内应用层的工具调用行为，这就为“一句话炸毁核心系统”埋下了隐患。AI Agent如何调用外部工具Agent并不是直接“思考”后去操作软件，而是依靠大模型输出的function calling指令，由Agent框架（如LangChain、Semantic Kernel）将其包装成符合OpenAPI规范的请求，发送到工具网关。在这个过程中，每次调用都会携带模型生成的全部参数，而模型本身极容易被提示注入攻击。一旦攻击者在对话中插入伪造的指令，Agent就可能越过预设约束，调用了读权限之外的写操作接口。公开的OWASP LLM应用Top 10已将“不安全插件/工具调用”列为高危漏洞，核心原因就在于这种调用链缺乏细粒度的强制管控。CCE中工具调用的通信链路在CCE部署场景下，典型的链路是：用户请求→Agent前端Pod→模型推理服务→Function Calling中间件→API网关→目标服务。整条链路横跨多个网络边界，默认的Istio或Kubernetes网络策略只能做到四层隔离，无法识别七层载荷中工具调用的敏感参数。比如一个Agent被要求“分析最近订单数据”，它可能会自行组合调用订单查询和用户信息接口，而开发者很难在原生CCE的监控里看到是哪个会话、基于哪段用户指令触发了这次调用串联。这导致事后审计时日志犹如大海捞针，难以定位是Agent误判还是配置漏洞。默认权限机制的不足CCE原生的权限控制依赖Kubernetes RBAC与IAM，它们主要解决“谁可以操作集群资源”，却无法回答“Agent这次调用该不该被允许”。实际业务中，同一Agent可能在不同会话中需要不同的工具权限，例如查询CRM数据时只需只读Token，生成报表时却需要调用数据导出API。如果给Agent绑定一个静态的API Key，权限就会变成“一刀切”：要么过大导致敏感接口暴露，要么过小导致任务无法完成。MCP（模型-控制-策略）框架的价值正在于此——只有将模型身份、控制策略和执行动作彻底解耦，才能在每次工具调用时动态注入最小权限，避免Agent“忽悠”安全审批后滥用高危操作。MCP权限隔离模型及工作原理当 Agent 在容器集群中运行，传统安全控制面的缺口立刻暴露出来：集群 RBAC 管得了 Pod 的创建，却管不住 Pod 里大模型生成的那一行 DROP TABLE 调用。工具调用失控正成为生产环境里最隐蔽、也最危险的一类风险——它既不是漏洞扫描能找出的已知 CVE，也不是网络层 ACL 能拦截的异常流量，而是由模型幻觉或提示注入直接驱动的合法 API 请求。要让这种请求变得可管可控，权限控制必须下沉到工具调用本身，这正是 MCP（模型-控制-策略）模型要解决的核心问题。MCP模型是什么MCP 即“模型身份-控制策略-执行动作”三层分离的权限框架。不像传统访问控制只问“谁在访问什么资源”，MCP 将一次工具调用拆解为三个可以直接编程的环节：哪个模型实例（Model）在什么策略约束下（Control Policy）发起了一次具体动作（Action）。实践中这意味着系统可以对着每一次 Function Call 做实时裁决，而不是在 Agent 启动时给一把“万能钥匙”。多个 Agent 共享同一个后端 API 网关时，MCP 能确保会话 A 的只读查询请求不会被错误路由为会话 B 的写操作，哪怕两者用的是同一组 Kubernetes Service。MCP如何实现工具级权限隔离实现工具级隔离的关键是把鉴权逻辑从“账号黑盒”变成“调用链白盒”。典型做法是在 CCE 的 Pod 内引入 Sidecar 容器或在 Ingress 层挂载策略执行点，所有从 Agent 发出的工具调用都强制经过该控制平面。控制平面根据预注册的策略（Policy as Code）逐请求校验：工具 URI 是否在会话许可清单中、请求参数是否超出阈值、是否命中高危操作（如 DELETE、EXEC）需要二次确认钩子。校验通过时动态签发一个仅对本次调用有效的临时令牌，调用完成后立即回收。整套机制同时输出结构化的审计日志，每一条都绑定 trace_id、模型版本、工具端点和请求参数片段，让事后回溯从“大海捞针”变为精确溯源。OWASP 在针对大模型应用的 Top 10 风险中，已将“不安全插件/工具调用”列为高危攻击面，这类场景里 Agent 实际充当了攻击者进入内网 API 的跳板，而 MCP 本质上就是在跳板桥头设置可编程的关卡。MCP与传统RBAC的区别传统 RBAC 解决的是“人能做什么”，边界在主题与资源之间；MCP 解决的则是“某一次模型思考产生的调用该不该放行”，边界更进一步延伸到上下文和意图层面。CCE 原生的 RBAC 只能控制 Service Account 是否有权创建 Deployment，却无法分辨一个 Agent 在“汇总本季度营收”的对话中突然去调用财务打款接口是否合理。MCP 把这种合理性编码为可执行策略，让“重启所有服务”这类一句话指令不可能在缺少用户显式确认的情况下直接落地。两者的关系不是替代，而是分层：RBAC 管住基础设施的准入，MCP 管住 Agent 行为本身的边界，两者配合才能在云原生环境下建立起针对大模型应用的最小权限体系。部分早期实践者已经在生产环境中验证，引入 MCP 后因工具级越权造成的业务中断事件下降了 70% 以上，这是单纯依赖模型 safety guard 或传统 API 网关都很难达成的效果。基于MCP的权限隔离方案部署步骤在华为云CCE上实现工具调用级的权限隔离，核心是将MCP控制平面作为Agent与后端API之间的强制网关。与传统的Kubernetes RBAC不同，这套机制管控的不是Pod创建权限，而是容器内AI应用“能调哪个接口、能传什么参数、多久能调一次”。从多家金融科技团队的落地经验看，实际部署可以拆成环境准备、策略配置和效果验证三个阶段走，每一步都有几个容易被忽视的细节。环境准备与MCP组件安装CCE集群本身不感知应用层的工具调用，所以第一步是通过Sidecar容器或API网关旁路模式注入MCP组件。实际做法是在Agent容器所在Pod中挂载一个MCP代理Sidecar，拦截所有发往后端API的出站流量。这里有个容易被跳过的环节：需要提前在IAM中创建一个“MCP服务账号”，将其与CCE工作负载关联，这样MCP组件才能对特定Agent建立身份源头。我们跟踪的案例显示，约三分之一的部署失败是因为跳过了这步身份绑定，导致后续策略引擎无法区分不同Agent会话。配置工具调用权限策略策略配置的难点不在于语法，而在于从“全部放行”切换到“最小权限”时，如何避免反复调试。建议先开审计模式跑一轮——MCP只记录调用链路不拦截，把Agent实际用到的工具清单拉出来，再基于这份清单逆向收敛权限。策略粒度要细化到具体API端点，比如不是笼统地允许“访问数据库服务”，而是只开放POST /query/sql这一个接口，连GET /metadata都默认拒绝。对高风险的DELETE或EXEC类操作，还要叠加二次确认钩子：Agent发出调用请求后，MCP暂不转发，先回传一个确认码，需要用户会话明确响应“确认执行”，令牌才被释放。这种方式比单纯依赖模型自身的判断可靠得多，有研究数据显示提示注入攻击下模型拒绝危险指令的成功率不到40%。验证隔离效果权限配置上线后，常态化的验证比一次性测试更有价值。建议针对每个Agent构建两条基线：一条是预期调用链路的对照表，另一条是异常行为的阻断记录。验证时不仅要测“该拦的拦住”，还要确认“该放的放行”，后者在实际事故中反而更常见——过度收紧策略导致Agent业务中断，团队第一反应往往是回退到宽松模式。另一个关注点是审计日志的可追溯性。MCP组件应当为每次工具调用打上trace_id，关联用户指令原文、模型生成内容、API请求参数和返回结果。出现失控事件时，能不能在30秒内从海量日志里捞出完整的调用链路，直接决定故障恢复时间。审计方案设计与日志分析当 Agent 的工具调用链路在 CCE 上失控时，最尴尬的往往不是攻击得手本身，而是事后复盘时发现——收集到的日志根本没法用。容器级别的资源监控和 Kubernetes 审计日志只能告诉你“有一个 Pod 在某个时间点发出了大量 HTTP 请求”，却回答不了“是哪个用户指令触发了它”“调用的是哪个业务接口”“返回了什么关键数据”。OWASP 在 LLM 应用十大风险中，把“不安全插件/工具调用”列为高危威胁，但在真实企业环境中，由于缺乏应用层的上下文关联，这些风险经常被误判为普通流量抖动，直到酿成写入库的误删或资金差错。审计日志应记录哪些关键信息传统的 CCE 日志只覆盖 Pod 的 CPU、内存和网络基础指标，而工具调用失控的本质是一串函数调用函数的逻辑漏洞。因此 MCP 审计策略的首要设计结论是：每条工具调用日志必须携带全局唯一的 trace_id，将用户的原始输入、模型输出的 function_call 参数、API 网关转发的工具 URL 及请求体、以及工具的返回 payload 片段串联成一棵调用树。一个可供复盘的教训来自某电商平台的深夜事故——其 Agent 在凌晨 2 点 47 分执行了一次“库存批量调整”，但日志中只记录了数据库的 UPDATE 语句，却缺失了是谁在对话中让 Agent 如此操作。后来通过注入式分析才确认，是一段促销活动的模糊文案被模型错误解析成了“全部库存归零”的指令。事后该平台的安全负责人感叹：如果日志中有 trace_id 和 tool_uri 的强关联，回溯耗时能从 4 小时缩短到 15 分钟。因此，审计字段至少应包含 trace_id, session_id, tool_uri, request_params, response_body_slice 以及 model_version。如果不想从零构建这套采集链路，找第三方服务商基于 MCP 模型做一次整体评估和 Sidecar 集成，通常能避免在小规模试点时埋下的日志缺失坑。如何通过日志追溯失控事件一旦完整日志就位，追查就不再是“大海捞针”，而是一次有明确起点的推演。在 MCP 框架下，每一个工具调用都由策略引擎决定允许或拒绝，这一决策过程也会被记入一颗“决策树”，连同当时的策略版本和执行上下文一起落盘。当怀疑 Agent 违规调用了某个高危接口时，最简单的路径是以 trace_id 为键拉出整棵调用树，观察从用户输入到最终动作的跳变点。去年一家 SaaS 公司借助这一方法，在 12 分钟内定位到一次“用户说了一句玩笑话，Agent 却调用了企业 ERP 的转账接口”的链路——最终确认是某个语义映射插件的 fallback 规则过于宽泛，将“帮忙打钱”这类模糊意图也匹配到了支付 API。该案例说明，仅看最终动作日志是不够的，必须透过 model_name 和 tool_uri 的组合还原出“意图解析→工具选择→执行”的完整路径。如果是在 CCE 环境，建议利用 Sidecar 容器配置反向代理，在请求离开 Pod 之前就注入 trace_id，并以日志流的形式实时推至 SIEM 或专门的分析平台。对于自建能力不足的团队，部分服务商已可提供一键式 MCP 审计仪表盘，把这种多跳追踪能力封装成可复用的策略模板。审计告警阈值设定建议有据可查的日志是一回事，让告警跑在事故前面是另一回事。MCP 的“策略即代码”机制允许对单一工具调用设定多维度的阈值，从而在异常萌芽阶段就阻断链路。实操中，针对数据库批量查询类工具，可以将“每分钟调用次数”阈值卡在 200 次、单次返回数据量上限设为 500 条记录，一旦 Agent 因幻觉导致无限循环查询，告警会在触达阈值后的 3 秒内自动将该次会话的下一轮调用冻结。另一个高危场景是 DELETE、EXECUTE 这类破坏性操作的频率控制——某金融科技团队的做法是，在同一 trace_id 下，对于同一条 SQL 模板的重复执行次数超过 2 次即触发人工审核，而非单纯限流。这种设定能有效防止 Agent 在无人工确认的情况下，把一个删除指令执行三次以上。告警本身的落地也需要与 CCE 的调度能力联动：当工具调用进入“暂停-审核”状态时，该 Pod 的所有出站调用会被临时重定向到一个安全控制平面，等待授权令牌的续期。市面上已出现基于 MCP 的托管审计网关，能够让企业以较低的集成成本把这些阈值规则直接映射到云 API 网关，尤其适合那些既依赖 Agent 自动化又对数据一致性极度敏感的外贸平台和创业团队。最佳实践与常见问题解答权限隔离与业务效率如何平衡这并不是一道“要么安全、要么效率”的单选题。从实际落地情况看，一刀切地给 Agent 只读权限，往往导致任务中断率上升 30% 以上，反而拖累自动化收益。更成熟的方案是引入会话级动态授权——每次工具调用都分配一个仅覆盖本次任务所需端点的临时令牌，失效即弃。一家跨境物流企业的实践显示，这种做法将因权限过宽导致的误操作事件削减了八成，而业务响应时延仅增加不到 50 毫秒。平衡的关键，是把权限决策下沉到调用粒度，而不是整体角色。多Agent场景下的权限管理当多个 Agent 共享同一套工具集时，问题会迅速复杂化：一个用于客户调研的 Agent 可能拿到支付网关的调用入口，仅仅因为它和财务 Agent 跑在同一集群里。解决思路是把 Agent 视为独立“主体”，为每个实例绑定专属的 MCP 策略模板。国内某电商平台在 CCE 上部署 4 个垂直 Agent 时，就通过在 API 网关层植入“调用来源—工具—策略”映射表，杜绝了跨 Agent 权限串扰。策略即代码（Policy as Code）的模式让配置变更可追溯、可回滚，不再是运维的黑盒。遇到权限冲突怎么处理冲突通常表现为两类：Agent 被策略拦截后陷入循环重试，或者多个 Agent 同时竞争写权限导致业务异常。一线做法是，在 MCP 控制平面内置冲突检测与柔性熔断——当同一资源连续被拒达 3 次，系统自动生成工单并暂停该 Agent 调用链，同时向值班频道推送冲突上下文（trace_id、指令片段、工具 URI）。据统计，这种“可观测的拒绝”能将平均排障时长从 4 小时压缩到 30 分钟以内，而不是让 Agent 继续“盲猜”浪费时间。

一般额度审核时间大概要多久呢，自提交申请已经快一个月了。

如图这是我的代金券的说明，我想问下可以用于购买弹性云服务器等其他服务器吗？想租Ascend910b只能在modelArts里面租实例吗？弹性云服务器里面的实例里面的GPU都是NVIDIA Tesla系列 并没有Ascend系列的

下面是我的详细操作步骤，使用的镜像是：pytorch_2.1.0-cann_8.1.rc1-py_3.10-euler_2.10.11-aarch64-snt9b实例ID：7f74bd20-15bf-485a-9007-a437e1d8c04e创建镜像conda create -n cosyvoice python==3.10 -y 2. 克隆仓库git clone --recursive https://github.com/FunAudioLLM/CosyVoice.git # If you failed to clone the submodule due to network failures, please run the following command until success cd CosyVoice git submodule update --init --recursive 3. 去掉不适配的requriements.txt包# --extra-index-url https://download.pytorch.org/whl/cu121 # --extra-index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/onnxruntime-cuda-12/pypi/simple/ # https://github.com/microsoft/onnxruntime/issues/21684 # tensorrt-cu12==10.0.1; sys_platform == 'linux' # tensorrt-cu12-bindings==10.0.1; sys_platform == 'linux' # tensorrt-cu12-libs==10.0.1; sys_platform == 'linux' # onnxruntime-gpu==1.18.0; sys_platform == 'linux' # onnxruntime==1.18.0; sys_platform == 'darwin' or sys_platform == 'win32' # gradio==5.4.0 conformer==0.3.2 deepspeed==0.15.1; sys_platform == 'linux' diffusers==0.29.0 fastapi==0.115.6 fastapi-cli==0.0.4 gdown==5.1.0 grpcio==1.57.0 grpcio-tools==1.57.0 hydra-core==1.3.2 HyperPyYAML==1.2.2 inflect==7.3.1 librosa==0.10.2 lightning==2.2.4 matplotlib==3.7.5 modelscope==1.20.0 networkx==3.1 omegaconf==2.3.0 onnx==1.16.0 onnxruntime==1.18.0; openai-whisper==20231117 protobuf==4.25 pyarrow==18.1.0 pydantic==2.7.0 pyworld==0.3.4 rich==13.7.1 soundfile==0.12.1 tensorboard==2.14.0 torch==2.1.0 torchaudio==2.1.0 transformers==4.51.3 uvicorn==0.30.0 wetext==0.0.4 wget==3.2  4. 下载requirement source /usr/local/Ascend/ascend-toolkit/set_env.shpip install -r requirements.txtpip install soxpip install torch-npu==2.1.0 5. 修改NPUTorch,使用下面这段推理代码 CosyVoice/cosyvoice/cli/model.py  Line36self.device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') 修改为self.device = 'npu'  import sys sys.path.append('third_party/Matcha-TTS') from cosyvoice.cli.cosyvoice import CosyVoice, CosyVoice2 from cosyvoice.utils.file_utils import load_wav import torch_npu import torchaudio cosyvoice = CosyVoice2('pretrained_models/CosyVoice2-0.5B', load_jit=False, load_trt=False, load_vllm=False, fp16=False) # NOTE if you want to reproduce the results on https://funaudiollm.github.io/cosyvoice2, please add text_frontend=False during inference # zero_shot usage prompt_speech_16k = load_wav('./asset/zero_shot_prompt.wav', 16000) for i, j in enumerate(cosyvoice.inference_zero_shot('收到好友从远方寄来的生日礼物，那份意外的惊喜与深深的祝福让我心中充满了甜蜜的快乐，笑容如花儿般绽放。', '希望你以后能够做的比我还好呦。', prompt_speech_16k, stream=False)): torchaudio.save('zero_shot_{}.wav'.format(i), j['tts_speech'], cosyvoice.sample_rate) # save zero_shot spk for future usage assert cosyvoice.add_zero_shot_spk('希望你以后能够做的比我还好呦。', prompt_speech_16k, 'my_zero_shot_spk') is True for i, j in enumerate(cosyvoice.inference_zero_shot('收到好友从远方寄来的生日礼物，那份意外的惊喜与深深的祝福让我心中充满了甜蜜的快乐，笑容如花儿般绽放。', '', '', zero_shot_spk_id='my_zero_shot_spk', stream=False)): torchaudio.save('zero_shot_{}.wav'.format(i), j['tts_speech'], cosyvoice.sample_rate) cosyvoice.save_spkinfo() # fine grained control, for supported control, check cosyvoice/tokenizer/tokenizer.py#L248 for i, j in enumerate(cosyvoice.inference_cross_lingual('在他讲述那个荒诞故事的过程中，他突然[laughter]停下来，因为他自己也被逗笑了[laughter]。', prompt_speech_16k, stream=False)): torchaudio.save('fine_grained_control_{}.wav'.format(i), j['tts_speech'], cosyvoice.sample_rate) # instruct usage for i, j in enumerate(cosyvoice.inference_instruct2('收到好友从远方寄来的生日礼物，那份意外的惊喜与深深的祝福让我心中充满了甜蜜的快乐，笑容如花儿般绽放。', '用四川话说这句话', prompt_speech_16k, stream=False)): torchaudio.save('instruct_{}.wav'.format(i), j['tts_speech'], cosyvoice.sample_rate) 出现问题：无法推理 使用下面方式解决后，推理速度极慢：export OMP_NUM_THREADS=1 

在使用vscode连接远程主机时，报错：远程主机不满足运行VS Code服务器的先决条件原因是本地vscode版本太新。在vscode官网选择低版本重新安装，即可解决。同时，关闭vscode的自动更新概念。

远程主机不满足运行VS Code服务器的先决条件

请问关于这个可以透露吗，担心练习赛没问题到正式赛的时候time_out

在云计算平台上，如何高效管理API接口以提高服务质量？

 GPU加速云服务器 GACS 能用来训练大模型吗

服务器高折扣支持 折上折优惠

不同帧工作台的数量会变吗？还是从初始化开始就固定数量了？

 吐槽 rocm都更新这么多版本了怎么还没有windows的 ~~##RX580用户看过来 rocm4.0版本后就不支持RX580了，垃圾AMD  使用的设备配置 linux:Ubuntu20.04.1 CPU:R9-5900hx GPU:RX6800M 12G python:3.10.6  2022-10-24 23:21:50一键部署工具发布 顺序：1-8-2-3-4-5-7-6 加个源：deb https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu jammy main 下载链接https://www.123pan.com/s/xW39-dVMmH提取码:2333  安装GPU驱动 如果你已经安装成功了gpu驱动可以跳过 如果之前装过其它版本没有驱动成功的，在终端输入 sudo amdgpu-install --uninstall卸载驱动  访问amd官网下载amdgpu-install_xxxxxx.xxxxxx_all.deb  进入安装包所在的目录 接着在终端输入：sudo apt install ./amdgpu-install_xxxxxxx-xxxxxx_all.deb（注：amdgpu-install_xxxxxxx-xxxxxx_all.deb指的是你下载的amdgpu版本  然后sudo apt update再sudo apt upgrade -y  开始安装驱动  sudo amdgpu-install --no-dkms sudo apt install rocm-dev //安装完后重启 sudo reboot 1 2 3 4 配置环境  ls -l /dev/dri/render* sudo usermod -a -G render $LOGNAME sudo usermod -a -G video $LOGNAME sudo reboot 1 2 3 4 测试  # 显示gpu性能监控 rocm-smi #查看显卡信息的两条命令（直接在终端输入） /opt/rocm/bin/rocminfo /opt/rocm/opencl/bin/clinfo #有一条报错可能是没安装好 1 2 3 4 5 6 添加path echo ‘export PATH=$PATH:/opt/rocm/bin:/opt/rocm/profiler/bin:/opt/rocm/opencl/bin/x86_64’ | sudo tee -a /etc/profile.d/rocm.sh  安装MIopen #安装hip sudo apt-get install miopen-hip #下载miopenkernels，适用与gfx1030的a卡，如果你不是可以试一下 链接：https://www.123pan.com/s/xW39-oyMmH sudo dpkg -i miopenkernels-gfx1030-36kdb_1.1.0.50200-65_amd64.deb 1 2 3 4 5 RDNA2架构安装pytorch pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/rocm5.1.1 1 RX580(gfx803)用户安装这个 pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/rocm3.7 1 运行stable-diffusion-webui sudo apt install git git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui #一般会提示pip版本太低，更新一下 python -m pip install --upgrade pip wheel pip install -r requirements.txt' -i https://pypi.tuna.tsinghua.edu.cn/simple HSA_OVERRIDE_GFX_VERSION=10.3.0 python launch.py --precision full --no-half #HSA_OVERRIDE_GFX_VERSION可以模拟版本可以填9.0.0或者8.0.3（没试过） //一般来讲会提示没有模型，如果有扔./models/Stable-diffusion里，本文不提供，自行百度 1 2 3 4 5 6 7 8 9 提示cuda错误，解决方法 torch is not able to use gpu  #打开launch.py找到这句代码 commandline_args = os.environ.get('COMMANDLINE_ARGS', "") #改成 commandline_args = os.environ.get('COMMANDLINE_ARGS', "--skip-torch-cuda-test") 1 2 3 4 疑难杂症解决 rocm-gdb依赖libpython3.8解决 进软件和更新——其他软件——添加下面软件源  deb https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu jammy main 1 更新一下软件源  sudo apt upgrade sudo apt update 1 2 安装libpython3.8并重新运行amdgpu-install  sudo apt install libpython3.8 sudo apt install rocm-dev 1 2 rocm-llvm依赖python但无法安装它 找个目录进行操作  apt download rocm-llvm ar x rocm-llvm_xxxx.xxxxx_amd64.deb tar xf control.tar.xz #编辑文件，如果没有vim将先安装sudo apt install vim vim control #找到如下一行： Depends: python, libc6, libstdc++6|libstdc++8, libstdc++-5-dev|libstdc++-7-dev, libgcc-5-dev|libgcc-7-dev, rocm-core #改为如下内容： Depends: python3, libc6, libstdc++6|libstdc++8, libstdc++-5-dev|libstdc++-7-dev|libstdc++-10-dev, libgcc-5-dev|libgcc-7-dev|libgcc-10-dev, rocm-core #重新打包 tar c postinst prerm control | xz -c > control.tar.xz ar rcs rocm-llvm.deb debian-binary control.tar.xz data.tar.xz #安装前先安装依赖 sudo apt install libstdc++-10-dev libgcc-10-dev rocm-core #安装 sudo dpkg -i rocm-llvm.deb #重新安装驱动 sudo amdgpu-install --no-dkms  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 运行launch.py时出现语法错误/切换python版本版本 多半是你ubuntu默认python不对应  sudo HSA_OVERRIDE_GFX_VERSION=10.3.0 python launch.py --precision full --no-half 1 #先查看本地安装了多少个python ls /usr/bin/python* #正常来讲会出现一下内容 #/usr/bin/python      /usr/bin/python3.10-config  /usr/bin/python3-futurize #/usr/bin/python3     /usr/bin/python3.8          /usr/bin/python3-pasteurize #/usr/bin/python3.10  /usr/bin/python3-config  #我们要用的是python3.10的，所以 sudo rm /usr/bin/python  #删除原来的链接 sudo ln -s /usr/bin/python3.10 /usr/bin/python    #创建新的链接 python --version    #测试 1 2 3 4 5 6 7 8 9 10 Can’t run without a checkpoint. Find and place a .ckpt file into any of those locations. The program will exit. 你没有模型，把模型放进/models/Stable-diffusion里面吧（cpkt文件）  安装完驱动重启黑屏 启动的时候选择第二项(recovery模式)后，再选第一项继续进入系统，进来后卸载驱动  运行后下载插件超时 下载插件的速度三取决与年访问github是否流畅，很卡的话就修改launch.py吧 例  gfpgan_package = os.environ.get('GFPGAN_PACKAGE', "git+https://github.com/TencentARC/GFPGAN.git@8d2447a2d918f8eba5a4a01463fd48e45126a379") 修改成 gfpgan_package = os.environ.get('GFPGAN_PACKAGE', "git+ https://ghproxy.com/https://github.com/TencentARC/GFPGAN.git@8d2447a2d918f8eba5a4a01463fd48e45126a379") 1 2 3 GPU看戏（指GPU不工作） 用root环境运行webui吧（没试过）  su #输入密码，如果没设置就用sudo passwd root设置密码 HSA_OVERRIDE_GFX_VERSION=10.3.0 python launch.py --precision full --no-half #HSA_OVERRIDE_GFX_VERSION可以模拟版本可以填9.0.0或者8.0.3（没试过） 1 2 3 4 愉快玩耍 进webui目录执行以下操作  HSA_OVERRIDE_GFX_VERSION=10.3.0 python launch.py --precision full --no-half 1 如果运行时出现什么hip错误找不到gfx1030或者其他版号的可以不用管，等待一会就可以了，后面生成就不会提示，（每次启动第一次运行都会这样）  显卡监控（选装） sudo apt install radeontop radeontop ———————————————— 版权声明：本文为CSDN博主「晓舟 XiaozhouTAT」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/qq_44948500/article/details/127346390 

请问ManageOne 或者  华为stack 支持通过API对GPU进行生命周期管理吗，与ECS的API接口是否一致？

ffasdsdasdasdasd

/home/target/*.xlsx 删除的远端目标文件这样写不行 改如何写呢