百度内部组织架构最近出现一个值得关注的变动——基础模型研发部（BMU）和应用模型研发部（AMU）统一向新设立的百度模型委员会（Baidu Model Committee，BMC）汇报。委员会成员由年轻且对大模型有深刻理解的研究员组成，核心目标是集中优势资源，持续强化 AI 方向的技术壁垒。
这不是一次简单的管理层调整。当基础模型和下游应用模型分属不同汇报线时，资源争夺、方向分歧、重复投入几乎是必然结果。BMC 的出现，本质上是给大模型研发装了一个"中央调度器"。
为什么需要模型委员会
大模型研发的组织难题，百度不是第一个面对的。行业里普遍存在两类矛盾：
基础模型与应用模型的节奏冲突。 基础模型团队追求通用能力和长线指标，应用模型团队要的是快速适配和场景落地。两条线各自汇报时，优先级谈判往往变成零和博弈——算力给谁、数据给谁、发布窗口谁先占。
技术决策的碎片化。 模型架构选型、训练策略、评测标准，如果每个团队各自定义，很快就会出现"同一公司内两套模型用两套评测体系"的尴尬。对外无法形成统一技术叙事，对内无法复用关键组件。
BMC 把两条线的汇报关系收拢到同一个决策节点，意味着资源分配、技术路线、发布节奏都可以在委员会层面统一裁定，而不是靠部门间的横向协商。
年轻研究员做委员：能力优先还是资历优先？
一个有意思的细节：BMC 成员强调"年轻"和"对大模型有深刻理解"。这背后反映的是大模型领域的一个现实——真正理解 Transformer 架构演进、训练工程细节、Scaling Law 实践的人，往往不是传统意义上的"资深管理者"，而是近两三年深度参与模型研发的一线工程师和研究员。
用能力而非资历做决策权分配，在大模型赛道上是合理的。这个领域变化太快，两年前的经验可能已经失效，决策者必须对当前技术前沿有直接感知。
从组织架构到工程实践：模型研发的集中调度怎么做
组织层面的集中调度只是第一步，工程层面同样需要一套机制把"委员会决策"落地为可执行的流程。下面给出一个模型研发流水线的配置示例，模拟 BMC 统一调度下基础模型与应用模型的协作方式。
用 YAML 定义模型研发流水线
这个示例展示如何用一份配置文件统一管理基础模型训练、评测、应用模型微调的依赖关系和资源分配——对应 BMC 在组织层面要解决的问题。
# bmc-pipeline.yaml — 百度模型委员会统一调度流水线配置
# 实际使用时可接入 CI/CD 系统（如 GitLab CI、Argo Workflows 等）
pipeline:
name: bmc-model-dev
version: "1.0"
description: "BMC 统一调度：基础模型 → 评测 → 应用模型微调"
# 全局资源池，由 BMC 统一分配
resources:
gpu_pool:
total_a100: 256
allocation:
bmu_foundation: 160 # 基础模型训练占 62.5%
amu_application: 96 # 应用模型微调占 37.5%
# BMC 可按阶段动态调整比例
dynamic_rebalance: true
stages:
# 第一阶段：基础模型训练（BMU 负责）
- id: foundation_train
owner: BMU
trigger: manual # BMC 审批后启动
config:
base_model: "ernie-4.5-base"
dataset: "baidu-corpus-v3"
training:
epochs: 3
batch_size: 2048
learning_rate: 1e-4
scheduler: "cosine_with_warmup"
warmup_steps: 2000
checkpoint:
save_every_n_steps: 5000
push_to_registry: true # 产出模型自动推入内部 registry
# 第二阶段：统一评测（BMC 主持）
- id: unified_eval
owner: BMC
depends_on: [foundation_train]
config:
benchmarks:
- c-eval
- mmlu
- humaneval
- baidu_internal_bench_v2
gate:
# 评测门槛：达不到则不进入下一阶段
min_mmlu: 72.0
min_humaneval: 45.0
min_ceval: 80.0
# 第三阶段：应用模型微调（AMU 负责）
- id: application_finetune
owner: AMU
depends_on: [unified_eval]
config:
scenarios:
- name: "search_augmented"
dataset: "search-query-v2"
method: "lora"
lora_rank: 64
epochs: 2
- name: "content_generation"
dataset: "writing-style-v1"
method: "lora"
lora_rank: 32
epochs: 1
- name: "code_assistant"
dataset: "baidu-code-corpus-v1"
method: "full_finetune"
epochs: 2
base_model_from: foundation_train # 自动引用基础模型产出
# 发布审批：BMC 最终把关
release_gate:
owner: BMC
require_eval_pass: true
require_safety_review: true
max_concurrent_releases: 2 # 避免发布窗口冲突
使用方式： 将此 YAML 作为模型研发平台的配置输入，配合内部调度系统执行。关键设计点：
- 资源池统一分配——GPU 不再由 BMU 和 AMU 各自抢占，BMC 按阶段动态调整比例。
- 依赖链强制顺序——应用模型微调必须等基础模型评测通过，避免在未验证的底座上浪费算力。
- 统一评测门槛——一套 benchmark、一套标准，两条线不再各自定义"好模型"。
- 发布审批集中——BMC 控制发布窗口，防止基础模型和应用模型撞车发布。
实际落地时，可以把这份配置接入 Argo Workflows 或类似系统，每个 stage 映射为一个 Workflow Step，depends_on 变成 DAG 依赖，gate 条件变成分支判断。
组织调整的边界与风险
BMC 的架构调整解决了集中调度问题，但也引入新的风险：
- 决策瓶颈。 所有重大路线选择都经过委员会，如果 BMC 运转效率低，反而比两条线各自决策更慢。委员会规模和议事规则需要明确。
- 应用响应速度。 AMU 向 BMC 汇报后，场景侧的紧急需求（比如竞品发布后的快速跟进）能否获得足够优先级？如果基础模型排期占满，应用层可能被拖慢。
- 年轻委员的管理经验。 技术判断力强不等于组织协调能力强。BMC 需要配套的运营机制，否则容易变成"技术讨论会"而非决策机构。
这些风险不是否定 BMC 的理由，但需要在落地过程中持续观察和调整。
给大模型团队的组织建议
如果你所在的公司也在经历类似的模型研发组织调整，可以参考以下清单：
- 统一评测体系先行。 在调整汇报线之前，先让两条线用同一套 benchmark 评测模型。没有统一度量，集中调度就没有依据。
- 委员会人数控制在 5-7 人。 超过这个规模，决策效率会明显下降。确保委员中有基础模型和应用模型两方代表。
- 明确委员会的决策范围。 哪些事项必须经过 BMC（架构选型、算力分配、发布审批），哪些事项团队可自行决定（微调策略、数据清洗细节），边界要清晰。
- 设置动态资源分配机制。 不要用固定比例分配算力，按阶段和优先级动态调整，才能应对突发需求。
- 保留应用层的快速通道。 为紧急场景需求设立加速审批流程，避免所有需求都走完整委员会周期。
百度的 BMC 是大模型进入深水区后组织形态的一次实验。技术壁垒不只是模型参数和训练数据，也包括研发组织能否高效地把资源转化为产出。这次调整的效果，值得持续跟踪。