企业官网建设流程全解析

跑一个中等规模的参数扫描模型，从晚上十点挂到凌晨三点，机器风扇转了五个小时，第二天早上打开结果文件发现参数网格少填了一格——这种经历我猜做过数值仿真、建模仿真或者数据处理的人都不陌生。也正因为被这么折腾过几回，我才下决心把手上那套"加速模型速算工具"整理成一套固定的组合拳：全是免费、可离线部署、不依赖任何付费授权的方案，核心就干一件事——把原本要跑几个小时的模型求解压到几十分钟甚至几分钟。这篇分享讲的就是这套工具的构成、每一层加速为什么这么选、改造的具体步骤，以及我在实测里踩到的那些"看起来加了速、其实更慢了"的坑。适合手上有自己写的求解脚本、被运行时间拖得没脾气的同学，也适合刚接触数值计算、想知道性能该从哪下手的初学者——不需要你懂编译原理，跟着改就行。

1. 先把时钟掰开看：模型到底慢在哪一段

1.1 一次跑了一夜的仿真，时间都花在哪儿

我最开始的做法非常朴素：模型能跑通就万事大吉，慢就慢点，反正挂着过夜。直到有一次要做敏感性分析，参数组合一下从十几个膨胀到两千多个，单次求解从四十秒涨到四十秒乘两千，算下来要一天多。那时候我才意识到，"慢"不是一个笼统的感觉，它是有结构的——一次完整运行的时间，大致可以切成三块：纯计算时间（真正在做浮点运算、矩阵乘法、迭代求解）、数据搬运时间（读写数组、在内存和缓存之间倒腾、序列化落盘）、调度与解释开销（语言解释器逐行解析、函数调用、循环控制、进程间通信）。

这三块的性质完全不同，优化手段也完全不同。纯计算靠向量化和编译优化；数据搬运靠减少拷贝、改数据结构、提高缓存命中；调度开销靠减少函数调用层数、批量处理。很多人一上来就换更快的机器或者加载 GPU，结果模型里 60% 的时间其实花在 Python 的 for 循环解释和 pandas 逐行 apply 上，换什么硬件都没用。我后来养成一个习惯：任何优化动作之前，先用计时器把这三块的比例量出来，比例明确之前不动手。这个习惯至少帮我省下了三次白折腾。

1.2 计算密集、搬运密集、调度密集：三类瓶颈的判别方法

判别方法其实不难，不用专业工具也能做粗筛。我的做法是：先把模型里最可疑的那段循环单独抠出来，喂一个极小的输入（比如 10 个样本），记录耗时；再喂一个 10 倍大小的输入，再记录。如果耗时接近线性甚至超线性增长，那基本是计算密集；如果耗时增长不明显、大头在固定开销上，那是调度密集；如果耗时增长跟规模关系不大但内存占用蹭蹭涨，大概率是搬运密集。

再补一个土办法：跑的时候开着系统资源监视，看两个指标——CPU 单核是不是跑满、内存带宽相关指标是不是接近上限。如果只有一个核心满载而其他核心闲着，说明你没用上并行，属于白白浪费算力；如果所有核心都没满但整体就是慢，那很可能卡在 I/O 或者进程调度上。我第一次拆解自己的模型时发现，单次求解里有将近三分之一的时间是在反复读取同一个静态查找表——那张表只有几兆，完全可以在启动时读一次缓存住。改完之后什么都没换，时间直接掉了一截。这就是先测量再动手的价值：你以为的瓶颈和真实的瓶颈，经常不是同一个。

1.3 加速比的天花板：Amdahl 定律给出的硬约束

这一节可能有点扫兴，但我必须写，因为它能帮你避免大量无效工作。加速比是有理论上限的，这个上限由可并行部分占总耗时的比例决定。公式很朴素：设可并行部分占比为 p，并行度为 n，则整体加速比 S = 1 / ((1 - p) + p / n)。

拿具体数字算一下。假设你的模型里有 90% 的计算可以完美并行，你上了 8 核：S = 1 / (0.1 + 0.9/8) = 1 / (0.1 + 0.1125) = 1 / 0.2125 ≈ 4.7 倍。注意，你用了 8 倍的核，只拿到 4.7 倍加速——剩下那 10% 的串行部分在死死压着你。如果可并行比例降到 70%，8 核的加速比只有 1/(0.3+0.0875) ≈ 2.58 倍。反过来推，如果你已经用了 8 核却只快了 2.5 倍，那就说明你的代码里大概有 30% 是串行的，再怎么加核也没用，得先去啃那 30%。

我用这个公式给自己定过一条规矩：先把串行部分压到 15% 以下，再考虑堆核心数。串行部分包括模型初始化、结果汇总、文件写入、参数校验这些"看起来不重要"的环节，实际在长时间仿真里它们串起来能占总时间的两成以上。有个很典型的例子：我的模型每次运行结束要写一个几百兆的结果文件，写盘时间是串行的，五秒左右。单次求解四十秒时这点时间不算什么，但当我把计算部分优化到八秒后，这五秒就变成了总时间的近四成——优化越到后面，越要回头收拾那些原本不起眼的串行尾巴。

2. 免费方案的工具组合与选型依据

2.1 单机路线第一层：数组化计算与即时编译

我用的第一层加速工具是**数组化计算库加即时编译（JIT）**的组合。数组化计算库的作用是把"逐元素循环"变成"整块内存上的批量运算"，底层走的是高度优化过的线性代数例程，而且能自动利用 CPU 的向量指令集。举个直观的例子：对一百万个元素逐个做乘法并累加，纯解释执行的循环要几百毫秒，换成数组运算通常只要几毫秒——差两个数量级，而且你一行代码都不用优化，只是写法变了。

即时编译则是针对那些"实在没法数组化"的部分——含有复杂条件分支、递推依赖、循环间数据耦合的逻辑，数组化写起来极其别扭或者干脆写不出来。JIT 的思路是：你在函数上加个装饰器，第一次调用时它把这段代码编译成机器码，之后每次调用都直接跑机器码，跳过了逐行解释。我实测过一段带三层嵌套循环的粒子位置更新，纯解释执行单次 1.8 秒，JIT 编译后 0.03 秒，六十倍。这两个工具加起来，覆盖了我模型里八成以上的纯计算瓶颈，而且完全免费、纯本地运行、无网络依赖。

选它们而不选别的，理由有三：一是改造成本低，不用重写整个工程，一处一处换过去就行；二是结果可控，数组运算和编译后的代码跟原逻辑是一一对应的，不容易引入语义偏差；三是没有授权与联网风险，纯离线，跑在什么机器上都一样。相比之下，那些需要额外运行环境、需要许可证服务器、跑起来还要联网校验的方案，我在实验室的老机器上吃过太多次亏，能不用就不用。

2.2 单机路线第二层：多进程与任务分块

数组化和 JIT 解决的是"单次计算更快"，多进程解决的是"多次计算同时做"。这两件事是正交的，必须都做。我的模型典型形态是参数扫描：几千组参数，每组独立求解一次，组与组之间没有任何数据依赖。这种结构简直就是为并行而生的，但很多人写的还是一个大 for 循环顺着跑，一个核累死，其它核看戏。

这里的选型有个关键分岔：多线程还是多进程。我踩过的教训是，在解释型语言里做数值计算，多线程往往拿不到预期收益，因为存在全局解释器锁——同一时刻只有一个线程在执行字节码，你的多线程实际上还是在排队。而数组运算库内部释放了这把锁，所以纯数组运算多线程有效，但你自己的循环逻辑多线程基本无效。结论很干脆：自己写的循环用多进程，库函数内部的运算交给它自己调度。

多进程的实现我用的是进程池加分块：把参数列表切成若干块，每块交给一个工作进程，进程数取物理核心数（注意是物理核心，不是逻辑线程数，超线程在计算密集场景下收益很小甚至为负）。这里有个容易忽略的细节：分块大小要显著大于调度开销。如果每个任务只有几毫秒，而进程间传递数据要几毫秒，那你就是在做无用功。我一般的经验值是单块任务至少跑半秒以上，块数略多于进程数（比如进程数乘 2 到 4），这样能起到负载均衡的作用，避免某个慢任务拖住整体。

2.3 什么情况下才值得上 GPU 与推理引擎

GPU 这块我得泼点冷水。它的优势是海量并行的小核心，适合规整的大矩阵运算；它的劣势是启动开销大、数据传输慢、显存有限、代码改造量大。我见过太多人一上来就上 GPU，结果模型里有大量条件分支和小规模循环，GPU 上跑得比 CPU 还慢——因为分支发散会让大量核心空转，而每次把数据从主存搬到显存的开销，在小规模计算下完全盖过了收益。

我自己的判断标准是三条，全部满足才考虑：单次计算的核心运算能被表达成大规模规整的矩阵或张量操作（比如批量矩阵乘、卷积、大规模元素级运算）；单次计算的数据量足够大（我一般以"单次运算耗时超过 100 毫秒"为界，低于这个量级搬运开销压不住）；同一份数据要反复参与计算（这样搬运一次可以摊薄）。三条里有一条不满足，我就老老实实待在 CPU 上。

至于推理引擎类工具，它们主要针对已经训练好的模型做部署端加速，核心手段是算子融合、量化压缩、内存复用。如果你的"模型速算"指的是跑现成的神经网络推理，那这类工具确实值得花时间——我实测过一个中等规模的图像分类网络，经过算子融合和半精度量化后，单张推理从 40 毫秒降到 9 毫秒，四倍多，而精度掉不到 0.5 个百分点。但如果你的模型是自己写的数值求解器，这类工具帮不上忙，别浪费时间。

2.4 一张选型对照表

这张表是我自己项目里反复验证出来的经验区间，不是理论值，你的场景可能有出入，但数量级上应该有参考价值。特别提醒最后一行：任何涉及精度压缩的手段，必须建立精度回归的比对样本，改完之后拿一批固定输入跑新旧两版，逐项比对的不仅仅是最终指标，还有中间关键量的偏差。这一步我省略过一次，结果模型精度掉了两个百分点，直到三天后做结果分析才发现，前面所有实验全部作废。

3. 改造实操：四步把原始代码推到提速版本

3.1 第一步永远是测量：给模型装一个计时器

动手前先给自己的模型装一套最小可用的计时装置。我用的是标准库里的高精度计时器，在两个位置打点：整体运行的首尾，以及每个主要阶段（数据加载、预处理、核心求解、结果汇总、落盘）的首尾。这一步的代码量不到二十行，但它是后面所有决策的依据。

import time from contextlib import contextmanager @contextmanager def timer(label, records): start = time.perf_counter() try: yield finally: cost = time.perf_counter() - start records.setdefault(label, []).append(cost) records = {} with timer("load", records): data = load_input("input.dat") with timer("solve", records): result = solve(data) with timer("save", records): save_output(result, "out.dat") total = sum(sum(v) for v in records.values()) for k, v in records.items(): print(f"{k:8s} {sum(v):8.3f}s {sum(v)/total:6.1%}")

几个实操细节值得说清楚。用高精度计时器而不是普通的时间戳，前者精度到纳秒级，后者在很多平台上只有十几毫秒的粒度，测小段代码完全没意义。不要用"算一次总时间然后除以次数"的方式估单次耗时，误差会被放大，而且你根本不知道时间花在哪一段。记录要落地成文件而不是只打印，我一般存成一份简单的表格，跑完一批实验后回看，能立刻定位到底是哪个阶段在随参数变化而膨胀。

还有一点：测量本身有开销，perf_counter单次调用是微秒量级，如果你的循环体本身只有几微秒，那测量就会严重失真。这种情况下不要在每个迭代里打点，改成在批次边界打点。我吃过这个亏——曾经在千万次迭代的内层循环里加计时，结果程序慢了四倍，测出来的全是计时器自己的耗时。

3.2 第二步：把 for 循环换成数组运算

这是收益最高、风险也最需要控制的一步。基本思路是把"对每个元素做同样的操作"改写成"对整个数组做一次操作"。但要注意一个反直觉的坑：不是所有循环都值得数组化。如果你的循环体里有明显的跨迭代依赖（第 i 次的结果是第 i+1 次的输入），那强行数组化会写出极其扭曲的代码，收益还不一定好。这种情况直接跳到 JIT 编译更划算。

数组化里最容易踩的雷是隐式生成大临时数组。比如一个表达式里连续做四五次整数组运算，中间每次都会生成一个新的完整大小的临时数组，内存峰值可能翻好几倍，反而把时间花在了内存分配和回收上。我的处理办法是拆开写，中间结果复用预先分配好的缓冲区，用out=参数把结果直接写进已有数组。这一招在数组规模超过几百兆时效果非常明显，我有一次光靠这个改动就把某段处理从 12 秒压到 4 秒。

另一个细节是数据类型。默认的浮点类型往往是双精度，如果你的模型对精度要求没那么苛刻，改成单精度能直接把数据搬运量减半，数组运算速度通常也能提升接近一倍。但这一步要谨慎，尤其是在做迭代求解或者累加求和时，单精度的舍入误差在长链条计算里会累积。我的做法是：用双精度跑一遍得到基准结果，再用单精度跑，逐项比对相对误差，误差在可接受范围内才切换，并且把比对样本存下来，以后每次改代码都跑一遍。

3.3 第三步：JIT 编译落地，类型标注与首次编译开销

对于那些实在没法数组化的部分，JIT 编译是性价比最高的选择。核心用法就是在函数上加装饰器，然后给所有参数和中间变量一个明确的类型——这一点很关键，编译器需要靠类型信息做优化，类型不明确它会退化甚至编译失败。

import numpy as np from numba import njit @njit(cache=True) def update_particles(pos, vel, dt, steps): n = pos.shape[0] for s in range(steps): for i in range(n): # 跨迭代依赖的递推逻辑，不适合数组化 v = vel[i] + dt * force(pos[i]) vel[i] = v pos[i] = pos[i] + v * dt return pos, vel

这里有三个经验点。第一，首次调用有编译开销，通常是零点几秒到几秒，取决于函数复杂度。这意味着如果你只调用一次，JIT 反而更慢。解决办法有两个：一是加cache=True让编译产物落到磁盘，下次启动直接加载；二是在正式计时前先拿小输入跑一次做预热，把编译时间排除在统计之外。第二，循环里的写法要"朴素"，编译器对简单的数值循环优化得最好，一旦你调用了不支持的库函数，它要么报错要么悄悄退化成慢路径。编译器的静默退化是最坑的，你的代码能跑，但根本没提速，所以每次改完必须重新测时间，不能想当然。第三，函数边界会影响优化效果，小函数被内联后优化更彻底，但拆得太碎也会增加编译时间和调用开销，我的经验是单次调用耗时超过一微秒的逻辑才值得单独开一个编译函数。

3.4 第四步：多进程与数据分块，把核用满

最后一层是把互相独立的计算任务摊到多个核上。我用的是标准库的进程池加数组分块，结构非常固定：

import numpy as np from multiprocessing import Pool def solve_one(param_chunk): return [solve_model(p) for p in param_chunk] if __name__ == "__main__": params = generate_param_grid() n_proc = 8 # 取物理核心数 n_chunk = n_proc * 3 # 块数略多于进程数，做负载均衡 chunks = np.array_split(params, n_chunk) with Pool(n_proc) as pool: results = pool.map(solve_one, [list(c) for c in chunks]) results = [r for chunk in results for r in chunk]

几个必须注意的地方。入口保护一定要有，就是那个if __name__ == "__main__":，没有它在某些平台上会无限递归创建进程，直接把机器拖死——这个坑我第一次写多进程时踩得结结实实。传给子进程的数据要尽量小，进程间通信靠序列化，传一个几百兆的数组过去，光拷贝就够你等的。正确做法是让每个子进程自己读数据，或者用共享内存。结果汇总的顺序要跟参数顺序对齐，map会保持输入顺序，但如果你用异步方式提交就要自己管理顺序，我曾经因为顺序错位把两组实验的结论搞反了，白写了一整段分析。

还有一个隐性开销容易被忽略：进程启动本身有成本，每个进程初始化环境、加载库、导入模块，加起来可能是几百毫秒。如果你的任务总量只有几秒，那多进程反而更慢。判断标准很简单：串行跑一遍的总时间，除以进程数，如果结果小于一秒，就别上多进程了，先想办法把单次任务本身优化快，或者把多个小任务打包成一个批次再做并行。

4. 亲测踩坑：让加速彻底失效的那几个细节

4.1 首次运行反而更慢：编译与预热开销

改完代码兴冲冲跑第一遍，结果比原来还慢——这是最常见的挫败时刻，也是很多人放弃加速的原因。原因是第一次调用时编译器在工作，或者库在初始化各种内部结构。这不是你的代码有问题，是测量方式有问题。

我的处理办法是固定三步：预热、清空、计时。先用一个小输入调用一次目标函数（触发编译和初始化），然后把计时器重置，再跑正式的那一次。如果用了磁盘缓存，还要确认缓存确实命中——我遇到过一次缓存因为函数签名带了匿名类型而每次都重新编译，等于白加。一个稳定的判断方法是连续跑三次，看第一次和后面两次的耗时差，如果差距超过 20%，说明预热没做干净。

顺便说一句"2023-10-23 更新"这类版本记录的重要性。这套工具组合我维护了一年多，中间因为某个依赖库的小版本升级，某段编译函数的性能掉了将近一半，而我完全没有察觉，直到某次批量实验跑了两天才发现不对劲。从那以后我在脚本里加了一行环境打印：把关键库的版本号在每次运行的日志开头写出来。这样一旦性能有异常波动，回头对日志就能立刻定位到是不是版本变化导致的。这个习惯看起来笨，但真的救命。

4.2 多进程把小任务拖垮：调度开销吃掉全部收益

第二个大坑是把并行用在了不该用的地方。我有个预处理步骤，每个任务大概 8 毫秒，一共有两万个小任务，我兴冲冲地开了 16 个进程，结果总时间从串行的 160 秒变成并行的 420 秒——慢了将近三倍。原因很清楚：每个任务的调度、序列化、进程间通信加起来的开销，远超任务本身。

修复思路有两层。第一层是批量化：把两万个小任务打包成几百个批次，每个批次内部串行跑，批次之间并行。这样进程通信的次数下降两个数量级，收益立刻回来。第二层是判据化：我后来给自己定了一条硬规则，直接写在代码注释里——单任务耗时低于 50 毫秒的，一律先打包再并行。这条规则帮我省了很多次无谓的尝试。

顺带说一个相关的坑：进程数不等于越快越好。在内存受限的场景下，进程数开太多会导致频繁的换页，性能断崖式下降。我的经验是进程数从物理核心数开始试，如果加进程后总时间不降反升，就是内存带宽或者容量到顶了，赶紧退回去。这也呼应了前面 Amdahl 定律的结论：资源不是无限堆就有收益的。

4.3 内存带宽成为新瓶颈：算得快了，搬不动了

这是优化到后期才会遇到的坑，但一旦遇上就很难受。你把计算部分优化得很好，CPU 利用率看起来很漂亮，但总时间就是下不去——因为瓶颈从"算"转移到了"搬"。数组运算的本质是在内存上做批量操作，数据规模一大，内存带宽就成了硬上限，再怎么优化指令都没用。

判断方法：如果数组规模翻倍、耗时也几乎翻倍，而 CPU 占用率并不高，那基本就是带宽受限。对策有三条，我按优先级用：一是改数据布局，让访问模式变成连续的顺序访问而不是跳跃访问，缓存命中率能差出好几倍；二是减少中间数组，能原地操作就原地操作，能复用缓冲区就复用；三是分块处理，把大数组切成能塞进缓存的小块，逐块处理完再进下一块。第三条我用得最多，某次把一个几百兆的矩阵运算按缓存大小分块后，耗时从 30 秒降到 11 秒，代码只多了一个循环。

4.4 浮点精度与结果漂移：提速之后答案变了

这是最危险的一类坑，因为程序不报错、能跑完、结果看起来也"合理"，但就是跟原来不一样。加速手段本身可能改变浮点运算的顺序——数组化的求和顺序跟逐个累加不同，编译器的优化可能重排运算、使用融合乘加指令，并行归约的结合顺序也不一样。浮点加法不满足结合律，顺序一变，末位就可能不同。在迭代成百上千次的模型里，这点微小的差异会被放大，最终结果偏离几个百分点完全可能。

我的应对是建立一套固定的回归样本：挑十到二十组有代表性的输入，跑原始版本存下结果，之后每次改代码都跑一遍对比，看最大相对偏差和关键中间量的偏差。偏差在机器的浮点误差量级（1e-12 相对误差）就放过；偏大到 1e-6 以上就要搞清楚原因；如果影响最终结论，宁可放弃这个优化。千万不要因为"看起来差不多"就跳过这一步，我见过的最惨案例是优化后某组边界参数下模型直接不收敛，而那次批量实验已经跑了整整两天。

4.5 排查清单：症状与对应方向

这张表我贴在项目目录的说明文件里，每次遇到异常先扫一遍，大部分问题能在十分钟内定位到方向，不用从头猜。

5. 让提速成果可复用：开关化、缓存与记录

5.1 把加速做成开关，而不是推倒重来

我最初的改造方式很粗暴：直接把原代码改掉。结果第一次出问题时就麻烦了——想退回旧版本跑一遍对照，得去翻备份。后来我改成开关式改造：所有加速手段都通过配置项控制，单进程还是多进程、是否启用编译、是否启用缓存，全部是一行配置就能切换的。

这么做的好处很实在。第一，任何时候都能跑出"基准版本"的结果做对照，这比翻备份可靠得多。第二，出问题时能快速二分定位——把开关逐个关掉，看性能在哪一层掉的，比读代码猜快十倍。第三，不同机器上可以用不同配置：实验室那台老机器只有四核，我的笔记本有更多核，配置项一改就能跑，不用维护两套代码。具体实现上，我会写一个统一的入口函数，读一份配置字典，然后按配置组装计算流程。代码不多，但可维护性提升非常明显。

这里还有一个细节值得说：开关的默认值要选"正确优先"而不是"快优先"。我踩过一次坑，默认开了单精度和并行，结果新来的同学直接拿去跑正式实验，跑完才发现精度不够要重跑。正确的做法是默认走最稳妥的路径，需要提速的时候显式打开，让人有意识地做选择。

5.2 结果缓存与断点续算：别让一次中断毁掉整批实验

参数扫描最怕的就是跑到 90% 的时候机器被重启或者进程被意外终止。我之前被这个坑过两次，每次都是几个小时的损失。后来我加了两层保险。

第一层是结果缓存，每组参数算完立刻把结果落盘成一个小文件，文件名用参数的哈希值来命名。这样重跑的时候先检查文件存不存在，存在就直接读，跳过计算。实现起来非常轻量，但收益巨大——我有一次实验跑到第 1500 组时挂了，重启后只用了十分钟就把前面的全"读"回来了。

第二层是单次运行的中间状态存档，针对那种单次就要跑很久的模型。做法是在迭代循环里每隔若干步把当前状态序列化落盘，重启时从最近的存档继续。这里有个取舍：存档太频繁会拖慢主流程，太稀疏又浪费重算时间。我的经验是让存档开销控制在总时间的 1% 以内，通常对应每几十秒存一次。

缓存还带来一个额外好处：便于增量对比。当你改了一小段代码，只需要重算受影响的参数组，其余的读缓存即可，验证周期从小时级降到分钟级。这个效率提升对调试阶段的价值，甚至超过加速本身。

5.3 环境与版本的完整记录

最后这条听起来最不像"加速"，但它是所有加速成果能被长期信任的前提。我现在的每个项目目录下都有一份环境记录：运行环境版本、关键依赖版本、关键配置项、以及这份配置下基准测试的耗时。每次改动后追加一行。这份记录让我能在几个月后回来看时，清楚知道"当时这个十秒是怎么跑出来的"。

为什么强调这个？因为性能是个非常脆弱的东西。依赖库一次小版本更新、操作系统一次调度策略调整、甚至机器换了个散热状态导致频率策略变化，都可能让性能悄悄退化。没有基线记录，你根本发现不了。有一次我发现某段代码比半年前慢了三成，翻了记录才确认是某次依赖升级导致的，退回旧版本立刻恢复。如果没有那份记录，我大概会花好几天去怀疑自己的代码。

顺便说，把基准测试脚本本身也纳入版本管理。我写了一个极简的测试入口，固定输入、固定参数、跑三次取中位数、输出一行结果。每次提交代码前跑一次，三十秒的事，但能挡住绝大多数性能回退。这个习惯坚持下来之后，我这套工具组合在一年多的时间里性能一直稳在预期区间内，没有出现过那种"某天突然发现怎么变慢了"的情况。

我个人在实际操作中的体会是，所谓"加速模型速算"，真正见效快的从来不是某个神奇的工具，而是先测后改、逐层验证、把结论固化成开关和记录这三件事。工具本身换过好几轮，方法反而是最耐用的资产。如果你手上也有跑得让人抓狂的模型，建议从给它装一个计时器开始，二十分钟就能知道劲该往哪儿使。