ལས་ཀ
སྔོན་འགྲོ་མི་སྣའི་འབྲེལ་མཐུན་ལས།
Senior ML Engineer | Kimchi (Inference Stack Optimization)
གནས་སྐབས་ཀྱི་གོང་ཚད་འབད།
ཞིབ་ཕྲ་
- ལས་ཀའི་རིགས།
- ཆ་ཚང་ལས་ཀ།
- རིམ་པོ་ཊ
- འོ།
- ཀུམ་པ་ནི།
- Kimchi
གསལ་བཤད།
Why Kimchi?
Great models are raw ingredients. Kimchi is what happens when you ferment them with good engineering. We started inside CAST AI helping companies run LLMs on their own Kubernetes clusters; today we run our own coding harness on any model you pick, and we run the models underneath it ourselves.
Kimchi Inference
One API line and a customer's existing client just works: DeepSeek, GLM, Kimi, MiniMax, Nemotron served serverless from our own GPU fleet (OpenAI- and Anthropic-compatible, pay per token, spend visible per user, team, and key). When control matters, the same models run on the customer's own cluster instead. Behind that one line sits the machinery you'll own: SGLang and vLLM engines, B300 nodes, a shared cluster filesystem that holds every checkpoint exactly once, KV caches riding coding traffic with heavy prefix reuse, and the benchmark harness that gates every change we ship.
Made by Cast AI — a Miami-headquartered, globally distributed team across 34 countries that hit unicorn status in January 2026 with a $50B+ backed investment pushing its valuation past $1 billion.
About the role
Throughput. Latency. Cold starts. Cost per token.
Move those four numbers in the right direction and two things happen: customers get faster, cheaper inference, and our margins improve. That's the entire thesis of this role. Every loader you tune, every scheduler decision you land, every kernel you stare at shows up in a customer's p99 and on our P&L. Your mandate is the inference stack's optimization, whatever it takes, and the technical direction of how we optimize it is yours to argue with data.
The problem: the checkpoints run 0.3-1.5 TB, and the "right" serving configuration depends on traffic shape, sequence-length distribution, batch dynamics, GPU SKU, memory bandwidth, and quantization tolerance, all variables that shift week to week. Most teams pick a configuration once, over-provision GPUs, and absorb the cost. We don't: we took Kimi-K3 (1.5 TB) from over an hour cold-to-serving to under twelve minutes with a shared filesystem, O_DIRECT weight loaders, and node-local JIT caches, and we're nowhere near done. Prefill/decode disaggregation and tiered KV caches are next.
Stack: Python; SGLang; vLLM; TensorRT-LLM; PyTorch; fastsafetensors; CUDA-adjacent tooling; Kubernetes; virtiofs shared filesystems; ClickHouse; OpenTelemetry; Prometheus; Grafana; GitLab CI.
Requirements
• You've built real ML systems for 5+ years, and your portfolio shows depth in inference or training infrastructure, not just model training notebooks.
• Your Python is production-grade: services, not scripts.
• You've run vLLM, SGLang, or TensorRT-LLM for real, and you have a working mental model of why an engine performs the way it does on a given GPU.
• You've measured quantization regressions, not just compression ratios.
• Multi-GPU and multi-node setups hold no fear: tensor and expert parallelism, collective communication, and their practical failure modes.
• You know where the bytes live (page caches, O_DIRECT, network filesystems under terabyte-scale reads) and how fast they move.
• You instrument before you optimize, and you can tell a real win from a benchmark artifact.
• A wide mandate excites you more than it unsettles you.
Nice to haves
• You've worked on LLM routing specifically: RouterBench-class evals, cost/quality/latency Pareto fronts.
• Calibration, abstention, or conformal methods in production decision systems.
• You've run online A/B loops with drift monitoring on a model that touches real money.
Responsibilities
• Push throughput. Continuous batching, chunked prefill, speculative decoding with draft models, CUDA-graph capture, and scheduler tuning across the engine
fleet. Find the ceiling on each GPU SKU, then raise it.
• Cut latency. Attack TTFT and inter-token latency separately; profile to find the actual bottleneck (compute, memory bandwidth, scheduling, storage, or
network) and fix it, not the one you assumed.
• Get more out of the KV cache. Hierarchical and paged attention, prefix caching on heavy-reuse coding traffic, eviction policies, quantized KV. A lot of the
unrealized throughput lives here, and you'll own it.
• Kill cold starts. Weight loaders (O_DIRECT, fastsafetensors-class), JIT and compile caches, shared-filesystem read paths. A 1.5 TB checkpoint has no business
taking an hour to reach serving.
• Quantize without regressing quality. INT8/INT4, FP8/FP4 across weights, activations, and KV, measured on real workloads, not just perplexity benchmarks.
• Scale across nodes. Distributed inference topologies, network-aware placement, prefill/decode disaggregation, checkpointing strategies that don't bottleneck
on storage or interconnect.
• Set the technical direction. Decide what we benchmark, what we adopt, and what we build ourselves. Bring the team along with strong writeups and reproducible
experiments.
What’s in it for you?
• Competitive salary (depending on the level of experience).
• Enjoy a flexible, remote-first global environment.
• Collaborate with a global team of cloud experts and innovators, passionate about pushing the boundaries of Kubernetes technology
• Equity options.
• Get quick feedback with a fast-paced workflow. Most feature projects are completed in 1 to 4 weeks.
• Spend 10% of your work time on personal projects or self-improvement.
• Learning budget for professional and personal development - including access to international conferences and courses that elevate your skills.
• Annual hackathon to spark new ideas and strengthen team bonds.
• Team-building budget and company events to connect with your colleagues.
• Equipment budget to ensure you have everything you need.
• Extra days off to help maintain a healthy work-life balance.
Hiring process
• Screening call with Recruiter…
Source: Arbeitnow (https://www.arbeitnow.com/jobs/companies/kimchi/senior-ml-engineer-kimchi-inference-stack-optimization-248455)
Great models are raw ingredients. Kimchi is what happens when you ferment them with good engineering. We started inside CAST AI helping companies run LLMs on their own Kubernetes clusters; today we run our own coding harness on any model you pick, and we run the models underneath it ourselves.
Kimchi Inference
One API line and a customer's existing client just works: DeepSeek, GLM, Kimi, MiniMax, Nemotron served serverless from our own GPU fleet (OpenAI- and Anthropic-compatible, pay per token, spend visible per user, team, and key). When control matters, the same models run on the customer's own cluster instead. Behind that one line sits the machinery you'll own: SGLang and vLLM engines, B300 nodes, a shared cluster filesystem that holds every checkpoint exactly once, KV caches riding coding traffic with heavy prefix reuse, and the benchmark harness that gates every change we ship.
Made by Cast AI — a Miami-headquartered, globally distributed team across 34 countries that hit unicorn status in January 2026 with a $50B+ backed investment pushing its valuation past $1 billion.
About the role
Throughput. Latency. Cold starts. Cost per token.
Move those four numbers in the right direction and two things happen: customers get faster, cheaper inference, and our margins improve. That's the entire thesis of this role. Every loader you tune, every scheduler decision you land, every kernel you stare at shows up in a customer's p99 and on our P&L. Your mandate is the inference stack's optimization, whatever it takes, and the technical direction of how we optimize it is yours to argue with data.
The problem: the checkpoints run 0.3-1.5 TB, and the "right" serving configuration depends on traffic shape, sequence-length distribution, batch dynamics, GPU SKU, memory bandwidth, and quantization tolerance, all variables that shift week to week. Most teams pick a configuration once, over-provision GPUs, and absorb the cost. We don't: we took Kimi-K3 (1.5 TB) from over an hour cold-to-serving to under twelve minutes with a shared filesystem, O_DIRECT weight loaders, and node-local JIT caches, and we're nowhere near done. Prefill/decode disaggregation and tiered KV caches are next.
Stack: Python; SGLang; vLLM; TensorRT-LLM; PyTorch; fastsafetensors; CUDA-adjacent tooling; Kubernetes; virtiofs shared filesystems; ClickHouse; OpenTelemetry; Prometheus; Grafana; GitLab CI.
Requirements
• You've built real ML systems for 5+ years, and your portfolio shows depth in inference or training infrastructure, not just model training notebooks.
• Your Python is production-grade: services, not scripts.
• You've run vLLM, SGLang, or TensorRT-LLM for real, and you have a working mental model of why an engine performs the way it does on a given GPU.
• You've measured quantization regressions, not just compression ratios.
• Multi-GPU and multi-node setups hold no fear: tensor and expert parallelism, collective communication, and their practical failure modes.
• You know where the bytes live (page caches, O_DIRECT, network filesystems under terabyte-scale reads) and how fast they move.
• You instrument before you optimize, and you can tell a real win from a benchmark artifact.
• A wide mandate excites you more than it unsettles you.
Nice to haves
• You've worked on LLM routing specifically: RouterBench-class evals, cost/quality/latency Pareto fronts.
• Calibration, abstention, or conformal methods in production decision systems.
• You've run online A/B loops with drift monitoring on a model that touches real money.
Responsibilities
• Push throughput. Continuous batching, chunked prefill, speculative decoding with draft models, CUDA-graph capture, and scheduler tuning across the engine
fleet. Find the ceiling on each GPU SKU, then raise it.
• Cut latency. Attack TTFT and inter-token latency separately; profile to find the actual bottleneck (compute, memory bandwidth, scheduling, storage, or
network) and fix it, not the one you assumed.
• Get more out of the KV cache. Hierarchical and paged attention, prefix caching on heavy-reuse coding traffic, eviction policies, quantized KV. A lot of the
unrealized throughput lives here, and you'll own it.
• Kill cold starts. Weight loaders (O_DIRECT, fastsafetensors-class), JIT and compile caches, shared-filesystem read paths. A 1.5 TB checkpoint has no business
taking an hour to reach serving.
• Quantize without regressing quality. INT8/INT4, FP8/FP4 across weights, activations, and KV, measured on real workloads, not just perplexity benchmarks.
• Scale across nodes. Distributed inference topologies, network-aware placement, prefill/decode disaggregation, checkpointing strategies that don't bottleneck
on storage or interconnect.
• Set the technical direction. Decide what we benchmark, what we adopt, and what we build ourselves. Bring the team along with strong writeups and reproducible
experiments.
What’s in it for you?
• Competitive salary (depending on the level of experience).
• Enjoy a flexible, remote-first global environment.
• Collaborate with a global team of cloud experts and innovators, passionate about pushing the boundaries of Kubernetes technology
• Equity options.
• Get quick feedback with a fast-paced workflow. Most feature projects are completed in 1 to 4 weeks.
• Spend 10% of your work time on personal projects or self-improvement.
• Learning budget for professional and personal development - including access to international conferences and courses that elevate your skills.
• Annual hackathon to spark new ideas and strengthen team bonds.
• Team-building budget and company events to connect with your colleagues.
• Equipment budget to ensure you have everything you need.
• Extra days off to help maintain a healthy work-life balance.
Hiring process
• Screening call with Recruiter…
Source: Arbeitnow (https://www.arbeitnow.com/jobs/companies/kimchi/senior-ml-engineer-kimchi-inference-stack-optimization-248455)
འབྲེལ་ཡོད་ཀྱི་འབྱུང་ཁུངས་ལས་ཐོན་པའི་ཐོ་གཞུང་འདི་ཡིན། འབྱུང་ཁུངས་ཀྱི་ཝེབ་ས་ཚིགས་སུ་འགྲོ་རོགས།
ཁ་བྱང: Kimchi
Kimchi ལས་ཐོབ་མི་ལིས་ཊིང་།
