团队里有人提了一句「要不咱们自己搭个编码助手」，然后就卡在第一步：到底要几张什么卡、显存够不够、几个人同时用会不会崩。这篇不讲该不该自建，只讲要落地需要满足哪些硬条件，以及怎么从「几个人用、写多长的代码」倒推回显卡和量化档位。
团队里有人提了一句「要不咱们自己搭个编码助手」，然后就卡在第一步：到底要几张什么卡、显存够不够、几个人同时用会不会崩。这篇不讲该不该自建，只讲要落地需要满足哪些硬条件，以及怎么从「几个人用、写多长的代码」倒推回显卡和量化档位。
先说一句实话：自建编码助手不是买一张卡插上就完事，它更像一个小型在线服务，硬件、显存、并发、许可四样里任意一样没算清，上线当天就会暴露。下面按落地顺序拆开讲，每一步都给能直接照着做的动作。
先定任务边界，再谈硬件
很多人一上来就问「跑得动多大模型」，这顺序反了。先写清楚这个助手要干什么：是补全单行代码、解释整个仓库，还是能自己改多文件。任务不同，对上下文长度和推理速度的要求差一个量级，硬件预算也跟着差一个量级。
| 需求维度 | 要写清楚的内容 | 写不清的后果 |
|---|---|---|
| 并发人数 | 同时有几个人在提问 | 按单人估配置，上线就排队 |
| 单次代码量 | 一次贴进去多少行或多少文件 | 上下文给短了，长文件直接截断 |
| 等待容忍度 | 用户能接受几秒出第一个字 | 体验指标没定，没法验收 |
| 使用时段 | 全天挂机还是偶尔用 | 全天占用对显存和散热要求更高 |
- 并发人数按「同时活跃」算，不是按团队总人数算，十个人的团队可能常态只有两个人挂着。
- 单次代码量要留余量，解释一个中等仓库比补全一行多消耗的上下文是数量级差别。
- 等待秒数建议按场景分档，交互式补全要快，整仓分析慢一点通常能接受。
- 这三列定不下来，后面选卡就是瞎猜，先去 /ai-dict/category/basics 把 Token 和上下文的换算对一遍再继续。
显存与量化：真正卡死你的那一项
显存要同时装下模型权重、KV 缓存和运行时开销，三部分缺一不可。权重按参数量和量化档位估，KV 缓存按上下文长度乘并发数估。只算权重就会得出「明明装得下却一并发就爆」的结论，这在自建编码助手里是最常见的翻车方式。
- 模型权重
- 参数乘以每个参数的字节数，量化档位越低占得越少。
- KV 缓存
- 随上下文长度和并发数线性增长，长代码场景下它经常比权重还吃显存。
- 运行时开销
- 框架自身的缓冲与临时张量，估算时要留出一块固定余量。
- 量化档位
- 显存和质量的交换，档位越低越省显存，代码任务对精度比较敏感。
量化档位是显存和质量的交换。档位越低越省显存，但代码这类任务对精度比较敏感，掉档之后容易出现语法对、逻辑飘的情况。同一个模型，量化档位换一档，能塞进的并发数和上下文长度就换一个量级，所以「跑得动」和「够用」是两件事，别混着说。
卡的选择：显存之外的三个约束
显存是硬门槛，但它不是唯一约束。选卡时至少还要看三件事：单卡显存上限、显存带宽、整机可扩展性。这三项决定了你以后是加卡还是整台换掉，差别很大。
- 单卡显存上限：模型塞不进一张卡就要做张量并行，跨卡通信会吃掉一部分吞吐，配置复杂度也上一个台阶。
- 显存带宽：同一个模型，带宽高的卡出字更快，直接影响「等几秒」这个体验指标能不能达标。
- 整机可扩展性：主板插槽、供电、散热这些不起眼的东西，决定了你以后能不能加卡。
- 功耗与散热：多卡长时间跑推理的发热量容易被低估，机箱和机房要先想好。
消费卡和专业卡的差别主要在显存容量、带宽和能不能做多卡互联，不是单纯的快慢问题。哪些卡真能租到、哪些已经在机房常见，去 /compute/gpus 和 /compute/domestic 看当下的规格与渠道，别按半年前的印象下单。
并发与推理框架：决定体验的那一半
自建最容易踩的坑是「单机能跑」被当成「团队能用」。多个人同时提问时，请求会在队列里排队，延迟是叠加的，不是平均分摊。一个人测着飞快，五个人用就变成转圈，问题通常不在卡，而在并发估算和服务框架的批处理策略。
- 定单人延迟上限先按交互场景定一个可接受的出字速度，用它反推单卡能稳定服务的并发数，别用跑分当依据。
- 乘卡数再打折单卡并发乘卡数得到理论上限，然后至少留三成余量给长上下文请求，长请求会暂时占掉更多显存。
- 选框架再配卡推理框架的批处理策略直接影响吞吐，同样硬件框架选错可能少带一半并发，所以框架要和卡一起选。
- 压测验证用接近真实的请求长度和并发数跑一轮，看排队时间和显存峰值，别只跑短请求。
这套估算口径在 /compute/sizing 有现成的算法，配合 /ai-dict/category/infra 把吞吐、批处理、首字延迟这些词对上号再动手。术语不统一，很容易和采购或运维各说各话。
许可证与长期维护：别只看能不能跑
权重能不能商用、能不能改、改了要不要开源，每个模型条款不一样，团队内部用和对外交付也是两回事。如果这个助手要接公司内网代码库，还要确认数据不出内网的边界，以及日志、审计这些配套怎么落。这两项没有统一答案，但至少在下单前把条款逐条读一遍，别等到交付前才发现不能商用。
| 检查项 | 要确认的问题 | 不适用的情况 |
|---|---|---|
| 商用许可 | 权重和输出能不能用于对外产品 | 纯内部试验阶段可以后置 |
| 修改与再分发 | 改了要不要开源、能不能转手 | 自己用不外发时约束较松 |
| 数据边界 | 代码和日志是否离开内网 | 全离线部署且不接外部服务时风险低 |
| 运维成本 | 电费、散热、人力、换模型迁移 | 用云租卡时部分成本转为账单 |
硬件只是启动成本，后面还有电费、散热、运维人力和换模型时的迁移成本，都要在预算表里留位置。换模型不是换个文件那么简单，量化档位、上下文长度、推理框架往往要跟着调，这部分工作量要提前算进去。
自建编码助手的门槛不在「能不能跑起来」，而在「五个人同时用、贴进去一整仓代码、还能在可接受时间内出结果」。下一步把并发人数、单次代码量、可接受等待秒数这三项填进需求表，再去模型部署估算页和显卡规格页对照一遍，你会立刻看出自家预算卡在哪一环。→
常见问题
我们团队就三五个人，是不是随便一张消费卡就够了？
不一定。关键看两件事：模型能不能塞进单卡显存，以及三五个人同时提问时延迟会不会排队。模型小、每人问得零散，一张盘大的消费卡可能就够；但只要开始贴整仓库代码进去，显存和上下文需求会立刻跳一档。建议先按任务边界估一遍再决定，别按人数估。
显存不够，是加卡还是降量化档位？
优先判断缺口在哪：如果只是权重装不下，降一档量化往往最省钱；如果是并发一上来就爆，那是 KV 缓存的账，降量化帮助有限，得考虑加卡或缩短单次上下文。加卡也不是无脑加，模型跨卡就要配张量并行，配置和调试成本会上去，通常先优化量化档位和上下文策略更划算。
自建之后还要不要担心许可证和合规问题？
要，而且这块比硬件更容易被忽略。权重能不能商用、改完要不要开源、内部使用和对外交付的边界，各家条款不同，团队自用和拿去做产品是两件事。另外要确认代码和数据是否真的不出内网，以及日志审计怎么留。这些在下单前逐条读完，比事后返工便宜得多。
