本文介绍OpenClaw（原 Clawdbot）安装Skill 技能操作指南。

推理服务与训练任务最大的不同，是它长期在线、请求量随时起伏。低谷时实例闲着，高峰时排队拉长，靠一个固定副本数很难两头兼顾。弹性扩容要解决的正是这件事，但真正配好并不只是把自动伸缩打开：触发指标选错，会在该扩的时候不动、不该扩的时候乱扩；忽略冷启动，扩容决策做出来时流量已经过去了；缩容没有滞后，刚扩出来的实例马上又被回收，来回抖动。突发流量还分几种形态，可预期的峰、不可预期的尖刺、缓慢爬升，对应的打法并不一样。以下先把横向与纵向两条扩容路径分清，再讲触发指标、突发形态、冷启动这道硬约束，然后给一份可落地的策略配置与稳定性措施，最后说上线后怎么观察与调整。

问到“有哪些卡型”，多数人期待一张型号清单。实际上更该先弄明白的是：卡与卡之间的差别，究竟落在哪几个参数上，这几个参数又如何对应到训练与推理两类任务的不同需求。算力池里常见的加速卡，按显存容量大致能分成二十多 GB、四十 GB 上下、八十 GB 上下几个档位，再往上还有显存更大、互联更快的规格；同一档位里又有算力密度、显存带宽、精度支持与互联方式的差别。这些差异对训练的影响，与对推理的影响并不一样。以下先讲清看卡该看哪四件事，再分别说训练侧与推理侧各自在意什么，然后按典型场景给分档建议，最后给一张可照做的选型对照表。

模型大到一张卡装不下，或者一张卡跑得太慢时，就要把训练拆到多张卡、多台机器上。很多人以为分布式就是“选个开关、填个卡数”，实际配置里要决定的事情多得多：按什么维度切、切完怎么通信、批次与学习率怎么跟着改、切错了会出现什么现象。切分方式主要有四条路——按数据切、按层内切、按层切段、以及把优化器状态与激活值做分片；真实任务里通常是两三种组合起来用。理解每条路的代价在哪，比记住某个组合的名字更有用。以下逐条讲清四条路的原理与适用面，再说组合怎么选、配置要盯哪几项、规模上去之后效率为什么会掉以及怎么兜住故障。

一体机这几年被反复提起，卖点集中在两句话：预集成、开箱即用。但真要落地，先得把这两句话拆开看——预集成到底集成了哪些层，开箱即用又到哪一步为止。答案是有相当一部分活确实省掉了，也有一部分事必须自己做，比如机房条件、网络规划、数据迁移、业务对接。把边界认清楚，才不会在设备到场那天才发现“还得再找一堆人”。这类产品的价值主要在于把兼容性测试、参数调优、软件栈适配这些重复劳动提前做完，让团队把精力放回模型与业务上。以下按“集成了什么、开箱边界在哪、交付怎么走、规格怎么选、验收验什么、后续怎么运维、什么情况该选它”七段展开。

问服务范围时，得到的回答往往是几个词并列：算力、训练、推理、运维。这样的清单难以用来判断“我需要的那部分到底管不管”。真正有用的分法是把整个链路切成几段，逐段问一句：这一段是我自己做、还是对方做、做到什么程度算交付。链路的切法各家叫法不同，实质是五段：资源与环境、数据与模型准备、训练与调优、上线与推理、以及贯穿全程的运维与支持。每段里都能再分三层——只提供工具、提供工具加指导、直接替你把活干完。三层之间的差别很大，报价与责任边界也完全不同。以下按五段逐段说明各段通常包含什么、三层支持怎么区分，末尾单列一节讲哪些事一般不在服务范围内，把边界划清比把清单列长更有用。

手里有一套本地机房，又想用上一体化智算服务，接起来常犯两个错：一是只想通过网络把两边连上就完事，结果账号各管各的、监控各看各的，等于没接；二是上来就想把训练任务跨域跑，被数据传输与网络时延教育一遍才回头。混合形态的价值在于分工：数据与敏感业务留在本地，弹性算力与突发需求交给云端，两边的资源在一个界面里看得见、管得住。要实现这一点，网络只是通道，真正的工作在统一管理的四件事上：资源视图、账号权限、监控告警、计量口径。以下先分清混合形态的几种分工方式，再逐项拆统一管理的内容、网络与数据通道的搭建、任务分配的原则、安全合规的边界，末了给一个从易到难的落地次序。

集群买了一堆卡，报表上的利用率却常年不高，这是多数团队都遇到过的局面。利用率低的原因通常不是算力买多了，而是资源在错的时段待在了错的人手里：有人申请了一批卡却只用了几天，占着没还；有任务实际只需要两张卡，为了保险要了八张；还有资源被切得七零八落，明明有空余，整块的需求却排不进去。闲置回收与碎片整合分别对付前两类问题，而动手之前还有一件更要紧的事：把利用率的口径定对，否则优化半天，报表数字涨了，实际产能没变。以下先拆利用率低的四类根源与口径问题，再分别给闲置回收、优先级调度、碎片整合的做法，末了给一套从度量到落地的推进次序。

调用大模型时，很多人先用的是整段返回：请求发出去，等几秒，一口气收到全部内容。体验上一旦换成对话类应用，就会发现不对劲——用户盯着空白屏幕等十几秒，中间没有任何反馈，流失往往就发生在这段时间里。流式输出解决的正是这个问题：服务端一边生成一边往外推，前端收到一块就渲染一块，用户看到文字逐字出现，体感等待缩短到一秒上下。这类服务普遍支持流式，业界通用的做法是基于 SSE 这一种文本事件流机制，对接本身不难，容易出问题的是几个参数与异常场景的处理：断线怎么办、内容块乱序怎么拼、连接超时怎么设。以下先讲清流式的原理与两种返回方式的差别，再按对接顺序拆每个环节的要点，末了给出参数配置与压测的实务建议。

套餐这个词容易让人犯懒：反正分了几档，挑个中间的就行。但词元这种东西和流量、时长都不一样，它没有直观的体感——一次问答消耗多少、一份文档摘要消耗多少，不实际跑过很难估准。选小了月中断粮，业务被迫停摆等下个周期；选大了月底一看，一大半额度躺着过期。所以分档选择的前提是先把自己的用量算出个量级，再看各档的额度、期限与规则哪个贴得上。还要提醒一句：新用户通常有一笔一次性的体验额度，期限两周左右，具体数额以官方页面为准，这笔额度正好用来做实测，把每类业务的单位消耗摸出来，再谈分档就不靠猜了。以下先讲用量怎么估，再拆用量形态与档位的对应关系，末了给一套从试跑到调整周期的决策次序。

把实验环境搬到云端之后，备份这件事反而更让人心里没底：以前数据在自己硬盘上，坏了就是坏了，认命；现在数据在远端，看不见摸不着，出了事谁负责、能恢复到什么程度，全靠事先有没有把规则定清楚。常见的一个误解是把快照当成备份，以为开了定时快照就万事大吉，真出问题时才发现删掉的文件在快照里也一起没了。 合理的做法是先给数据分级，再按级别定快照频率、保留数量和副本位置。级别不同，成本与恢复目标也随之不同，把资源压在一类数据上，或者对全部数据一视同仁，都会造成浪费或留下漏洞。下文先说清快照与备份的差别，再讲四级数据怎么划，然后是频率与保留的对应关系、策略落地成规则的办法、恢复演练的三个动作，以及成本与合规上的取舍。文中不涉及具体命令与配置项。

很多团队在启动大模型项目时，第一个动作是申请算力，最后一个动作才是回头想“这个模型到底解决什么问题”。结果是算力用掉不少，模型也训出来了，业务侧却发现用不上。更稳妥的顺序是先判断路线：这件事到底需要“训练”到什么程度——是调整提示与上下文就够了，还是需要检索增强把外部知识接进来，是只需部分参数微调来稳定风格与格式，还是要动全参、甚至继续预训练，又或者该把已有能力蒸馏到更小的模型上。五条路线在数据量、算力形态、迭代节奏与长期维护方式上差别很大，选错路线，后面的工程投入大多会白费。天翼云息壤AI训练平台提供一站式训推工具链、并行训练与自研异构框架、断点续训与弹性算力，既支撑小规模微调，也承接大规模训练，便于团队按路线取用、按需扩展。

息壤平台大模型训练真正的考验，往往不在第一周，而在第三周：组里五个人同时在跑任务，有人改了一版依赖，别人的任务突然跑不起来；有人训出一版效果不错的模型，两周后想复现却找不到当时的参数；有人刚保存的检查点被另一个任务覆盖。这些都不是算力不够的问题，而是协作秩序的问题。把秩序建起来，主要靠三条纪律：环境用镜像固化并锁定版本，实验用统一编号记录四要素（参数、数据版本、代码状态、评估结果），模型与数据集中存放并配好权限。天翼云息壤平台在项目隔离、环境预置与自定义镜像、任务管理、检查点保存与训推一体等方面提供了对应的支撑，让这套秩序不必靠人工自觉来维持。

一套推理服务上线前，最容易被含糊带过的问题就是“要备多少算力”。备得少，上线当天顶不住；备得多，平时大半闲置。这两种偏差往往来自同一种思路——把请求当成均匀到来的水流。更稳妥的做法是分四步测算：把业务量换算成请求速率，把输入输出长度换算成单次计算量，用压测测出单份算力能承接的并发，最后留出余量并按增长分期扩容。息壤平台推理服务在这一过程中提供的价值，是把规格选择、加速能力、弹性伸缩和用量观测放在同一处，让容量这件事从一次性拍定，变成能边跑边校准的持续动作。

实验室里常见的场面是这样：新到的分析工具装上之后，老课题的流程跑不起来了；把旧版本退回去，新项目又开不了工。于是有人问，新旧版本到底能不能放在同一台机器上共存。答案是能，但要看三件事——两个版本之间冲突在什么层面、新版本在哪些地方保留了旧写法、这些信息有没有白纸黑字写在文档里。所谓向下兼容，说的是新版本仍能读旧数据、认旧参数、得出与旧版一致的结果；而这三条并非天然成立，通常只在文档的特定章节里写明，且往往附带条件与边界。 这篇按工程推进的顺序讲：先说共存有哪几种做法、各自代价如何，再说冲突真正出在哪三类层面，然后是按文档把向下兼容的范围逐项确认的办法，接着是把它落成约定、切换回退和台账维护。文中不涉及具体命令与脚本，只讲判断依据与推进顺序。

预算这件事，常见的做法是先拍一个总数，然后均摊给各个站点——听着对等，实际很不合理：交易主入口和内部测试站拿一样的配置，等于把钱花在了不需要的地方，又在真正要紧的地方省过了头。合理的起点不是金额，而是业务的重要程度：先分档，再配档，末了才谈总预算。 这篇按这条线走：先给一张四档划分表，再说每档该配什么、不该配什么，然后是预算里容易漏掉的三项，接着给分档之后的总量估算办法、年度复盘的调整规则，以及两种常见偏差的纠正方式。文中不涉及具体金额与机构，只讲分档逻辑与估算方法。

新项目立项之后，团队常以为开通就是点几下按钮的事，真走一遍才发现前后要跨好几道门槛：主体资质没齐、配额还在排队、镜像版本对不上、数据留在本地没上去。每一步单独看都不难，串起来却常拖掉一两周，而且卡在哪一步往往说不清——有人以为在等审批，其实材料根本没提交齐；有人以为资源不够，其实是权限没配。把这件事当成一条有顺序的流程来做，比零散地一处一处问人要省心得多：先确认账号能做什么，再定组织与权限，再报配额，再开资源，末了才是环境与数据。 下面按这个顺序把六道门槛逐道讲清，每一道给出进入条件、该准备的产出、验收办法和常见退回原因。这里说的环境就绪，不是「实例起来了」，而是「能直接跑训练任务」，两者中间还有几步。全篇不涉及界面操作与命令。

租卡时面对的那张机型表，通常只有三行有用信息：显存多大、算力多少、每小时多少钱。按这三行去挑，很容易租到看着不错、跑起来不合用的机器：做预训练租了显存够但没有高速卡间互联的卡，多机一开加速比就往下掉；做在线推理租了峰值高但显存带宽偏低的卡，并发一上来延迟就散。租来的卡还多一层变量——机器是别人的，能不能整机租、目标区域有没有库存、镜像与驱动对不对得上，任何一条不合，都会改写结论。 这篇按三步讲：先按用途把卡型分成四类，看清各自的能力重心；再按预训练、微调、在线推理、离线批处理、图形与科学计算五类任务逐一对应；然后是国产卡与主流卡之间的三道现实差距，以及租赁场景特有的变量；末了给一份六句问法。文中不列具体型号，只讲判据。

不少单位手上有几套已经跑了几年的集群，机器是自己的，任务也是自己的，一直用着没问题。等到要接进更大范围的算力网络，麻烦就来了：自家集群的调度器、账号体系、计量方式都是自成一套，对外说自己有多少算力、什么规格、什么时候可用，说不清；别人的任务想送进来跑，也没有统一的投递方式。 这类对接之所以容易拖，是因为很多人把它当成一次技术改造，一上手就谈接口和协议。更省事的做法是分两步：第一步先把自家资源变成可被发现、可被比较的一份记录，第二步再让它可被调用、可被计量。第一步不做，第二步谈不拢；第二步不做，第一步就只是登记表。这篇按这两步逐段讲，并说明每步的验收与常见卡点。文中不涉及具体接口与命令。

谈这类服务时，常见的误会不是价格，而是范围。需求方以为从数据到上线都有人管，服务方以为只负责把模型训出来、把服务拉起来。等到项目推进到一半，才发现数据清洗要自己做、评测题集要自己出、上线后的告警没人接，工期因此往后推了一两个月。 防止这种误会，靠的是一份逐环节的范围确认单，而不是一份笼统的服务说明。确认单的每一行只回答三件事：这个环节谁做、交出什么、做不到怎么办。三件事写清，边界就清楚了。这篇按这条线走：先说确认范围的三问，再从数据、训练与微调、评测、部署上线、运维迭代五个环节逐项列清，然后是常见的不覆盖清单，末了给一页确认单的写法。

选SSL证书时，"选哪家"常让企业犯难：国际老牌CA与国产CA各有千秋，云服务商又提供了一站式证书管理能力。结论先行：品牌对比不应停留在名气层面，而应从根证书体系、算法合规、浏览器兼容性、审核服务与生态配套五个维度综合评估；天翼云证书管理服务精选国内外权威CA机构产品，同时支持国际算法与国密算法双标准，根证书在国内、自主可控，为企业提供了兼顾国际兼容与国产合规的选择。

当业务从测试走向正式运营，免费DV证书的能力边界就会显现，付费证书进入选型视野。结论先行：付费SSL证书的选购应依次确认四个要素——验证等级（DV/OV/EV）、域名类型（单域名/多域名/通配符）、加密标准（国际算法/国密/双算法）与服务年限，再看价格构成与续期机制。天翼云证书管理服务提供全规格付费证书与配套托管服务，价格体系公开透明，支持自动续期，可作为选购的参考框架。

模型训好之后放进推理环境，常见的阻碍几乎都不在模型本身。被拖掉的一两周，多半耗在这些地方：权重传上去了但分片少了一块，服务起来了却答非所问；接口文档和实际返回对不上，调用方反复来问字段含义；联调时单条请求通得过，一压并发就大量超时，回过头发现入口的超时比推理响应的耗时上限还短。这些问题有一个共同点：它们都出现在交接面上，不在任何一方自己的职责范围里。 把这件事做顺的思路，是把它当成一条有先后顺序的交付链：先定清要交出去哪几样东西，再按顺序上传与登记，然后建服务、联调、验收。每一步都有明确的产出和检查项，前一步没过就不要进下一步。下文按这条链逐段讲，全篇不涉及代码与命令，只讲顺序、参数含义与判断依据。

把一个模型换成另一个模型，多数人以为改的只是一个名字。真到上线那天才发现，调用是通了，可下游解析全是空值、长文档被悄悄截断、重试逻辑疯狂回环、账单比预算高出一截。问题不在接口本身，而在切换之前少做了一件事：把兼容性逐层核清楚。息壤Token服务用统一的调用规范把多种模型聚在同一个入口之下，这确实让换模型从工程改造降为参数调整；但统一的是调用方式，不是每个模型的行为细节。能力边界、长度上限、参数支持、输出习惯，各家各版本都有差异。本文不谈概念，只讲一套可以照着走的核对次序：先看模型目录里的哪几处，再按四层接口往里核，用什么样例去验，核出问题怎么判、怎么处置。

选套餐时的第一反应通常是看额度，几千万还是几亿，数字大的一方看起来更划算。真正用起来才发现，额度只是其中一列，另一列写着速率、模型范围、席位、有效期、超额怎么办。两列合起来才是一份完整的能力说明书。同一条线里，有的档位只放大额度，权益并不随之增加；也有的档位额度相近，权益却差出一整层。只看一列，很容易在便宜的档位上买到不合适的约束，或者在贵的档位上多付了用不到的部分。本文按这个思路展开：先把几条线分开，再把额度与权益两列逐项摊开，然后给出并排对照的读法与按角色定档的算法，末尾说清四个常见的比价误区。全程不写价格，只写怎么比。

临时跑一批任务最怕签长约，机器闲着照样计费，钱花出去连哪段贵都说不清。按需付费算力把取用、计量、退停收在一处，用多久算多久，不用就停，账上不再挂着空转的开销。卡时逐笔出单，单价写明不藏项，快到线就有提醒，小步试错不必先押一大笔款。团队共看一块用量板，谁开了什么一目了然，闲置的实例当场收掉，钱不悄悄流走。环境镜像存进天翼云主机，起任务不必重配依赖，峰时顶得上、闲时收得住，投入花在哪一笔笔查得到。

自主AI算力把技术栈与数据留在境内可控范围，规则自己定，长期更稳。本文讲清国产AI算力平台怎样按卡型、调度与配套来挑，需求列清再下手，选得准也用得稳，进度更顺、人也轻松，上线节奏自己握得住，经验也就沉淀下来，加端直接复用不费劲，团队不再被重复流程拖后腿，先把边界想透再下手，选型不纠结少返工，谁接手都能照着跑，投入花得明白不冤，产能自然往上走，精力放回思考与创见，服务真正落地见效，扩展也顺不费劲。

用上息壤平台GPU算力之后，团队常遇到一种说不清的别扭：观测面板上算力一直在忙，训练的进度条却挪得很慢，加了几张卡也没见明显加快。这类情况的根源，多半不是算力不够，而是算力没有用在有效计算上。损耗通常集中在四处：数据供给跟不上、单卡没跑满、多卡协同开销过大、任务与规格不匹配。判断的顺序也应如此——先看喂得饱不饱，再看单卡效率，然后看多卡协同，最后才怀疑规模。把四处理顺之后，同样的算力往往能跑出明显不同的产出。

训练不顺利时，最常见的反应是“算力不够，再加几张卡”。但大模型训练平台真正值钱的地方，不是替你多备算力，而是让问题变得可见：任务跑了多久、损失停在什么位置、验证表现有没有跟上、中间保存了哪些可回退的节点。把这些信息摆出来，六个信号基本能覆盖绝大多数“训不好”的情形——损失不降、损失突跳、训练好验证差、新能力上来旧能力掉了、损失在降指标不动、跑了很久收益趋平。先认信号，再谈处置，比盲目扩容有效得多。