在决定将大模型落地到企业具体业务时，首先要面对的问题是：该如何选择基座模型？选择多大参数？需要重点关注模型的哪些能力？要回答这个问题，我们需要先理解一个大前提：
企业落地 LLM，本质上是把 LLM 当作“大脑”，通过它来规划并自主完成特定任务。在此之上，还需要追求极致的 TTFT（首字响应时间）与最小化的算力成本（资源占用）。
因此，企业在选择开源模型时，需重点关注当前业务场景下的具体能力需求。如：智能问答/知识库场景，与智能体（Agent）自动化调度场景，对模型的能力偏向有着不同的要求和容忍度。所以实际落地中通常不会只选择单一模型，而是采用“大小模型组合”的策略。
我们暂不讨论复杂的模型路由策略，而是聚焦到智能体（Agent）和自动化场景下，探讨其核心的基础能力——-这是当前企业落地 AI 应用最主流、覆盖最广的场景。
Table of contents
Open Table of contents
参数规模与资源的参考
8B - 14B 级别（轻量级执行层）
定位：极致的首字响应时间（TTFT）与极低的推理成本。
场景：适合高频、确定性强的单一任务，如意图路由、格式化数据抽取（JSON 输出）、基础 Agent 工具调用。
显存与并发参考：硬件门槛极低，单张消费级显卡（如 RTX 4090 24G）或单张 A10（24G）即可部署。在 INT4/8 量化下，模型仅占用 8-15G 显存，剩余显存全部分配给 KV Cache，单卡即可轻松支撑 30-50+ 的高并发请求而不明显掉速。
32B 级别（均衡选择）
定位：当前私有化部署的核心中枢。综合能力逼近上一代旗舰大模型，但在推理准确率和高并发吞吐量之间取得了最佳的 ROI（投资回报率）。
场景：担任常规 Agent 的核心调度节点，或作为企业知识库（RAG）的主力问答模型，处理绝大多数具备一定逻辑深度的业务。
显存与并发参考：建议采用单张 80G 显卡（如 A800）全精度运行，或双卡 24G 进行量化部署。在单节点 80G 显存环境下，预留充足 KV Cache 后，可稳定支撑 10-30 的中等并发，且延迟表现依然处于业务可接受范围内。
70B+ 级别（深度推理与规划）
定位：专攻复杂推理，但并发承载力弱、响应时延较高。
场景：绝对不适合作为高频调用的节点。通常隐藏在业务链路的最深处，专精于复杂 Multi-Agent 系统的前期“全局规划（Planning）”、事后的“纠错反思（Reflection）”或复杂代码生成。
显存与并发参考：硬件成本极高，通常需要 2 到 4 张 80G 显卡进行张量并行（TP）部署。由于模型参数量巨大，对显存带宽消耗极高，单节点的极限并发通常在 5-10 左右。一旦并发超过阈值，首字时延（TTFT）和生成速度会呈指数级恶化，因此只能作为“低频、高价值”的慢思考节点使用。
工具调用 (Function Calling / Tool Use)
LLM 是通过工具（Tools）调用来建立与外部服务（各种内部或第三方服务）的连接，它是 LLM 能自主跨系统跨业务完成任务的关键。可以通过业界权威的 Berkeley Function Calling Leaderboard 来查看各模型的基准测试能力。实际应用中，tools 的选择和调用会受到 system prompt 和 tools 描述的影响；工具选择的契合度和调用准确性会直接影响任务的完成度和失败率。对于单次调用的失败率应该小于 15%，重试纠错（Self-Correction）后应该小于 5%；如果高于这两个值，稳定性和失败率都将大大增高。
指令遵循
LLM 应用通过系统提示词来进行核心的业务规则的约束或安全性上的申明；在自动化场景下，还会涉及到极其严格的输出要求（比如：JSON，XML，Thought，Action），并且程序会对输出进行校验和解析，如果指令遵循在对话中失效（比如：遗忘了系统提示词约束，输出格式与约束的格式不一致），那么会引起下游的执行异常和失败。通用的指令遵循能力可以通过
IFEval，AgentIF,AdvancedIF来了解；实际应用中，开启 JSON Mode，结合 Schema 校验以及校验失败后二次重试，指令遵循失败率应该在 5% 以内。
推理与多步规划 (Reasoning & Multi-step Planning)
拥有推理与多步规划能力（Thinking）的模型由于具备较长的思维链（CoT），首字响应通常较慢，因此不适合直接用于高并发、低延迟的工具调用节点。在 Fast/Slow 架构中，思考模型更适合用于任务前的全局规划，通过详尽的思考和纠错，输出完整的执行计划（plan），然后由另外的非思考模型进行具体的执行，这样能在速度和资源上取得一个相对合理的平衡。通常经验是，当对准确性和完整性要求比较高而对时延要求不那么高的场景需要优先选择思考模型，比如：调研报告的信源对比、研究框架设计、数学与代码。
长上下文处理 (Long Context & NIAH)
长上下文处理能力决定了模型在智能体（Agent）多步调度与企业知识库（RAG）场景下的稳定性与准确度。
在 Agent 自动化工作流中，模型需要时刻承载庞大的上下文信息，包括预设的海量工具 API 描述（System Prompt）、多轮任务执行历史（History），以及外部工具返回的非结构化长文本结果（Observation）。而在知识库问答场景下，模型通常需要一次性摄入并分析由检索引擎召回的大量文档切片（Chunks）。
如果基座模型在长文本下的注意力机制衰减严重，或在“大海捞针（NIAH, Needle In A Haystack）”测试中准确率不佳，会直接导致“上下文失忆”。这在 Agent 场景中表现为中途遗忘初始任务目标或漏掉关键参数；在 RAG 场景中则表现为“无视”已正确召回的关键文档，从而引发幻觉或漏答。
在选择模型时，针对涉及知识库问答或复杂链路调度的业务节点，基座模型的有效上下文窗口（Effective Context Window）应至少能够无损支撑 32K 乃至 128K 的输入长度。
总结
通常在企业落地大语言模型时，并不会选择单一的模型，而是会部署多个不同参数不同类型的模型来应对不同场景。比如有知识库需求则需要用到向量模型（Embedding Models），应用会根据需要把不同任务分配到不同的模型上来达到资源、速度、质量的相对平衡。模型选择的本质是在有限资源下对模型能力的取舍。被选中的模型也不是一劳永逸，随着业务和场景迭代，应该时刻关注资源利用率、模型在业务上的表现，用足够的可量化的数据来为模型选择和迭代做支撑。