[商汤/大装置] 诚邀 Rust 系统工程师共建下一代 AI 推理基础设施

[adamcavendish]

Hi V2EXers 👋

我们正在构建全球最具适应性的「推理基础设施底座」——不仅服务于当下的大语言模型（ LLM ），更面向未来十年的前沿模型、异构加速器（ GPU/NPU/ASIC ）以及符合数据主权与合规要求的部署实践。

从单节点开发集群，到横跨公有云、国家级私有云与物理隔离数据中心的多区域 GPU/NPU 异构算力舰队——大装置在「模型实际运行的位置」完成推理请求的智能路由、弹性编排与深度可观测性：保障可预期的低延迟、严苛的服务等级目标（ SLO ），且彻底杜绝厂商锁定（ zero vendor lock-in ）。这一切，均由 Rust 实现——它足够安全，可贴近内核级系统；足够高效，能支撑微秒级关键路径；也足够表达力丰富，可精准建模全权衡：从 HTTP 头字段解析，到 RDMA 队列对（ queue pair ）调度。

你不会只是"胶水式对接 API"。你将与团队共同设计定义下一代大规模、生产级 AI 推理所依赖的基础设施原语（ infrastructure primitives ）——让推理真正变得可靠、高效、可持续演进：

• 支持跨地域与硬件代际（ H200 、Ascend 910B 等）的全局网关；
• 面向场景自适应的控制器（适配合规性、延迟敏感性或成本约束）；
• 原生集成 Kubernetes 的 Operator ，将基础设施意图（ infrastructure intent ）转化为可观测、自愈合的运行现实——服务于研究人员、初创公司、国家实验室，以及中国最具雄心的 AI 战略项目。

---

商汤/大装置 · AI 推理平台｜后端工程师

后端工程师（ Rust / 系统 / 基础设施方向）

🔧 你将实际构建并长期负责的核心系统

🌐 全球规模推理编排体系

• 全局网关层（ Global Gateway Layer ）

基于 pingora 自研高吞吐、低延迟 Rust HTTP 反向代理与智能路由系统：

• 跨地域、跨硬件代际（如 H200 / Ascend 910B ）、跨合规边界（如数据驻留区）动态分发请求；
• 强制执行地理围栏（ geo-fencing ）、租户级精细化限流（按 token / 请求 / 音频秒计费），以及故障时自动降级策略（ dynamic fallback ）。

• 场景专用轻量网关（ Scenario-Specific Gateways ）

为不同推理模态（ LLM 、ASR 、TTS 、OCR 、向量嵌入、重排序、视觉-语言多模态等）定制嵌入式 HTTP 适配器：

• ✅ 支持模态特化的请求整形（如音频分块、Prompt 校验、图像预处理提示）；
• ✅ 原生支持流式响应语义（text/event-stream、分块二进制传输）；
• ✅ SLO 感知型路由（如优先选择 P95 延迟 <300ms 的 ASR 后端）；
• ✅ 所有网关共享统一控制平面：API 密钥管理、分布式追踪、指标采集、策略引擎。

• 跨集群服务发现与健康网格（ Cross-Cluster Service Discovery & Health Meshing ）

深度集成 Kubernetes Endpoints / EndpointSlices / Service APIs，并通过 eBPF 实现毫秒级、业务感知的存活探针（ liveness probe ）：动态加权路由决策依据包括——实时 token 吞吐量、GPU 显存压力、RDMA/PCIe 互连带宽饱和度等真实负载信号。

⚙️ 基础设施原语（而非抽象封装）

• 微批调度器（ Micro-batch Scheduler ）

跨硬件部署单元（单机 / 集群 / 跨云）进行智能负载均衡——不依赖传统 CPU/内存指标，而是基于推理引擎反馈的深层 telemetry：请求队列积压率、PCIe 总线带宽利用率、NCCL Ring 健康状态等。

• Token 成本归因管道（ Cost-per-Token Attribution Pipeline ）

将请求元数据（租户 ID 、模型名称、部署区域、SLA 等级）与底层硬件指标（ GPU 显存带宽、DRAM 访问周期、NIC 卸载使用率）精确关联，实现细粒度、可审计的资源成本核算。

🧱 全栈所有权（ Cross-Stack Ownership ）

与 GPU/NPU 内核与固件团队协同：针对特定模型优化 CUDA/Ascend Kernel 、调优 NCCL 集体通信、加固基于 eBPF 的可观测性模块——因为推理可靠性始于运行时（ runtime ）之下。

🛡️ 可靠性即代码（ Reliability as Code ）

• 自动扩缩容逻辑触发条件为业务语义指标：token 吞吐量、KV Cache 命中率、互连网络饱和度——而非泛化的 CPU 或内存使用率；
• 渐进式灰度发布（ canary traffic shift ）默认绑定可观测性回滚机制：一旦错误率飙升或显存碎片率超阈值，立即全自动回退，并完整关联全链路 trace 。

📈 复利型工程素养（ Engineering Posture That Compounds ）

• 编写 RFD （ Request for Discussion ）文档，清晰阐述关键架构决策背后的权利衡，例：

  “我们选择去中心化 JWK 分发 + 每请求 JWS 验证，而非 mTLS ，以在跨地域、跨云厂商、跨主权网络场景下实现零信任服务身份——用微量 CPU 开销换取跨集群证书同步消除带来的运维韧性。”

• 对每一条关键路径进行结构化日志、直方图统计与 eBPF 探针埋点——因为调试推理系统，本质是调试整个系统栈，而非单一服务。

✨ 我们寻找的人——不是"完美匹配 JD 的人"，而是"能重新定义问题的人"

✅ 你进化迅速，且刻意为之

• 持续跟踪开源基础设施前沿动态（如 OpenTelemetry 架构演进、CNI 性能趋势），并理解其背后的技术动因；
• 过去 6 个月内曾主动交付一个"学习型"项目：K8s Operator PoC 、Rust 编写的压测框架、或 HTTP/2 vs HTTP/1.1 在 token 流式传输场景下的基准测试报告。

✅ 你以基础设施思维思考，以协作者姿态行动

• 善于做合理假设，并立刻验证：用火焰图定位调度器卡顿，用 eBPF 追踪 TCP 重传；
• 文档聚焦意图、权衡与失败模式：一份好 README 应说明——
  • ✅ 为何将 NCCL 锁定在某版本？
  • ✅ 网关如何应对后端部分宕机？
  • ✅ 若未调优 SO_KEEPALIVE，长连接流式场景会崩溃在哪一环？

✅ 你对结果负责，而非仅对任务负责

• 将模糊目标"降低延迟"拆解为可验证假设：是调度延迟？多租户网关 DNS 解析慢？分片间 KV Cache 碎片化？ 然后测量、隔离、落地；
• 主导闭环式复盘（ post-mortem ），例：

  “根因定位为 ASR 网关音频 Handler 与后端 Dispatcher 之间使用了 unbounded channel ，在突发流量下积压数千请求，导致 async runtime 饿死、P99 延迟激增 12 倍、最终触发 OOM Kill 。修复方案：替换为容量 128 的 bounded channel + try_send() 驱动的背压机制，并在满载时返回 HTTP 429 。下一步：按模态采集 channel 深度直方图，基于实测 token 吞吐量自动伸缩容量。”

🎯 我们珍视什么？又不看重什么？

🔷 我们极度重视：

• 在强约束下交付成果的技术判断力：
  • 延迟（ LLM 流式响应 P99 < 500ms ）
  • 内存（ GB 级租户隔离）
  • 合规（数据驻留、审计日志）
  • 硬件异构（同一集群同时调度 CUDA 与 Ascend 模型）
• 端到端所有权：从架构设计 → 代码实现 → 可观测性埋点 → 迭代优化，尤其跨越多层技术栈（ Tokio 服务 → eBPF telemetry → Linux kernel module ）；
• 快速学习能力：尤其在底层系统领域——Rust 异步运行时原理、Kubernetes controller-runtime 模式、GPU/NPU 驱动接口、RDMA 编程模型、RoCE/InfiniBand 互连拓扑；
• 系统直觉（ Systems Intuition ）：知道何时该用无锁环形缓冲区 vs Channel ，何时该信任 CNI 插件 vs 用 eBPF 绕过，何时该增加结构化 telemetry vs 简化控制平面；
• 开放共塑心态：愿与内核工程师、模型开发者、合规专家、共建主权 AI 栈的学术伙伴深度协作。

❌ 我们不筛选：

• • 学历、工作年限、就职公司 Logo ；
• "全栈"作为空洞标签——但我们高度认可能完整追踪一次请求路径的工程师：
  HTTP/2 HEADERS → Tokio task → HTTP handler → K8s Endpoints watch → eBPF socket filter → NIC RX ring，并在任意环节卡顿时，知道该看哪里、查什么。

⚡ 加分项（非必需，但会让你脱颖而出）

• 向基础设施相关开源项目提交过高质贡献：如 vLLM 的 HTTP Server 层、Envoy Gateway 插件等——尤其欢迎已合并的 patch 、公开的 benchmark 报告、或在真实负载上验证的性能提升；
• 构建过被多个团队复用的共享基础设施：如用于 GPU 拓扑校验的 CLI 工具、使网关 SRE 告警疲劳降低 40% 的内部仪表盘、或让跨集群服务发现对其它团队"开箱即用"的 Rust 库。

🌟 这不是一个职位——这是一次基础设施的共同创造

在大装置，你不会"支持"AI 推理——你将参与重新定义"生产级 AI 推理基础设施"的内涵：跨越硬件、软件、地理与应用场景。

你将参与决策：

• 某类服务器是否需要定制内存分配器？还是应抽象出新一层统一接口？
• 私有云部署是否需要加固型网关？抑或应设计全新的合规感知路由策略？

如果你相信：卓越的 AI 基础设施，必须由通晓内核、分布式系统、Kubernetes 控制平面与监管边界的通才型工程师来构建；
如果你渴望以充分的技术自主权、真实的业务影响力、零历史技术债务的方式打造下一代 AI 底座——
我们诚挚邀请你加入这场基础设施的共同创造。

---

📌 请随申请附上：

• 一个能体现你好奇心或所有权精神的任意作品链接：GitHub 仓库、技术博客、Gist 、PR 记录，或任何你亲手构建的成果。
• 联系方式：商汤官网投递链接

[adamcavendish]

想要邮箱投递的也可以联系： [email protected]

[Grapevine]

请问有前端 HC 嘛

[adamcavendish]

@Grapevine 应该是有的，可以发邮件给我，我问问前端组

[enrolls]

举手试试，虽然 Python 才是我 powerful ，不过最近有看 cf 的 pingora ，而且 rust 优化了我 Python 的好多东西，譬如 geoip 的 search ，Loyalsoldier/geoip 的版本产出文件还是大了。rust + python 协助我完成 中国地址的标准化，顺便 支持了 ISO 3166 和相关抽象的

[coefu]

80%的 v2exer 可能看不懂你的 jd 。😄

[adamcavendish]

@enrolls 要不要邮件或者官网投递一下

[adamcavendish]

@coefu 不至于不至于，我们只是抛砖引玉

[coefu]

@adamcavendish #7 完全匹配条件的，不会超过 2 位数。
一则 rust 拦住一波，二则熟悉 ML 底层工程实现的拦住一波，三则 k8s 深入到 operator 能力的拦住一波，四则 sys 内核底层拦住一波，五则可能还得从 ML 原理层面有所理解才能有真正的性能剖析优化的能力。这五个条件一筛，还能有几个人能达到条件？
就不要说 V2EX 上 80%都是搞 web 前后端的了。