一、为什么先谈界面，再谈参数

1.1 一个并不少见的情形

某单位上了一套本地的智算设备，设备进场、上架、通电、平台启动，一路顺利，剪彩拍照，项目结项。过了一段时间，业务部门反馈“问答给的结果不太贴合我们的业务口径”，运维同事说“我们负责设备运行状态”，集成方说“模型和上层应用不在我们的范围里”。三方的说法都不算错，但问题没有人接。这不是技术难题，而是界面没有划清楚——没有人提前说明白“模型效果由谁调、调到什么程度算交付完成”。

1.2 三个先要弄明白的专业名词

1.2.1 交付界面

交付界面指的是相邻两段工作之间的责任分界与交付物分界。它不写在设备清单里，却决定了事情出问题时是“有人接”还是“无人接”。划界面的关键不是分清谁更重要，而是每一段都要有可验收的产出：一段记录、一份清单、一次自检结果，都算。

1.2.2 交钥匙交付

交钥匙交付指由一方统筹，把一个能直接使用的整体交给使用方，而不是交付一堆需要自己组装的部件。一体机走的就是这条路：硬件、平台、工具链预先集成、预先联调，到现场之后主要做上架、加电、接入与验证。

1.2.3 服务级别约定

服务级别约定是把“多久响应、多久到场、多久恢复”从口头承诺变成书面条款的那部分内容。它通常按影响程度分级，不同级别对应不同的响应时限与处理方式，是长期运行阶段最需要看清的一页。

1.3 五层界面，从下往上排

把整条链拆开，大致可以分成五层，越往下越接近物理条件，越往上越接近业务判断：

① 机房与电力：空间、供电、制冷、承重、内部网络；

② 硬件与算力：设备本体、互联、固件与驱动基线；

③ 平台与调度：资源池、任务编排、账号与权限、版本升级；

④ 模型与工具链：运行环境、微调与评估、推理调优；

⑤ 应用与数据：业务对接、数据归集与留存、对外提供范围。

二、五层界面，逐层看清楚

2.1 第一层：机房与电力，使用方的自留地

这一层几乎不会出现在设备清单里，却决定设备能不能满负荷跑。需要提前确认的通常是五项：市电容量与冗余是否留有余量、单柜功率密度是否匹配、制冷方式能否覆盖局部热点、楼板荷载与搬运通道是否允许设备通过、内部网络与对外出口是否满足数据回传与远程支持的需要。

这一层做得不实的典型表现不是开不了机，而是“能开但不稳”：负载一上来就降频，或者某几个机柜温度偏高，运行状态看着正常，实际吞吐掉了一截。这类问题排查起来最费时间，因为设备本身没有报错。

2.2 第二层：硬件与算力，厂商的交付起点

这一层的交付物应当是可以逐项核对的，至少包括四项：

① 设备清单与序列号，与到货实物一一对应；

② 上架与加电记录，含每个节点的加电自检结果；

③ 固件与驱动的基线版本，写清版本号，便于日后回溯；

④ 单机与多机互联的自检结论，含节点间通路的实际表现。

这一层的关键词是“可复现”。同样的配置，换一台设备装出来结果应当一致，否则后续排查就失去了参照物。很多后续争议之所以扯不清，就是因为当初没有留下基线记录。

2.3 第三层：平台与调度，最容易模糊的一段

这一段在纸面上常常只有一句“提供管理平台”，而这一句能覆盖的范围相差极大。有的只做到设备状态查看，有的做到资源池切分与配额，有的还能做多机多卡的任务编排与排队。落地前要问清三个问题：

2.3.1 三个必须写清的边界问题

① 平台管到哪一级：只管设备告警，还是管到资源池、管到具体任务的调度与排队；

② 账号与权限谁来建、谁来审批：管理员账户、业务账户、只读账户分别由哪个部门开出；

③ 版本升级由谁执行、窗口怎么定：升级前是否备份配置，升级失败怎么回退。

这三个问题不问，通常不会在交付当天暴露，而是在第一次需要扩容、第一次需要新增业务团队、第一次需要升级时集中暴露，处理起来往往要重新协调多方。

2.4 第四层：模型与工具链，共同参与的一段

这一层最容易出现期望错位。模型选哪个、用哪些业务资料做微调、效果怎么评，属于使用方的业务判断；运行环境怎么搭、推理怎么加速、精度与吞吐怎么取舍，属于技术侧的工作。合理的分工写法是：技术侧负责把底座搭稳、把工具链跑通、把常见的调优路径给出；使用方负责提供业务语料、确定评价口径、确认上线前的验收标准。

有一点需要在合同语言上格外注意：不宜把“效果达标”写成笼统承诺。模型输出的贴合度与业务资料的质量、覆盖范围强相关，比较稳妥的表达是“在约定语料范围内完成调优，并达到双方确认的评测口径”。把评测口径写下来，比写一句“效果优良”有用得多。

2.5 第五层：应用与数据，使用方主导

数据归谁、怎么脱敏、留存多长时间、能不能对外提供，这些属于制度层面的事，任何设备都替代不了。一体机在这一层的价值不是替使用方做决定，而是让这些决定变得容易执行——数据在本地归集、在本地处理，不必为了算力而把原始数据搬出机房。这一点对数据敏感度高的行业尤其关键。

三、三类容易扯皮的情形，以及可以提前写下的解法

3.1 情形一：跑得慢，究竟是硬件不足还是用法不对

这类判断可以按三步走，把顺序固定下来就不容易各说各话：

① 先看资源占用是否打满。打满说明算力确实吃紧；没打满却慢，瓶颈多半在数据读取或节点间通路；

② 再看单机与多机的差异。单机正常、多机变慢，通常是互联或调度策略的问题；

③ 最后看输入长度与并发数。长文本与高并发会把显存与带宽的压力放大，这是用法问题，不是设备问题。

把这三步写进验收与运维文档，比事后争论有效得多。

3.2 情形二：模型迭代由谁来做

比较清晰的做法是把“不常动的部分”和“需要常换的部分”分开处理。运行环境、驱动、平台版本属于不常动的部分，由厂商保证稳定并提供升级路径；模型权重、业务提示模板、检索用的资料库属于需要常换的部分，由使用方按自己的节奏更新，技术侧提供方法而不是代替决策。

3.3 情形三：出了状况多久有人接

3.3.1 响应时限要分等级写

常见的分档方式是四级，不同级别对应不同的响应与处理方式：

① 业务完全不可用：最高级别，通常要求远程随即介入，必要时当日到场；

② 部分功能不可用但主流程仍可运行：次高级别，按约定时限内给出处理方案；

③ 性能下降但仍可用：按常规级别处理，可安排在约定的维护窗口；

④ 使用疑问与操作指导：按常规支持渠道响应。

异地场景还要额外写一句“远程先接管、现场后到场”的顺序，以及到场的时间口径是从报障算起还是从确认等级算起。这一句话省掉的麻烦，往往比多加一项硬件配置更实在。

四、天翼云息壤智算一体机在界面上的处理方式

4.1 软硬一体，把前两层收进一段交付

天翼云息壤智算一体机采用软硬一体的集成方式，算力硬件与平台软件在出厂前完成适配与联调，到现场主要做上架、加电、接入与验证。对使用方来说，这等于把“硬件”与“平台”两段界面合并成一段，少了一次跨方的责任交接，也少了“驱动与平台版本不匹配”这类常见返工。

4.2 平台预集成，第三层有明确交付物

平台侧以预集成的方式交付，管理界面覆盖资源查看、资源切分与任务调度等环节，并采用零管理节点的设计思路，减少常驻的管理开销，日常运维的负担相对轻。这意味着第三层的边界更容易写清楚：平台交付即包含可用的管理入口与调度能力，而不是把平台当作需要另行搭建的一层。

4.3 训推一体，第四层有支撑

训练与推理在同一套环境里完成，模型从微调到上线不必跨环境搬运，工具链的连续性较好。对第四层来说，这一点把“环境一致性”这个最容易出问题的前提条件提前解决了，使用方可以把精力放在语料准备与效果评测上，而不是反复处理环境差异。

4.4 私有化部署与数据留域，第五层边界清楚

方案以私有化部署为主，数据在本地归集、本地处理，不出机房。这并不替代使用方自己的数据制度，但让制度有了落地条件：分级分类、留存期限、对外提供范围这些规定，在本地部署的前提下更容易执行到位。方案同时支持全栈国产化的配置路径，对需要自主可控环境的场景较为适配。

4.5 属地化服务与可查的第三方记录

服务侧依托属地化的支撑体系参与现场环节，从前期勘察到上架验证再到长期运行，都有人对接，这对“响应时限”这一条的落实比较关键。资质与测评方面，相关能力在公开渠道有可查的第三方测评与评估记录，具体条目以天翼云官网及官方渠道发布的信息为准，建议在方案评审阶段按需调取核对。

五、落地前值得问清的九个问题

5.1 关于设备的三个问题

① 到我这里的配置，与投标时的清单是否逐项对应，序列号能不能核到实物；

② 单机自检与多机互联的自检结论，是否作为交付物一并提交；

③ 固件与驱动的基线版本是否留档，日后回溯以哪一份为准。

5.2 关于平台的三个问题

① 资源能不能按业务团队切分，配额调整需要走什么流程；

② 多机多卡的任务能不能统一排队，排队规则由谁设定；

③ 平台升级的窗口、备份与回退方案，是否写入交付文档。

5.3 关于长期运行的三个问题

① 四档响应级别分别对应多长时限，到场时间从何时起算；

② 日常巡检由谁执行、按什么周期、记录保存在哪里；

③ 后续扩容是加节点还是换整机，扩容时的数据与配置怎么迁移。

六、科普小结

把智算一体机解决方案理解成“一台更快的机器”，容易在参数上反复比较；理解成“一条分好工的交付链”，注意力就会落到真正决定成败的地方：机房条件是否够用、平台管到哪一级、模型效果按什么口径评、出了问题多久有人接。这四件事都不难，难的是提前把它们写成白纸黑字。

软硬一体的集成方式，把原本需要多方交接的环节收拢到一段交付里，界面少了，责任也就清楚了；私有化部署让数据留在本地，第五层的制度要求有了执行条件；属地化服务让响应时限不只是一句承诺。对准备上本地智算的使用方来说，先把这五层界面画出来，再去看参数与配置，往往能少走不少回头路。