V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 外包信息请发到 /go/outsourcing 节点。
• 不要把相同的信息发到不同的节点
adamcavendish
V2EX  ›  酷工作

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

  •  
  •   adamcavendish · 7 小时 47 分钟前 · 338 次点击

    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 HEADERSTokio taskHTTP handlerK8s Endpoints watcheBPF socket filterNIC RX ring,并在任意环节卡顿时,知道该看哪里、查什么。

    ⚡ 加分项(非必需,但会让你脱颖而出)

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

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

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

    你将参与决策:

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

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


    📌 请随申请附上:

    • 一个能体现你好奇心或所有权精神的任意作品链接:GitHub 仓库、技术博客、Gist 、PR 记录,或任何你亲手构建的成果。
    • 联系方式:商汤官网投递链接
    adamcavendish
        1
    adamcavendish  
    OP
       7 小时 8 分钟前
    想要邮箱投递的也可以联系: [email protected]
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1034 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 18:05 · PVG 02:05 · LAX 10:05 · JFK 13:05
    ♥ Do have faith in what you're doing.