给 long-context LLM 任务用的调度中间件——智能做批处理和路由，不换新硬件也能把推理成本砍掉 60%。

1. Fractile 在 2026 年 5 月拿到 Accel 和 Founders Fund 领投的 $220M，说明顶级投资人已经把推理吞吐视作 AI 基础设施的新主战场，也给软件层调度工具立住了买方叙事。
2. Fractile 报出的 40 到 1,200 tokens/sec，把 30 倍吞吐缺口摆到了台面上；而在 Fractile 硬件还要 12–18 个月才普及之前，软件调度今天就能先吃下其中大约一半。
3. 按照 Fractile 自己的对外说法，一些 long-context 推理任务在传统芯片上已经会跑上几周——这是企业 AI 团队此刻就在遇到的失效场景，也让软件补丁有了立刻的预算紧迫性。
4. 资本开支正在明确从训练转向推理基础设施，Fractile 对自己后训练硬件定位就是证据——在专用芯片还没商业化之前，ML 团队最先愿意掏预算的，就是软件调度这一层。

催化因素。 Fractile 在 2026 年 5 月融到 $220M，把投资人和一线操盘者的共识彻底坐实：推理吞吐就是新战场。在下一代硬件距离全面可用还要 12–18 个月时，ML 团队已经在主动找软件层补丁。

产品是一套云托管的推理调度控制平面，作为一层轻代理，部署在任何兼容 OpenAI 的端点前面。请求一进来，调度器先按上下文长度、优先级和截止时间给任务画像，再把它和兼容的在途请求动态拼批，并挑出既满足时延 SLA、又最便宜的端点。团队只要在代码里加一次 SDK 调用，马上就能在看板里看到单任务成本拆解、队列深度和吞吐指标。调度器的批处理引擎能把 GPU 利用率拉到 80% 以上，而行业里很多超配部署通常只有 30–40%。遇到截止时间宽松的任务——比如隔夜批量分析、大语料导入——调度器会自动切到可抢占算力，把实际单 token 成本再压低 60–70%。

差异化。 现有推理 serving 框架（vLLM、TGI、LiteLLM）盯的是在线请求的中位时延，默认每个请求都同样紧急；这款产品则第一次把“感知吞吐”的批处理调度和按 SLA 分层的优先级机制，专门做给 long-context 任务。和云厂商自带的 batch API 不同，它不绑模型，任何兼容 OpenAI 的端点都能接，包括私有基础设施上的自托管模型。按节省额分成的定价方式，也和工程团队的利益天然一致——他们得向 CFO 证明新工具值这个钱，但又不想先背一笔固定承诺。

待完成任务

flowchart LR
  Client[ML Engineer / Agent App] --> Proxy[Scheduling Proxy SDK]
  Proxy --> Profiler[Job Profiler\nContext Length and Priority]
  Profiler --> Batcher[Dynamic Batcher\nSLA-Tier Queue]
  Batcher --> Router[Endpoint Router]
  Router --> GPU1[Current GPUs\nH100 / A100]
  Router --> GPU2[Preemptible Compute\nSpot / Batch]
  GPU1 --> Dashboard[FinOps Dashboard\nCost Attribution]
  GPU2 --> Dashboard

高管要点

• long-context 推理已经是实打实的运营问题，但现有厂商大多给的是点状优化——batch API、prompt caching 或 provider-specific serving stack——而不是一套按上下文长度、SLA 和最便宜可行端点来分类任务的中立调度器 [18][2][4][40]。
• 最适合起步的买家，仍然是已经为生产推理付费的 ML infra 负责人，因为企业 AI 正从 pilot 走向规模化部署，而组织在扩实验和补治理这两件事上依然卡得很厉害 [11][13]。
• 竞争很激烈，但格局仍然分散：超大云卖吞吐预留，托管平台卖自己云上的更快推理，开源栈给原语；真正的空白，是跨 provider 的成本归因，加上对 long-context 任务做 SLA 感知路由 [1][30][9][16][28]。
• 技术 thesis 站得住，因为文献已经证明，持续批处理、prefix caching 和 prefill/decode 解耦都能带来明显增益；在 Fractile 或 Cerebras 这类定制芯片还没全面普及前，创业公司先把编排层商业化是可行的 [37][38][39][12]。
• 监管摩擦可控，但绝不轻：买家一旦把敏感文档路由到多个端点，就需要能审计的治理、区域控制和数据保护姿态，而不只是更低时延 [31][14][25][29]。

市场定义

这个市场指的是：服务于 long-context LLM 推理的控制平面软件，位于模型 API、自托管 runtime 和托管推理云之上。它给任务做形态画像、把兼容请求排队拼批、结合 batch/caching 感知做路由，并按工作负载归因支出。这个市场不包括通用模型托管，也不包括泛可观测性工具，除非它们明确在优化 long-context 批处理经济性和跨 provider 调度 [2][30][35][41]。

用户与买方

主要用户是 ML infrastructure 工程师和平台团队：他们在运营生产级的文档分析、代码分析或 agentic 工作流，提示词很长、截止时间也参差不齐。真正的经济买家通常是 Head of ML Infrastructure、VP Engineering，或对吞吐、时延和云 GPU 支出负责的中央平台 owner [11][13][9]。

购买触发点

• 当月度推理支出大到值得系统化地运营 batch、缓存和预留吞吐折扣，而不是再靠人工管理时，采购意愿会起来。 [1][29][4][16][36]
• 当 long-context 任务或隔夜文档批处理在现有 vLLM/TGI 栈上带来明显排队、解码变慢或尾时延失稳时，买方会开始找解法。 [19][9][5]
• 当管理层把推理视为下一个基础设施瓶颈，并在下一代硬件大规模落地前先拨预算做优化时，购买就会被推进。 [18][22][7][26]

支付意愿

市场已经接受为优化能力做明确价格分层。Anthropic 对 cache read 收费远低于基础输入价，AWS 和 Azure 都公开打出 50% 的 batch 折扣，Fireworks 对缓存 token 和 batch token 也给折扣，Together 则直接宣传 batch inference 成本低 50%。这给调度器留出了可信的预算空间——前提是它能证明自己在单一 provider 之外还能再多省一截 [4][1][29][16][36]。 [4][1][29][16][36]

品类动态

增长信号 19.2% CAGR

验证信号

• Fractile 的 $220M 融资，明确把推理时延定义成训练之后的下一个瓶颈。
• Baseten 和 Groq 都围绕推理基础设施拿到大额融资，说明这个类别还在持续吸资本。
• 云厂商和托管平台已经把 batch 与缓存折扣直接写进定价页，说明买家早就在按工作负载类别，而不只是模型质量，来优化成本。
• 社区和一线操盘材料里仍不断冒出 long-context 性能痛点和 continuous batching 的收益，说明这不是一个抽象问题。

监管与技术约束

• batch API 往往不支持工具调用或结构化输出这类交互能力，所以调度器能延后的工作，不能靠改变应用行为来硬做。
• prompt caching 的收益取决于前缀是否稳定，有时还依赖 session 亲和性或 replica locality，所以软件调度不能只看价格表，还得懂工作负载形态。
• 吞吐预留和区域部署模式高度 provider-specific，这会显著增加中立控制平面对配额、时延和驻留选项的归一化难度。
• 只要请求可能跨区域或跨模型提供方，敏感企业文档流就需要可审计的治理与数据保护控制。

竞争格局可以拆成四类。超大云（AWS、Azure、Vertex）在单一云里卖 batch、缓存和预留吞吐 [1][30][21]。Baseten、Fireworks、Together 这类托管推理平台，卖的是它们自己基础设施上的更快、更便宜推理 [9][16][36]。Anyscale、vLLM、LiteLLM、BentoML、KServe 这类开源编排层提供的是原语，但集成和策略工作仍然压在买家身上 [6][41][28][10][27]。Groq、Cerebras、SambaNova、Fractile 这类专用硬件厂商则把性能天花板继续往上抬，同时也让端点异构性更强，反而进一步强化了中立路由层的价值 [22][12][26][18]。

为什么现有厂商不会默认胜出

• 云平台. AWS、Azure 和 Vertex 越来越多地暴露 batch 与预留吞吐控制，但这些能力都长在云厂商自己的体系里，默认并不能解决跨 provider 调度或硬件无关的 FinOps。
• 托管推理平台. Baseten、Fireworks 和 Together 已经能把速度和成本效率卖出去，但它们的胜法是把工作负载留在自家栈里，而不是在多套栈之间替客户挑最便宜端点。
• 开源与自建. vLLM、LiteLLM、Ray Serve、BentoML 和 KServe 给了强团队足够多原始零件，但买家仍要自己设计路由策略、节省归因和可靠性运营。
• 专用推理硬件. Groq、Cerebras、SambaNova 和 Fractile 能把 tokens-per-second 抬高，但它们并没有解决“先分类工作负载、在多个端点间裁决、再按任务类型解释支出”这件事。

Long Context Inference Scheduler 是一层给 AI 团队用的控制平面：当文档分析和代码分析负载已经先被 long-context 推理成本和排队拖住，而还没到必须上新硬件的时候，它先把问题扛下来。第一个客户画像，是 10–80 名工程师的 Series A–C AI-native 创业公司；它们每月已经在推理上花掉约 $50k–$120k，并且在 64k–200k token 任务上碰到了预算冲击或 SLA 失守。产品以可直接接入的 SDK 和代理切进来，按上下文长度、优先级和截止时间给请求分类，再把可延后的任务打包并路由到仍满足策略要求的最便宜端点。研究支持它先打一个聚焦市场，而不是一开始就讲大而全的推理平台故事：初始 long-context 控制平面类别的 TAM 约 $600.0M，SAM 约 $72.0M，Y3 SOM 约 $5.4M。买方逻辑站得住，因为云厂商、模型厂商和托管推理平台，已经把“为批处理、缓存和吞吐优化付费”这件事教育出来了，只是大多数工具仍绑在单一提供方，或者要求团队自己做不少平台工程。更稳妥的打法，是先打穿一个窄而深的工作流，在买家已经打开原生优化开关之后，仍证明自己能带来增量节省，再往更广的 inference FinOps 和多硬件 brokerage 扩。需要保持克制的地方也很清楚：超大云和开源的替代风险很强，敏感文档路由会碰到治理摩擦，而直接客户证据目前主要还是研究语料和 Fractile 融资这一条 headline catalyst。换句话说，这更像一套值得推进的运营型 thesis，且能被清晰证伪，还谈不上已经去完风险的基础设施投资。

问题

• 在 vLLM、TGI 或云模型 API 上跑 64k–200k token 文档/代码分析任务的 AI-native 团队，因为当前 serving stack 把 long-context 负载当成低时延请求来处理，最后只能超配 GPU、吞下队列尖峰，还看不清成本。
• 云厂商原生的 batch、缓存和预留吞吐控制，只能在单一栈里起作用；买家仍然缺一套中立系统，来判断哪些任务能延后、在策略约束下哪个端点最便宜，以及花出去的钱到底对应了哪类工作负载和业务价值。

解决方案

• 在兼容 OpenAI 的端点前部署一层轻代理和 Python SDK，让每个请求在执行前先按上下文长度、SLA 分层和截止时间完成画像。
• 先用 shadow mode 跑，再逐步放开受控路由，把兼容的 long-context 任务做批处理，把隔夜或低优先级任务导向更便宜的算力，并把任务级成本归因露出来，证明节省来自原生厂商特性之外的增量。

为什么我们会赢

• 滩头市场虽然窄，但痛得很急：买家手里已经有一张看得见的月账单，也能比采购一个大平台更快量出节省、排队减少和部署速度。
• 中立调度器可以架在 AWS、Azure、自托管 vLLM 栈和新硬件之上，而不是逼客户把负载迁到某一家厂商的商业栈里。
• 围绕上下文形态、截止时间松弛度、缓存复用和真实节省积累起来的专有遥测，能慢慢长成路由和策略护城河，而开源原语默认并不会沉淀这些东西。

里程碑

flowchart LR
  Wedge[Long-context document and code workloads] --> MVP[Shadow-mode scheduler and savings dashboard]
  MVP --> Proof[Paid pilots with verified savings and SLA protection]
  Proof --> Expansion[Inference FinOps and multi-hardware brokerage]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少四分之一的合格目标账户，必须有足够多可延后的 long-context 工作，才能靠拼批和路由省钱，同时不打穿时延承诺。
• 即便客户已经启用当前提供方的原生 batch、缓存输入或预留吞吐功能，仍然要能看到至少 15% 的增量节省。
• 在大多数 pilot 里，shadow-mode 部署必须在 1 天内跑出第一版 benchmark 结果，并在 2 周内进入第一轮受控路由。
• 至少在最早几单付费 pilot 里，真正买单的人必须来自基础设施或平台预算，而不是实验性质的 AI 预算。
• 早期客户在首个工作负载被验证后，必须愿意扩到更广的 FinOps 或多提供方 brokerage；否则这个切口最后只会停在一个窄工具上。

待尽调问题

• 目标客户的 long-context 负载里，真正有截止时间弹性的比例是多少？又有多少是面向用户、时延极敏感的流量？
• 在客户把现有提供方的原生 batch、prompt caching 和预留吞吐都开足后，还剩多少节省空间？
• 为什么买家会装一层中立代理，而不是把更多流量直接迁去 Baseten、Fireworks、Together 或云厂商原生控制？
• 真实交易里，最先冒出来的治理阻力是什么：热路径可靠性、提供方审批，还是数据驻留？
• 单个工作负载能不能在不依赖重服务化定制部署的前提下，就落到 $30k–$80k 年支出？

模型合理性

• 收入引擎. 基准情景在 Q4Y3 达到 67 个活跃付费部署，混合年收入约 $60K/部署；大部分抬升来自 Year 1 之后 pilot 的重复转化。
• 必须跑顺的事. 产品必须持续证明自己比原生 batch 和缓存功能更省钱，净新增才能在 Y2 维持每季度 4–6 个、在 Y3 维持每季度 8–12 个。
• 模型会失效的条件. 如果定价滑向 $52K，且毛利率卡在 68% 左右，downside 情景会在下一轮融资逻辑坐实前把现金打到 0 以下。
• 下一轮融资证明点. 只有当公司在 Y2 末拿到 25 个活跃部署、约 68% 毛利率，以及能缩短销售周期的多个 production reference，下一轮融资才算站得住。

情景

敏感性

flowchart LR
  Leads --> PaidPilots
  PaidPilots --> ActiveDeployments
  ActiveDeployments --> PlatformRevenue
  PlatformRevenue --> GrossProfit
  GrossProfit --> Cash

警示项: 模型在 Y1 仍要烧掉超过 $1.0M，Y2 再烧 $1.17M，因此执行风险高度集中在：要在现金跌破 $1M 前，证明 pilot 转化能更快。 · 由于 Y3 仍有不少 solutions 工作和部署支持，退出时每个 FTE 的收入只到 SaaS benchmark 的低端。 · Q4Y3 才是第一个 EBITDA 转正季度，所以只要转化节奏慢 1–2 个季度，融资时间点大概率就会被迫提前。 · 客户数按“扣除流失并包含小幅扩张后的净值”建模；如果真实毛流失超过 2.0% 这个经验值，且没有 upsell 抵消，Y3 收入会明显低于预期。

• 云厂商反制. AWS、Azure 和 GCP 可能会把原生 long-context 批量调度直接打包进托管推理 API，12–18 个月内就把核心切口商品化。 缓解措施: 在任何单一云厂商推出竞争性 batch API 之前，先把多云和自托管模型兼容性做出来，并把护城河转到专有任务形态数据和云厂商难以复制的 FinOps 集成上。
• 开源替代. vLLM 或 LiteLLM 社区可能会把“感知吞吐”的批量调度做成开源能力，削弱商业产品的价值主张。 缓解措施: 把底层调度原语贡献给开源，拿它做分发渠道；同时把托管控制平面、成本归因引擎和多端点路由留在商业闭源层。
• 单一来源证据缺口. Fractile 的硬件性能说法（40 到 1,200 tokens/sec）还没有独立 benchmark 验证；如果这套硬件叙事被证明夸大，推理调度的紧迫信号也会变弱。 缓解措施: 在 Series A 之前，先靠 ML infra 访谈直接验证客户痛点；这个调度产品的价值，并不依赖 Fractile 硬件是否准时出货。