模拟面试实录 · 一个绝不放水的面试官 vs 唐连杰

你说得对,我不反驳,板子我零实操,这条我不洗。但你刷我该刷"缺什么"——我的缺口是刷机流程、算子清单、板级 BSP 这些手感,不是端侧那套判断力。给你三件我真踩过、对得上号的:① 硬件能力对齐:比赛那台官方机是 Blackwell、sm_120,torch 的 is_available 返回 True 我没信它——那只是编译期布尔、只说它编了 CUDA、不说编了我这张卡的核,换 cu128 实跑一次真迭代才认;这跟 TensorRT engine 绑硬件、换板子必须重 build 是同一类问题。② 受限离线环境:那台机 github、pytorch 源全封,依赖是本机下好 tar over ssh 推过去的。③ 模型格式转换加数值验证:导出 policy.onnx,手算 actor 参数量 55 万乘四字节对上文件 2.2 兆确认没残缺,再跟原 pt 逐次前向比误差 2e-6。这三件端侧每天在干、我做过,真缺的是拿板子跑一遍。你不信我嘴上说的,最有效的不是听我承诺几周,是给我一个上板小任务、你自己看。

你抓得准,我照实说,这三个我答不出你要的那种"亲手调"。opset 我不给你编一个数字,我得翻导出脚本才知道。 dynamic_axes 我没设——但不是漏了,是不需要:obs 固定 750 维、action 20 维、batch=1、单机单路实时流,没有动态轴需求,设了反而给下游图优化添麻烦。算子不认一个没碰到,原因不光彩——我那 actor 就是四层 MLP 加 ELU,全是最基础算子。所以你判断成立:那行 export 我没自己写,用的是官方 play.py 的 export_policy_as_onnx。那我把这张牌重新报个价:它证明的不是"我调得动导出",是"我不信任产物、会去验它"——我之前把这张牌报大了,说成硬牌不合适,它是"我会验收"不是"我会导出"。 你要的是能处理 LayerNorm/GELU 被 BPU 拒了手动拆的人,我现在不是,这个我不装。

先把最硬的说了:如果那个已经上板过的人坐门外、价钱谈得拢,你应该招他,我争也争不过。但你这坑是三个月、兼职、这日薪,那人大概率不来——所以你真实的选择不是我和他,是我和另一个同样没上过板的人。在这个对比里我值三条:① 上板是一条链,前面几段(模型转换/完整性验证/离线装依赖/obs-action 契约对齐)我第一天就产出、不用带——踩过的:仿真发的图是 BGR、训练数据是 RGB 不翻通道成功率莫名偏低;20 关节策略接进官方 23 关节框架,我把 84 减 75 等于 9 正好是 3 个腰关节核对清才敢接。② 我今天就能防端侧最贵的事故——把没验证的当交付:83.3% 我改回真实 64%、task5 标 0%、reward 涨到五十多我去量前进速度只有 0.085 发现会站不会走。③ 量化我不是零,换工具不换方法。最后:我产出里很大一块是 AI 落地的,这是事实,你买到的是一个人跑一个半人的工程量、每步为什么都能讲,买不到的是每行代码出自我手。我不值一个上过板的人的钱,我值的是这个价位上你能找到的最不糊弄的那个。

没有。

是后者。如实说:我没读那 reward 函数、没逐项看懂、更没从代码层判断出权重不对。我是先觉得"这么顺利不对劲",靠量前进速度和直立占比这个外部结果信号发现的。代码层解释是后补的——发现后我才去拆那 44 个 scalar、看到 track_lin_vel_xy_exp 早期塌、到 vC 才拉到 1.20,那个我看得懂能解释,但那是事后读懂不是事前判断。所以你推论我接大半:我"对原理负责"应该收窄成——我能对产出做事后审计和解释,不能对没写的代码做事前预判。这两件我之前措辞混在一起、混得对我有利,你拆开是对的。 而且我把代价说到底:这意味着有一类问题我防不住——错在代码里、但结果看着正常那种。reward 那次是运气好露了马脚,没露我就发现不了。这是我工作方式实打实的窟窿,不是谦虚。

这条我不让,我认为你说错了。 有 Tensor Core 和支持 bf16 是两件事。T4 是 Turing、sm_75,那代 Tensor Core 支持 fp16/int8/int4,电路里没有 bf16 的 MMA 通路;bf16 原生硬件支持是 Ampere 三代 Tensor Core 才加的、和 TF32 一起。更可证伪点:bf16 是 1 符号 8 指数 7 尾数,跟 fp16 的 5 指数 10 尾数是完全不同的两种格式,Tensor Core 要单独开一条乘累加通路,不是"16 位就能通用"——这也是 FA2 卡 Ampere、bf16 也卡 Ampere 的原因。你要验成本很低:T4 上 compute capability 是 7.5,拿 bf16 张量做 matmul 挂 profiler 看走不走 Tensor Core kernel。我唯一承认你可能对的:"跑"这个字——取决于 torch 版本,bf16 可能静默 fallback 到 fp32 软件路径,程序不崩能出数,但没 Tensor Core 加速、数值路径也变了;那种成功率我不会当 bf16 基线做对照,条件不干净。还有一层实话:我当时没硬撞、没留 bf16 在 T4 的报错日志,判断依据是硬件世代不是试出来的;7B 的 bf16 光权重 14G、T4 只 16G 我也不认为塞得下,这是我算的账不是测的。但结论我不改:bf16 那档引论文,是这卡给不了干净基线,不是我懒得试。

先说死:我没在任何板子上跑过,一次都没有,下面是推断不是经历。我赌第一个崩的是 bitsandbytes、崩在 import 那行,模型都还没开始加载。报错形态是找不到 libbitsandbytes_cudaXXX.so,或退一步是 undefined symbol——二进制层面加载失败。为什么它先崩:Orin Nano 是 aarch64、我 T4 那套是 x86_64,bnb 的量化反量化 kernel 预编译进 .so、pip 的 wheel 基本只给 x86_64 加特定 CUDA,aarch64 加 JetPack 自带的 CUDA 组合根本没有对应预编译产物,所以 import 期就死,显存分配都轮不到。我敢押是因为这类坑云端真踩过三次、能分清形态:bnb 是"找不到 .so"、flash-attn 是 undefined symbol(ABI 层)、vLLM 是段错误(运行时 C 层崩)。换到 Jetson 是架构整个换了,属最前面那类,比显存问题早得多。