35B开源模型自部署实测：成本拐点混合选型

开源阵营这批新模型正在改写一道老题：到底多少任务值得自己养机器。35B 上下这个参数量级，恰好卡在"单卡可部署"与"能力够执行"的交点上。

一、两份开放权重的成绩单

我注意到两条同日出现的开源动态，合起来正好覆盖"通用执行"与"专用检索"两个方向。

第一条：一个名为 Occamy-1.0 的 co-work 模型公开了权重与部分训练数据。它在 Qwen3.6-35B-A3B 的后训练检查点上继续训练，路线是执行接地——构造可执行验证的数据与环境、跨多个 Harness 捕获可回放的长程轨迹、分阶段后训练巩固能力。公布的成绩是在广泛的 co-work 基准上处于同尺寸最强之列，部分任务上与更大的旗舰系统竞争；按其评测与定价口径，四项代表性基准的聚合性能落在成本-性能曲线的低成本拐点。

第二条：小红书 AllSpark 团队开源了 Search Agent 模型 Iris，35B 与 397B 两个规格，同量级成绩领先，权重与评测代码公开，数据与训练配方陆续放出。搜索代理单独成为一个开源模型类别这件事本身，就说明检索型任务已经被市场认为值得专用模型。

两条动态的共同点：开放权重的竞争焦点从通用聊天转向任务型智能体，而且都把"执行能力 ÷ 参数规模"当作核心卖点。

二、自部署与 API 的成本分界

自部署的真实成本从来不是 GPU 标价，而是利用率。把账摊开：

成本项	自部署（35B 档，单节点）	API（高性价比档）
固定成本	GPU 折旧 + 电费 + 运维，按月固定	无
边际成本	每千 token 几乎为零	每千 token 按牌价计
空闲代价	利用率低于四成时，摊销成本急升	无空闲代价
弹性上限	受节点数限制，扩容要采购周期	弹性随上游供给
隐性成本	版本升级、推理服务维护人力	无

自部署在数学上占优的条件只有一个：稳定的高利用率。粗算的临界点在每天数百万 token 的持续负载——低于这条线，API 的按量计费几乎总是更便宜；高于这条线，且负载曲线平稳（白天黑夜不塌），自部署的边际成本优势开始兑现。负载曲线大幅波动的团队，混合架构才是正解。

三、原理速览：混合部署的请求路由

业务请求
    |
    v
任务画像：是否敏感 / 是否高频稳定 / 是否需专有能力
    |
    +--> 敏感数据、高频稳定任务 ──> 本地 35B 集群（数据不出域）
    |
    +--> 尖峰流量、长尾任务 ──> API 弹性通道（按量计费）
    |
    +--> 检索密集任务 ──> 专用 Search Agent（本地或 API 视画像）
    |
    v
统一网关：同一 OpenAI 兼容协议，路由差异对业务透明
    |
    v
审计：按通道归因成本与质量，利用率与账单同图监控

混合架构的关键不是"本地跑什么模型"，而是路由条件必须可解释：为什么这条请求走本地、那条走 API，条件写进配置而不是写进口口相传的经验。

四、35B 档到底能接什么活

Occamy-1.0 的能力面对选型给了直接参考：co-work 场景的信息收集、工具调用、编码、文件操作，多数步骤拼的是状态跟踪、协调、恢复与跟进，而不是旗舰级的深度推理。这类执行型任务正是 35B 档的主场。

具体的任务画像上，我在 4sapi 的接入数据里看到三类任务对自部署的适配度最高：一是内部工具链上的高频自动化（工单分类、日志摘要、格式转换），数据敏感且模式固定；二是持续运行的批处理（夜间回归、定时对账），负载平稳天然适合吃满利用率；三是已验证过成绩衰减可接受的中等复杂度代码任务。反过来，长程规划、跨仓库重构、高风险变更审批仍然留给旗舰 API，这些任务的错误代价远超省下的 token 钱。

Iris 的出现补上了第四类：检索密集的代理任务。搜索代理与通用 co-work 模型分开部署还有一个工程红利——检索链路的版本迭代可以独立于主模型进行，互不拖累。

五、接入教程：本地与 API 的双通道客户端

下面这段 Python 示例展示混合架构的最小客户端：本地 35B 服务与 4sapi 的 API 通道都走 OpenAI 兼容协议，路由条件集中在一张表里，业务代码无感。4sapi 一侧统一管理上游密钥与模型清单，本地集群故障时同一任务可平滑切到云端同档模型。

import openai

LOCAL = openai.OpenAI(base_url="http://intra-gpu-01:8000/v1",
                      api_key="local-only")          # 内网自部署推理服务
CLOUD = openai.OpenAI(base_url="https://4sapi.com/v1",
                      api_key="sk-xxx")              # 云端聚合通道

# 路由表：条件 → (通道, 模型)。条件集中一处，可解释、可审计
ROUTE_TABLE = [
    {"when": lambda t: t.get("sensitive"),           "route": (LOCAL,  "occamy-35b")},
    {"when": lambda t: t["type"] == "batch_nightly", "route": (LOCAL,  "occamy-35b")},
    {"when": lambda t: t["type"] == "search_agent",  "route": (LOCAL,  "iris-35b")},
    {"when": lambda t: t["type"] == "hard_plan",     "route": (CLOUD,  "flagship-model")},
]


def dispatch(task: dict) -> dict:
    for rule in ROUTE_TABLE:
        if rule["when"](task):
            provider, model = rule["route"]
            break
    else:
        provider, model = CLOUD, "mid-tier-model"    # 默认走云端中档

    try:
        resp = provider.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": task["prompt"]}],
            temperature=0,
        )
        return {"answer": resp.choices[0].message.content,
                "channel": "local" if provider is LOCAL else "cloud",
                "model": model}
    except Exception:
        if provider is LOCAL:                        # 本地故障：云端同档兜底
            resp = CLOUD.chat.completions.create(
                model="mid-tier-model",
                messages=[{"role": "user", "content": task["prompt"]}],
                temperature=0,
            )
            return {"answer": resp.choices[0].message.content,
                    "channel": "cloud_fallback", "model": "mid-tier-model"}
        raise

三处实现要点。第一，路由表用谓词函数集中定义，每个条件的含义写在注释里，半年后接手的人不用考古。第二，本地到云端的兜底是同档位兜底，不是降级到轻量档——数据敏感任务宁可临时多花 API 钱，也不把内容路由到不对的模型档上。第三，channel 字段逐条落库，月底把本地摊销成本与云端账单画在同一张图上，利用率的临界点什么时候被突破，一目了然。

六、成本对比：一条真实负载曲线的账

以每天 800 万 token、其中六成负载集中在工作时段的画像为例（示例口径，实际以硬件牌价与账单为准）：

方案	月成本（估算）	数据出域	弹性
全 API（高性价比档）	中	是	最高
全自部署（按峰值配节点）	高（利用率不足四成）	否	差
混合（本地吃六成 + 云吃尖峰）	最低	敏感部分不出域	高

混合方案成本最低的原因是两侧各干擅长的事：本地节点按稳定基线配，利用率维持在七成上下；尖峰与长尾交给 API，不为百分之十的峰值多买百分之百的硬件。数据敏感任务留在本地是合规红利，不计进成本也值回票价。

七、成本与风险提示

第一条风险是把跑分当产能。公开基准的低成本拐点是评测口径下的结论，自己的任务分布要用自己的回归集重验一遍再决定迁移比例，尤其注意长任务与多轮任务上的衰减。

第二条风险是升级陷阱。开源模型迭代很快，升级推理框架或权重版本时，量化方案、上下文长度、接口行为都可能变。本地服务要有金丝雀实例，新版先在小流量上过一遍回归集再全量替换。

第三条风险是利用率幻觉。拿"峰值利用率"算自部署账是常见错误，账要按七日平均利用率算，夜间与周末的空转成本一分不少地摊进去。

红线不变：本地部署走官方发布的权重与许可条款，商用授权逐条核对；不做违反许可的转售与分发，敏感数据不出域的前提是内网本身治理到位。

八、上自部署前的自查清单

利用率已测算：按七日平均负载估临界点，低于数百万 token 日量先不建。
回归集已自建：用自己的任务分布验过成绩，不拿公开榜单直接当产能承诺。
路由表已集中：本地与 API 的分流条件写在一张配置里，可审计可回滚。
兜底链路已演练：本地故障切云端同档的路径定期演练，切换带标记。
许可已核对：权重许可、商用条款、分发限制逐条过，留档备查。
版本升级有金丝雀：新权重先小流量回归，再全量替换旧实例。

九、开源专有化的下一个信号

从通用 co-work 到 Search Agent 专用模型，开源阵营的专有化分工已经起步。对接入方，这个趋势的利用方式不是追每个新模型，而是把"专用能力"做成路由表里的一个条目：检索密集的任务路由给专用模型，执行型任务路由给 co-work 档，规划审查留给旗舰。模型层越分化，路由层的价值越大——这也是把接入架构沉淀在协议与路由上、而不是绑死在某一个模型名上的理由。下一次专有化浪潮来的时候，换的只是路由表里的一行。

十、总结

这一期想沉淀的结论是：35B 档开源模型把"执行型任务的低成本拐点"从 API 阵营复制到了自部署阵营，Occamy-1.0 的 co-work 成绩与 Iris 的检索专精分别占住了通用与专用两个位置。选型的分界线不在模型好坏，而在利用率曲线与数据敏感度：稳定高负载与敏感数据走本地，尖峰与长尾走 API，中间用统一协议和一张可解释的路由表缝合。我在 4sapi 接入的双通道客户里，账单最平的就是这类混合架构。对利用率临界点或路由条件的设计有不同经验，欢迎在评论区聊聊。